dt-alerting

dt-alerting

Dynatrace のアラートライフサイクル全体を設定し、理解します。異常検知の設定から、Grail でのイベント保存、問題のグルーピング、ワークフローによる通知配信までを扱います。

アラートライフサイクル

┌─────────────────────────────────────────────────────────────────────┐
│  Alert Sources — five categories, each fires a DAVIS_EVENT          │
│  ─────────────────────────────────────────────────────────────────  │
│  1. DQL-based  · Grail-scheduled server-side detector               │
│  2. Edge       · OneAgent on monitored host or process              │
│  3. Pipeline   · OpenPipeline ingest-stream filter matcher          │
│  4. Synthetic  · Worldwide synthetic checker node                   │
│  5. External   · Events API, Workflow, or OneAgent local ingest     │
└──────────────────────────────┬──────────────────────────────────────┘
                               │ DAVIS_EVENT created per trigger per entity
                               ▼
             ┌─────────────────────────────────────┐
             │  Event stored in Grail              │  Persisted and queryable via DQL.
             └──────────────────┬──────────────────┘  One event per trigger per entity.
                                │ correlated by root-cause and impact graph
                                ▼
             ┌─────────────────────────────────────┐
             │  Problem (Denoising)                │  Events sharing the same root-cause
             └──────────────────┬──────────────────┘  and impact graph → one Problem.
                                │ problem event triggers workflow
                                ▼
             ┌─────────────────────────────────────┐
             │  Workflow Notification              │  Filters problems and routes to
             └─────────────────────────────────────┘  email, Slack, ServiceNow, webhook.

このスキルを使用する場面

• 検知器の設定 — 「異常検知器を作成するにはどうすればよいですか？」「どの種類の検知器を使えばよいですか？」「適応型と季節型の違いは何ですか？」
• アラートイベント履歴 — 「このサービスのすべてのアラートイベントをクエリしてください」「先週、どのメトリクスがアラートをトリガーしたかを表示してください」
• 問題のノイズ除去 — 「この2つのアラートが1つの問題に統合されたのはなぜですか？」「Davis はどのようにアラートをグループ化しますか？」
• 通知の設定 — 「問題が発生したときに Slack メッセージを送信するにはどうすればよいですか？」「重大な問題が発生したときに ServiceNow のチケットを作成するよう設定してください」
• ベストプラクティス — 「アラートの嵐を防ぐにはどうすればよいですか？」「どの感度設定を使えばよいですか？」
• 過剰なアラートの分析 — 「アラートが多すぎるのはなぜですか？」「アラート疲れを減らすにはどうすればよいですか？」「最も頻繁に発火している検知器はどれですか？」「ノイズを防ぐために感度やしきい値を調整するにはどうすればよいですか？」
• 通知のルーティング — 「アラートを適切なチームにルーティングするにはどうすればよいですか？」「ワークフローでスケーラブルな問題フィルターを設定してください」「影響を受けたサービスの担当チームにのみ Slack 通知を送信してください」

エージェントへの指示

アラート設定の依頼では、まず最初に行うこと — 特定の検知器やモデルを推奨する前に、references/anomaly-detectors.md を読み込み、カテゴリとモデルの選択ガイドを使用して、ユーザーのユースケースに最適な検知器カテゴリ（DQL ベース、Edge、Pipeline、Synthetic、External）とモデル（Static、Adaptive、Seasonal）を特定してください。適切な検知器の種類を確定してから、設定の案内に進んでください。

数を増やさず、まとめる — ユーザーが同じ種類の複数のエンティティ（例：「サービス A、B、C を対象にアラートを設定して」）についてアラートを求めた場合は、エンティティごとに検知器を作成するのではなく、常に単一の統合検知器を推奨してください。DQL の timeseries 呼び出しで by: { <dimension> } を使ってエンティティごとに結果を分割し、関連するエンティティを対象とする単一の filter: 句を使用してください。統合検知器には、すべてのアラート条件で共通の単一の dt.alert_group タグを設定し、対応するワークフロー通知フィルターにも使用してください。これにより、検知器の設定数を抑え、一貫したルーティングを確保し、同じグループに追加されるエンティティにもワークフロー通知チャネルを再利用できます。

3つのサービスを対象とする例 — 検知器1つ、ワークフロー1つ：

timeseries avg(dt.service.request.response_time),
  by: { dt.smartscape.service },
  filter: { in(dt.smartscape.service, {toSmartscapeId("SERVICE-0000000000000001"), toSmartscapeId("SERVICE-0000000000000002"), toSmartscapeId("SERVICE-0000000000000003")}) }

検知器のイベントプロパティに dt.alert_group: "checkout-team" を設定し、通知ワークフローを matchesPhrase(dt.alert_group, "checkout-team") でフィルターしてください。新しいサービスを対象に含める場合は、単一の filter: リストに追加するだけです。新しい検知器やワークフロールールは必要ありません。

インテントマッピング

ユーザーのリクエスト	アクション	参照先
「...に関するアラートを設定する方法」「...に関するアラートを作成する」「異常検知器を作成する」「アラートを設定する」「アラートルールを構成する」	検知器のカテゴリーと種類を説明し、モデルの選択を案内します	anomaly-detectors.md
「異常検知器にはどんな種類があるか」「エッジアラート」「パイプラインアラート」「Synthetic アラート」「OneAgent アラート」	5 つのアラートソースカテゴリーと、それぞれのトレードオフを説明します	anomaly-detectors.md
「静的と適応型の違い」「どの検知器モデルを選ぶか」「季節性検知器」	モデルを比較し、選択ガイドを適用します	anomaly-detectors.md
「アラート履歴をクエリする」「発生したアラートを確認する」「Grail の Davis イベント」	Grail で fetch dt.davis.events を使って dt.davis.events をクエリします	davis-events.md
「アラートがマージされた理由」「問題のグルーピング」「ノイズ除去」	ここではマージルールを説明しないでください。dt-obs-problems を読み込み、マージロジックの全容については problem-merging.md を参照してください	dt-obs-problems/references/problem-merging.md
「Slack 通知を送る」「問題発生時にメールを送る」「ServiceNow チケット」「アラート通知」	問題をトリガーとするワークフローの設定を説明します	workflow-notifications.md
「アラートストーム」「通知が多すぎる」「ノイズを減らす」	フィルタリング戦略、ノイズ除去、感度の調整を説明します	workflow-notifications.md + anomaly-detectors.md

既存の問題の分析 — ユーザーがアクティブまたはクローズ済みの問題（根本原因、影響、傾向）をクエリまたは調査したい場合は、代わりに dt-obs-problems を読み込んでください。 このスキルの対象は設定とフローであり、問題のクエリ分析ではありません。

検知器の稼働状態の監視 — 検知器が実行中か、失敗しているかをユーザーが尋ねた場合は、dt-platform（ANALYZER_EXECUTION_EVENT、 ANOMALY_DETECTOR_STATUS_EVENT）を読み込んでください。このスキルの対象はセットアップであり、運用状態の監視ではありません。

前提条件

• 検知器の構成に必要な Settings v2 の書き込み権限を持つ Dynatrace 環境へのアクセス
• アラート履歴をクエリする場合：dt.davis.events に対する DQL 権限
• DQL クエリを作成する前に dt-dql-essentials を読み込んでください

ナレッジベースの構成

#	参照先	内容
1	anomaly-detectors.md	検知器の種類、モデルの選択、構成、ベストプラクティス
2	davis-events.md	Grail での Davis イベントの保存、主要フィールド、DQL クエリのパターン
3	workflow-notifications.md	問題をトリガーとするワークフロー、フィルタリング、通知チャネル

主な概念

アラートソースのカテゴリー

異常検知器には、検知が実行される場所とアラートイベントが Dynatrace に届く方法によって区別される、5 つの基本的なカテゴリーがあります。

#	カテゴリー	検知の実行場所	レイテンシー	アラートロジックの管理者
1	DQL ベース	Grail（サーバー側、スケジュール実行）	数分	Dynatrace
2	エッジ	監視対象のホスト／プロセス上の OneAgent	数秒	Dynatrace（OneAgent）
3	パイプライン	OpenPipeline の取り込み経路（ストリーム内）	ほぼゼロ	Dynatrace（パイプラインルール）
4	Synthetic	Synthetic チェッカーノード（世界各地）	数秒	Dynatrace（Synthetic ノード）
5	外部	顧客／外部ツール	呼び出し元によって定義	顧客

各カテゴリーの詳しい内訳（トレードオフや構成の開始場所を含む）については、references/anomaly-detectors.md を参照してください。

検知器モデルの概要

モデル	しきい値	最適な用途
静的	ユーザーが定義する固定値	既知の厳格な上限（例：エラー率 > 5%）
適応型ベースライン	直近の履歴から学習	固定の上限はないものの、正常な動作が明確なメトリクス
季節性ベースライン	時刻や曜日を考慮して学習	トラフィック、リクエスト率、または周期的なパターンがあるメトリクス全般

Davis イベントと問題

概念	テーブル	範囲
Davis イベント	fetch dt.davis.events	エンティティごとに検出器がトリガーされるたびに1レコード
問題	fetch dt.davis.problems	根本原因と影響を共有する、相関関係のあるイベントのグループごとに1レコード

1つの問題には通常、複数のイベントが含まれます。問題をクエリすると運用上の状況を把握でき、イベントをクエリするとアラートの生の履歴を確認できます。

問題のノイズ除去

アラートが問題に統合された理由や、Davis がイベントをどのようにグループ化するかについて質問する場合は、dt-obs-problems を読み込んでください。統合ロジックとルールは dt-obs-problems/references/problem-merging.md に記載されています。このスキルでは、アラートの設定とフローのみを扱います。

クイックスタート

過去24時間に発生したアラートを確認する

fetch dt.davis.events, from: -24h
| filter event.status == "ACTIVE"
| summarize alert_count = count(), by: {event.name, event.category, dt.smartscape_source.id}
| sort alert_count desc
| limit 20

カテゴリ別のアラート数を確認する

fetch dt.davis.events, from: -24h
| summarize count = count(), by: {event.category, event.status}
| sort count desc

すべてのアクティブな問題を確認する（→ 完全なクエリパターンについては dt-obs-problems を読み込んでください）

fetch dt.davis.problems, from: -24h
| filter not(dt.davis.is_duplicate) and event.status == "ACTIVE"
| fields event.start, display_id, event.name, event.category
| sort event.start desc
| limit 20

ベストプラクティス

1. メトリクスの挙動に合わせてモデルを選ぶ — 厳密な SLO 境界には静的モデル、自然な固定上限がないメトリクスには適応型モデル、営業時間や週次パターンに従うものには季節性モデルを使用します。
2. 検出器の対象範囲を狭くする — 関連するエンティティのみを対象にするエンティティセレクターを使用すると、ノイズが減り、問題への対応がしやすくなります。
3. 本番環境に移行する前に感度を調整する — まず感度を LOW に設定し、誤検知率を確認してから MEDIUM または HIGH に上げます。
4. 通知の前に Davis にノイズを除去させる — ワークフロー通知は、個々のアラートイベントではなく問題をトリガーにします。問題は相関するアラートをまとめるため、メトリクスごとではなく、インシデントごとに1回通知できます。
5. 重大度レベルで通知をフィルタリングする — event.severity <= 2 の問題はオンコールチャネルに即時にルーティングし、event.severity >= 3 の問題は緊急度の低いチャネルにルーティングします。重大度は検出器の設定で指定するか、パイプラインルールまたはワークフローで割り当てます。
6. ルーティングには dt.alert_group イベントプロパティを使用する — dt.alert_group を割り当てて、アラートを適切なチームにルーティングします。検出器の設定で静的な値を指定するか、DQL クエリ結果のマッピングで動的に割り当てるか、パイプラインルールで割り当てます。
7. 同じ条件のアラートを1つの検出器と1つのワークフローにまとめる — 同じメトリクスとしきい値で複数のエンティティを対象にアラートを設定する場合は、by: { <dimension> } と結合した filter: 句を使用して、1つの DQL ベースの検出器にまとめます。その検出器内のすべての条件に同じ dt.alert_group 値を割り当て、ワークフローの通知チャネルをそのグループ1つに設定します。論理的なアラートグループごとに1つの検出器と1つのワークフローを使用するほうが、N 個の検出器と N 個の通知ルールを使用するよりも拡張性に優れます。また、新しいエンティティの追加も、検出器やワークフローを一から追加するのではなく、フィルターを1行変更するだけで済みます。

関連スキル

• dt-obs-problems — 検出された問題のクエリ、分析、傾向の把握
• dt-obs-predictive-analytics — MCP アナライザーツールを使用したアドホックな異常検知と新規性検知（永続的なアラート設定ではありません）
• dt-platform — 異常検知器の運用状況（実行イベント、失敗率）
• dt-platform-costs — 異常検知器の DQL が発生させるクエリコスト
• dt-sdlc-quality-gates — デプロイゲートのアラート設定に使用する Site Reliability Guardian
• dt-dql-essentials — 検出器のクエリとアラート履歴のクエリを記述するための DQL 構文