dd-monitors

Datadog モニター

アラート用のモニターを作成、管理、保守します。

前提条件

pup がパスに含まれている必要があります。Pup のセットアップを参照してください。

コマンド実行順序（トークン効率化）

対象を絞ったコマンドでは、次の順序で実行してください。

1. まずコンテキストを確認します（過去の出力、会話、保存済みの値）。
2. 必須の値が不足している場合は、まず情報を確認するコマンドを実行します。
3. それでも曖昧な場合は、ユーザーに確認を求めます。
4. その後、対象のコマンドを実行します。
5. 失敗する可能性が高い、推測に基づくコマンドは避けます。

クイックスタート

pup auth login

よく使う操作

モニターの一覧表示

pup monitors list
pup monitors list --tags "team:platform"

モニターの取得

pup monitors get <id>

モニターの作成

pup monitors create --file monitor.json

アラートの一時停止（ダウンタイム）

# No pup monitors mute/unmute commands.
# Use downtime payloads to silence monitor notifications.
pup downtime create --file downtime.json
pup downtime cancel <downtime_id>

モニター作成のベストプラクティス

1. アラート疲れを防ぐ

ルール	理由
頻繁に発生・解消を繰り返すアラートを避ける	last_1m ではなく last_Xm を使用します
意味のあるしきい値を設定する	推測ではなく、SLO に基づいて設定します
対応可能なアラートにする	対応が不要な場合は、アラートを出さないようにします
ランブックを含める	メッセージに @runbook-url を含めます

# WRONG - will flap constantly
query = "avg(last_1m):avg:system.cpu.user{*} > 50"  # ❌ Too sensitive

# CORRECT - stable alerting
query = "avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 80"  # ✅ Reasonable window

2. 適切なスコープを設定する

# WRONG - alerts on everything
query = "avg(last_5m):avg:system.cpu.user{*} > 80"  # ❌ No scope

# CORRECT - scoped to what matters
query = "avg(last_5m):avg:system.cpu.user{env:prod,service:api} by {host} > 80"  # ✅

3. 復旧しきい値を設定する

monitor = {
    "query": "avg(last_5m):avg:system.cpu.user{env:prod} > 80",
    "options": {
        "thresholds": {
            "critical": 80,
            "critical_recovery": 70,  # ✅ Prevents flapping
            "warning": 60,
            "warning_recovery": 50
        }
    }
}

4. メッセージにコンテキストを含める

message = """
## High CPU Alert

Host: {{host.name}}
Current Value: {{value}}
Threshold: {{threshold}}

### Runbook
1. Check top processes: `ssh {{host.name}} 'top -bn1 | head -20'`
2. Check recent deploys
3. Scale if needed

@slack-ops @pagerduty-oncall
"""

モニターを直接削除しないでください

安全な削除ワークフローを使用します（ダッシュボードと同様です）。

def safe_mark_monitor_for_deletion(monitor_id: str, client) -> bool:
    """Mark monitor instead of deleting."""
    monitor = client.get_monitor(monitor_id)
    name = monitor.get("name", "")
    
    if "[MARKED FOR DELETION]" in name:
        print(f"Already marked: {name}")
        return False
    
    new_name = f"[MARKED FOR DELETION] {name}"
    client.update_monitor(monitor_id, {"name": new_name})
    print(f"✓ Marked: {new_name}")
    return True

モニターの種類

種類	用途
metric alert	CPU、メモリ、カスタムメトリクス
query alert	複雑なメトリクスクエリ
service check	Agent のチェック状態
event alert	イベントストリームのパターン
log alert	ログパターンのマッチング
composite	複数のモニターを組み合わせます
apm	APM メトリクス

モニターの監査

# Find monitors without owners
pup monitors list | jq '.[] | select(.tags | contains(["team:"]) | not) | {id, name}'

# Find noisy monitors (high alert count)
pup monitors list | jq 'sort_by(.overall_state_modified) | .[:10] | .[] | {id, name, status: .overall_state}'

ダウンタイムとミュートの違い

使用する機能	使用する状況
ダウンタイム	計画的にアラートを停止する時間帯全般
モニターの編集	クエリやしきい値の動作を変更する場合

# Downtime (preferred)
pup downtime create --file downtime.json

失敗時の対応

問題	解決方法
アラートが発生しない	クエリがデータを返すか、しきい値を確認します
アラートが多すぎる	ウィンドウを長くし、復旧しきい値を追加します
データなしのアラート	Agent の接続状態とメトリクスの存在を確認します
認証エラー	pup auth refresh

参考資料

• モニターの種類
• アラートのベストプラクティス
• SLO モニター