Monitor Porter with Sazabi
Last verified on Nov 8, 2026.
Porter deploys your apps onto a Kubernetes cluster in your own cloud account. That is the point of it, and it shapes the logs. Porter keeps application logs for up to 7 days by default, stored in a Loki instance inside your cluster, and does not copy them to Porter's own systems. A bug that appears on Monday can be gone from Porter's log view by the next Monday.
Sazabi is AI-native observability and security. For Porter it takes logs and traces from your app over OpenTelemetry, and its agent can read Porter itself through a connector.
What Sazabi reads from Porter
Porter has no platform log drain. The Porter source is your app, instrumented with the OpenTelemetry SDK and pointed at your Sazabi intake. Logs and traces both arrive. Use your runtime's logger for logs, because the SDK does not forward stdout.
What makes the Porter version useful is the metadata. Porter injects variables into every app: PORTER_APP_SERVICE_NAME, PORTER_IMAGE_TAG, PORTER_POD_REVISION, PORTER_POD_NAME and others, including PORTER_RESOURCES_RAM, PORTER_NODE_NAME and PORTER_DOMAINS (Porter: app metadata). Sazabi's setup turns four of them into resource attributes: service.name, service.version, porter.revision and porter.pod.name. Porter does not expand $PORTER_* inside other variable values, so the service name is set from the start command or in code.
Metrics sent to this endpoint are not stored; send them to the OpenTelemetry Metrics source.
Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.
The agent connects to Porter in two other ways. The Porter MCP connector reads application logs, deployment status, revisions, runtime notifications, CPU, memory and request metrics, and cluster state. It can also update, redeploy and create apps unless you turn on read-only mode. The Porter CLI can be added to the agent sandbox with a PORTER_TOKEN.
Questions it answers
- Which
porter.revisionstarted producing errors? - Is the failure on one
porter.pod.name, or on every replica? - Did the image tag change between the last good and first bad release?
- Is a preview environment logging the same error as production?
- What do the cluster and the pods look like for the service that is failing?
A worked example: one pod, one revision
Porter's PORTER_POD_NAME is the internal hostname of the replica, and PORTER_POD_REVISION is the revision ID Porter assigns to the latest deployment. When you carry both into your telemetry, a regression has two coordinates. Ask:
sazabi logs ask "Group error-level records from service api-web by porter.revision and porter.pod.name over the last 3 hours"Read the result like this. If one revision has all of the errors, the release is the problem, and the service.version on those records is the image tag to compare against the last good one. If errors sit on one pod across revisions, the pod or its node is the problem. In a thread, ask the agent to read the pod and node state for that service through the MCP connector, and to compare the CPU and memory of that pod with its peers.
The example needs porter.pod.name to be real. If you see a literal $PORTER_POD_NAME in the field, the variable was set in Porter's Variables page. Move it into the start command.
Where the data lives
Porter's own logs stay in your cluster for a week. Sazabi receives only what your app exports, so volume depends on your logger and on the OpenTelemetry batch settings. The SDK buffers up to OTEL_BLRP_MAX_QUEUE_SIZE records per process, 2048 by default, and drops records when the queue is full, which happens only if exports fall behind. If a service logs in bursts, raise it. Do not run ddtrace and OpenTelemetry auto-instrumentation together, because both patch the same libraries.
How it fits with other integrations
If you already run Datadog's Agent through Porter, the Datadog integration adds Sazabi as a second logs endpoint with no app changes. Porter runs in your own cloud account, and for AWS accounts the AWS page applies. The protocol is covered by OpenTelemetry, and other platforms are listed under cloud platforms.
Log sources
- Porter (manual log source, cloud platforms): Add OpenTelemetry environment variables to your Porter service and initialize the SDK to send application logs and traces directly to Sazabi.
What Sazabi detects from these logs today
These detections are on for every production project, with no monitors or alert rules to write. Sazabi opens an issue when one fires.
- Novel event: A kind of error that has never appeared before.
Frequently Asked Questions
Does Porter have a log drain for Sazabi?
No. Porter has no platform log drain, so your application sends logs and traces to Sazabi with the OpenTelemetry SDK. If you already run the Datadog Agent through Porter's Datadog add-on, you can add Sazabi as a second logs endpoint on the Agent instead.
Why does my service name show a literal $PORTER_APP_SERVICE_NAME?
Porter passes variable values through as written and does not expand $PORTER_* references inside them. Set the OpenTelemetry service name and resource attributes from the start command, or read the PORTER_* variables in code.
Why are my console.log and print lines missing?
The OpenTelemetry SDK does not forward stdout. Log through the runtime logger: Python logging, or pino, winston or bunyan on Node. Plain print and console.log output stays in Porter's application logs.
What can the Sazabi agent do with Porter?
With the MCP connector it can read application logs, deployment status, revisions, metrics, cluster state and job runs, and with write access it can update, redeploy and create apps. Turn on read-only mode to block those writes. The Porter CLI connection is a separate option.
Sources
- Porter has no platform log drain; OpenTelemetry SDK logs and traces; PORTER_* variables are not expanded in values; resource attributes service.name, service.version, porter.revision, porter.pod.name; stdout not forwarded; metrics not stored (accessed Nov 8, 2026)
- Porter MCP connector reads application logs, deployment status, revisions, notifications, CPU, memory and request metrics, clusters, nodes, pods and job runs; read-only mode; tools get_projects, get_app_logs, get_application_status (accessed Nov 8, 2026)
- Porter CLI in the agent sandbox with PORTER_TOKEN and optional PORTER_PROJECT, PORTER_CLUSTER and PORTER_HOST (accessed Nov 8, 2026)
- List of PORTER_* variables injected into every app, including PORTER_APP_SERVICE_NAME, PORTER_IMAGE_TAG, PORTER_POD_REVISION and PORTER_POD_NAME, and the preview-only PORTER_PR_BRANCH and PORTER_PR_NUMBER (accessed Nov 8, 2026)
- Porter retains application logs for up to 7 days by default, stored in the customer cluster using Loki (accessed Nov 8, 2026)