オペレーターフェーズ 1：アラートの分析および確認
イベント管理 オペレーターとして最初に実行する必要があるのは、アラートにアクセスし、重点的に取り組むアラートを見つけることです。アラートフォームを開いて詳細を分析し、アラートを確認すると、アラートの原因となっている問題を何らかの方法で解決する必要があることを他のオペレーターに知らせることができます。
始める前に
フェーズ 1 |
|
アラートの分析および確認 |
フェーズ 2 |
|
|
フェーズ 3 |
|
サービスオペレーションワークスペースダッシュボードとサービスオペレーションワークスペースという両方のオペレーター環境を理解する必要があります。まだ確認していない場合は、イベント管理 オペレーター環境を確認してください。このチュートリアルでは、サービスオペレーションワークスペースダッシュボードを使用します。
必要なロール：evt_mgmt_operator
手順
-
移動先 .
リストで、 . デフォルトでは、すべてのアラートが、[グループ] でソートされたリストに表示されます。任意の見出しをクリックすると、該当する値でソートされます。現在のフィルター設定を表示するには、フィルターアイコン
をクリックします。フィルター設定を変更するには、[詳細ビュー] をクリックします。 -
アラート名をクリックすると、そのアラートの [詳細] タブが表示されます。
このフォームの重要なフィールドと関連アイテムについては、スクリーンショットの後に説明しています。
表 : 1. 単一の CI に関連付けられているアラートの [アラートの詳細] タブのフィールド フィールド 説明 番号 サービスオペレーションワークスペースダッシュボードのアラートのリストで表示される、自動的に生成されたアラート番号。
ノード アラートが関連付けられている CI の名前。この CI で発生したアラートを生成したイベント。コンピューター名、あるいはデバイスの IP アドレスまたは MAC アドレスが表示される場合があります。 リソース イベントの原因となった、ノード上のオブジェクト。ハードディスクの名前、CPU、プロセスまたはサービスの名前などの値が表示される場合があります。必要に応じて、このフィールドに情報を追加できます。 構成アイテム このアラートが適用される、CMDB 内の CI。[ノード] フィールドに入力されていても、このフィールドが空で、ノードがどの CI を表しているかがわかっている場合は、このフィールドに CI を入力して、アラートをその CI に手動で関連付けることができます。 注:アドミニストレーターは、CI をアラートに自動的にバインドするルールを設定できます。通常は、[ノード] フィールドの内容に基づいて設定します。ただし、アラートのバインド先の正しい CI が見つからない可能性があります。この場合には、手動で CI を選択する必要があります。このチュートリアルでは、正しい CI がアラートにバインドされていることを前提にしています。
アラートに CI が含まれている場合、アラートを選択すると [概要] タブが開きます。
タスク このフィールドには、インシデント、変更要求、問題などのアラートに関連付けられている既存のタスクが表示されます。最初にアラートを確認するときに、このフィールドは空白です。アラートをトリアージしたときに、タスクを関連付けることができます。インシデントをアラートに関連付けて、そのインシデントをこのチュートリアルの後のステージで他のユーザーにアサインします。 説明 組織のアラート監視ソフトウェアからのアラートの説明。必要に応じて、情報を追加できます。 重大度 アラートの重大度値： - [重大]：即時アクションが必要です。リソースが機能していないか、重大な問題が発生しそうな状況です。
- メジャー：主要な機能に深刻な障害が発生するかパフォーマンスが低下しています。
- マイナー：機能の重要でない部分が失われたか、パフォーマンスが低下しています。
- 警告：リソースはまだ機能していますが、注意が必要です。
- 情報：情報メッセージ。アラートは作成されますが、リソースはまだ機能しています。
- クリアまたは解決済み：アクションは必要ありません。このイベントからはアラートが作成されません。既存のアラートはクローズされています。
状態 アラートの現在の処理ステータス。新たに生成されたアラートは「オープン」ステータスになります。その他の進捗状況は、次のとおりです。 - 「再オープン」は、以前にクローズされたアラートが再度オープンされ、注意が必要であることを示します。
- 「フラッピング」は、アラートが同じソースから同一イベントを高頻度で受信していることを示します。これにより、アラートがクローズされた後も、多数のアラートが再オープンされる可能性があります。
- 「クローズ済み」は、アラートがクローズされ、それ以上のアクションを必要としないことを示します。このチュートリアルの最後のステージの一環として、アラートをクローズします。
メンテナンス アラートが動作不要になっており、サービスオペレーションワークスペースダッシュボードのアラートのリストで非表示になっていることを示します。この例では、アラートをメンテナンス状態にしないようにしています。
確認済み アラートが本物であり、トリアージされているのをオペレーターが確認したことを示します。このトピックの後のステージでアラートを確認します。 イベント管理 アドミニストレーターは、アラートが生成された直後に自動的に確認されるようにすることもできます。これが実現されている場合は、アラートフォームの [確認] チェックボックスが既にオンになっている可能性があります。
親 セカンダリアラートにのみ値を表示します。値は、親アラートのアラート番号を示します。プライマリアラート (親アラートのないアラート) の場合、このフィールドは空です。 ナレッジ記事 アラートに関連付けられている既存のナレッジベース (KB) 記事。最初にアラートをオープンするときに、このフィールドは空白です。アラートをトリアージしたときに、KB 記事を関連付けることができます。 -
[影響を受けるサービス] タブをクリックし、サービス名をクリックします。
アラートを確認する前に、アラートのソースになっているサービスが原因で影響を受けるサービスについて、詳しく調べた方がよい場合があります。
サービスが開き、[詳細] タブが表示されます。[サービスマップ] をクリックして、関連するアプリケーションサービスのマップを表示します。
オレンジのメジャー重大度インジケーターがいくつかの CI に表示されていることに注意してください。Oracle データベース (PS ORA01) から始まり、データベースに依存しているすべての CI まで適用されています。これにより、Oracle データベース上の、重大度が最高のアラートが問題の根本原因を示していると推測できます。
これが必ずしも CI ごとの個別アラートの生成を意味するわけではありませんが、その可能性があります。アラートをトリアージする際に、他の CI のアラートをプライマリアラートの下で相互に関連付ける必要があるかどうかを判断できます。
-
[影響ツリー] タブをクリックし、各 CI への影響を確認します。
影響ツリーの各 CI の横にあるパーセンテージは、各 CI に対する影響度を示しています。この例では、アラートによって各 CI が 100% の影響を受けています。つまり、アラートの原因となっている、根底にある問題が、アプリケーションサービスの機能に影響を与えるほど深刻であるということです。
-
戻って確認したアラートを探します。
[確認済み] の値が true になっていることがわかります。
次のタスク
「オペレーターフェーズ 2：アラートのトリアージ」に進みます。