Suivi de l'infrastructure

Le suivi de l'infrastructure permet de découvrir et de maintenir l'infrastructure. Pour cela, il est nécessaire de mettre en place les fonctions suivantes.

Dans le cadre d'une infrastructure informatique, l'objectif de la documentation est double:

• donner une vision global du fonctionnement, pour permettre un accès rapide aux nouveaux venus
• permettre la compréhension rapide d'un domaine particulier, pour résoudre les incidents et pour développer le domaine

Idéalement, toutes les informations seraient accessibles au même endroit, mises à jour en temps réel directement par l'infrastructure. Il n'existe cependant pas (encore ?) de solutions permettant une documentation complète.

Il existe cependant des services permettant de centraliser certaines informations. Comprendre l'infrastructure passe donc par la recherche d'information dans différents systèmes d'informations (wiki, services de documentation, services dédiés, configuration des équipements).

L'inventaire permet de découvrir les services existants sur l'infrastructure, en plus de la documentation. Avoir un inventaire sous un format connu, plutôt que simplement sous la forme d'une documentation, permet également de l'utiliser depuis d'autres services.

L'inventaire comprend à la liste des équipements et des services, leur configuration et certaines données (notemment les secret).

Dans l'idéal, il existe deux inventaires: le premier décrit l'état désiré du service, le second l'état actuel (opérationnel).

Idéalement, l'inventaire opérationnel est rempli de façon automatique. L'inventaire désiré devrait toujours avoir une supervision, cela passe donc par une entrée de données manuelle, et (pour plus de facilité), une validation de la transition d'une donnée depuis l'inventaire opérationnelle vers l'inventaire désiré.

L'inventaire comprend les fonctions suivantes:

• IPAM: Gestion des adresses IPs
• Gestion des certificats
• Gestion des noms de domaines
• DCIM: Gestion des infrastructures physique:
  • Baies / Racks
  • Réseau éléctrique
  • Réseau informatique
  • Climatisation
• Gestion du Cloud
• Gestion du stockage
• Gestion du matériel informatique (disques, cartes réseaux, clavies, laptops, …)

L'objectif du monitoring est de permettre le suivi l'évolution de l'infrastructure. Ceci afin d'anticiper, de détecter et de résoudre les problèmes.

Cela passe donc par la visualisation de l'état de l'infrastructure, à la fois son état présent, ses états passés et l'analyse de l'évolution (et les prédictions sur l'état future).

On distingue parfois deux formes de monitoring:

• blackbox monitoring: observation des objets d'un point de vue externe (par exemple si l'objet est un machine, une seconde machine peut effectuer un ping régulier [heartbeat] pour vérifier qu'elle est en ligne).
• whitebox monitoring: observation des objets d'un point de vue interne (l'objet reporte lui-mêmes les informations le concernant).

Symptoms (User perspective) vs Causes (Admin perspective, sometimes no impact on users)

Application monitoring vs Server monitoring

Application healthcheck (by accuracy):

• command (redis-cli ping) [whitebox]
• application probe (HTTP GET, …) [blackbox]
• transport probe (tcp/udp/…) [blackbox]

Server healthcheck:

• network probe (ping) [blackbox]

Service monitoring (Continuous) vs Job monitoring (Action success)

Job monitoring ⇒ Job result not present () vs Job failure (cause, not triggered if host down)

L'inventaire opérationnel est l'un des outils du monitoring

Evolution de l'infrastructure

Blackbox: (from the outside)

• Healthchecks (ping,

Whitebox: (from the inside)

• Logs
• Traces
• Metrics

RED

USE: utilization, saturation, and errors (http://www.brendangregg.com/usemethod.html)

The Four Golden Signals (latency, saturation, traffic, and error)

Alerts on traffic

• traffic amount (derivative of requests counts)
• traffic spike (derivative of traffic amount, take pattern into account [less requests at night])
• traffic pattern derivation (compare pattern to previous day/day of the week)

https://blog.digitalocean.com/observability-and-metrics/

Maintenance prédictive (Certificate expiry, low storage, …) Réparation (node taken offline)

Plusieurs niveaux d'alertes:

• Debug (actions mises en place par le système) [par exemple, certificat renouvelé automatiquement]
• Action requise

Urgence vs Priorité:

• urgence: nécessite une action immédiate
• priorité: nécessite d'être prise en compte

Alertes non urgente: batch mode (immediate, then X times a day)

Alerte peux prendre plusieurs formes:

• Slack / IRC
• Auto filling a ticket
• Email
• Report (X times a day)
• Page someone (active alert)

Symptom based (user can't reach a service) vs cause based (server is down)

Most cause based alerts should be on debugging dashboards ?

https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/edit

Gestionnaire d'alertes:

• deduplicate: même alerte (service down) de deux sources différente (ping + internal) → une seule alerte
• group: groupe les alertes liées
• route: notifie uniquement l'équipe responsable
• silence: silence une alerte si une autre est déjà en cours (par exemple host down silence service unavailable)