Consumer-Reported Dependency Health

Une étude approfondie de la pratique CRDH, où les usagers deviennent des sondes distribuées pour mesurer la santé réelle des dépendances. Une approche moderne et fiable pour le monitoring, l'observabilité et la détection d'incidents.

I. Réinventer la manière d’évaluer la santé des systèmes distribués  

Dans les architectures distribuées modernes, la santé d’un système dépend autant — voire davantage — de l’état de ses dépendances que de son état interne. Pourtant, la plupart des stratégies de monitoring reposent encore sur des healthchecks synthétiques ou dédiés : endpoints /health, sondes liveness/readiness, scripts externes, etc.

Ces techniques fonctionnent, mais elles ne capturent pas l’essentiel :
l’expérience réelle des consumers.

Une approche alternative existe, simple, robuste et naturellement distribuée :
Consumer-Reported Dependency Health (CRDH).

II. Qu’est-ce que CRDH ?  

Consumer-Reported Dependency Health (CRDH) que ce sont les consumers eux-mêmes qui indiquent si une dépendance fonctionne, en se basant directement sur ce qu’ils observent lors de leurs appels réels.

Le principe :

• Si un appel réel vers une dépendance réussit → le consumer rapporte un succès.
• Si un appel réel échoue → le consumer rapporte un échec.
• Les métriques sont exportées automatiquement (Prometheus / OpenTelemetry).
• La vision globale se construit par agrégation.

En pratique, cela crée une matrice distribuée permettant de comprendre instantanément si un problème est :

• global (plusieurs consumers impactés),
• local (un seul consumer),
• lié à la configuration,
• lié à la charge,
• lié à un pattern d’accès spécifique.

III. Pourquoi les healthchecks classiques sont insuffisants  

1. Ils ne reflètent pas le trafic réel  

Un endpoint /health dit souvent “SELECT 1”, “PING Redis”, “GET /status”.
Mais le trafic métier réel est plus complexe (permissions, payloads, batchs…).

Un service peut donc être “healthy” en healthcheck, mais inutilisable en réalité.

2. Ils ne détectent pas les problèmes locaux  

Un consumer peut échouer à cause :

• d’un DNS local,
• d’un firewall,
• d’un secret expiré,
• d’un problème de routing interne.

Le healthcheck de la dépendance restera pourtant “OK”.

3. Ils demandent une maintenance constante  

Chaque nouveau service doit :

• écrire ses sondes,
• les maintenir,
• s’assurer qu’elles testent la “vraie” fonctionnalité.

CRDH élimine ce besoin.

IV. La “Health Matrix”  

Grâce aux métriques CRDH, une vision globale apparaît :

C’est un outil extrêmement puissant pour :

• diagnostiquer plus vite,
• éviter les faux positifs,
• comprendre la portée réelle d’un incident,
• prioriser les remédiations.

V. Spécification technique CRDH  

1. Métriques Prometheus recommandées  

Succès  

crdh_dependency_success_total{
  consumer="order-service",
  dependency="payment-api",
  method="POST",
  status="200"
}

échec  

crdh_dependency_error_total{
  consumer="order-service",
  dependency="payment-api",
  error="timeout",
  status="504"
}

2. Latence par dépendance  

crdh_dependency_latency_ms_bucket{
consumer="web",
dependency="db",
le="100"
}

3. Taux de santé  

(toujours calculé par PromQL)

100 * sum(rate(crdh_dependency_success_total[5m]))
/
sum(rate(crdh_dependency_success_total[5m]) + rate(crdh_dependency_error_total[5m]))

VI. Exemple : implémentation en Go  

func CallPaymentAPI(ctx context.Context) error {
    start := time.Now()
    err := doRealPaymentCall(ctx)
    duration := time.Since(start)

    labels := prometheus.Labels{
        "consumer":   "order-service",
        "dependency": "payment-api",
    }

    if err != nil {
        CRDHErrors.With(labels).Inc()
    } else {
        CRDHSuccess.With(labels).Inc()
        CRDHLatency.With(labels).Observe(duration.Seconds())
    }

    return err
}

Et c’est tout.
Aucun healthcheck spécifique n’est nécessaire.

VII. Comparaison : CRDH vs pratiques SRE existantes  

CRDH n’est pas une alternative mais un complément naturel :
il ajoute le contexte métier manquant dans les sondes classiques.

VIII. Alerting : un modèle plus intelligent  

1. Alertes locales (1 consumer impacté)  

sum(rate(crdh_dependency_error_total{consumer="serviceA", dependency="redis"}[5m])) > 5

2. Alertes globales (plusieurs consumers impactés)  

count by (dependency) (
sum(rate(crdh_dependency_error_total[5m])) by (consumer, dependency) > 5
) > 2

3. Alertes de dégradation (latences croissantes)  

histogram_quantile(0.95, sum by (le, consumer, dependency) (rate(crdh_dependency_latency_ms_bucket[5m]))) > 200

IX. Quand adopter CRDH ?  

CRDH est particulièrement efficace si :

• tu as plusieurs services consommant les mêmes dépendances,
• tu veux réduire les faux positifs d’alerting,
• tu veux comprendre rapidement la portée d’un incident,
• tu veux éviter la maintenance des healthchecks dédiés,
• tu veux un modèle robuste de monitoring multi-services.

X. Limites (et solutions)  

Connaissance du code par les équipes  

CRDH suppose que les développeurs comprennent très bien le fonctionnement réel de leurs appels vers une dépendance : retries, timeouts, fallbacks, erreurs logiques, et ce qui constitue réellement un succès métier. Si ce n’est pas le cas, les métriques CRDH risquent d’être incorrectes ou trompeuses.

Pour éviter cela, il est recommandé d’utiliser un middleware ou un SDK commun qui standardise l’émission des métriques, et de documenter clairement la définition de “succès” et “échec” pour chaque dépendance.

XI. Pourquoi cette approche marche si bien ?  

Parce qu’elle repose sur un principe simple :

La meilleure mesure de la santé d’un système, c’est l’expérience réelle des services qui l’utilisent.

CRDH transforme l’ensemble des consumers en une sonde distribuée, gratuite, réaliste et auto-entretenue.

C’est exactement l’équivalent du user-reported health côté produit —
mais appliqué aux services backend.

XII. Conclusion  

CRDH apporte un changement de perspective puissant :
ce ne sont plus les services qui doivent prouver qu’ils sont vivants —
ce sont leurs consumers qui rapportent ce qu’ils observent réellement.

C’est simple.
C’est robuste.
C’est fidèle à la réalité.
Et cela améliore radicalement la manière dont on détecte, diagnostique et corrige les incidents dans des architectures distribuées.

🔗 Liens utiles  

• Prometheus — Best Practices
• OpenTelemetry — Metrics Specification
• OpenTelemetry Collector