Monitors et incidents
Créez et contrôlez des monitors planifiés, puis triez les incidents depuis le terminal.
Un monitor exécute un test selon un planning. Quand une exécution surveillée enfreint une règle d'alerte, elle déclenche un incident. Les deux sont scriptables depuis le CLI, ce qui convient à l'automatisation d'astreinte et aux dashboards.
Créer et contrôler les monitors
# Planifier un monitor pour un test (définir la cadence avec --scheduling ; voir le lien ci-dessous)
ktm monitors create --product acme~web --test-id 16480 --variant "API:Prod" --scheduling "<schedule>" --start
# Lister, forcer une exécution immédiate, mettre en pause ou reprendre en masse
ktm monitors list --operator acme -o table
ktm monitors force-run <monitor-id>
ktm monitors toggle --ids 12,13 --active false
Voir Planification pour le format de cadence et Monitoring pour les concepts.
Trier les incidents
# Aperçu rapide : compteurs ouverts / avertissement / fermés
ktm incidents counter --operator acme
# Lister les incidents ouverts, puis en inspecter un
ktm incidents list --operator acme --status OPEN
ktm incidents get --operator acme --id 4567
# Le fermer une fois traité
ktm incidents close --operator acme --id 4567
Voir les exécutions récentes d'un monitor
ktm monitoring-results list --product acme~web --monitoring-id <monitor-id>
Le CLI vous indique *qu'*un monitor a échoué. Pour comprendre pourquoi en langage naturel, le serveur MCP est généralement plus rapide : demandez à votre assistant « pourquoi le monitor 4521 a-t-il échoué, et qu'est-ce qui a changé ? » Voir Exemples MCP.
Et ensuite ?
Last updated on