Zum Hauptinhalt springen
Connic
Platform

Drains

Logs, Run-Events, Environment Health, Traces und Audit-Einträge an Datadog, ein OpenTelemetry-Backend oder einen Webhook weiterleiten.

Zuletzt aktualisiert

Überblick

Ein Drain beobachtet eine Art von Projektdaten und leitet neue Einträge an einen Channel weiter. So laufen Monitore, Dashboards und Paging in den Tools, die dein Team bereits nutzt. Drains und Channels erfordern einen Enterprise-Plan und die Berechtigung channels.manage.

DrainKonfigurationLeitet weiterFilter
Run-DrainAgent Runs → More actions → Run DrainsRun-Events mit Inputs, Outputs und Kontext, Traces und Environment Health jede Minute.Environment, Run-Status, Auslöser, Entry-Ausdruck.
Log-DrainLogs → Log DrainsZeilen aus eigenem Code und der Runtime, bis zu 500 pro Anfrage.Environment, Level, Quelle, Auslöser, Entry-Ausdruck.
Audit-DrainProjekt-Settings → Audit LogAudit-Log-Einträge, etwa alle 60 Sekunden, bis zu 200 pro Anfrage.Aktionskategorie, Benutzer, Entry-Ausdruck.

Channels

Lege unter Projekt-Settings → Notifications einen Channel an. Ein Channel kann gleichzeitig mehrere Drains, Benachrichtigungen und Approval-Anfragen bedienen.

ChannelZustellungVerfügbarkeit
WebhookEin JSON-Array pro Anfrage. Mit einem Signing Secret enthält jede Anfrage X-Connic-Timestamp und X-Connic-Signature, den hexadezimalen HMAC-SHA256 über {timestamp}.{raw body}.Verfügbar
DatadogDatadog Logs, mit API-Key und deiner Datadog-Site.Verfügbar
OpenTelemetryOTLP/HTTP mit JSON-Encoding an einen beliebigen Collector oder Anbieter-Endpunkt, optional mit Headern.Verfügbar
SlackNachrichten in einem Slack-Channel über einen Incoming Webhook.Auf Anfrage
Microsoft TeamsNachrichten in einem Teams-Channel über einen Incoming Webhook.Auf Anfrage

Channel-Typen mit Auf Anfrage erscheinen in der Channel-Auswahl (dort als On request) und werden freigeschaltet, wenn du sie beim Connic Support anfragst.

Datadog

Jeder Eintrag wird ein Log mit der Quelle connic, dem Agent-Namen als service (connic, wenn es keinen gibt), einem env-Tag aus dem Environment-Namen und einem Status aus level. Connic sendet jeden Eintrag vollständig; Datadog selbst kürzt ein einzelnes Log über 1 MB. Alle weiteren Felder sind Log-Attribute, sodass Log-Monitore und Log-basierte Metriken Werte wie @run_status oder @duration_ms direkt nutzen können:

SignalLog-AbfrageMesswert
Fehlgeschlagene Runs pro Agentsource:connic @type:run @run_status:failedcount by service
Run-Dauersource:connic @type:run@duration_ms
Queue-Tiefe pro Environmentsource:connic service:connic @type:environment_health@queued_runs
Längster laufender Run pro Agentsource:connic @type:environment_health -service:connic@oldest_running_seconds

OpenTelemetry

Setze als Endpunkt die Basis-URL des Receivers, etwa https://otel.example.com:4318. Connic sendet Spans an /v1/traces und alle anderen Einträge an /v1/logs. Header verwenden das Format key=value,key2=value2 von OTEL_EXPORTER_OTLP_HEADERS.

Die Resource enthält service.name (den Agent-Namen) und deployment.environment.name. Log Records eines Runs verwenden die Run-ID als Trace-ID, sodass ein Backend die Logs eines Runs neben seinem Trace anzeigen kann.

Private Endpunkte

Webhook- und OpenTelemetry-Channels können über eine Connic Bridge zustellen. Wähle die Bridge am Channel aus, um einen Endpunkt in deinem Netzwerk zu erreichen, auch über einfaches HTTP. Richte zum Beispiel einen OpenTelemetry-Channel auf den OTLP-Receiver eines Datadog Agents in deinem Cluster, etwa http://datadog-agent.datadog.svc.cluster.local:4318, um Traces in Datadog APM zu erhalten. Ist für den Bridge-Agenten ALLOWED_HOSTS konfiguriert, muss die Liste Host:Port des Endpunkts enthalten.

Run-Drains

Ein Run-Drain leitet standardmäßig alles weiter: Run-Events mit Inputs, Outputs und Kontext, Traces und Environment Health. Schalte Teile ab, die du nicht brauchst, oder wähle Environments aus. Filter nach Run-Status, Auslöser und Entry-Ausdruck gelten nur für Run-Events und Traces. Nichts wird gekürzt.

Run-Events

Ein Eintrag pro beendetem Run, auch für Test-Runs aus Deployments (trigger_source deploy_gate). Der Drain prüft alle 15 Sekunden und übernimmt einen Run etwa eine Minute nach seinem Ende, damit spät gespeicherte Runs nicht übersprungen werden. duration_ms ist die aktive Ausführungszeit; queue_wait_ms ist die Zeit zwischen Einreihen und Beginn der Verarbeitung. input und output sind der vollständige Input und Output des Runs, als JSON geparst, wenn möglich, und context enthält die von Middleware gesetzten Kontext-Schlüssel. Schalte Inputs and outputs oder Run context ab, um sie wegzulassen.

Run-Event
{
  "type": "run",
  "id": "a1b2c3d4-...",
  "timestamp": "2026-10-12T09:41:07.512000Z",
  "level": "error",
  "run_id": "a1b2c3d4-...",
  "run_status": "failed",
  "agent_name": "invoice-processor",
  "environment_id": "e7f8a9b0-...",
  "environment_name": "production",
  "project_id": "9840b2b8-...",
  "deployment_id": "d4c3b2a1-...",
  "connector_id": "5e6f7a8b-...",
  "parent_run_id": null,
  "trigger_source": "connector",
  "test_name": null,
  "queued_at": "2026-10-12T09:38:55.104000Z",
  "started_at": "2026-10-12T09:38:57.880000Z",
  "ended_at": "2026-10-12T09:41:07.512000Z",
  "queue_wait_ms": 2776.0,
  "duration_ms": 129632.0,
  "token_usage": { "input_tokens": 18234, "output_tokens": 2210, "total_tokens": 20444 },
  "error": "TimeoutError",
  "context": { "request_type": "invoice_validation", "customer_id": "C-1042" },
  "input": { "payload": { "invoice_id": "INV-7731" } },
  "output": null,
  "channel_id": "c5d4e3f2-...",
  "channel_name": "Datadog Produktion"
}

Environment Health

Zu Beginn jeder Minute ein Snapshot pro Environment mit der aktuellen Zahl wartender, laufender und auf ein Approval wartender Runs sowie dem Alter des ältesten wartenden und laufenden Runs. Jeder Agent mit aktiven Runs erhält zusätzlich einen eigenen Snapshot. Environment-Summen haben keinen agent_name. Alarmiere auf oldest_running_seconds, um hängende Runs zu finden, und auf queued_runs für einen wachsenden Rückstau.

Environment Health
{
  "type": "environment_health",
  "id": "0f9e8d7c-...",
  "timestamp": "2026-10-12T09:42:00.031000Z",
  "level": "info",
  "environment_id": "e7f8a9b0-...",
  "environment_name": "production",
  "agent_name": "invoice-processor",
  "queued_runs": 4,
  "running_runs": 2,
  "awaiting_approval_runs": 1,
  "oldest_queued_seconds": 312.4,
  "oldest_running_seconds": 2950.1
}

Traces

Jeder Span jedes passenden Runs wird weitergeleitet, mit der Run-ID als Trace-ID sowie den Eltern-Verknüpfungen, Zeiten, Status und Attributen aus dem Trace des Runs. Jeder Span enthält außerdem seinen vollständigen Input, Output und sein Reasoning, sofern Inputs and outputs nicht abgeschaltet ist. Spans werden in Paketen von bis zu 1.000 gesendet.

OpenTelemetry-Channels erhalten sie als OTLP-Traces, mit Input, Output und Reasoning in connic.input, connic.output und connic.thoughts. Webhook- und Datadog-Channels erhalten einen Eintrag pro Span. Für Traces in Datadog APM sende sie über einen OpenTelemetry-Channel an den Datadog Agent.

Span
{
  "type": "span",
  "id": "7c1d2e3f-...",
  "timestamp": "2026-10-12T09:39:01.204000Z",
  "level": "info",
  "run_id": "a1b2c3d4-...",
  "trace_id": "a1b2c3d4e5f6...",
  "span_id": "9f8e7d6c5b4a3921",
  "parent_span_id": "0011223344556677",
  "name": "tool:lookup_invoice",
  "span_status": "ok",
  "start_time": "2026-10-12T09:39:01.204000Z",
  "end_time": "2026-10-12T09:39:02.118000Z",
  "duration_ms": 914.0,
  "attributes": { "tool.name": "lookup_invoice" },
  "input": "{\"invoice_id\": \"INV-7731\"}",
  "output": "{\"total\": 1840.5}",
  "thoughts": null,
  "agent_name": "invoice-processor",
  "trigger_source": "connector",
  "environment_id": "e7f8a9b0-...",
  "environment_name": "production",
  "project_id": "9840b2b8-..."
}

Log-Drains

Ein Log-Drain leitet etwa alle 15 Sekunden die Zeilen weiter, die Tools, Middleware, Hooks und Guardrails ausgeben oder loggen. Strukturierte Felder bleiben erhalten, wenn du sie als json.dumps(...)-String loggst; der Empfänger kann message dann parsen.

Log-Eintrag
{
  "type": "log",
  "id": "3f1c7a9e-...",
  "timestamp": "2026-10-12T09:41:07.512000Z",
  "level": "warning",
  "source": "log:tool:lookup_customer",
  "message": "cache miss for C-1042",
  "run_id": "a1b2c3d4-...",
  "agent_name": "invoice-processor",
  "trigger_source": "connector",
  "environment_id": "e7f8a9b0-...",
  "environment_name": "production",
  "project_id": "9840b2b8-..."
}

Audit-Drains

Audit-Einträge verwenden "type": "audit_log" mit action, resource_type, resource_id, user_id, user_email, changes, ip_address und created_at. Guardrail-Blockierungen kommen als guardrail.block mit dem Guardrail-Typ in changes.after an.

Filterausdrücke

Ein Entry-Ausdruck wird für jeden Log- oder Audit-Eintrag sowie jedes Run-Event als entry ausgewertet, und nur passende Einträge werden weitergeleitet. Bei Run-Drains entscheidet er auch, welche Runs getraced werden, und entry.context, entry.input und entry.output stehen zur Verfügung, auch wenn sie nicht weitergeleitet werden. Beispiele:

  • entry.agent_name == 'invoice-processor' and entry.duration_ms > 60000
  • entry.context.request_type == 'tco_mapping'
  • entry.level == 'error'

Die Syntax steht unter Ausdrücke.

Zustellverhalten
  • Ein neuer Drain leitet Einträge weiter, die nach seinem Anlegen entstehen. Ältere Einträge werden nicht nachgeliefert.
  • Jede Antwort unter 400 gilt als zugestellt. Fehlgeschlagene Zustellungen von Run-Events, Traces, Logs und Audit-Einträgen werden im nächsten Zyklus wiederholt. Fehlgeschlagene Health-Snapshots werden in der nächsten Minute durch aktuelle Snapshots ersetzt.
  • Ein Eintrag kann mehrfach ankommen. Dedupliziere anhand von id; bei Run-Events ist das die Run-ID.
  • Wird ein Channel deaktiviert, pausieren seine Drains. Aktiviere sie danach in der Drain-Liste wieder, sobald der Channel aktiv ist.