Downtimes

Planifiez des downtimes pour éviter de déclencher vos monitors en cas d’arrêt système, de maintenance hors ligne ou de mise à niveau. Les downtimes désactivent les alertes et les notifications de l’ensemble des monitors, mais n’empêchent pas les monitors de changer d’état.

Planifier un downtime

Pour planifier un downtime de monitor dans Datadog, utilisez le menu principal : Monitors –> Manage Downtime. Cliquez ensuite sur le bouton Schedule Downtime en haut à droite.

Choisir les éléments à désactiver

Utilisez le menu déroulant pour choisir les monitors à désactiver ou la fonction de recherche pour les trouver. Si vous choisissez de laisser le champ vide, tous les monitors seront désactivés par défaut. Vous pouvez également sélectionner un contexte afin de limiter votre downtime à un host, appareil ou tag de votre choix. Seuls les monitors qui correspondent à TOUS les contextes sélectionnés sont désactivés.

Planifiez un downtime basé sur un ou plusieurs tags de monitor. Vous devez sélectionner au moins un tag, et il n’est pas possible de définir plus de 32 tags. Les noms de tag ne doivent pas dépasser 256 caractères. Seuls les monitors possédant TOUS les tags sélectionnés sont désactivés. Vous pouvez également sélectionner des contextes pour restreindre encore plus le downtime.

Si vous choisissez de désactiver des monitors limités par un contexte, cliquez sur Preview affected monitors pour voir les monitors inclus. Tous les monitors créés ou modifiés après la planification du downtime sont automatiquement inclus dans le downtime s’ils correspondent au contexte.

Contexte des downtimes

Si vous limitez un downtime à un simple monitor d’alerte, vous pouvez ignorer le champ Group scope. En effet, votre monitor d’alerte est agrégé sur l’ensemble des sources de transmission afin d’envoyer une seule alerte.

Si un monitor à alertes multiples est inclus, il est uniquement désactivé pour les groupes couverts par le contexte. Par exemple, si un downtime est couvert par le contexte host:X et qu’une alerte multiple est déclenchée pour host:X et host:Y, Datadog envoie une notification de monitor pour host:Y, mais pas pour host:X.

Pour inclure tous les groupes dans la portée d’un downtime appliqué à des monitors à alertes multiples, définissez Group scope sur All.

L’exemple ci-dessous illustre comment appliquer Group scope à des monitors à alertes multiples.

Exemple 1 : désactiver les notifications d’un service spécifique

  1. Pour planifier un downtime pour un seul groupe (ici, service:web-store), saisissez le nom de ce groupe dans le champ Group scope.
  2. L’option Preview affected monitors indique que le monitor sélectionné est toujours couvert par le contexte. Par conséquent, les alertes concernant le groupe service:web-store sont désactivées lors du downtime planifié.
exemple de downtime
  1. Le downtime planifié commence, et seules les alertes concernant le groupe service:web-store sont désactivées pour ce monitor.
exemple de downtime
  1. Pour planifier un downtime sur plusieurs groupes (par exemple, service:synthesizer et service:consul), vous pouvez créer un downtime supplémentaire par groupe.

Exemple 2 : désactiver les notifications pour un environnement spécifique d’un monitor regroupé en fonction de env et service

  1. Pour planifier un downtime pour l’un des groupes (ici, env:dev), saisissez le nom de ce groupe dans le champ Group scope.
  2. L’option Preview affected monitors indique que le monitor sélectionné est toujours couvert par le contexte. Par conséquent, les alertes concernant le groupe env:dev sont désactivées lors du downtime planifié.
downtime en fonction du nom du monitor avec l'environnement dev couvert
  1. Le downtime planifié commence, et les alertes concernant le groupe env:dev et tous les services associés à l’environnement dev sont désactivées.
statut du groupe indiquant que les alertes de l'environnement dev et des services connexes sont désactivées lors du downtime
  1. Pour planifier un downtime avec plusieurs critères de regroupement (par exemple, env:dev ET service:web-store), ajoutez le contexte supplémentaire au downtime.

Si un downtime planifié repose sur un tag de monitor commun et que les monitors couverts envoient des alertes multiples avec un critère de regroupement, le champ Group scope vous permet de désactiver un groupe commun aux monitors couverts.

Exemple 1 : deux monitors à alertes multiples, chacun avec un critère de regroupement, partagent le tag de monitor downtime:true.

  1. Le monitor A est un moniteur à alertes multiples pour les hosts transmettant une métrique de moyenne, calculée pour plusieurs groupes service.
  2. Le monitor B est un moniteur à alertes multiples pour les hosts transmettant la même métrique pour service:web-store.
  3. Un downtime est planifié pour tous les monitors qui possèdent le tag de monitor downtime:true.
  4. Ce downtime est limité au groupe service:web-store.
  5. L’option Preview affected monitors affiche les deux monitors qui partagent le groupe service:web-store.
exemple de downtime
  1. Le monitor A indique que le downtime a commencé, mais uniquement pour le groupe couvert par le contexte : service:web-store.
exemple de downtime
  1. Le monitor B indique que le downtime a commencé pour service:web-store. Puisque tous les groupes du monitor (basés sur host) appartiennent à service:web-store, tous les hosts sont désactivés pour ce monitor lors du downtime.
exemple de downtime

Planifier un downtime

Définissez un downtime ponctuel en saisissant la date et l’heure de début, ainsi que le fuseau horaire. Vous pouvez aussi définir une date et une heure de fin.

downtime sur une alerte

Les downtimes récurrents sont utiles pour les périodes de maintenance récurrentes.

Définissez un downtime récurrent en saisissant la date et l’heure de début, le fuseau horaire, la répétition et la durée. Vous pouvez aussi préciser une date de fin ou un nombre d’occurrences.

Lorsqu’une occurrence d’un downtime récurrent prend fin, cette occurrence est annulée et un nouveau downtime possédant les mêmes caractéristiques (avec une nouvelle date de début et de fin) est créé. Remarque : le créateur d’origine est associé à tous les nouveaux downtimes créés.

downtime sur une alerte

Utilisez des RRULE, ou règles de récurrence, pour planifier des downtimes. Servez-vous du générateur de RRULE officiel pour créer des règles de récurrence.

Ces règles vous permettent notamment de définir des downtimes pour certains jours du mois, par exemple le 3e lundi de chaque mois :

downtime sur une alerte

Remarque : les attributs spécifiant une durée ne sont pas pris en charge par les RRULE (par exemple, DTSTART, DTEND ou DURATION).

Ajouter un message

Saisissez un message pour informer votre équipe à propos de ce downtime. Le champ de message prend en charge la mise en forme Markdown standard ainsi que la fonction de notification « @ » de Datadog.

Informer votre équipe

Informez votre équipe en spécifiant les membres de l’équipe ou envoyez le message à une intégration de service.

Désactiver la première notification de rétablissement

Par défaut, Datadog envoie une notification de rétablissement pour les monitors qui se déclenchent avant un downtime et se rétablissent pendant celui-ci. Cette notification s’avère particulièrement utile si vous utilisez des intégrations tierces pour fermer automatiquement des incidents en cours. Cochez la case indiquée ci-dessous pour désactiver l’envoi de ces notifications.

désactiver la première notification de rétablissement

Cette option peut se cumuler sur plusieurs downtimes. Par exemple, si un certain nombre de downtimes se chevauchent et qu’ils désactivent un même monitor, la première notification de rétablissement est désactivée tant que l’option est activée pour au moins un de ces downtimes.

Remarque : cette option désactive la première notification de rétablissement. Si un monitor se déclenche et est rétabli pendant un downtime, les notifications correspondantes sont toujours désactivées, et ce peu importe les paramètres de l’option.

Gérer les downtimes

La page Manage Downtime affiche la liste des downtimes actifs et planifiés. Sélectionnez un downtime pour afficher ses détails, le modifier ou le supprimer. Les détails d’un downtime comprennent son créateur, son contexte et la liste des monitors auxquels il s’applique. Utilisez le volet des facettes et la barre de recherche pour filtrer la liste en fonction du Creator, du Scope, des Monitor Tags ou encore des paramètres Active, Automuted ou Recurring.

page Manage Downtime

History

L’historique des downtimes est accessible depuis la page Monitor Status (il est superposé à l’historique de transition des groupes). Vous pouvez également le consulter dans l’Events Explorer en recherchant tags:audit,downtime, ou en précisant un ID de downtime spécifique : tags:audit,downtime_id:<ID_DOWNTIME>.

Désactivation

Les monitors déclenchent des événements lorsque leur statut, à savoir ALERT, WARNING, RESOLVED et NO DATA, change. Lorsqu’un monitor est désactivé ou fait l’objet d’un downtime planifié et que son statut passe de RESOLVED à un autre statut, aucun événement ni aucune notification ne se déclenche.

downtime sur une alerte

Remarque : si vous désactivez ou réactivez les notifications d’un monitor à partir de la page de statut du monitor, les downtimes planifiés associés à ce monitor ne sont pas supprimés. Pour modifier ou supprimer un downtime, utilisez la page Manage Downtimes ou passez par l’API.

Expiration

Si un monitor possède un état nécessitant l’envoi d’une alerte (ALERT, WARNING ou NO DATA) lorsque le downtime prend fin, le monitor déclenche l’envoi d’une nouvelle notification. Cette logique s’applique aux monitors qui changent d’état lors d’un downtime (en passant par exemple de l’état OK à l’état ALERT, WARNING ou NO DATA), ainsi qu’aux monitors qui possédaient déjà un état nécessitant l’envoi d’une alerte au début du downtime. Lorsqu’un downtime est annulé manuellement, les notifications ne sont pas envoyées, même si le monitor passe à un état nécessitant l’envoi d’une alerte.

1er exemple : monitor possédant un état d’alerte avant le début du downtime et conservant le même état pendant la durée du downtime :

  1. Pendant le downtime, les notifications pour cette alerte sont désactivées.
  2. Le monitor conserve son état d’alerte, car les conditions sont toujours remplies.
  3. Le downtime prend fin.
  4. Les conditions d’alerte sont toujours remplies, ce qui déclenche l’envoi d’une notification.

2e exemple : monitor possédant un état d’alerte avant le début d’un downtime et rétabli pendant le downtime :

  1. Le monitor passe d’un état d’alerte à l’état OK.
  2. La notification de rétablissement est envoyée pendant le downtime, mais uniquement pour le premier rétablissement de ce downtime.

Rapport sur les monitors

Tous les états d’alerte sont inclus dans le rapport hebdomadaire sur les monitors, même si le monitor est en downtime.

Pour aller plus loin