You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently columns (lines or keys) are hardcoded in GraphConstants.js.
It would be nice to have the flexibility to have more or less lines or have custom labels. Some examples:
when return-value matching is enabled there would be an additional total_count (counting all the function calls) and count would show the number of matched return values. Useful to see the ratio of matching.
command funcount would only gather call count (and maybe average latency) but not percentiles. This is an optimisation in the backend using different kind of tracing with less overhead. So it would only have count and mean keys.
So columns and labels should be created based on the keys in the data sent by the backend. It is guaranteed that one monitor (belonging to one query) would always send the same keys in its samples.
Open question how to set colours and which columns to hide by default.
The text was updated successfully, but these errors were encountered:
#154 gives a generic and lightweight FE solution where only the lines sent by the BE as keys are displayed on the line-graphs. There is no hard-coded list any more, but it is possible to define colors, y-axes etc for certain names (if they are present).
There is no derived lines or switching, instead the BE sends all of count, total_count and match_rate if applicable, but the two later will be hidden by default.
Currently columns (lines or keys) are hardcoded in
GraphConstants.js
.It would be nice to have the flexibility to have more or less lines or have custom labels. Some examples:
total_count
(counting all the function calls) andcount
would show the number of matched return values. Useful to see the ratio of matching.funcount
would only gather call count (and maybe average latency) but not percentiles. This is an optimisation in the backend using different kind of tracing with less overhead. So it would only havecount
andmean
keys.So columns and labels should be created based on the keys in the data sent by the backend. It is guaranteed that one monitor (belonging to one query) would always send the same keys in its samples.
Open question how to set colours and which columns to hide by default.
The text was updated successfully, but these errors were encountered: