インシデントフィールド 用語集 🔗
Splunk On-Callタイムラインのインシデントは、フィールド名とそのフィールドの値という2つの列を持つ単純なテーブルのように機能します。フィールド名は2つの方法で定義できます：- Splunk On-Callによる自動定義、- 統合モニタリングツールによる定義、- ルールエンジンルールによる定義です。
このため、すべての可能性のある分野を網羅的にリストアップすることはほぼ不可能です。しかし、特定のフィールドは常に存在します。これらのフィールドを以下に定義および説明し、それらの値がインシデントの動作にどのように影響するか、またルールエンジンを使用してこれらのフィールドをどのように操作できるかを示します。
インシデントの詳細な構造 🔗
インシデントをタイムラインで表示する場合、イベントを要約するいくつかのフィールドのみが表示されます： * インシデントオリジン（監視ツール） * message_type critical*) * entity_display_name (Tune Squad Deployed) * インシデント番号 (#10) * state_message (Someone hit the red button) * タイムスタンプ。
ここに表示されるフィールドを設定することはできませんが、ルールエンジンを使ってこれらのフィールドを変換することができます。
インシデント番号を選択すると、アラートの詳細を表示できます。アラートの詳細には、すべてのペイロードフィールドが含まれます。
重要なフィールド 🔗
Message-typeとentity_idは2つの重要なフィールドです。
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 🔗
このフィールドは、インシデントの中心的なアイデンティティの役割を果たします。関連イベントを認識するために使用され、インシデントのライフサイクルを通じて一貫性を保つ必要があります。このフィールドにより、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リクエストに手動でフィールドを追加するか、ルールエンジンを使用して新しいフィールドを作成することで実行できます。
フィールドの用語集 🔗
ほとんどのペイロードフィールドの標準文字数制限は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_is_host |
ブーリアン |
問題を報告しているエンティティがホストでもあるかどうかを示します。 |
ルールエンジンとは併用できません。 |
entity_state |
|
監視対象のエンティティの現在の状態 (インテグレーションによってはmessage_typeと異なる場合があります) |
ルールエンジンとは併用できません。 |
eventType |
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
host_name |
任意 |
影響を受けるホストを表示します。 |
特定のホストに関連するインシデントを制御するには、このフィールドにマッチさせます。message_typeフィールドを 「INFO 「に変換することで、 |
message_type |
重要 |
新しいインシデントを開きます |
インシデントを常に開くには、フィールドをこの値に変更します。これはレガシーメールインテグレーションで便利です。 |
message_type |
警告 |
設定 (設定>>インテグレーション) によっては、新しいインシデントを開くことがあります。 |
Settings、次に Integration と Create incidents for entities in [ ] state で選択したオプションによって制御される動作。 |
message_type |
承認 |
インシデントをトリガーから確認に移動し、エスカレーションとページングを停止します。 |
フィールドをこの値に変更すると、ページングが防止され、インシデントがそのまま確認済み状態に送信されます。 |
message_type |
INFO |
新しいインシデントを作成することなく、タイムラインに情報を投稿します。 |
フィールドをこの値に変更すると、耳障りなアラートが静かになり、新しいインシデントを開いてページングするのを防ぐことができます。 |
message_type |
RECOVERYまたはOK |
インシデントを解決し、エスカレーションとページングを停止します。 |
インシデントを解決するには、フィールドをこの値に変更します。これはレガシーメールインテグレーションで便利です。 |
monitor_name |
任意 |
特定のモニター（複数ある場合）、またはメッセージ送信者（メール）の名前。 |
特定のモニターからのアラートを制御するには、このフィールドに一致させます。 |
monitoring_tool |
任意 |
インシデントをトリガーしたモニタリングツールを表示します。 |
特定のモニタリングツールからのすべてのアラートを制御するには、このフィールドに一致します。 |
通知タイプ |
文字列 |
Nagiosインテグレーションのために作成されたレガシーフィールド。 |
ルールエンジンとは併用できません。 |
routing_key |
任意（ユーザー定義） |
インシデントを特定のチームに指示するために使用されます。 |
変換を使用してルーティングキーを変更し、インシデントを別のチームに送信します。 |
sender |
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
SERVICESTATE |
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
ルールエンジンとは併用できません。 |
state_message |
任意 |
|
|
state_start_time |
日付または時刻 |
監視対象のホストまたはサービスで問題が発生した日時を示します。 |
ルールエンジンとは併用できません。 |
subject |
任意 |
特定のレガシーインテグレーションのためのフィールド。 |
インシデントの重大度を調整するには、このフィールドで一致します。 |
timestamp |
日付または時刻 |
監視対象ホストまたはサービス上でモニタリングツールが異常を検出した場合(モニタリングツールから送信される、または定義されていない場合はデフォルトで |
ルールエンジンでは使用できません - 実際のデータはUnix時間形式であり、時間ベースのルールには使用できません。 |
VO_ALERT_RCV_TIME |
日時 |
Splunk On-Callエンドポイントがメッセージを受信したとき。 |
ルールエンジンとは併用できません。 |
VO_ALERT_TYPE |
文字列 |
内部使用のみのアラートタイプのインデックス。 |
ルールエンジンとは併用できません。 |
VO_MONITOR_TYPE |
整数 |
内部使用のみのモニタータイプのインデックス。 |
ルールエンジンとは併用できません。 |
VO_ORGANIZATION_ID |
org slug |
アカウントを識別するために内部的に使用される組織名のスラグ化されたバージョン。 |
ルールエンジンとは併用できません。 |
VO_UUID |
ランダム文字列 |
Splunk On-Callが内部的にロギングに使用します。 |
ルールエンジンとは併用できません。 |