Investigate
Evidence
How AutoObserve gathers, qualifies, and presents inspectable production evidence.
Docs v1.0Updated Supported
When should I use this?
- You need to understand what counts as evidence before trusting an investigation conclusion.
- You are connecting telemetry and want evidence quality to support strong investigations.
- You want to inspect the sources behind a claim instead of accepting an AI summary.
Requirements
- Metrics, logs, and traces connected via OpenTelemetryRequired
- Consistent resource identity (service.name, k8s.* attributes)Required
- Deployment or change signals when availableOptional
Steps
1. Know what evidence includes
AutoObserve correlates multiple signal types into evidence cards:
| Type | Examples |
|---|---|
| Metrics | Latency spikes, error rates, saturation |
| Logs | New error signatures, stack traces |
| Traces | Failed spans, latency propagation |
| Changes | Deployments, config changes, rollouts |
| Topology | Dependency paths, blast radius |
| Runtime | Pod restarts, OOMKills, scheduling events |
2. Inspect every claim
Open any evidence card to see the observation, source query, timestamp, and correlation strength. AI answers without inspectable evidence are not the product model.
3. Understand evidence quality
Evidence is rated by coverage and correlation — weak, moderate, strong, or complete. Partial telemetry reduces confidence instead of disappearing silently.
Optional deep dive: Explore evidence cards on the Demo investigation or Platform investigation pages.
Did it work?
- Demo evidence cards open with inspectable sources
- Live telemetry shows correlated signals for a known service
Troubleshooting
Problem
Investigation evidence has low correlation or partial coverage.
Symptoms
- Single signal type only
- Missing k8s or deploy context
Likely causes
- Incomplete OpenTelemetry pipelines
- Weak resource identity
Resolution
Connect metrics, logs, and traces. Align resource attributes across pipelines. See [OpenTelemetry identity](/docs/connect/opentelemetry#resource-attributes).
Verify fix
Evidence cards include multiple signal types with consistent service identity.
Problem
Expected evidence type does not appear in an investigation.
Symptoms
- No trace evidence despite trace pipeline
- Missing deploy correlation
Likely causes
- Pipeline omits signal type
- Change source not connected
Resolution
Verify all three signal pipelines export to AutoObserve and cluster change signals are available.
Verify fix
Missing evidence types appear or are explicitly marked unavailable.