イベント記録
最終更新日: 20 年 2024 月 XNUMX 日Dexda エージェントは、サポートされているイベント ソースから受信および/または送信されたイベントを処理し、それらを Common Event Format (CEF) に正規化します。 CEF イベントは Dexda にストリーミングされ、そこですぐにイベント管理プロセスに入ります。イベント処理が完了すると、イベントはデータベースに保存され、イベント インデックスを通じてクエリできるようになります。
イベント記録フォーマット
次の表では、各イベント フィールドと、Dexda CEF にマップされた対応する LM ソース データについて説明します。
コラム | 説明 | LM アラート フィールドのマッピング |
_id | データベース レコードの ID。 | – |
Time | ソース イベントの UTC タイムスタンプの文字列表現。 | – |
ソース | イベントが生成された監視/管理ツール、アプリケーション、ログ、または API。 | ロジックモニター (文字列) |
名前 | 報告されたイベントの名前。たとえば、 ディスク容量不足 or 高い CPU 使用率. | データポイント.データソース |
重大度 | イベントの重大度の数値。5 は重大です。4 は重大です。 3 はマイナーです。 2 は警告です。 1 は不定です。 0 はクリアです。イベントごとに実行されるデフォルトのアラート処理アクション グループは、受信したイベントに基づいて変更のステータスをアクティブとクリアの間で自動的に遷移するようにプログラムされています。 | 重大度 LM アラートの重大度は、Critical 5 (重大)、Error 4 (重大)、Warning 2 (警告)、SDT 1 (中間)、Clear 0 (クリア) など、Dexda の数値重大度にマップされます。 |
CI | イベントが報告される構成アイテム (サーバーまたはルーターのホスト名など)。 | リソース |
オブジェクト | イベントが関係する CI 上のオブジェクト (ディスク、データベース インスタンス、CI 自体など)。 | インスタンス |
説明 | イベントの簡単な要約。 | 詳細な説明 |
詳細 | イベントの詳細な要約。フィールドのメタ グループは、イベント レシーバー サービスによって設定されます。 | – |
テナントID | LM テナント識別子 | システム.テナント識別子 |
パイプラインのタイムスタンプ | パイプラインのタイムスタンプ | – |
スタンプ | ソース イベントの UTC タイムスタンプ。 | 報告日 / 清算日 |
組織ID | 内部データ | – |
受信者ID | 内部データ | – |
受信者のタイムスタンプ | 内部データ | – |
トリガーされたルールの数 | トリガーされたルールの数 | – |
トリガーされたルール ID リスト | トリガーされたルール ID のリスト | – |
内部データ | – | |
ソースレコード | 内部データ | – |
エージェントID | 内部データ | – |
エージェント CI | 内部データ | – |
エージェント IP | 内部データ | – |
エージェントのタイムスタンプ | 内部データ | – |