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 centrales terminées par application, opération et résultat.
  • scrydon_authorization_decision_duration_ms — latence de décision incluant l'ajout obligatoire de la preuve.
  • scrydon_authorization_evaluation_duration_ms — latence d'évaluation de politique OPA.
  • scrydon_authorization_evidence_append_duration_ms — latence et succès de la transaction atomique de l'Audit Log.
  • scrydon_authorization_evidence_append_failures_total — transactions obligatoires de preuve ayant échoué.
  • scrydon_authorization_requests_total / scrydon_authorization_request_duration_ms — requêtes admises par opération et statut HTTP.
  • scrydon_authorization_requests_in_flight — requêtes admises par le service central.
  • scrydon_authorization_capacity_rejections_total — requêtes rejetées avant tout travail OPA ou base de données lorsque la limite de concurrence est atteinte.

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.
Requête d'autorisation p95≤ 100 msCouvre l'admission, OPA, la preuve atomique et la réponse. Le calcul utilise scrydon_authorization_request_duration_ms.
Évaluation OPA p95≤ 50 msDétecte la saturation du moteur de politique indépendamment du stockage des preuves.
Transaction de preuve d'autorisation p95≤ 75 msDétecte la contention de chaîne ou la pression sur la base de données.
Rejets de capacité sous charge stable0Un rejet signifie que la limite de concurrence centrale a été atteinte avant tout travail OPA ou base de données.
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é 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.

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