この記事では、Linuxの Defender for Endpoint に関連するパフォーマンスの問題を絞り込む方法について説明します。 診断ツールは、パフォーマンスに影響を与える既存のリソース不足とプロセスを理解して軽減するのに役立ちます。 これらの診断ツールを使用して、Microsoft Defender ポータル内の可視性を高めることもできます。 1 つ以上のハードウェア サブシステムのボトルネックは、主にシステム上のリソース使用率のプロファイルに応じてパフォーマンスの問題を引き起こします。 場合によっては、アプリケーションがディスク I/O リソースに敏感であり、CPU 容量が増える必要がある場合や、一部の構成が持続可能でない場合や、新しいプロセスが多すぎるトリガーやファイル記述子のオープンが多すぎる場合があります。
実行中のアプリケーションとデバイスの特性によっては、Linuxで Defender for Endpoint を実行するときに最適でないパフォーマンスが発生する場合があります。 特に、CPU、ディスク、メモリなどの多くのリソースに短時間でアクセスするアプリケーションまたはシステム プロセスは、Linuxの Defender for Endpoint のパフォーマンスの問題につながる可能性があります。
警告
開始する前に、 他のセキュリティ製品が現在デバイス上で実行されていないことを確認してください。 複数のセキュリティ製品が競合し、ホストのパフォーマンスに影響を与える可能性があります。
LinuxのMicrosoft Defender for Endpointから診断ツールを使用して、ノイズの多いプロセスとディレクトリをトラブルシューティングするには、次の 3 つの異なる方法があります。
- リアルタイム保護統計の使用
- ホット イベント ソースの使用
- eBPF 統計の使用
リアルタイム保護統計を使用したパフォーマンスの問題のトラブルシューティング
適用対象:
- ウイルス対策に関連するパフォーマンスの問題のみ
リアルタイム保護 (RTP) は、脅威からデバイスを継続的に監視および保護する、Linux上の Defender for Endpoint の機能です。 ファイルとプロセスの監視とその他のヒューリスティックで構成されます。
次の手順を使用して、これらの問題のトラブルシューティングと軽減を行うことができます。
次のいずれかの方法を使用してリアルタイム保護を無効にし、パフォーマンスが向上するかどうかを確認します。 このアプローチは、Linuxの Defender for Endpoint がパフォーマンスの問題に貢献しているかどうかを絞り込むのに役立ちます。 デバイスがorganizationによって管理されていない場合は、コマンド ラインからリアルタイム保護を無効にすることができます。
mdatp config real-time-protection --value disabledConfiguration property updatedorganizationがデバイスを管理している場合、管理者は「Linuxで Defender for Endpoint の基本設定を設定する」の手順を使用して、リアルタイム保護を無効にすることができます。
注:
リアルタイム保護がオフになっている間にパフォーマンスの問題が解決しない場合、問題の原因はエンドポイント検出と応答 (EDR) コンポーネントである可能性があります。 この場合は、ウイルス対策と EDR からグローバル除外を追加する必要があります。 この場合は、「 ホット イベント ソースを使用したパフォーマンスの問題のトラブルシューティング」セクションの手順に従います。
最も多くのスキャンをトリガーしているアプリケーションを見つけるには、Linuxで Defender for Endpoint によって収集されたリアルタイム統計を使用できます。
注:
この機能は、バージョン 100.90.70 以降で使用できます。
この機能は、
DogfoodおよびInsiderFastチャネルで既定で有効になっています。 別の更新チャネルを使用している場合は、コマンド ラインからこの機能を有効にすることができます。mdatp config real-time-protection-statistics --value enabledこの機能では、リアルタイム保護を有効にする必要があります。 リアルタイム保護の状態をチェックするには、次のコマンドを実行します。
mdatp health --field real_time_protection_enabledreal_time_protection_enabledエントリがtrueされていることを確認します。 それ以外の場合は、次のコマンドを実行して有効にします。mdatp config real-time-protection --value enabledConfiguration property updated現在の統計を収集するには、次を実行します。
mdatp diagnostic real-time-protection-statistics --output json注:
--output json(二重ダッシュに注意) を使用すると、出力形式を解析する準備が整います。このコマンドの出力には、すべてのプロセスとそれに関連するスキャン アクティビティが表示されます。
次のコマンドを入力します。
mdatp diagnostic real-time-protection-statistics --sort --top 4出力は、パフォーマンスの問題に対する上位 4 つの共同作成者の一覧です。 たとえば、コマンドの出力は次のようになります。
===================================== Process id: 560 Name: NetworkManager Path: "/usr/sbin/NetworkManager" Total files scanned: 261 Scan time (ns): "3070788919" Status: Active ===================================== Process id: 1709561 Name: snapd Path: "/snap/snapd/23545/usr/lib/snapd/snapd" Total files scanned: 247 Scan time (ns): "19926516003" Status: Active ===================================== Process id: 596 Name: systemd-logind Path: "/usr/lib/systemd/systemd-logind" Total files scanned: 29 Scan time (ns): "716836547" Status: Active ===================================== Process id: 1977683 Name: cupsd Path: "/usr/sbin/cupsd" Total files scanned: 20 Scan time (ns): "985110892" Status: Active =====================================Linuxでの Defender for Endpoint のパフォーマンスを向上させるには、
Total files scanned行の下に最も多い番号の Defender for Endpoint を見つけて、ウイルス対策の除外を追加します (除外しても安全かどうかを慎重に評価します)。 詳細については、「Linuxでの Defender for Endpoint の除外の構成と検証」を参照してください。注:
アプリケーションは、統計をメモリに格納し、ファイル アクティビティが開始され、リアルタイム保護が有効になってからのみ追跡します。 リアルタイム保護がオフだった前または期間中に起動されたプロセスはカウントされません。 さらに、スキャンをトリガーしたイベントのみがカウントされます。
ホット イベント ソースを使用したパフォーマンスの問題のトラブルシューティング
適用対象:
- ファイルシステム全体でほとんどの CPU サイクルを消費しているファイルと実行可能ファイルのパフォーマンスの問題。
ホット イベント ソースは、お客様がリソース消費量が多いプロセスまたはディレクトリを特定できる機能です。 最もノイズが発生しているプロセス/実行可能ファイルを調査するには、次の手順に従います。
注:
これらのコマンドでは、ルートアクセス許可が必要です。 sudo を使用できることを確認します。
まず、コンピューターのログ レベルをチェックします。
mdatp health --field log_level
"デバッグ" にない場合は、ホット ファイル/実行可能ファイルに関する詳細なレポートのために変更する必要があります。
sudo mdatp log level set --level debug
Log level configured successfully
現在の統計 (ファイルの場合) を収集するには、
sudo mdatp diagnostic hot-event-sources files
出力はコンソールの次のようになります (これは出力全体のスニペットにすぎません)。 ここでは、最初の行はカウント (出現頻度) を示し、2 番目の行はファイル パスを示します。
Total Events: 11179 Time: 12s. Throughput: 75.3333 events/sec.
=========== Top 684 Hot Event Sources ===========
count file path
2832 /mnt/RamDisk/postgres_data/pg_wal/0000000100000014000000A5
632 /mnt/RamDisk/postgres_data/base/635594/2601
619 /mnt/RamDisk/postgres_data/base/635597/2601
618 /mnt/RamDisk/postgres_data/base/635596/2601
618 /mnt/RamDisk/postgres_data/base/635595/2601
616 /mnt/RamDisk/postgres_data/base/635597/635610
615 /mnt/RamDisk/postgres_data/base/635596/635602
614 /mnt/RamDisk/postgres_data/base/635595/635606
514 /mnt/RamDisk/postgres_data/base/635594/635598_fsm
496 /mnt/RamDisk/postgres_data/base/635597/635610_fsm
このコマンドは、さらに調査できるローカル フォルダーに保存されるホット イベント ソース レポートを生成します。 json ファイルの出力は次のようになります。
{
"startTime": "1729535104539160",
"endTime": "1729535117570766",
"totalEvent": "11373",
"eventSource": [
{
"authCount": "2832",
"csId": "",
"notifyCount": "0",
"path": "/mnt/RamDisk/postgres_data/pg_wal/0000000100000014000000A5",
"pidCount": "1",
"teamId": ""
},
{
"authCount": "632",
"csId": "",
"notifyCount": "0",
"path": "/mnt/RamDisk/postgres_data/base/635594/2601",
"pidCount": "1",
"teamId": ""
}
]
}
この例では、ファイル /mnt/RamDisk/postgres_data/pg_wal/0000000100000014000000A5が最も多くのアクティビティを生成していることがわかります。 また、実行可能ファイルの場合も同様に、
sudo mdatp diagnostic hot-event-sources executables
出力は、コンソールの次のようになります。
Total Events: 47382 Time: 18s. Throughput: 157 events/sec.
=========== Top 23 Hot Event Sources ===========
count executable path
8216 /usr/lib/postgresql/12/bin/psql
5721 /usr/lib/postgresql/12/bin/postgres (deleted)
3557 /usr/bin/bash
378 /usr/bin/clamscan
88 /usr/bin/sudo
70 /usr/bin/dash
30 /usr/sbin/zabbix_agent2
10 /usr/bin/grep
8 /usr/bin/gawk
6 /opt/microsoft/mdatp/sbin/wdavdaemonclient
4 /usr/bin/sleep
これは、json のホット イベント ソース レポートに保存された出力です。
{
"startTime": "1729534260988396",
"endTime": "1729534280026883",
"totalEvent": "48165",
"eventSource": [
{
"authCount": "8126",
"csId": "",
"notifyCount": "0",
"path": "/usr/lib/postgresql/12/bin/psql",
"pidCount": "2487",
"teamId": ""
},
{
"authCount": "5127",
"csId": "",
"notifyCount": "0",
"path": "/usr/lib/postgresql/12/bin/postgres",
"pidCount": "2144",
"teamId": ""
}
]
}
この例では、18 秒後に、 コマンドは実行可能ファイルを示しています。/usr/lib/postgresql/12/bin/psql と /usr/lib/postgresql/12/bin/postgres は最も多くのアクティビティを生成します。
調査が完了したら、ログ レベルを "info" に戻すことができます。
sudo mdatp log level set --level info
Log level configured successfully
Linuxでの Defender for Endpoint のパフォーマンスを向上させるには、カウント行で最も多いパスを見つけ、グローバル プロセスの除外 (実行可能ファイルの場合) またはグローバル ファイル/フォルダーの除外 (ファイルの場合) を追加します (除外しても安全かどうかを慎重に評価します)。 詳細については、「Linuxでの Defender for Endpoint の除外の構成と検証」を参照してください。
eBPF 統計を使用したパフォーマンスの問題のトラブルシューティング
適用対象:
- システム呼び出しベースのパフォーマンスの問題を含むすべてのファイル/プロセス イベント。
eBPF (拡張バークレイ パケット フィルター) 統計コマンドは、最も多くのファイル イベントを生成している上位のイベント/プロセスとその syscall ID に関する分析情報を提供します。 システムからシステム呼び出しが行われると、システムに大量のワークロードが生成されます。 eBPF 統計を使用して、そのような問題を特定できます。
eBPF 統計を使用して現行統計を収集するには、以下を実行します。
mdatp diagnostic ebpf-statistics
出力はコンソールに直接表示され、次のようになります (これは出力全体のスニペットにすぎません)。
Top initiator paths:
/usr/lib/postgresql/12/bin/psql : 902
/usr/bin/clamscan : 349
/usr/sbin/zabbix_agent2 : 27
/usr/lib/postgresql/12/bin/postgres : 10
Top syscall ids:
80 : 9034
57 : 8932
60 : 8929
59 : 4942
112 : 4898
90 : 179
87 : 170
119 : 32
288 : 19
41 : 15
このコマンドは、システムを 20 秒間監視し、結果を表示します。 最上位のイニシエーター パス (postgresql/12/bin/psql) には、ほとんどのシステム呼び出しを生成したプロセスのパスが示されています。
Linuxでの Defender for Endpoint のパフォーマンスを向上させるには、Top initiator path行でcountが最も高いものを見つけて、グローバル プロセスの除外を追加します (除外しても安全かどうかを慎重に評価します)。 詳細については、「Linuxでの Defender for Endpoint の除外の構成と検証」を参照してください。
パフォーマンスを向上させるためにグローバル除外を構成する
パフォーマンスの問題に影響を与えるプロセスまたはディスクの場所を除外して、LinuxのMicrosoft Defender for Endpointを構成します。 詳細については、「Linux 用の Microsoft Defender for Endpoint の除外を構成および検証する」 を参照してください。 それでもパフォーマンスの問題が解決しない場合は、詳細な手順と軽減策についてサポートにお問い合わせください。