監視ツールを1つのオンコールエージェントにまとめる

5xxアラートが鳴ると、オンコール担当者はまずタブを開き始めます。Datadogでモニターを見て、Sentryでスタックトレースを確認し、OpenSearchで同じ時間帯のログを掘り起こします。それからGitHubで、直前に何かリリースされていないかを確かめます。

これらのツールを1つのエージェントに接続しておけば、この一連の確認を1文で任せられます。「この1時間で何が起きた？」と聞けば、エージェントが各ツールを順に照会し、根拠を添えた要約を返します。接続にコードは要りません。各サービスが発行するAPIキーをフォームに貼り付けるだけです。

こんなチームに向いています

• アラートが鳴るたびに、4つも5つもダッシュボードを行き来している
• オンコールを引き継ぐたびに、「いま何が鳴っている？」の確認からやり直している
• サービスごとに監視ツールが違い、まとめて見られる場所がない

必要なもの

• endueのアカウントとエージェント1つ
• 接続したい監視ツールそれぞれのAPIキー。エージェントに照会だけを任せるなら、読み取り専用のキーから始めてください

1. 監視ツールを接続する

1. 左のレールでResources → Connectorsに進み、Discoverタブを開きます。監視ツールはObservability & Incidentsにまとまっています。
2. ツールを選ぶと、エージェントがそのツールで何をできるようになるかが先に表示されます。問題なければConnectを押します。
3. 接続名とキーを入力してConnectを押します。これで完了です。名前はDatadog · prodのように、あとで見分けやすいものにしてください。

各フォームで入力する内容は次のとおりです。

• Datadog：サイト、APIキー、アプリケーションキー。サイトには、ブラウザのアドレスバーにあるapp.datadoghq.comをそのまま貼り付けられます
• Elasticsearch · OpenSearch：クラスターのhttps URLとAPIキー
• Grafana：GrafanaのURLとサービスアカウントトークン（glsa_で始まるもの）
• Sentry：サーバーURL（SaaSの場合はhttps://sentry.io）、組織スラッグ、認証トークン
• New Relic：リージョン（usまたはeu）とUSERタイプのAPIキー（NRAK-で始まるもの）
• PagerDuty：APIキーと、インシデント操作の記録先となるアカウントのメールアドレス

OpenSearchはElasticsearchコネクタで接続します。検索APIと集計APIが同じなので、クエリはそのまま動きます。ただし認証はAPIキー（Authorization: ApiKey）のみのため、ユーザー名とパスワードしか受け付けないクラスターはまだ接続できません。

GitHubとSlackは、キーではなくログインで接続します。接続はアカウントに1度作れば、どのエージェントからでも使えます。

2. エージェントに追加する

接続を作っただけでは、すべてのエージェントに渡るわけではありません。どのツールを持たせるかは、エージェントごとに決めます。

1. エージェントを開き、上部でStudioに切り替えます。キャンバスには、エージェントの全体が1画面に並びます。
2. 右上の「+ Add Connector」を押し、My connectorsタブから先ほど作った接続を選びます。まだ接続していないツールは、Catalogタブからその場で接続できます。
3. 追加したツールは、キャンバスの右側の列に並びます。

コネクタの列をクリックすると、このエージェントに追加された接続の一覧が開きます。接続ごとに現在のステータスが表示されます。スイッチを切り替えれば一時停止でき、Removeを押せば外せます。どちらもこのエージェントにだけ影響し、接続そのものはアカウントに残ります。

3. 確認の順番をプロンプトに書く

ツールを追加した時点で、エージェントは質問に合ったものを自分で選びます。それでも、チームが実際にたどる順番を書いておくと、回答が安定します。キャンバスでPromptを開き、次のように書きました。

アラートや質問が来たら、次の順番で確認する。

1. Datadog：対象サービスのモニターの状態、直近1時間のエラーログ
2. Sentry：新しいイシュー、最新のスタックトレース、どのリリースから始まったか
3. OpenSearch：同じ時間帯のapp-logs-*のリクエストログ
4. GitHub：その前後にマージされたPR
5. PagerDuty：オープン中のインシデントと、現在のオンコール担当者

回答は短くまとめる。原因の候補には、根拠となるログ行やイシューを必ず添える。モニターのミュート、インシデントの確認や解決、Slackへの投稿は、事前に確認を取る。

サービス名、インデックスパターン、リポジトリ名など、チームにしかわからないことは書いておく価値があります。エージェントが聞き返さなくなります。

使ってみる

チャットで、届いたアラートをそのまま貼り付けるか、ひとこと質問します。

checkout-apiで5xxアラートが出た。この1時間で何が起きた？

エージェントはまず、Datadog、Sentry、PagerDutyを一度にまとめて確認します。気になる点が見つかると、Sentryのスタックトレース、OpenSearchのログ、GitHubのPRで絞り込みます。ツールの呼び出しとその引数はすべて回答の上に残るので、どの結論も出どころまでたどれます。

元に戻しにくい操作は、先に確認します

照会は確認なしで実行します。アラートを止める操作や、チームの目に触れる痕跡を残す操作では、先に承認カードが表示されます。カードのデフォルトはCancelなので、Enterをうっかり押しても何も実行されません。

監視ツールのうち、承認を経るのは次の操作です。

• Datadogモニターのミュート、Grafanaアラートのサイレンス
• PagerDutyインシデントの確認、解決、メモの追加
• Sentryイシューの解決や無視、New Relicイシューの確認やクローズ

Slackメッセージの送信とGitHubイシューの作成も、同じカードを経由します。

日々の運用

• 朝のチェック：チャットで「平日の毎朝9時にこのチェックを実行して」と伝えれば、ルーティンにできます。ルーティンの実行は誰も見ていないので、ミュートのように承認が必要な操作はスキップされ、スキップしたことが結果に記載されます。
• まずステータスを見る：キーの期限が切れたり権限が変わったりすると、コネクタ一覧のステータスも変わります。エージェントが特定のツールでだけ行き詰まっているようなら、まずここを確認してください。