1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
---
title: "Supervision"
description: "Supervision"
weight: 58
sort_by: "weight"
extra:
parent: 'operations/_index.md'
---
# Journaux
Les journaux ne sont pas centralisés aujourd'hui.
Vous pouvez les consulter avec `docker logs`, `nomad` et `journalctl`.
# Métriques
Grafana est accessible à l'adresse suivante : https://grafana.deuxfleurs.fr
La connexion est possible avec ses identifiants Guichet (via LDAP).
Pour les admins, il est aussi possible d'utiliser le mot de passe admin en allant le chercher dans Consul KV.
Les dashboards ne sont pour l'instant pas stockés dans un dépot git, ils sont édités manuellement dans l'interface de Grafana.
Il y a également une instance Grafana de staging, sans intégration LDAP/Guichet : https://grafana.staging.deuxfleurs.org
# Supervision et alerting externe
Nous avons un système de supervision externe, accessible à l'adresse <https://status.deuxfleurs.fr>.
Il s'agit d'une instance de [Uptime Kuma](https://github.com/louislam/uptime-kuma), hébergée gracieusement par [RésiLien](https://resilien.fr/).
Son but est de vérifier le bon fonctionnement des services exposés publiquement par Deuxfleurs : sites web statiques, services web (cryptpad, jitsi, plume), email, ainsi que l'API S3 de Garage.
Pour rajouter des services à surveiller ou configurer des envois d'alertes, les identifiants de connexion sont dans le [dépôt des secrets](@/operations/pass.md).
Un bot envoie les alertes sur le canal Matrix `deuxfleurs::alertes`. Ce bot est un compte Matrix Deuxfleurs ajouté manuellement dans LDAP, les identifiants de ce compte sont dans le [dépôt des secrets](@/operations/pass.md) (entrée `monitoringbot`).
# Alerting interne
Nous ne disposons actuellement pas de supervision interne complète avec envoi d'alertes.
Une telle supervision interne serait complémentaire à la supervision externe : elle permettrait de détecter des problèmes en amont qui ne sont pas forcément encore visibles sur les services.
Par exemple, Garage tolère la panne d'une zone sans impacter le service, il est donc facile de ne pas se rendre compte de la panne ... jusqu'à ce qu'une deuxième panne arrive !
Les éléments suivants seraient pertinents à surveiller :
- système : espace disque, état SMART des disques, charge I/O
- connectivité : connectivité interne Wireguard, IPv6
- état du cluster Garage (perte d'une zone ou d'un noeud)
- état du cluster Nomad
- état du cluster Consul
- état du cluster Stolon
- état des backups
- crash dans le catalog consul / les allocs nomad
|
