What we add
- Deployment — Which deployment or release the log line belongs to (e.g. from CI/CD or Git SHA).
- Kubernetes instance ID — Which pod or node produced the log, so you can tie logs to a specific instance in your cluster.
How it works
Rocketlog uses OpenTelemetry resource attributes and standard semantic conventions where possible:- Deployment — We look for attributes such as
deployment.environment,service.version, or your CI/CD–injected deployment ID. You can set these in your SDK or via the OpenTelemetry resource (e.g.OTEL_RESOURCE_ATTRIBUTES=service.version=1.2.3,deployment.environment=prod). - Kubernetes — When you run in Kubernetes, the OpenTelemetry collector or SDK can add
k8s.pod.name,k8s.node.name,k8s.namespace.name, etc. We use these to tag logs with the relevant instance and node.
Setting resource attributes
In your app (Python)
In your app (Node.js)
In Kubernetes
If you use the OpenTelemetry Operator or a sidecar collector, configure the collector to add Kubernetes attributes (pod name, node name, namespace) to the resource. Rocketlog will then tag logs with the corresponding Kubernetes instance ID and deployment context when available.Using enriched logs in Rocketlog
- Open the Rocketlog dashboard and select a time window.
- In logs view, filter or group by deployment or instance (e.g. pod name).
- Use AI root cause analysis; the model can use these tags to narrow down which deployment or instance was involved.