Generees depuis ce que chaque role declare, avec un schema mermaid et la raison de chaque ligne. Une section vide est une information : l index recompte ce que la flotte ne declare pas — 36 sans flux, 40 sans sonde, 67 sans metrique. La charte du wiki disait de ne pas recopier le depot, pour eviter la derive. Le motif ne vaut pas pour une page qui relit sa source ; l exception est nommee plutot que prise en silence. La navigation exigeait une citation DIRECTE alors que son motif parle d atteignabilite. L exigence litterale interdisait toute page d index — la garde forcait a degrader ce qu elle protegeait. Elle suit maintenant les liens de proche en proche, et son motif reconnait le souligne : un motif trop etroit ne rend pas une garde prudente, il la rend aveugle. Et le compte du wiki serait passe de 27 a 96 : une fiche generee n est pas une unite d apprentissage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
3 KiB
3 KiB
Rôle serveur_postgresql
Généré par
scripts/fiche_role.pydepuis lesmeta/de ce rôle. Ne pas éditer à la main : corriger la déclaration, puis régénérer.
Pour qui : celui qui doit agir sur ce rôle et veut savoir, avant de toucher quoi que ce soit, qui lui parle, ce qu'il rend, et ce qu'il coûte.
graph LR
R["<b>postgresql</b>"]
E0["forgejo"] -->|"5432 · tls-requis"| R
E1["icinga"] -->|"5432 · tls-requis"| R
E2["keycloak"] -->|"5432 · tls-requis"| R
E3["nextcloud"] -->|"5432 · tls-requis"| R
E4["prometheus"] -->|"9187 · clair"| R
R -.->|"sonde « base »"| ICINGA[["Icinga"]]
R -.->|"9187 · postgresql"| PROM[["Prometheus"]]
Qui lui parle
| port | depuis | chiffrement | pourquoi |
|---|---|---|---|
5432 |
serveur_keycloak, serveur_forgejo, serveur_icinga, serveur_nextcloud |
tls-requis | Connexions applicatives à PostgreSQL (verify-full ; pg_hba hostssl). |
9187 |
serveur_prometheus |
clair | Metriques PostgreSQL lues par l'observatoire. Series, pas verdicts : ce qui derive lentement — cache qui decroche, connexions qui montent, bases qui grossissent — n'a que le graphe pour se faire voir. En clair pour l'instant, contrairement a client_metrique : dette inscrite, a fermer par --web.config.file + client_pki. |
Ce qu'il rend à la supervision
| sonde | TTL | ce qu'elle voit |
|---|---|---|
base |
5400 s | La base repond-elle a une VRAIE requete, et lui reste-t-il des connexions ? Un PostgreSQL a court de connexions accepte encore le port et refuse tout le monde : chaque application tombe en meme temps sans que la base ait l'air morte. |
Ce qu'il expose en séries
Exportateur prometheus-postgres-exporter — port 9187, job postgresql.
| panneau | unité | pourquoi on le regarde |
|---|---|---|
| Connexions utilisées | connexions | La sonde Icinga crie a 70 % et a 90 %. Ce panneau dit ce qu'elle ne peut pas dire : depuis QUAND ca monte. Une base qui passe de 20 a 60 connexions en trois semaines n'a rien casse — elle annonce la date ou elle cassera. |
| Taux de succès du cache | ratio | CELUI-LA N'AURA JAMAIS DE VERDICT, et c'est pourquoi il compte. Quand les donnees depassent shared_buffers, la base va chercher sur disque de plus en plus souvent. Rien ne casse, rien n'alerte : tout devient lent. C'est exactement la panne qu'un graphe voit et qu'une sonde ne verra jamais. |
| Taille des bases | octets | La croissance est la seule chose qu'on ne peut pas mesurer apres coup. Savoir qu'une base a double en deux mois se decide deux mois plus tot — ou jamais. |
| Transactions par seconde | tps | Le contexte des trois autres. Des connexions qui montent a charge CONSTANTE ne disent pas la meme chose que des connexions qui montent parce que le travail a double — et le geste qui suit n'est pas le meme non plus. |
Ce qu'il coûte, et qui entre
- Empreinte : 2 cœur(s), 2048 Mo, 20 Go.
- Authentification :
sans-auth-humaine— Comptes de service, secrets en voute ; pas d'humain.