Add additional sections to telemetry.mdx
- Dominant language
- Go
- Stars
- 30.1k
- Forks
- 4.6k
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 39
Description
#### Feature Description
Our telemetry docs do an effective job at identifying the key metrics operators should be tracking and suggested alerting thresholds. However, we currently provide a table with every metric after that without groupings. The metrics in this table are second or third order - likely to be used for debugging after a problem has been identified and needs to be narrowed down. They're the metrics that are specific enough to provide operators insights into how Consul's being used.
In order to make this better, we should categorize the remaining metrics by the workloads they're used in. Often this is captured by the second token in the metric name, e.g. ACLs: `consul.acl.etc`.
#### Use Case(s)
We should group metrics by workload where applicable so we may provide guidelines on grokking them, alerting on them, debugging with them, and getting insights from them.
Contributor guide
Research direction
Open telemetry.mdx and review the existing metrics table and the naming patterns described in the issue. Group the remaining metrics by applicable workload and add guidance for interpreting, alerting on, debugging with, and gaining insights from those groups.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, observability-sre
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100