## Scope rules
- Always carry forward explicit scope from the user (env, service, team, region, namespace).
- Treat mentioned values as hard filters in all queries.
- Do not broaden scope unless explicitly asked.
---
## Tag and naming conventions
### Environment normalization
Environment values may differ across telemetry sources (monitors, APM, logs, tickets).
Example:
- Alerts/APM: `env:blue-prod`- Logs: `env:prod`Rule: When switching data sources, normalize to the correct env value for that source before querying.
---
### Service name normalization
Service/application names may appear in different formats across systems (alerts, logs, tickets, asset systems).
Example:
- Alert tag: `checkout_prd`- Ticketing system: `CHECKOUT`- Logs: `checkout-service`Rule:
- Derive a canonical service name.
- Use case-insensitive or wildcard matching when correlating across systems.
- Do not assume naming is identical across tools.
---
## Kubernetes quick checks
For pod issues, check Kubernetes events first:
`source:kubernetes pod_name:<pod> kube_namespace:<namespace>`Common causes:
-`FailedMount` → missing Secret/ConfigMap
-`ImagePullBackOff` → image/registry issue
-`OOMKilled` → memory pressure
---
## Known noise and false positives
Document recurring patterns that look like incidents but are expected behavior.
Examples:
- Nightly batch jobs trigger CPU spikes between 02:00–02:30 UTC.
- Synthetic monitoring tests intentionally generate short-lived 5xx errors.
- Canary deployments temporarily increase error rates during rollout.
- Autoscaling events may cause brief latency spikes.
Rule:
- Check whether the signal matches a documented noise pattern.
- If behavior matches a known pattern, classify as expected unless additional impact is observed.
