---
title: Santé et supervision
description: Les sondes de liveness et de readiness, ce qu'elles vérifient ou non, le format des journaux et les signaux sur lesquels alerter.
canonical: https://developer.unico.io/fr/human-plugin/self-hosting/health-and-monitoring
locale: fr
generated_by: markdown-export
---

# Santé et supervision

Ce qu'il faut sonder, ce qu'il faut surveiller et ce que les sondes ne peuvent pas vous dire.

## Sondes

| Endpoint | Réponse | Usage |
| --- | --- | --- |
| `GET /health/live` | `200 {"status":"ok"}` tant que le processus traite des requêtes | Liveness |
| `GET /health/ready` | `200 {"status":"ok"}` quand PostgreSQL répond, sinon `503 {"status":"unavailable"}` | Readiness : n'acheminez du trafic qu'une fois prêt |

```yaml
livenessProbe:
  httpGet: { path: /health/live, port: 8080 }
readinessProbe:
  httpGet: { path: /health/ready, port: 8080 }
  timeoutSeconds: 5
```

Définissez `timeoutSeconds` sur la sonde de readiness. Si PostgreSQL accepte les connexions mais cesse de répondre, la vérification peut attendre bien plus longtemps, et le délai d'expiration fait échouer la sonde au lieu de la laisser bloquée.

### Ce que la readiness ne vérifie pas

La readiness ne vérifie que la base de données. Elle ne vérifie **pas** que la clé d'accès est valide ni qu'Unico est joignable. Une clé d'accès incorrecte se manifeste par des erreurs à la création, pas par l'échec d'une sonde. Incluez une vraie requête de création dans vos vérifications après déploiement.

<a id="logs"></a>

## Journaux

Les journaux sont des lignes JSON sur la sortie standard, avec `timestamp`, `severity`, `service` et `message`. Les échecs qui concernent un processus stocké incluent son `id`. Les erreurs commises par l'appelant (`400`, `404`, `409`, `422`) ne sont pas journalisées.

Un démarrage sain journalise ces lignes, dans cet ordre, parmi les messages de connexion à PostgreSQL (le `version` et le `count` du catalogue changent à chaque version du catalogue) :

```json
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.482913407Z","message":"attribute catalog loaded","service":"human-plugin","version":"2026-10-29.1","count":53,"url":"https://human-token-assets.unico.app/attribute-catalog.json"}
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.731050212Z","message":"database schema ready","service":"human-plugin"}
{"severity":"INFO","timestamp":"2026-11-03T14:02:11.733418901Z","message":"human plugin listening","service":"human-plugin","addr":":8080"}
```

## Sur quoi alerter

- Readiness en échec : la base de données est injoignable.
- Réponses `503 DATABASE_UNAVAILABLE` ou `502 UPSTREAM_UNAVAILABLE` répétées aux appels de votre back-end.
- Redémarrages du conteneur : une boucle de redémarrage indique généralement un paramètre manquant, un catalogue injoignable ou un problème de base de données. Le journal précise lequel.
- Lignes de journal de niveau erreur, comme `creating process` ou `retrieving process`.

Human Plugin n'exporte pas de métriques. Utilisez votre passerelle ou votre service mesh pour les débits de requêtes et la latence.