Échantillons Liveness/Lecture

2) Principes de conception

1. Séparez les sémantiques.

La capacité externe de répondre aux demandes (compte tenu des dépendances critiques).
Liveness : un détail de l'état « incurable » du processus.
2. Fail-fast, mais pas « false-fast ». Ajustez le délai/seuil 'failureThreshold'de manière à ce que les éclats courts ne conduisent pas à des restarts supplémentaires.
3. Pas de chirurgie lourde dans les échantillons. Le contrôle doit être rapide (≤100-200 мс) et sans effets secondaires.
4. Dégradation gracieuse. En cas d'indisponibilité partielle des dépendances - Read....= OK s'il y a un follback sécurisé (cache/grondement).
5. Deterministic I/O. Les statuts ne dépendent que de l'état actuel et non des tests externes « aléatoires ».

3) La sémantique des endpoints SANTÉ

3. 1 approche HTTP (recommandée)

'GET/healthz/liveness '→ 200 si le processus est « vivant » (event-loop tourne, GC n'est pas coincé, watchdog « cœur » bat).
'GET/healthz/read....' → 200 si l'instance est prête pour le trafic de la classe critique. Vérifications : pool de connexions, caches locaux, disponibilité du noyau de logique métier.
'GET/healthz/startup '→ 200 après l'initialisation (migration/chauffage du cache/chargement des modèles).

• Vous ne pouvez pas aller à des bases de données/API externes dans liveness - cela conduira à des « suicides » lors d'incidents de dépendance.
• Dans la lecture, vous pouvez vérifier les dépendances critiques, mais avec les délais et la dégradation : s'il y a un follback validé - ne pas tomber.

3. 2 gRPC Health Checking

Utilisez le standard 'grpc. health. v1. Health/Check 'avec des états scopés de service (' SERVING ',' NOT _ SERVING '). Pour Kubernetes, un échantillon grpc (ou un proxy http).

3. 3 Déclencheurs internes

Watchdog « soft » stop : avec SIGTERM, afficher Read....= FAIL → attendre 'terminationGracePeriodSecond' → se terminer en faisant des files d'attente.

4) Temps et seuils (tuning)

• `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `successThreshold`, `failureThreshold`.

• readiness: `period=5s, timeout=0. 2–0. 5s, failure=2`
• liveness: `period=10s, timeout=0. 2–0. 5s, failure=3`

• startup : ' period=5s, failure=60 ' (jusqu'à ~5 mines)
• read..../liveness activé après le succès de startup

• read....reflète la volonté de traitement (connexion avec le courtier, s'il y a dégradation du DLQ),
• liveness est un heartbeat loop interne.

Bakof sur les échecs : dans l'application, utilisez un backoff exponentiel pour se reconnecter aux dépendances, sinon read....sera « scié ».

5) Configurations (fragments)

5. 1 Kubernetes, échantillons HTTP

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, échantillon gRPC

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Graceful shutdown

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

'/healthz/drain 'dans le service traduit Read....= FAIL (stop-accepting), donne le temps de terminer les demandes actives.

6) Dépendance et dégradation

Critiques (vous ne pouvez pas les servir sans eux) : Bases de données d'autorisation pour '/login ', passerelle de paiement pour '/pay'. Vous pouvez vérifier le temps de lecture avec ≤80 % de l'échantillon 'timeoutSecond'.
Non critique : Analyse, email, cache en présence d'un dogme. Ne les incluez pas dans la lecture ; utilisez follback.
Feature-flags : en cas de dégradation partielle, désactivez les fiches dépendantes en conservant Read....= OK.

7) Files d'attente et gestionnaires d'arrière-plan

• Read....= OK si l'abonnement/connect au courtier est installé et qu'il existe une ressource à traiter.
• En cas de dépassement de DLQ/Lag, le → Read....peut rester OK (si accepté et plié), mais le SLI « fraîcheur/Lag » s'allume - alert selon les données.
• Liveness : Contrôler le bou-cycle/heartbeat, détecteur de dedelk.

Idempotence : accélère la récupération après les restarts liveness.

8) Sidecar/mesh/ingress

• Activer « read....@@Gate » (K8s) pour tenir compte du statut sidecar,
• Assurez-vous que les échantillons ne pénètrent pas dans les barrières mTLS (ou ajoutez des exceptions).
• Ingress/Envoy/Nginx : projetez '/healthz/' localement, ne « sortez » pas les pièces intérieures.

9) Sécurité et vie privée

Les endpoints de santé ne doivent pas révéler les configues, les versions des bibliothèques, les lignes d'erreur - seulement « OK/FAIL » + code de cause minimum.
Limitez l'accès de l'extérieur (NetworkPolicy/ACL). Pour le public, ne faisons qu'un ping-ping sans détails.
Logs de contrôle de santé - au niveau DEBUG, avec trottinette.

10) Observabilité et SLO

Exportez les métriques : 'health _ read....{ status}', 'health _ liveness {status}', le temps de traitement de l'échantillon.
Associez les flaps de lecture à la disponibilité SLO (chute des endpoints → 5xx/connexion reset).

• « Restarts fréquents par liveness> N/heure » est un symptôme de dedlocks/fuites.
• Flap Read....> X/15 min est un symptôme de problèmes de dépendance/réseau.
• Corrélation avec le déploi ('service. version`).

11) Tests

Unit/Contract : les endpoints '/healthz/' renvoient les statuts corrects lorsque chaque dépendance est désactivée.
Chaos : Désactivation de la base de données/cache/courtier : La lecture doit tomber ou allumer le follback strictement sur le modèle. Liveness - ne déclenchera pas si le processus est « vivant ».
Load/Soak : sous charge, les endpoints de santé doivent rester rapides (ne pas percer la boucle).
Canary : vérifiez la stabilité de la lecture avant d'augmenter le trafic.

12) Erreurs fréquentes et comment les éviter

Liveness vérifie les bases de données/API externes. Le résultat est des restarts infinis dans les incidents. Solution : limiter le liveness à la « vie du processus ».
Contrôles lourds dans les échantillons. Conduit à de faux refus. Solution : contrôles faciles + moniteurs de santé individuels.
Pas de Startup Probe. Les lancements lents sont « tués » par la vie. Solution : ajouter un startup avec une fenêtre large.
L'absence de graceful shutdown. Peu fréquent 5xx à la dérive. Solution : préStop + déséquilibrage.
Les tempêtes Flap. Des seuils trop agressifs. Solution : soulever 'failureThreshold', agrandir' timeoutSecond', ajouter un backoff.
Les mêmes endpoints pour tout. Mélange de sémantiques. Solution : « liveness/read..../startup ».

13) Mini-modèles de réalisation

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Chèques-feuilles

Avant la vente

• Les endpoints liveness/read..../startup sont séparés, leur sémantique est décrite.
• Liveness ne touche pas aux dépendances extérieures ; Read....ne vérifie que les critiques avec des tannages et follback.
• Configuré 'initialDelay/period/timeout/failureThreshold'sous le profil de service.
• Activé graceful shutdown : 'preStop' + désalignement.
• Les métriques/logs de santé sont connectés ; alertes pour restarts/flap.
• Les tests de défaillance des dépendances et de démarrage lent sont passés.

Exploitation

• Rapport hebdomadaire sur les restaurateurs et les flaps de lecture.
• Réglage des seuils après les incidents ; lien avec les communiqués.
• Tests de chaos réguliers de l'arrêt des dépendances.
• Pertinence de la sémantique lorsque la criticité des dépendances change.

15) FAQ

Q : Puis-je tout fermer avec un seul essai ?
R : Non désiré. Séparez 'startup', 'read....',' liveness '- cela réduit les faux positifs et accélère RCA.

Q : Est-ce que le cache est en cours de lecture ?
R : S'il existe un mode correct (bien que le plus lent) sans cache - ne laissez pas tomber la lecture, activez simplement la dégradation.

Q : Que faire avec les restarts fréquents par liveness ?
R : D'abord, exclure le dégagement/fuite ; puis assouplir les seuils et ajouter watchdog à l'application.

Q : Comment tenir compte de la polyvalence ?
R : La lecture doit refléter la capacité de desservir tout trafic de location. Pour les problèmes privés d'un locataire particulier, ne changez pas la lecture, mais signalez avec des SLI/alerts distincts.

• « Observabilité : logs, métriques, tracés »
• Traces distribuées
• « SLO/SLA et métriques »
• « Garantie de livraison des webhooks »
• Cryptage In Transit
• « Gestion des secrets »