Ceci est un article invité d'Ilan Rabinovitch, directeur de la gestion des produits chez Chien de données .

La convergence du développement rapide des fonctionnalités, de l'automatisation, de la livraison continue et de la composition changeante des piles technologiques modernes a poussé les exigences de surveillance à une échelle potentiellement écrasante. Mais si les systèmes que vous devez surveiller sont complexes, votre stratégie de surveillance n'a pas à l'être non plus.

Chez Datadog, nous constatons la demande de surveillance à grande échelle en tant que produit de quatre changements :

1. Nombre croissant de composants d'infrastructure (microservices, instances, conteneurs)
2. Fréquence des changements de code et de configuration
3. Nombre de personnes et de rôles en interaction avec l'infrastructure
4. Prolifération de plateformes, d'outils et de services (de quelques packages de fournisseurs à de nombreux services hébergés et logiciels open source)

L'ampleur et le rythme des changements impliqués dans les opérations d'aujourd'hui exigent une stratégie de surveillance et de réponse aux incidents soigneusement élaborée. Garder la stratégie simple permettra d'alléger un peu la tâche de la surveillance.

Surveillez toutes les choses

Notre thème fédérateur pour le suivi est:

La collecte de données est peu coûteuse, mais ne pas les avoir lorsque vous en avez besoin peut être coûteux. Vous devez donc tout instrumenter et collecter toutes les données utiles que vous pouvez raisonnablement.

Lorsque vous surveillez autant de choses simultanément, des alertes automatisées et une stratégie de réponse aux incidents sont indispensables pour vous aider à éviter ou à minimiser les interruptions de service.

De toute évidence, une stratégie efficace de réponse aux incidents doit faire la distinction entre les problèmes qui nécessitent une attention immédiate et ceux qui peuvent attendre. Si vous ne parvenez pas à trouver le bon équilibre, vous risquez alerte fatigue , ce qui peut conduire à passer à côté de problèmes réels.

Notre objectif global approche de la gestion des alertes est:

• Collectez généreusement les alertes ; notifiez judicieusement (notamment par téléphone/SMS)
• Page sur les symptômes, pas sur les causes
• Prévenez la fatigue des alertes en séparant le signal du bruit dans vos notifications

Types d'alertes

Bien que nous vous recommandons de collecter généreusement les alertes, toutes les alertes ne sont pas traitées de la même manière. Vous pouvez organiser les alertes en plusieurs types : enregistrements (conservé dans votre système de surveillance pour référence ultérieure), ou des alertes qui sélectionnent l'urgence de notification appropriée en fonction de leur gravité (c'est-à-dire un e-mail ou un autre canal non interrompu pour une alerte de faible urgence et un appel téléphonique pour une alerte de haute urgence).

Vous pouvez déterminer le type d’alerte approprié en répondant à trois questions :

Question 1 : Le problème est-il réel ?

Non – Aucune alerte requise. Exemple : mesures dans un environnement de test

Oui – Passez à la question 2.

Question 2 : Le problème nécessite-t-il une attention particulière ?

Non – Comme aucune intervention n’est requise, l’alerte est simplement enregistré pour donner un contexte au cas où un problème plus grave surviendrait.

Oui – Passez à la question 3.

Question 3 : Le problème est-il urgent ?

Non – (Faible urgence) : Étant donné que l’intervention n’est pas immédiatement requis, vous pouvez envoyer une alerte automatiquement via un canal non interrompu comme le courrier électronique, le chat ou le système de billetterie.

Oui – (Urgence élevée) : ces problèmes nécessitent une intervention immédiate quelle que soit l'heure, par exemple en cas de panne ou de violation d'un accord de niveau de service. Les intervenants doivent être informés en temps réel par appel téléphonique, SMS ou tout autre canal qui attirera toute leur attention.

Les symptômes et non les causes

Lorsqu'une alerte est suffisamment grave pour qu'une personne soit appelée, dans la plupart des cas, cette page doit être liée à symptômes , pas les causes.

Un système qui cesse de faire un travail utile est un symptôme qui pourrait avoir une variété de causes . Par exemple, un site Web qui répond très lentement pendant trois minutes est un symptôme. Les causes possibles incluent la latence de la base de données, les serveurs d'applications défaillants, une charge élevée, etc.

La recherche de symptômes met l'accent sur les problèmes réels ayant un impact potentiel sur l'utilisateur. Les symptômes indiquent généralement des problèmes réels plutôt que potentiel ou des problèmes internes qui pourraient ne pas être critiques, ne pas affecter les utilisateurs ou revenir à des niveaux normaux sans intervention. Idéalement, les alertes liées peuvent toutes être automatiquement regroupées afin que lorsque les intervenants sont appelés, ils disposent de tout le contexte nécessaire pour diagnostiquer ce qui se passe et coordonner une réponse.

En plus de signaler des problèmes réels, les alertes déclenchées par des symptômes ont tendance à être plus durables, car elles se déclenchent dès qu'un système cesse de fonctionner comme il le devrait. En d'autres termes, vous n'avez pas besoin de mettre à jour vos définitions d'alerte à chaque fois que les architectures de votre système sous-jacent changent. Dans un environnement doté d'une infrastructure dynamique et de nombreux éléments mobiles, les alertes durables éliminent le travail supplémentaire et réduisent le risque d'apparition d'angles morts.

La règle des symptômes ne s'applique qu'aux cas où un problème est susceptible de se transformer en problème grave, même si le système fonctionne correctement. Un bon exemple est l'espace disque disponible insuffisant. Dans ce cas, la cause est une raison légitime d'envoyer une page, même avant l'apparition des symptômes.

D'autres stratégies d'alerte

Adopter un cadre raisonnable pour le suivi, alerte , et la pagination aide vos équipes à résoudre efficacement les problèmes de production sans être submergées par de fausses alarmes ou des alertes intermittentes. Pour plus de stratégies de surveillance, consultez notre Surveillance 101 série. Ou vous pouvez passer au stand Datadog à Sommet PagerDuty 2017 Nous serions ravis de vous montrer certains de ces principes en action et de discuter de la manière dont vous pouvez adapter votre stratégie de surveillance pour rendre les applications modernes plus observables. Nous espérons vous y voir nombreux.