documentation_publique:concepts:suivi [Wiki UNG]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
# 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.

## Documentation

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

## Ressources en lien avec le SI de l'UTT

Voir [[sia:explications:cri|SI de l'UTT]]

## Inventaire

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 physique

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


## Inventaire logique et administratif
```
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.

### Liens des entités dans l'inventaire

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

## Monitoring

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

### 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/


### Alerting

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)

### Debugging dashboards

### Logging