インシデントフィールド用語集

インシデントのフィールドに関する詳細。

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

  • タイムスタンプ

ここに表示されるフィールドを設定することはできませんが、ルールエンジンを使ってこれらのフィールドを変換することができます。

404 エラーメッセージ

インシデント番号を選択すると、アラートの詳細を表示できます。アラートの詳細には、すべてのペイロードフィールドが含まれます。

重要なフィールド

message_type

message_type フィールドは Splunk On-Call の必須フィールドです。他のフィールドはすべて自動的に入力されます。message_type はアラートが到着したときの動作を決定します。

可能な値:

  • 重要:新しいインシデントを開き、エスカレーションポリシーが設定され、ユーザーがページングされます。

  • 警告:SettingsAlert ConfigurationCreate 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)です。

フィールド名

有効な値

目的

一般的なルールエンジンの使用

ack_author

ユーザー名

このインシデントを確認したユーザー名を表示します。インシデントが確認されていない場合は空白のままです。

ルールエンジンとは併用できません。

ack_message

承認方法

承認に使用された方法が表示されるか、空白のままです。

ルールエンジンとは併用できません

agent

任意

特定のレガシーインテグレーションのためのフィールド。

ルールエンジンとは併用できません。

alert_type

任意

特定のレガシーインテグレーションのためのフィールド。

ルールエンジンとは併用できません。

api_key

長い文字列値

組織が Splunk On-Call にアクセスするために使用する REST エンドポイントキーを表示します。各組織に 1 つのみです。

ルールエンジンで変更すべきではありませんが、RESTエンドポイントを使用するすべてのインテグレーションに一致するルールに使用できます。

entity_display_name

任意

entity_idに影響を与えない、より簡潔で直感的なインシデントの名前。明示的に定義されていない場合、デフォルトは entity_id です。
  • このフィールドは、電話の着信通知時に読み上げられます。

  • このフィールドは、メール、SMS、プッシュ通知で表示されます(プッシュとSMSは長さのために切り捨てられます)。

インシデントの動作に影響を与えることなく、インシデントの名前をより簡潔で直感的なものに変更することができます。

entity_id

任意

インシデントの中央識別子。

インシデントの組み合わせや分離は変更可能です。

entity_is_host

ブーリアン

問題を報告しているエンティティがホストでもあるかどうかを示します。

ルールエンジンとは併用できません。

entity_state

message_type と同じ

監視対象のエンティティの現在の状態 (インテグレーションによってはmessage_typeと異なる場合があります)

ルールエンジンとは併用できません。

eventType

任意

特定のレガシーインテグレーションのためのフィールド。

ルールエンジンとは併用できません。

host_name

任意

影響を受けるホストを表示します。

特定のホストに関連するインシデントを制御するには、このフィールドを一致させます。message_type フィールドを INFOに変換することで、routing_key をこのホストを担当するチームに変更するか、このホストに一致するサイレントアラートに変更します。

message_type

重要

新しいインシデントを開きます

インシデントを常にオープンするには、フィールドをこの値に変更します。これは、レガシーメール統合で有用です。

message_type

警告

設定([Settings] >> [Integrations])によっては、新しいインシデントを開くことがあります。

Settings、次に IntegrationCreate incidents for entities in [ ] state で選択したオプションによって制御される動作。

message_type

承認

インシデントをトリガーから確認に移動し、エスカレーションとページングを停止します。

フィールドをこの値に変更すると、ページングが防止され、インシデントがそのまま確認済み状態に送信されます。

message_type

INFO

新しいインシデントを作成することなく、タイムラインに情報を投稿します。

フィールドをこの値に変更すると、耳障りなアラートが静かになり、新しいインシデントを開いてページングするのを防ぐことができます。

message_type

RECOVERYまたはOK

インシデントを解決し、エスカレーションとページングを停止します。

インシデントを解決するには、フィールドをこの値に変更します。これは、レガシーメール統合で有用です。

monitor_name

任意

特定のモニター(複数ある場合)、またはメッセージ送信者(メール)の名前。

特定のモニターからのアラートを制御するには、このフィールドに一致させます。

monitoring_tool

任意

インシデントをトリガーしたモニタリングツールを表示します。

特定のモニタリングツールからのすべてのアラートを制御するには、このフィールドに一致します。

NOTIFICATIONTYPE

文字列

Nagios インテグレーションのために作成されたレガシーフィールド。

ルールエンジンとは併用できません。

routing_key

任意(ユーザー定義)

インシデントを特定のチームに指示するために使用されます。

変換を使用してルーティングキーを変更し、インシデントを別のチームに送信します。

sender

任意

特定のレガシーインテグレーションのためのフィールド。

ルールエンジンとは併用できません。

SERVICESTATE

任意

特定のレガシーインテグレーションのためのフィールド。

ルールエンジンとは併用できません。

state_message

任意

インシデントに関する冗長な情報を渡すために使用される大きなフィールド。
  • このフィールドは、メール通知(フル)、時にはSMS、プッシュ、または電話通知(スペースと文字制限が許す限り entity_display_name に従う)に一貫して表示されます。

  • 他のフィールドから値を引き出し、ユーザーが新しいインシデントを通知されたときに受け取るメッセージに、より有用な情報を追加します。

state_start_time

日付または時刻

監視対象のホストまたはサービスで問題が発生した日時を示します。

ルールエンジンとは併用できません。

subject

任意

特定のレガシーインテグレーションのためのフィールド。

インシデントの重大度を調整するには、このフィールドで一致します。

timestamp

日付または時刻

監視対象ホストまたはサービス上でモニタリングツールが異常を検出した場合(モニタリングツールから送信される、または定義されていない場合はデフォルトで VO_ALERT_RCV_TIME )。

ルールエンジンでは使用できません - 実際のデータはUnix時間形式であり、時間ベースのルールには使用できません。

VO_ALERT_RCV_TIME

日時

Splunk On-Callエンドポイントがメッセージを受信したとき。

ルールエンジンとは併用できません。

VO_ALERT_TYPE

文字列

内部使用のみのアラートタイプのインデックス。

ルールエンジンとは併用できません。

VO_MONITOR_TYPE

整数

内部使用のみのモニタータイプのインデックス。

ルールエンジンとは併用できません。

VO_ORGANIZATION_ID

org slug

アカウントを識別するために内部で使用される組織名のスラグ化されたバージョン。

ルールエンジンとは併用できません。

VO_UUID

ランダム文字列

Splunk On-Callが内部的にロギングに使用します。

ルールエンジンとは併用できません。