Drains
Logs, Run-Events, Environment Health, Traces und Audit-Einträge an Datadog, ein OpenTelemetry-Backend oder einen Webhook weiterleiten.
Auf dieser Seite
Ü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.
| Drain | Konfiguration | Leitet weiter | Filter |
|---|---|---|---|
| Run-Drain | Agent Runs → More actions → Run Drains | Run-Events mit Inputs, Outputs und Kontext, Traces und Environment Health jede Minute. | Environment, Run-Status, Auslöser, Entry-Ausdruck. |
| Log-Drain | Logs → Log Drains | Zeilen aus eigenem Code und der Runtime, bis zu 500 pro Anfrage. | Environment, Level, Quelle, Auslöser, Entry-Ausdruck. |
| Audit-Drain | Projekt-Settings → Audit Log | Audit-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.
| Channel | Zustellung | Verfügbarkeit |
|---|---|---|
| Webhook | Ein 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 |
| Datadog | Datadog Logs, mit API-Key und deiner Datadog-Site. | Verfügbar |
| OpenTelemetry | OTLP/HTTP mit JSON-Encoding an einen beliebigen Collector oder Anbieter-Endpunkt, optional mit Headern. | Verfügbar |
| Slack | Nachrichten in einem Slack-Channel über einen Incoming Webhook. | Auf Anfrage |
| Microsoft Teams | Nachrichten 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:
| Signal | Log-Abfrage | Messwert |
|---|---|---|
| Fehlgeschlagene Runs pro Agent | source:connic @type:run @run_status:failed | count by service |
| Run-Dauer | source:connic @type:run | @duration_ms |
| Queue-Tiefe pro Environment | source:connic service:connic @type:environment_health | @queued_runs |
| Längster laufender Run pro Agent | source: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.
{
"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.
{
"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.
{
"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.
{
"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 > 60000entry.context.request_type == 'tco_mapping'entry.level == 'error'
Die Syntax steht unter Ausdrücke.
- 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.