Ingénierie
Concevoir des contrôles de santé pour les API créées avec l’IA
L’IA peut générer rapidement une API, mais la plateforme a besoin d’un point de terminaison de santé fidèle à son état avant de lui envoyer du trafic de production.
Le contrôle de santé le plus simple renvoie toujours 200. Un contrôle utile sait quand une API créée avec l’IA doit être retirée du routage.
Distinguer un processus vivant d’un processus prêt à servir
Le contrôle de vie détermine si le processus fonctionne encore suffisamment bien pour se rétablir sans redémarrage. Le contrôle de disponibilité vérifie s’il peut traiter le trafic sans risque maintenant. Combiner les deux dans un point de terminaison coûteux peut transformer une dépendance lente en boucle de redémarrage.
Gardez le contrôle de vie local et peu coûteux. Réservez le contrôle de disponibilité au petit ensemble de dépendances dont la défaillance empêche de traiter les requêtes. Un service d’analytics en arrière-plan en fait rarement partie ; une connexion obligatoire à la base de données, souvent.
- —Vie : la boucle d’événements ou le processus répond, sans appel externe nécessaire.
- —Disponibilité : les dépendances obligatoires du traitement des requêtes répondent dans un délai fixé.
- —Démarrage : l’initialisation et les migrations sont terminées avant que le contrôle de disponibilité devienne positif.
Borner les délais d’échec
Une sonde qui attend indéfiniment ne remplit pas son rôle. Fixez un délai court, évitez les nouvelles tentatives sans limite dans le gestionnaire et renvoyez un échec clair lorsque l’application ne peut pas établir sa disponibilité à temps. La plateforme peut alors cesser de router les nouvelles requêtes pendant que le processus se rétablit ou qu’un remplaçant démarre.
Le point de terminaison doit aussi éviter de modifier les données. Les contrôles de santé s’exécutent fréquemment, depuis plusieurs emplacements et dans des conditions déjà dégradées. Une requête en lecture seule ou un ping léger d’une dépendance est plus sûr qu’une écriture destinée uniquement à prouver l’accès.
export async function GET() {
const ready = await dependenciesReady({ timeoutMs: 500 });
return Response.json(
{ status: ready ? "ready" : "not_ready" },
{ status: ready ? 200 : 503 },
);
}Tester les scénarios d’échec
Une route de santé testée uniquement lorsque toutes les dépendances fonctionnent reste inachevée. Arrêtez la base de données, épuisez un pool de connexions, faites dépasser son délai d’attente à un service amont obligatoire et vérifiez que le contrôle de disponibilité échoue avant que les requêtes normales ne s’accumulent.
Rétablissez ensuite la dépendance et vérifiez que le processus rejoint le routage sans intervention manuelle. Le parcours de rétablissement fait lui aussi partie du contrat.
- —Bloquer les connexions à la base de données et vérifier que le contrôle de disponibilité renvoie 503.
- —Retarder un service amont obligatoire au-delà du délai de la sonde.
- —Envoyer SIGTERM et vérifier que le contrôle de disponibilité échoue avant le début de l’arrêt.
- —Rétablir les dépendances et vérifier que le réplica rejoint la rotation une fois son état stable.
Éviter les incidents provoqués par les sondes
La fréquence des sondes se multiplie rapidement avec le nombre de réplicas et d’emplacements de surveillance. Dix réplicas contrôlés chaque seconde peuvent ajouter des centaines de requêtes aux dépendances par minute. Gardez la requête peu coûteuse, n’utilisez du cache que s’il ne peut pas masquer une véritable panne et ajoutez un décalage aléatoire si toutes les sondes risquent de partir au même instant.
Déclenchez des alertes sur une perte prolongée de disponibilité et sur le nombre de réplicas opérationnels, plutôt que sur chaque contrôle échoué. Un dépassement de délai ponctuel est un indice ; la diminution du nombre de réplicas capables de servir le trafic est un incident.