Splunk On-Callのメールエンドポイントインテグレーション 🔗
一般的なメールエンドポイントは、タイムラインのインシデントを作成、確認、解決するために、特別に作成されたSplunk On-Callアドレスにメールを送信するために使用できる基本的なメール取り込みインターフェイスです。このインテグレーションは、任意のモニタリングツールまたはメールサービスプロバイダーからのメールを受け入れます。
メールの件名を変更できることは、メールエンドポイントインテグレーションの重要なコンポーネントです。メールの件名や本文をカスタマイズできない場合は、レガシーメールシステム および 推奨されるルールエンジンのルール を参照してください
注釈
メールアラートは、メールハンドラによって遅延される可能性があります。可能な限り、代わりにRESTエンドポイントを使用してください。Splunk On-CallのRESTエンドポイントインテグレーション を参照してください。
要件 🔗
このインテグレーションは以下のバージョンのSplunk On-Callと互換性があります：
Starter
Growth
エンタープライズ
Splunk On-Callの設定 🔗
Splunk On-Callポータルにログインし、Integrations、Email Generic を選択します。
Enable Integration を選択して、メールのエンドポイントアドレスを生成します。有効化すると、インテグレーションによって一般的なメールエンドポイントアドレスが生成されます。Email Options で、解析不可能なメールを情報として扱うか、重要なアラートとして扱うかを選択します。
メールのエンドポイントアドレス 🔗
オンコールメールエンドポイントアドレスは3つの部分から構成されています：
メールエンドポイントキーは、ルーティングキーの前にある数字、文字、ダッシュの長い文字列です。オンコールであなたの組織に固有のものです。キーを取り消し、新しいキーを生成することができますが、一度に使用できるエンドポイントキーは1つだけです。
ルーティングキーは、メールエンドポイントで開始されたインシデントをオンコール内の特定のチームまたはチームにルーティングするために使用できます。次の例では、ルーティングキーは
databaseです：70ysj-6ks..(endpoint key)..9284\ **+database**\ @alert.victorops.com
On-Callのルーティングキーは大文字と小文字を区別し、メールエンドポイントのルーティングセグメントのルーティングキー名と一致する必要があります。ルーティングキーの設定については、Splunk On-Callでルーティングキーを作成する を参照してください。
注釈
メールプロバイダーが
+記号の使用を禁止している場合は、ドット(.)を使用してみてください。メールのエンドポイントアドレスの最後の部分は、メールのドメイン
@alert.victorops.comです。
メールのフォーマットとインシデントの処理 🔗
メールエンドポイントを使用する場合、オンコールプラットフォームの結果の動作は、メールの件名行に定義済みのキーワードを使用することに依存します。以下のキーワードのいずれかを使用できます：
CRITICAL: 新しいインシデントを開き、インシデントを受け取るチームに設定したエスカレーションポリシーをトリガーします。認識されるパターンは「クリティカル」と「問題」です。WARNING: タイムラインにエントリを追加し、新しいインシデントを作成するか、Settings、Alert Configuration の設定に基づいて視覚的に表示することができます。認識されるパターンは」warn」と」warning」です。INFO: インシデントを起こさずに、タイムラインにインフォメーションイベントを投稿します。誰もページングされません。認識されるパターンは、」info」、」informational」、」information」です。ACKNOWLEDGEMENT: インシデントを確認します。プラットフォームはユーザーへのページングを停止します。認識されるパターンは、」acked」、」acknowledge」、」acknowledgement」、」acknowledged」です。RECOVERY: 未解決のインシデントを解決します。プラットフォームはユーザーへのページングを停止します。インシデントを解決する前に、インシデントを確認する必要はありません。認識されるパターンは、」resolved」、」recovered」、」recovery」、」ok」、」closed」です。
メールがOn-Callに取り込まれる際、件名が解析され、キーワードが削除されます。同様に、Re:、Fwd:、または Fw: のテキストが件名の先頭にある場合、それらは解析され、削除されます。件名行に残ったテキストは、結果のインシデント( entity_id フィールド)のタイトルとメインのIDになります。
メッセージ本文は、インシデントの state_message フィールドにテキストとして含まれます。ベストプラクティスは、インシデントのタイトルのスペースによる問題を避けるために、キーワードを件名の最後に含めることです。
メールにこれらのキーワードが含まれていない場合は、解析できません。
サンプルインシデント 🔗
以下のメールの例では、チーム「Lost」にルーティングされる新しいインシデントが作成されます。
その結果、インシデントは次のようになります：
同じメールを送信するが、キーワード CRITICAL をキーワード ACKNOWLEDGEMENT に置き換えることで、前回のサンプルインシデントを確認することができます。解決するには、キーワード ACKNOWLEDGEMENT をキーワード RESOLVED または OK に置き換えてください。
自動解決のトラブルシューティング 🔗
メールの件名は、キーワードを除き、あるインシデントに関連するすべてのメールで同じになるようにします。
たとえば、「データベースサーバーDB6がダウンしていますCRITICAL」という件名のメールを送信した後、「データベースサーバーDB6がアップしましたRECOVERY」という件名のインシデントを解決するためのメールを送信した場合、最初のアラートの entity_id には down という単語が含まれているのに対し、解決メッセージの entity_id には up という単語が含まれているため、On-Callプラットフォームは、2番目のメールが最初のアラートによって開かれたインシデントに関連しているとは認識しません。
レガシーメールシステム 🔗
レガシーモニタリングツールの中には、メール通知の件名行の内容をユーザーが変更できないものがあります。この場合、ルールエンジンツール（エンタープライズのみ）を使用して、そのツールで生成されたインシデントのワークフローを制御できます。この設定のヘルプについては、製品内チャットを使用してサポートにお問い合わせください。
推奨されるルールエンジンのルール 🔗
メールシステムの柔軟性に応じて、メールインテグレーションによるアラートの送信を制限することができます。メールの件名と本文を変更する機能があれば、重要なアラートを回復状態に変換することができます。この使用例については、以下のサンプルルールを参照してください。キーワード UP の両側にあるスペースに注意してください。
このルールは、アスタリスクで示されるワイルドカードマッチングを使用して、メール本文（ペイロード内の state_message ）内のキーワードまたはフレーズ UP を検索します。キーワードまたはフレーズ UP がメール本文に存在する場合、message_type は RECOVERY に変わります。これを メールのフォーマットとインシデントの処理 にリストされている解析可能なフィールドで置き換えることができます。
正規表現 🔗
高度なメールのユースケースに正規表現を使用することができます。詳細は 正規表現によるマッチング を参照してください。