イベント管理 構成設定

  • リリースバージョン: Xanadu
  • 更新日 2024年08月01日
  • 所要時間：14分

    • プロパティと全般的な構成の優先設定です。

    既知のエラーポータルとコミュニティを利用すると、問題に関する情報を見つけやすくなります。

    全般設定

    セルフ健全性
    デフォルトでは、セルフヘルスモニタリング機能は有効になっていません。有効にするには、 イベント管理 > 設定 > プロパティ をクリックし、Enable Event Management self-health monitoring (evt_mgmt.self_health_active) プロパティで [はい] を選択します。この機能を使用すると、イベント管理 の多くの機能を監視および追跡できます。
    注:
    セルフ健全性サービスで使用される CI は、CMDB 内で作成されます。
    次の設定を使用すると、パフォーマンスデグレードを防止できるようになります。
    トピック 詳細
    ビジネスルール
    • イベント挿入に使用される現在のデフォルトの REST URL では実行されないため、イベント [em_event] テーブルのビジネスルールを記述することは避けてください。
    • アラート [em_alert] テーブルに対して記述されるビジネスルールは、非常に効率的である必要があります。そうしないと、パフォーマンスの低下を招くおそれがあります。ビジネスルールを記述する代わりに、ジョブを作成する方が適切かどうかを検討してください。非効率的なビジネスルールでは、アラートのインシデントを作成できず、アラートのインパクトカリキュレーションに失敗するおそれがあります。
    • アラートテーブルに対しては、非同期ビジネスルールを作成しないでください。
    • ビジネスルールでは、イベント [em_event] テーブルの [カテゴリ] フィールドを変更してはいけません。
    スケールアップ イベント管理 を使い始めるときは、イベントのスループットを高める前に、平均イベント処理時間をチェックしてください。このチェックは、イベントの初期フローとすべてのルールが適用された後に実行します。処理時間がイベントあたり数ミリ秒以上かかる場合は、スケールアップを続行する前に処理速度低下の原因を特定します。パフォーマンス期間は、パフォーマンス統計情報 [sa_performance_statistics] テーブルで確認できます。
    大規模環境向けの設定
    • [マルチノードイベント処理を有効化] (evt_mgmt.event_processor_enable_multi_node) プロパティを [はい]に設定します。

      本番環境でマルチノードを有効にし、展開規模と予想されるイベントレートに基づいて値を設定します。

    • [イベントを処理するスケジュール済みジョブの数] (evt_mgmt.event_processor_job_count) プロパティを「4」に設定します。
    • カスタムソースからイベントを送信する場合は、イベントにメッセージキーまたはソース、ノード、タイプ、およびリソースのデータが含まれていることを確認します。
    イベント受信の待機時間の問題 次の設定を確認します。
    • イベント [em_event] テーブルの [バケット] フィールドがゼロ (0) より大きい値に設定されていることを確認します。
    • 移動先 システムスケジューラ > スケジュール済みジョブ 「 - process events*」を検索します

      [イベントを処理するスケジュール済みジョブの数] (event_processor_job_count) プロパティ設定に従って、すべての - process events* ジョブが存在することを確認します。[ステータス] が「Running」または「Ready」であることを確認します。ステータスが「Queued」または「Error」である場合は、ジョブのステータスを「Ready」に設定します。
    イベントのアーカイブ
    • イベントのデフォルト保持期間を変更しないようにします。
    • イベントをログに長期間記録するには、アーカイブテーブル、およびそこに新しいイベントをコピーするジョブを作成します。これを行うには、イベント [em_event] テーブルをカスタムテーブルに定期的にバックアップするジョブをスケジュールします。
    • 日数を追加してテーブルローテーションを延長しないでください。

    イベントデータ連携

    SNMP トラップ
    • デバイスから直接送信するのではなく、監視ツールを使用して SNMP トラップを送信します。
    • イベントルールを書き直さなくてもよいようにするには、イベントルールを定義する前に MIB をアップロードします。
    Web サービス API
    • データ連携用の Web サービス API を使用すると、必要なイベントルールの数を減らすことができます。このアクションにより、イベントを変換する必要がなくなります (準備されたデータはイベントでインスタンスに送信されます)。
    • データ連携には、専用の認証情報を使用します。必要に応じて、各イベントソースに固有の認証情報を指定します。
    CloudWatch
    CloudWatch と ServiceNow のデータ連携には、専用の認証情報を使用します。
    メール
    ソースのボリュームが少なく、他のオプション (スクリプトの実行や SNMP トラップの転送など) が利用できない場合にのみ、メールを使用します。
    イベントルール
    イベントルールを作成するときの構成設定：
    • 可能な限り広範囲のイベントに適用するイベントルールを記述します。その後、より詳細なルールを必要に応じて作成できますが、より小さい値を使用してください。
    • より一般的なルールでも同じ結果が得られる場合は、特定のイベントサブセットにのみ適用されるイベントルールを記述することは避けてください。
    • イベントルールがイベントに適用されるときに、元のイベントは変更されません。すべての処理はメモリー内で行われるため、トラブルシューティングには [処理のメモ] フィールドを使用するか、[イベントのプロセスのチェック] UI アクションリンクを使用してください。
    • 既存のマッピングルールがあるルール/変換を変更する場合は、実際のイベントまたはシミュレートされたイベントを確認して再テストする必要があります。
    • [送信元 (From)] フィールドの値が、イベントの additional_info フィールドの JSON の文字列と正確に一致することを確認します。この照合は、MIB ファイル内の情報に基づいてルールが設定されている場合に行われます。MIB ファイルがアップロードされていない場合、SNMP トラップ用の JSON では、MIB の変換後の名前ではなく、ドット形式の名前の付いた varbinds (変数バインド) を表示します。この場合、イベントフィールドマッピングルールは適用されません。
    • 一貫性のある命名規則を確立します。一般的な命名規則は <customer acronym>.<Event Source>.<Description> です。たとえば、 ACME.OEM.Normalize
    • 2 つのイベントルールに同様の条件が設定されている場合は、[順番] フィールドを使用して、実行するイベントルールを管理します。
    • イベントルールを使用して、アラートを CI に関連付けます。
    イベントルールをビルドするための追加設定：
    望ましい結果 必要なアクティビティ
    効果的な重複排除と効率的な並列イベント処理の有効化 [ソース]、[ノード]、[タイプ]、[リソース]、[メトリクス名] フィールドに入力します。
    CI バインディング
    • [ノード] フィールドと必要に応じて [CI ID] に入力することにより、ホストにバインドします。
    • [CI ID] フィールドと [追加情報] フィールドを入力することにより、アプリケーションやデバイスにバインドします。
    アラートのアグリゲーションを使用したアラート相関 [リソース]、[メトリクス名] フィールドに入力します。
    注:
    CI もバインドされている場合は、アラート相関が改善されます。
    カスタムイベントフィールド
    追加のフィールドをイベント専用の [追加情報] フィールドに含めます。
    イベントに追加フィールドを追加するためにイベント [em_event] テーブルにカスタムフィールドを追加するのはやめてください。
    イベント [em_event] テーブルに列を追加しないでください。

    イベントに追加フィールドを含める方法については、「カスタムアラートフィールド」を参照してください。

    重複排除
    重複排除の構成設定。
    • [message_key] フィールドは、重複排除に使用されます。信頼性の高いメッセージキーの値がソースイベントで指定されていない場合は、こうした識別子を作成するために明確な計画を立てることが重要です。
    • メッセージキーが定義されていない場合、デフォルトのメッセージキーは <Source + Node + Type + Resource + Metric Name> です。
    • ガイドラインでは、イベントソースに <Source + Node + Type + Resource + Metric Name> フィールドがそのまま入力され、メッセージキーを入力することになっています。このアクションにより、インスタンスワーカーとノードの間でイベント処理をより効果的に分散させることができます。
    • ソースイベントにこうしたフィールドの値がない場合は、変換ルールを使用して値を入力してください。このアクションはイベント処理には作用しませんが、重複排除に使用されます。インスタンスに送信する前にできるだけ多くのフィールドに入力してください。このアクションにより、イベントがより効果的にプロセッサーワーカーに分散されるため、スループットとスケールが改善されます。
    CI バインディング
    • 可能な場合は常に、アラートを CI にバインドしてください。
      注:
      イベントルールはイベントに定義されていますが、CI はそれぞれのイベントから発生するアラートにバインドされ、イベントにはバインドされません。
    • ホスト、マシン、または任意のデバイスを IP にバインドするには、イベントの [ノード] フィールドに一意のホスト名、FQDN、IP、または MAC アドレスを入力します。ホストを識別するために他の識別子が必要な場合は、[ci_identifiers] フィールドに JSON 形式の値を入力します。JSON 形式には、照合を実行するための CMDB フィールドの名前と値が含まれている必要があります。
      注:
      イベントの [ノード] フィールドには、イベントルールから入力するか、またはイベントが挿入される前にソースから一意のホスト名を入力する必要があります。
    • プライマリバインディング戦略では、[ノード] フィールドを使用します。イベントの [ノード] フィールドに事前入力されていない場合は、イベントルールを使用して入力できます。

    アラート設定

    アラートライフサイクル
    一般的なアラート機能：
    • イベントが無視されない場合、またはイベントルールがそのしきい値を超えている場合、アラートがオープンになり、重複排除ではイベントが既存のアラートに属するものとして識別されません。
    • アラートがクローズされるのは、クローズイベントが同じメッセージキーで送信されたとき、またはアラートが手動でクローズされたときです。
    • 同じメッセージキーを持つオープンアラートが、プロパティで定義された期間内 (デフォルトは 1 時間) に送信された場合は、アラートが再オープンされます。
    • プロパティの定義に従ってアラートが高い頻度でオープン/クローズすると、フラッピングになります。このような頻度のオープン/クローズが停止すると、アラートはフラッピングステータスから脱します。
    • インシデントがアラートからオープンされると、インシデントがオープンである限り、そのアラートはオープンのままになります。デフォルトでは、インシデントまたはアラートのいずれかがクローズされると、もう一方もクローズされます。この動作は、プロパティを使用して設定できます。
    • 対応するインシデントの作成時にアラートをクローズしないでください。
    • オープンアラートは削除しないでください。先にアラートをクローズしてから削除してください。
    • [確認] を使用すると、アラートが既知であり、一時的に無視できることを示すことができます。
    • アラートを要注意としてマークするために [確認] を使用するのはやめてください。
    • 次のいずれかの状況でアラートを作成しないでください。
      • クローズ済み
      • OK
      • オープン
    • evt_mgmt.alert_auto_close_interval プロパティを設定すると、指定された期間の後にアラートが自動的にクローズされます。0 を指定しないでください。値 0 は機能を無効にするため、パフォーマンスの低下につながるおそれがあります。
    • [OK] ステータスのアラートを作成しないでください。モニタリングシステムによっては、[OK] が問題の解決を示す場合もあれば、運用上重要ではないイベントを示すために [OK] が使用される場合もあります。前者の場合は、マッピングルールを使用して [OK] ではなく [クリア] を使用してください。後者の場合は、イベントが特定の値でない限り、無視ルールを使用してください。
    アラートアクションルール
    • スケジュール済みジョブは、11 秒ごとにアラートアクションルールを新規アラートに適用します。アラートルールがすぐに開始されない場合は、トラブルシューティングを開始する前に 10 ～ 15 秒間待ちます。
    • 2 つのアラートルールに同様の条件が設定されている場合は、[順番] フィールドを使用して、実行するアラートルールを管理します。
    • タスクテンプレートでアラートアクションルールを使用して、インシデントの静的な値を入力します。ポピュレータースクリプトを使用して、インシデントの動的な値を割り当てます。ポピュレータースクリプトは、インシデントの作成を中止する値として false を返すことができます。
    • イベント管理 (または類似の名前) というユーザーを作成します。次に、タスクテンプレート ([インシデント] など) 内の [作成者] フィールドは、そのユーザーがタスクのソースであったことを示すように設定できます。
    • 動的な値の割り当てを実行したり、OOB 動的値の割り当てを上書きしたりするには、EvtMgmtCustomIncidentPopulator スクリプトインクルードを使用します。
    修正
    • オーケストレーションワークフロープロパティを常に修復タスク [em_remediation_task] テーブルに設定します。
    • ECC キューの使用と ワークフロー > ライブワークフロー > すべてのコンテキスト 修復アクティビティに関する詳細情報を検索します。

    ビジネスルール

    • アラートテーブルで作成されたビジネスルールにかかる時間は、数ミリ秒以内にする必要があります。ビジネスルールを使用する代わりに、ジョブを使用して同じ機能を実現できるかどうかを検討してください。
    • ビジネスルールを使用して、アラートを CI に関連付けることはやめてください。ビジネスルールを使用せずにバインドするには、イベントルールを使用します。

    計画

    • フィルター、モジュールなどのイベントソース構成を順次ではなく複数の並列処理に編成します。
    • 処理されたイベントフォーマットを検証し、解析データが望ましい結果になっていることを確認します。
    • 非本番環境で本番イベントをテストします。非本番要素マネージャーおよび ServiceNow インスタンスとデータ連携します。非本番要素マネージャーが利用できない場合は、要素マネージャーから本番環境と非本番環境の両方にイベントを送信します。

    サービスとダッシュボード

    • サービスグループを使用してサービスを論理グループにグループ化すると、サービス健全性ダッシュボードに表示されるサービスの数を減らすことができます。
    • 手動で作成されたサービスマップをインポートします。

    メトリックインテリジェンス コレクターのログおよびファイル

    メトリックインテリジェンス コレクターのログおよびファイルは、パス $(MID_SERVER_DIR)/agent の下にあります。トラブルシューティングおよび監視に、こうしたログとファイルを使用します。

    表 : 1. メトリックインテリジェンス コレクターのログおよびファイルの場所
    ログまたはファイル パス
    PowerShell メトリクスコレクターのログファイル Logs/retrieve_metrics{connector instance ID}.log
    PowerShell 出力ファイル work/metrics/metrics_output_{connector instance ID}.txt  
    PowerShell 入力ファイル work/metrics/parameters_{connector instance ID}.txt

    mid.log.level MID サーバー パラメーターがデバッグモードになっている場合は、MID サーバー のログファイルで メトリックインテリジェンス のパフォーマンスを確認できます。

    メトリックインテリジェンス のパフォーマンス数値は、パフォーマンス統計情報 [sa_performance_statistics] テーブルで得られます。パフォーマンス数値を表示するには、[Metric Collector] のパフォーマンス統計情報リストをフィルタリングします。