Scrydon

Observabilité

Métriques, journaux et traces émis par Scrydon — ainsi que les SLO à surveiller.

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

Chaque sous-système expose des métriques compatibles Prometheus. Les tableaux de bord recommandés les regroupent par thématique :

Tableau de bord Plateforme

  • auth.signin.success / auth.signin.failure — par minute, par fournisseur.
  • event_log.events_per_minute — par espace de noms d'action.
  • secrets.access.count — par stratégie (LOCAL / BYOK / HYOK).

Tableau de bord Autorisation

  • scrydon_authorization_decisions_total — décisions de la façade par application, opération et résultat.
  • scrydon_authorization_decision_duration_ms — histogramme de latence des décisions de la façade.
  • scrydon_authorization_evidence_enqueue_failures_total — décisions dont la première mise en file durable de la preuve a été dégradée.
  • scrydon_authorization_evidence_outbox_depth — preuves en attente par application et statut.
  • scrydon_authorization_evidence_outbox_oldest_age_seconds — âge de la preuve en attente la plus ancienne.
  • scrydon_authorization_evidence_dead_letters_total — preuves ayant épuisé les tentatives de relais.
  • scrydon_authorization_evidence_reconciliation_total — résultats de réconciliation des preuves dégradées.

Tableau de bord Agentic

  • workflow.runs_started / workflow.runs_completed / workflow.runs_failed — par minute, par workflow.
  • workflow.run.duration_p95 — par workflow.
  • block.executed — nombre par type de bloc.
  • tool.call.duration_p95 — par vendeur.
  • cortex.llm_call.tokens_in / cortex.llm_call.tokens_out — par modèle.
  • cortex.llm_call.cost — par modèle.
  • cortex.llm_call.latency_p95 — par modèle.

Tableau de bord Analytics

  • managed_table.read.count — par minute, par table.
  • managed_table.write.count — par minute, par table.
  • managed_table.query.duration_p95 — par table.

Tableau de bord Voix

  • voice.session.active — nombre courant de sessions actives.
  • voice.session.duration_p95 — durée des sessions.
  • voice.stt.latency_p95 / voice.tts.latency_p95 — latence du pipeline.

SLO suggérés

SLOCiblePourquoi
Taux de réussite des connexions≥ 99,5 %En dessous, cela indique un problème avec l'IdP ou le réseau.
Taux de réussite des exécutions de workflow≥ 99 %Par workflow ; certains échecs sont attendus pour les exécutions conditionnées par un évaluateur.
Délai de transfert des journaux d'audit≤ 60 sLes outils en aval des audits ont besoin d'un flux quasi temps réel.
Décision de la façade d'autorisation p95≤ 50 msUne latence plus élevée se répercute sur les opérations protégées. Le calcul utilise scrydon_authorization_decision_duration_ms.
Âge de la preuve d'autorisation en attente la plus ancienne≤ 300 sUn âge croissant indique que le relais de preuves durables ne se vide plus.
Requête de table gérée p95≤ 2 sPour les requêtes de style tableau de bord ; les requêtes analytiques peuvent intentionnellement être plus longues.

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

Dépannage des preuves d'autorisation

Chaque accord, refus et résultat indéterminé de la façade émet une preuve durable dans l'Event Log. Une hausse des échecs de mise en file, une file d'attente croissante ou toute lettre morte constitue un incident de preuve d'autorisation, même si les requêtes protégées répondent encore normalement. Rétablissez le chemin vers l'Event Log Producer, laissez le relais vider la file, puis vérifiez que la réconciliation revient à recovered. Ne rejouez pas les opérations protégées pour fabriquer des preuves.

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.

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
ValeurDéfautDescription
dapr.tracing.samplingRate"1"Taux d'échantillonnage des traces Dapr. "1" = 100 %, "0" = désactivé.
dapr.tracing.exporterstdoutstdout écrit les spans dans les journaux du sidecar (pas de collecteur nécessaire). otel les envoie vers un endpoint OTLP.
dapr.tracing.otel.endpointAddress""Obligatoire quand exporter: otel. Le host:port de votre collecteur compatible OTLP.
dapr.tracing.otel.protocolgrpcgrpc (recommandé) ou http.
dapr.tracing.otel.isSecurefalseMettez 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.

Configurez le point de terminaison OTLP pour les traces non-Dapr sous observability.otlp.endpoint afin d'envoyer les spans applicatifs vers votre collecteur (Jaeger, Tempo, Datadog, Honeycomb, Lightstep, …).

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.
  • levelinfo / 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

Sur cette page

Sur cette page