Page MenuHomePhabricator

Create a central board to monitor the general health of our features
Closed, ResolvedPublic

Description

We want to have a central place to go where we can easily see the general health of the features we maintain. For that we want to create a Grafana board that's a collection of base line metrics across features. Thereby we also validate if there's anything missing and if we can stop gathering user preference data on a daily basis to do a similar health monitoring.

Acceptance criteria:

  • Create a new Grafana board as central TechWish feature health check
  • Make sure that it visualizes curves representing at best one indicator per tool that could be used as base value for it's usage
  • Figure out what's missing or is not working anymore along the way

Relevant features:

Done with the help of Grafana Library Panels

Overview of TechWish features ( Grafana )

  • Kartographer nearby

Maps nearby board ( Superset )

Reference preview board ( Superset )

Event Timeline

WMDE-Fisch renamed this task from Create a board monitor general health of our features to Create a board to monitor the general health of our features.Nov 2 2023, 3:30 PM
WMDE-Fisch renamed this task from Create a board to monitor the general health of our features to Create a central board to monitor the general health of our features.Nov 2 2023, 3:41 PM

/me wags eyebrows towards Superset. The very big advantage of using that platform is that we don't need to write a separate aggregation layer to get the data into Graphite, we can query hive and mysql directly.

/me wags eyebrows towards Superset. The very big advantage of using that platform is that we don't need to write a separate aggregation layer to get the data into Graphite, we can query hive and mysql directly.

Since the data is already in grafana and we are only displaying existing charts in an overview board, we do not need to do any new aggregations anyway.

I think this point was already made in discussion, but just for our records it hasn't worked out well to track feature enablement through the user preferences tables. See T260182 for an example of that approach going very badly. Instead, we should look at more operational metrics such as "number of times users entered the feature's main workflow".

@lilients_WMDE For Two-Column-Edit-Conflict-Merge it might be better to use Share of successful resolutions coming from TwoColConflict it seems to be more likely to show if something's wrong.

Okay, thanks. I changed the board accordingly.

WMDE-Fisch updated the task description. (Show Details)
WMDE-Fisch updated the task description. (Show Details)