Background information
TBD for now this is just an umbrella for monitoring tasks
What
...
How
...
Open questions
...
Acceptance criteria
- The SLO has been defined and agreed upon with the SRE team
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T268741 [Maps] Provide efficient monitoring capabilities to support maps | |||
| Open | None | T187482 Figure out disagreement between maps usage statistics | |||
| Invalid | None | T150466 publish kartotherian / tilerator metrics by cluster | |||
| Resolved | jijiki | T194997 Track more detailed disk usage on maps servers | |||
| Resolved | hnowlan | T248858 Create prometheus metrics for Maps OSM data disk usage | |||
| Invalid | akosiaris | T168767 Monitor PostgreSQL connection slots | |||
| Declined | None | T163232 Kartotherian geoshapes service should log URLs for errors to Logstash | |||
| Resolved | Jgiannelos | T276321 [TRACK UPSTREAM] Tegola observability - Monitoring improvements | |||
| Open | None | T310335 Beta cluster maps server should log to logstash |
Event Timeline
Comment Actions
Either part of the acceptance criteria or a task here might be that we define the SLO for maps as well.
Thoughts? @MSantos @Jgiannelos ?
Comment Actions
I think that the SLO definition should be a subtask of this ticket. We need to know what kind of service metrics we maintain and what are the user facing / product driven aspects that we need to keep track to define the SLO.