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).

Voir SI de l'UTT

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 (en particulier les secret).

Il devrait exister 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é.

On peut distinguer l'inventaire physique de l'inventaire logique.

Inventaire relativement statique

Équipements (Modèle, localisation et configuration)
  Serveurs
  Équipements réseaux
  Équipements électrique
Liens électriques
Liens informatiques
Arrangement des baies
Climatisation
Composants installés

Inventaire dynamique / stocké

Ordinateur portables
Périphériques
  Écrans
  Claviers
  Souris
  Adaptateurs
Gestion des espaces de stockage

Composants

CPU
Disques
Mémoire RAM
Carte réseau
Autres cartes d'extensions
Autres modules (Alimentation, modules switchs, SFP, ...)

Addresses IPs (IPAM)
Noms de domaines
Certificats
Liens informatique (link bonding, VPN, ...)
Machines virtuelles / Containers
Services
  Sites webs
Images systèmes
Configurations systèmes
Infrastructures Cloud

Au paroxysme de l'inventaire logique, il n'existe plus de distinction entre inventaire manuel et inventaire opérationnel, car le panneau de contrôle et l'inventaire utilisent les mêmes structures de données.

Pour découvrir l'infrastructure, il y a deux moyens :

de l'hébergement vers le service, c'est à dire répondre à la question “A quoi sert X (VM, serveur, cluster, …), quelles entités (services, VM, fonctions, …) sont dessus ?”
du service vers l'hébergement, c'est à dire répondre à la question “Comment ça (service, VM, …) tourne, où est-ce hébergé ?”

Pour permettre ces deux méthodes de découverte, toutes ces entités devraient avoir un article dédié, et des liens devraient être fait dans les deux sens pour :

applications ←→ hébergement
cluster ←→ machines
VM/container ←→ cluster/machine

Il faut également distinguer un service rendu (authentification), de son implémentation, c'est à dire du logiciel utilisé et de sa configuration. Il existera donc également le lien service(s) <--> application(s)

L'objectif du monitoring est de permettre le suivi l'évolution de l'infrastructure. Le principal intérêt du monitoring consiste à éviter et résoudre les panne de service. Cela à donc une utilité avant (anticipation et prévention), pendant (détection et résolution), et après (analyse) qu'un problème apparaisse.

Cela passe donc par la visualisation de l'état de l'infrastructure, à la fois son état présent, ses états passés et des 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)