Contrôles de santé

VérifiéSûr

Implémentez des endpoints de vérification de santé pour la disponibilité, la vivacité et le suivi des dépendances.

Spar Skills Guide Bot
DevOpsIntermédiaire
23/07/2026
Claude CodeCursorWindsurfCopilotCodex
#health-checks#kubernetes#service-readiness#graceful-shutdown#observability

Recommandé pour

Synthèse automatique

Met en place des endpoints de health check pour vérifier l’activité, la disponibilité et les dépendances d’un service.

Points forts

  • Distingue clairement les sondes liveness, readiness et startup avec les codes HTTP attendus.
  • Fournit une implémentation TypeScript typée avec enregistrement de vérifications de dépendances.
  • Couvre l’arrêt gracieux en faisant passer la readiness à 503 pendant le drainage des connexions.
  • Donne un exemple de configuration de probes Kubernetes.

Limites

  • L’exemple est centré sur TypeScript/Node.js et ne montre pas le branchement des routes dans un framework HTTP précis.
  • Ne traite pas le réglage fin des seuils de probes comme les timeouts, périodes et nombre d’échecs tolérés.
  • Suppose un contexte d’orchestrateur ou de load balancer ; peu utile pour un service sans dépendances ni trafic à drainer.
Quand l'utiliser

À utiliser lorsqu’un service doit exposer des probes à Kubernetes, à un load balancer ou à un orchestrateur pour piloter le trafic et l’arrêt.

Quand l'éviter

À éviter pour un site statique ou une fonction serverless sans dépendances critiques ni besoin de readiness ou de signalement d’arrêt.

Analyse de sécurité

Sûr
Score qualité86/100

This skill is a documentation/reference guide for implementing health check endpoints. It contains no executable commands, no destructive actions, no network exfiltration, and no use of tools. The code examples are TypeScript and YAML configuration snippets for service health monitoring, which pose no meaningful execution risk.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Add Kubernetes health probes
Add /health/live, /health/ready, and /health/startup endpoints to my Node.js service, including database and Redis readiness checks and 503 responses during graceful shutdown.
Review probe endpoints
Review my existing health check implementation and separate liveness from readiness so Kubernetes does not restart the pod when a dependency is temporarily down.
Graceful shutdown readiness
Update my service so SIGTERM marks the instance as not ready, waits for in-flight requests, and returns component-level health details.

Health Checks

Implement health check endpoints for service readiness, liveness, and dependency monitoring

When to Use

  • Deploying to Kubernetes or any orchestrator that uses health probes
  • Load balancers need to know if an instance can handle traffic
  • Monitoring dashboards need service status at a glance
  • Graceful shutdown requires draining connections before terminating

Instructions

  1. Implement three endpoints: /health/live (liveness), /health/ready (readiness), /health/startup (startup).
  2. Liveness — Is the process alive and not deadlocked? Should be lightweight (no dependency checks). Returns 200 if the process can respond.
  3. Readiness — Can this instance handle traffic? Checks database connections, cache availability, and critical dependencies. Returns 200 when ready, 503 when not.
  4. Startup — Has the service finished initializing? Used for slow-starting services to prevent premature liveness failures.
  5. Set the readiness check to return 503 during graceful shutdown to stop receiving new traffic.
  6. Health check responses should include component-level detail for debugging.
// health/health-controller.ts
interface HealthComponent {
  name: string;
  status: 'up' | 'down' | 'degraded';
  latency?: number;
  details?: string;
}

interface HealthResponse {
  status: 'healthy' | 'unhealthy' | 'degraded';
  uptime: number;
  timestamp: string;
  components: HealthComponent[];
}

export class HealthChecker {
  private ready = false;
  private shuttingDown = false;
  private startTime = Date.now();
  private checks: Array<{ name: string; check: () => Promise<HealthComponent> }> = [];

  registerCheck(name: string, check: () => Promise<HealthComponent>) {
    this.checks.push({ name, check });
  }

  setReady(ready: boolean) {
    this.ready = ready;
  }
  setShuttingDown() {
    this.shuttingDown = true;
    this.ready = false;
  }

  async liveness(): Promise<{ status: number; body: object }> {
    return {
      status: 200,
      body: { status: 'alive', uptime: Date.now() - this.startTime },
    };
  }

  async readiness(): Promise<{ status: number; body: HealthResponse }> {
    if (this.shuttingDown || !this.ready) {
      return {
        status: 503,
        body: {
          status: 'unhealthy',
          uptime: Date.now() - this.startTime,
          timestamp: new Date().toISOString(),
          components: [
            {
              name: 'server',
              status: 'down',
              details: this.shuttingDown ? 'shutting down' : 'not ready',
            },
          ],
        },
      };
    }

    const components = await Promise.all(
      this.checks.map(async ({ name, check }) => {
        try {
          return await check();
        } catch (err) {
          return { name, status: 'down' as const, details: String(err) };
        }
      })
    );

    const allUp = components.every((c) => c.status === 'up');
    const anyDown = components.some((c) => c.status === 'down');

    return {
      status: anyDown ? 503 : 200,
      body: {
        status: anyDown ? 'unhealthy' : allUp ? 'healthy' : 'degraded',
        uptime: Date.now() - this.startTime,
        timestamp: new Date().toISOString(),
        components,
      },
    };
  }
}
// Registering checks
const health = new HealthChecker();

health.registerCheck('database', async () => {
  const start = Date.now();
  await pool.query('SELECT 1');
  return { name: 'database', status: 'up', latency: Date.now() - start };
});

health.registerCheck('redis', async () => {
  const start = Date.now();
  await redis.ping();
  return { name: 'redis', status: 'up', latency: Date.now() - start };
});

// Graceful shutdown
process.on('SIGTERM', () => {
  health.setShuttingDown();
  // Allow in-flight requests to complete
  setTimeout(() => process.exit(0), 30000);
});

Details

Kubernetes probe configuration:

livenessProbe:
  httpGet: { path: /health/live, port: 3000 }
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3 # Restart after 3 failures

readinessProbe:
  httpGet: { path: /health/ready, port: 3000 }
  periodSeconds: 5
  failureThreshold: 2 # Remove from service after 2 failures

startupProbe:
  httpGet: { path: /health/startup, port: 3000 }
  periodSeconds: 5
  failureThreshold: 30 # Allow up to 150s for startup

Liveness vs readiness: Liveness failure triggers a pod restart. Readiness failure removes the pod from the service endpoint (no traffic routed to it). Making liveness too strict causes unnecessary restarts. Making readiness too lenient routes traffic to broken instances.

Health check anti-patterns:

  • Checking dependencies in the liveness probe (a database outage restarts all pods)
  • Not setting timeouts on dependency checks (health check hangs)
  • Returning 200 during shutdown (new requests arrive after drain starts)
  • Exposing sensitive information in health responses (connection strings, credentials)

Source

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Process

  1. Read the instructions and examples in this document.
  2. Apply the patterns to your implementation, adapting to your specific context.
  3. Verify your implementation against the details and edge cases listed above.

Harness Integration

  • Type: knowledge — this skill is a reference document, not a procedural workflow.
  • No tools or state — consumed as context by other skills and agents.

Success Criteria

  • The patterns described in this document are applied correctly in the implementation.
  • Edge cases and anti-patterns listed in this document are avoided.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/health-checks-mrx3xz91/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/health-checks-mrx3xz91' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/health-checks-mrx3xz91/download' --output '.skill-downloads/health-checks-mrx3xz91/SKILL.md.part' && mv '.skill-downloads/health-checks-mrx3xz91/SKILL.md.part' '.skill-downloads/health-checks-mrx3xz91/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/health-checks-mrx3xz91/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires