Getting started - PaaS Full Observability

Your namespace must be onboarded first

Platon must add your Kubernetes namespace to the configuration of Alloy, the in-cluster collector, before it accepts your telemetry. Until then, everything you send to Alloy is discarded without an error or a diagnostic, and none of it appears in Grafana.

Ask the Platon team on #platon-observability to onboard your namespace.

If you are new to OpenTelemetry, start with the OpenTelemetry tutorial, which covers what OTel is and how telemetry flows through Platon. This page covers only the PaaS-specific setup.

To get all three signals (logs, metrics and traces), instrument your application with OpenTelemetry and send the data over OTLP.

What OTLP gives you

Beyond stdout logging, OpenTelemetry instrumentation gives you:

• Application-specific metrics, such as request counts, latencies and custom business metrics.
• Distributed traces that show the flow and timing of each request across services.
• Structured logs that are correlated with traces.

Logs on stdout and over OTLP

Once your logs go over OTLP, stop writing them to stdout or stderr as well. If PaaS Logging also collects your namespace, each line reaches Loki twice.

Keep PaaS Logging enabled for your namespace. Stdout and stderr then carry only what never reaches your logger, such as the stack trace of a crash, and the SDK's own errors if your SDK writes them there. The Go SDK does, the Python SDK does only if your logging handlers send them to stderr, and the Node.js SDK only when OTEL_LOG_LEVEL is set.

Prerequisites

• Application running on Platon PaaS
• Tenant set up by Platon team (see PaaS Logging for how to request this)
• Namespace onboarded by Platon (see the note at the top of this page)

Instrument your application

Add the OpenTelemetry SDK to your application. The exact steps depend on your language:

• Python
• Java
• Node.js
• Go
• .NET

Configure the exporter

Point your OTLP exporter to the in-cluster Alloy collector. Set these environment variables in your deployment:

env:
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: "http://alloy.alloy.svc.cluster.local:4318"
  - name: OTEL_EXPORTER_OTLP_PROTOCOL
    value: "http/protobuf"
  - name: OTEL_SERVICE_NAME
    value: "your-service-name"
  - name: OTEL_RESOURCE_ATTRIBUTES
    value: "service.version=1.0.0"

OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES identify your service. Alloy fills in part of that identity for you:

• Service name. OTEL_SERVICE_NAME is required. Without it the SDK falls back to unknown_service:<executable>, which Platon does not replace.
• Namespace. Alloy sets service.namespace to your Kubernetes namespace. To group several applications under one name, set the pod annotation resource.opentelemetry.io/service.namespace. Alloy also keeps a service.namespace you set yourself. Your tenant stays the same either way, because Alloy assigns it from the Kubernetes namespace your pod runs in.
• Environment. Alloy sets deployment.environment.name to development for a namespace ending in -dev and to production otherwise. If it can't match your pod, it leaves the value unset, so set it yourself in OTEL_RESOURCE_ATTRIBUTES. Set it yourself too if you use other environments, such as staging. Alloy never overwrites a value you set.
• Version. Set service.version in OTEL_RESOURCE_ATTRIBUTES.

Keep the default exemplar filter, trace_based. It picks measurements recorded inside a sampled span, which are the only ones that carry the ID of a trace in Tempo. OTEL_METRICS_EXEMPLAR_FILTER=always_on also picks measurements from outside sampled spans, and their exemplars cannot open a trace. Metrics — Exemplars lists which SDKs support exemplars. If a link between signals doesn't show up, see When a link is missing.

Tenancy is handled by Alloy

You do not configure the tenant in your application. The application exports OTLP to Alloy, and once your namespace is onboarded, Alloy assigns the telemetry to a tenant based on the Kubernetes namespace your workload runs in.

Available ports

Protocol	Port	Use case
OTLP/HTTP	4318	Recommended (simpler, works everywhere)
OTLP/gRPC	4317	When you need gRPC

View your data

Once your application is instrumented, open Explore in Grafana and select the data source for the signal you want:

• Logs are in your Loki data source.
• Metrics are in your Mimir data source.
• Traces are in your Tempo data source.

All three data sources are pre-configured in your Grafana organization.

Next steps

• Logs — search and filter your logs.
• Metrics — working with metrics data.
• Traces — working with distributed traces.
• Choosing your signals — moving between logs, metrics and traces.
• Alerting — notifications when something goes wrong.