Moniteurs Datadog

Créez, gérez et maintenez des moniteurs pour les alertes.

Prérequis

Cela nécessite pup dans votre chemin. Voir Setup Pup.

Ordre d'exécution des commandes (efficace en tokens)

Pour les commandes avec portée, utilisez cet ordre :

1. Vérifiez d'abord le contexte (résultats antérieurs, conversation, valeurs enregistrées).
2. Si une valeur requise manque, exécutez d'abord une commande de découverte.
3. Si c'est toujours ambigu, demandez à l'utilisateur de confirmer.
4. Puis exécutez la commande cible.
5. Évitez les commandes spéculatives susceptibles d'échouer.

Démarrage rapide

pup auth login

Opérations courantes

Lister les moniteurs

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

Obtenir un moniteur

pup monitors get <id>

Créer un moniteur

pup monitors create --file monitor.json

Silencer les alertes (Downtime)

# Pas de commandes pup monitors mute/unmute.
# Utilisez des payloads downtime pour silencer les notifications de moniteur.
pup downtime create --file downtime.json
pup downtime cancel <downtime_id>

⚠️ Bonnes pratiques de création de moniteurs

1. Éviter la fatigue d'alerte

# WRONG - sera instable constamment
query = "avg(last_1m):avg:system.cpu.user{*} > 50"  # ❌ Trop sensible

# CORRECT - alertes stables
query = "avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 80"  # ✅ Fenêtre raisonnable

2. Utiliser une portée appropriée

# WRONG - alerte sur tout
query = "avg(last_5m):avg:system.cpu.user{*} > 80"  # ❌ Pas de portée

# CORRECT - porté à ce qui compte
query = "avg(last_5m):avg:system.cpu.user{env:prod,service:api} by {host} > 80"  # ✅

3. Définir des seuils de récupération

monitor = {
    "query": "avg(last_5m):avg:system.cpu.user{env:prod} > 80",
    "options": {
        "thresholds": {
            "critical": 80,
            "critical_recovery": 70,  # ✅ Prévient l'instabilité
            "warning": 60,
            "warning_recovery": 50
        }
    }
}

4. Inclure du contexte dans les messages

message = """
## Alerte CPU élevée

Host : {{host.name}}
Valeur actuelle : {{value}}
Seuil : {{threshold}}

### Runbook
1. Vérifier les processus principaux : `ssh {{host.name}} 'top -bn1 | head -20'`
2. Vérifier les déploiements récents
3. Scaler si nécessaire

@slack-ops @pagerduty-oncall
"""

⚠️ Ne JAMAIS supprimer les moniteurs directement

Utilisez un flux de suppression sécurisé (comme pour les dashboards) :

def safe_mark_monitor_for_deletion(monitor_id: str, client) -> bool:
    """Marquer le moniteur au lieu de le supprimer."""
    monitor = client.get_monitor(monitor_id)
    name = monitor.get("name", "")

    if "[MARKED FOR DELETION]" in name:
        print(f"Déjà marqué : {name}")
        return False

    new_name = f"[MARKED FOR DELETION] {name}"
    client.update_monitor(monitor_id, {"name": new_name})
    print(f"✓ Marqué : {new_name}")
    return True

Types de moniteurs

Auditer les moniteurs

# Trouver les moniteurs sans propriétaires
pup monitors list | jq '.[] | select(.tags | contains(["team:"]) | not) | {id, name}'

# Trouver les moniteurs bruyants (nombre d'alertes élevé)
pup monitors list | jq 'sort_by(.overall_state_modified) | .[:10] | .[] | {id, name, status: .overall_state}'

Downtime vs Silencieux

# Downtime (préféré)
pup downtime create --file downtime.json

Gestion des défaillances

Références

• Monitor Types
• Alerting Best Practices
• SLO Monitors