Observabilité

Scrydon émet des métriques, des journaux et des traces OpenTelemetry. Cette page documente ce qui est disponible et les SLO auxquels vous devez prêter attention.

Métriques

Les services envoient leurs métriques OpenTelemetry en OTLP/HTTP ; rien n'est collecté par scraping. Les métriques et les traces applicatives restent désactivées tant que vous ne donnez pas de collecteur au chart :

observability:
  otlpHttpEndpoint: http://otel-collector.monitoring.svc.cluster.local:4318   # OTLP/HTTP, pas gRPC 4317

Chaque série est nommée scrydon_<domaine>_<mesure>, avec _total pour les compteurs et _ms pour les durées. Les services exportent toutes les 15 secondes.

Une série qui n'apparaît jamais signifie en général que otlpHttpEndpoint est vide ou pointe vers le port gRPC.

SLO suggérés

Ces valeurs sont indicatives — ajustez-les à votre charge de travail.

Dépannage des preuves d'autorisation

Chaque accord, refus et résultat indéterminé n'est renvoyé qu'après qu'API Platform a enregistré atomiquement sa preuve dans l'Audit Log et son registre d'idempotence. Toute hausse de scrydon_authorization_evidence_append_failures_total ou toute série durable de réponses 503 constitue un incident ; l'opération protégée n'est pas exécutée. Rétablissez OPA ou la base de données de preuves, puis réessayez avec la même clé de décision stable. Une répétition identique est dédupliquée, tandis qu'une réutilisation conflictuelle renvoie 409.

L'Event Backbone des workflows est un transport distinct pour la collaboration et les événements de domaine. Son état ne prouve pas l'exhaustivité des preuves d'autorisation, et ces preuves ne dépendent pas de son activation.

Traces

Des traces OpenTelemetry sont émises pour :

• Chaque requête API (de l'entrée à la sortie).
• Chaque exécution de workflow (span parent) avec des spans enfants par exécution de bloc.
• Chaque appel LLM via Cortex (avec attributs de modèle, fournisseur, latence, coût).
• Chaque lecture de table gérée avec la décision de politique en attribut.

Une requête qui traverse plusieurs services forme une seule trace. Chaque service transmet l'en-tête W3C traceparent dans ses appels vers les autres services : chaque saut apparaît comme un span enfant de l'appelant. Si vous exportez aussi les spans Dapr (ci-dessous), les spans du sidecar rejoignent cette même trace.

Configuration des traces distribuées Dapr

Scrydon utilise Dapr pour la communication entre services. Par défaut, les spans Dapr sont écrits dans les journaux du sidecar (exporter: stdout) — ils ne sont pas envoyés à un collecteur.

Pour envoyer les traces distribuées Dapr vers un collecteur compatible OTLP (SigNoz, Grafana Tempo, Jaeger, un OpenTelemetry Collector, Honeycomb, endpoint OTLP Datadog, etc.), définissez les valeurs dapr.tracing dans votre chart Helm scrydon :

dapr:
  tracing:
    samplingRate: "1"   # "1" = 100% ; "0" = désactivé ; valeurs fractionnaires acceptées
    exporter: otel      # stdout (défaut, spans vers les journaux sidecar) | otel (envoi vers le collecteur)
    otel:
      endpointAddress: "my-otel-collector.observability.svc.cluster.local:4317"
      protocol: grpc    # grpc | http
      isSecure: false   # true si le point de terminaison du collecteur requiert TLS

Important : exporter: otel avec un endpointAddress vide est une erreur au moment du rendu du chart — le chart échoue de façon fermée pour éviter qu'une configuration incorrecte des traces n'entraîne une perte silencieuse de spans.

Exemple — envoi vers un sidecar/DaemonSet OpenTelemetry Collector :

dapr:
  tracing:
    exporter: otel
    otel:
      endpointAddress: "otel-collector.monitoring.svc.cluster.local:4317"
      protocol: grpc
      isSecure: false

Exemple — envoi vers Grafana Tempo :

dapr:
  tracing:
    exporter: otel
    otel:
      endpointAddress: "tempo.monitoring.svc.cluster.local:4317"
      protocol: grpc
      isSecure: false

Ces exemples utilisent des adresses intra-cluster — adaptez endpointAddress à l'emplacement de votre collecteur. Le paramètre exporter s'applique à tous les services compatibles Dapr dans le déploiement.

Les spans applicatifs partent vers observability.otlpHttpEndpoint, le même point de terminaison que les métriques ci-dessus. Pointez-le vers votre collecteur : Jaeger, Tempo, Datadog, Honeycomb, Lightstep ou tout autre récepteur OTLP/HTTP.

Une requête d'API dont l'appelant s'est déconnecté avant l'écriture de la réponse est enregistrée avec http.response.status_code 499 (requête fermée par le client). Son span n'est pas marqué en erreur. Excluez 499 lorsque vous calculez un taux d'erreurs serveur : rien n'a échoué, et l'appelant n'a rien reçu.

Accès aux journaux

Les journaux sont en JSON structuré, émis sur stdout. Configurez votre pipeline de journalisation (Loki, Cloud Logging, journaux Datadog, …) pour ingérer les journaux des pods dans les espaces de noms Scrydon.

Champs importants sur chaque ligne de journal :

• service — quel sous-système l'a émis.
• level — info / warn / error / fatal.
• requestId — identifiant de corrélation entre les services.
• actorId (dans un contexte utilisateur) — l'utilisateur.
• organizationId (dans un contexte tenant) — le tenant.

Les journaux ne contiennent jamais de valeurs secrètes ni de données personnelles — celles-ci sont occultées à l'émission. Voir Occultation.

Liens connexes

• Redirection vers le SIEM — pour le volet des événements d'audit.
• Journal d'audit — le journal d'événements interrogeable.