stitch primary metrics across elections
There might already be a way to do this, but I cannot find it. Please provide a way to combine "all primary" metrics into a single chart.
I love your metrics, but I hate that when primary moves from one server to another I get "data gaps" in my graphs. So then it becomes exceedingly difficult to look at temporal variations... requiring splicing together multiple segments from 2 or 3 different graphs.
I have attached a picture of what I am talking about. You can see that primary moved over for a few days so I get a graph with a hole in the middle. Please provide an option to "combine" all the various primaries into one chart.
Eric
shared this idea
-
Thomas
commented
It is really hard to understand the behaviour of primary replica-set on bigger timeframes, when it was switched some times. Would be very helpful to be able to see the metrics in a integrated chart, to understand consequences of some actions like application changes, index creations, version upgrades, etc.
-
Thomas
commented
Plus 1, it's so obvious. For now, it is not easy at all to have the big picture understanding of primary cluster behaviour when we look to a bigger timeframe.
-
Remee
commented
Providing an aggregated metrics based on the primary server. Right now in order to view history for the primary we have to compare the different charts based on failover, makes it cumbersome to view the active primary trends
-
Doron
commented
When there's an election and the primary changes, it's hard to get a good view on how does the primary functions in a macro fashion.
Please add a monitoring column (or an equivalent solution) that can show the monitoring information for the primary at the time, so I could look at the past month or so, and see how does the primary performed, even if it was a different server every time.This will make it much easier to understand various actions we take like changing indexes, improving queries, upgrading the database version, upgrading the driver, etc.
-
Hi Eric, We'd like to make a change in the future to do this automatically for you because we completely agree that it's the primary-ness that matters not the node-ness. It's a fairly large scale refactor to get there so this will not be possible over the near term unfortunately, but we want to do it.
