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

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.
• audit_log.events_per_minute — par espace de noms d'action.
• secrets.access.count — par stratégie (LOCAL / BYOK / HYOK).
• permission_check.duration_p95 — latence du point de décision de politique.

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.
• policy.evaluation.duration_p95 — latence de décision de politique Rego.

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

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

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

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