インシデントフィールド用語集
インシデントのフィールドに関する詳細。
Splunk On-Call タイムラインのインシデントは、フィールド名とそのフィールドの値の 2 列からなるシンプルな表のように機能します。フィールド名は、Splunk On-Call による自動定義、統合モニタリングツールによる定義、ルールエンジンルールによって作成された定義の 3 つの方法で定義されます。
そのため、すべての潜在的なフィールドを網羅的にリストアップすることはほぼ不可能です。ただし、特定のフィールドは常に存在します。このフィールドの値がインシデントの動作にどのように影響するか、またルールエンジンを使用してこのフィールドをどのように操作できるか、これらのフィールドを以下で定義および説明します。
インシデントの詳細な構造
インシデントをタイムラインで表示すると省略版として表示され、イベントを要約したいくつかのフィールドのみが表示されます。
インシデントの発生源(モニタリングツール)
message_type(Critical)
entity_display_name(Tune Squad Deployed)
インシデント番号(#10)
state_message(Someone hit the red button)
タイムスタンプ
ここに表示されるフィールドを設定することはできませんが、ルールエンジンを使ってこれらのフィールドを変換することができます。
インシデント番号を選択すると、アラートの詳細を表示できます。アラートの詳細には、すべてのペイロードフィールドが含まれます。
重要なフィールド
message_type
message_type フィールドは Splunk On-Call の必須フィールドです。他のフィールドはすべて自動的に入力されます。message_type はアラートが到着したときの動作を決定します。
可能な値:
-
重要:新しいインシデントを開き、エスカレーションポリシーが設定され、ユーザーがページングされます。
-
警告:Settings、Alert Configuration、Create incidents for entities in [xxxxxxx] stateの構成によっては、新しいインシデントが開く場合があります。そうでない場合は、インシデントを作成、またはエスカレーションポリシーをトリガーすることなく、タイムラインに情報が投稿されます。
-
INFO:インシデントを開かずに、タイムラインにエントリを表示します。INFO 値はエスカレーションやページングをトリガーできません。
-
承認:インシデントをトリガー状態から確認状態に移行し、エスカレーションとページングを停止します。
-
RECOVERYまたはOK:インシデントを解決し、まだアクティブな場合はエスカレーションとページングも停止します。
message_type フィールドにこれらの認識された値とは異なる値を持つアラートが受信された場合、それはINFO重大度アラートとして受け入れられます。entity_id
このフィールドは、インシデントの中心的な ID の役割を果たします。関連イベントを認識するために使用され、インシデントのライフサイクル全体を通じて一貫性を保つ必要があります。このフィールドにより、Splunk On-Call プラットフォームは、特定の復旧メッセージが特定のオープンインシデントに適用されることを認識します。
インシデントが未解決で、トリガーされた状態または確認済みの状態にあるときに、同じ entity_id で別の重要なメッセージが到着すると、この新しいメッセージは新しいインシデントを作成せずに既存のインシデントにロールアップされます。これは、同じ問題の重複通知を防ぐのに非常に有効ですが、同じ問題が新たに発生するのを見逃すおそれがあるため、ユーザーはインシデントを長時間未解決のまま放置しないように注意する必要があります。指定しない場合、このフィールドにはランダムな文字列値が自動入力されます。
ユーザーまたはモニター定義フィールド
routing_key
このフィールドは、特定のチームへのインシデントのルーティングを制御します。ルーティングキーは、[Settings] の[ Routing Keys] ページから 1 つ以上のチームを作成して割り当てることができます。インシデントには 1 つの routing_key のみを関連付けることができます。
entity_display_name
インシデントの entity_id は長く、専門用語が多いことがよくあります。entity_display_name を設定すると、インシデントのタイトルとして機能するため、タイムラインにインシデントが表示される方法が変わります。このフィールドは、電話コール通知中にも読み上げられるため、インシデントのライフサイクルに影響を与えることなく、メッセージを簡素化してカスタマイズすることができます。
state_message
state_message フィールドには、問題の詳細な説明を記述します。URL リンクを含めることもできます。メールのエンドポイント統合を使用する場合、メールの本文は [state_message] フィールドになります。
hostname
ペイロードに値を持つ hostname フィールドがある場合、インシデントカードの entity_display_name の後に表示します。
custom_fields
ユーザーは、カスタム名を持つカスタムフィールドをいくつでもインシデントに追加できますこれは、HTTP POST リクエストに手動でフィールドを追加するか、ルールエンジンを使用して新しいフィールドを作成することで実行できます。これは、HTTP POST リクエストに手動でフィールドを追加するか、ルールエンジンを使用して新しいフィールドを作成することで実行できます。
フィールドの用語集
ほとんどのペイロードフィールドの標準文字数制限は 1024 です。注意すべき例外は state_message(20480)および entity_id(512)です。
|
フィールド名 |
有効な値 |
目的 |
一般的なルールエンジンの使用 |
|---|---|---|---|
|
|
ユーザー名 |
このインシデントを確認したユーザー名を表示します。インシデントが確認されていない場合は空白のままです。 |
ルールエンジンとは併用できません。 |
|
|
承認方法 |
承認に使用された方法が表示されるか、空白のままです。 |
ルールエンジンとは併用できません |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
|
|
長い文字列値 |
組織が Splunk On-Call にアクセスするために使用する REST エンドポイントキーを表示します。各組織に 1 つのみです。 |
ルールエンジンで変更すべきではありませんが、RESTエンドポイントを使用するすべてのインテグレーションに一致するルールに使用できます。 |
|
|
任意 | entity_idに影響を与えない、より簡潔で直感的なインシデントの名前。明示的に定義されていない場合、デフォルトは entity_id です。
|
インシデントの動作に影響を与えることなく、インシデントの名前をより簡潔で直感的なものに変更することができます。 |
|
|
任意 |
インシデントの中央識別子。 |
インシデントの組み合わせや分離は変更可能です。 |
|
|
ブーリアン |
問題を報告しているエンティティがホストでもあるかどうかを示します。 |
ルールエンジンとは併用できません。 |
|
|
|
監視対象のエンティティの現在の状態 (インテグレーションによってはmessage_typeと異なる場合があります) |
ルールエンジンとは併用できません。 |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
|
|
任意 |
影響を受けるホストを表示します。 |
特定のホストに関連するインシデントを制御するには、このフィールドを一致させます。 |
|
|
重要 |
新しいインシデントを開きます |
インシデントを常にオープンするには、フィールドをこの値に変更します。これは、レガシーメール統合で有用です。 |
|
|
警告 |
設定([Settings] >> [Integrations])によっては、新しいインシデントを開くことがあります。 |
Settings、次に Integration と Create incidents for entities in [ ] state で選択したオプションによって制御される動作。 |
|
|
承認 |
インシデントをトリガーから確認に移動し、エスカレーションとページングを停止します。 |
フィールドをこの値に変更すると、ページングが防止され、インシデントがそのまま確認済み状態に送信されます。 |
|
|
INFO |
新しいインシデントを作成することなく、タイムラインに情報を投稿します。 |
フィールドをこの値に変更すると、耳障りなアラートが静かになり、新しいインシデントを開いてページングするのを防ぐことができます。 |
|
|
RECOVERYまたはOK |
インシデントを解決し、エスカレーションとページングを停止します。 |
インシデントを解決するには、フィールドをこの値に変更します。これは、レガシーメール統合で有用です。 |
|
|
任意 |
特定のモニター(複数ある場合)、またはメッセージ送信者(メール)の名前。 |
特定のモニターからのアラートを制御するには、このフィールドに一致させます。 |
|
|
任意 |
インシデントをトリガーしたモニタリングツールを表示します。 |
特定のモニタリングツールからのすべてのアラートを制御するには、このフィールドに一致します。 |
|
|
文字列 |
Nagios インテグレーションのために作成されたレガシーフィールド。 |
ルールエンジンとは併用できません。 |
|
|
任意(ユーザー定義) |
インシデントを特定のチームに指示するために使用されます。 |
変換を使用してルーティングキーを変更し、インシデントを別のチームに送信します。 |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
|
|
任意 | インシデントに関する冗長な情報を渡すために使用される大きなフィールド。
| |
|
|
日付または時刻 |
監視対象のホストまたはサービスで問題が発生した日時を示します。 |
ルールエンジンとは併用できません。 |
|
|
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
インシデントの重大度を調整するには、このフィールドで一致します。 |
|
|
日付または時刻 |
監視対象ホストまたはサービス上でモニタリングツールが異常を検出した場合(モニタリングツールから送信される、または定義されていない場合はデフォルトで |
ルールエンジンでは使用できません - 実際のデータはUnix時間形式であり、時間ベースのルールには使用できません。 |
|
|
日時 |
Splunk On-Callエンドポイントがメッセージを受信したとき。 |
ルールエンジンとは併用できません。 |
|
|
文字列 |
内部使用のみのアラートタイプのインデックス。 |
ルールエンジンとは併用できません。 |
|
|
整数 |
内部使用のみのモニタータイプのインデックス。 |
ルールエンジンとは併用できません。 |
|
|
org slug |
アカウントを識別するために内部で使用される組織名のスラグ化されたバージョン。 |
ルールエンジンとは併用できません。 |
|
|
ランダム文字列 |
Splunk On-Callが内部的にロギングに使用します。 |
ルールエンジンとは併用できません。 |