Another promotional useless crappy article full of keywords and totally void of content.
I was genuinely curious about what was done exactly, what part of the project is done in and with grafana exactly. In the end, without further detail, my guess is that everything useful is done by another service and Grafana is just used as a dashboard without much added value...
What I dislike about Grafana is just how much freedom it provides when building dashboards. It means that if you open up a dashboard that's made by someone else, you have absolutely no idea how to interpret the data. For example:
- I've worked with people who liked to use gauges all over the place. So you open up a dashboard and all it says is "Latency: 100 ms". How am I supposed to know whether that's good or bad? Has it always been like that, or is the system currently slower than usual? A gauge is inferior to a graph that shows the metric over time.
- When building graphs, you can independently control whether it is stacked, and whether a background fill is used. Why would you ever want to make a non-stacked graph with a background fill, or vice versa? The former is in fact the default when creating new graphs, which is outright ridiculous. As a cherry on top, you can also make stacked graphs logarithmic.
Pretty great that you can apparently use Grafana to monitor steel alloys, but all of this flexibility isn't helping people to build reusable and intuitive dashboards in the (cloud) observability space.
Isn't that a given that without knowing the system and the dashboard you wouldn't be sure how to interpret the data? An extended description can be added, but even for the simplest graphs I wouldn't want to ever assume too much.
> Why would you ever want to make a non-stacked graph with a background fill
Large displays where you rarely get two different lines active at the same time. This improves visibility. I guess you could also make the line thicker instead. For example I'd use it for showing number of nodes using each deployed version - adding the fill makes the change time more obvious and the overlap is small.
> A gauge is inferior to a graph that shows the metric over time.
Yes, but that's a bad usage of gauges. Again, large displays for example in a call centre. You want to know how many calls are queued and you know the capacity. The historic view may not matter much for the person looking at it, just the current state.
You can use any tool badly, but it doesn't make it a bad tool.
What I'm saying I guess is, if you're familiar with the system, then a dashboard is good. If unfamiliar people are the target, then an infographic-style website or a presentation is a better option.
For the example of the call centre a graph would still be better than a gauge. Because if the graph of people in the queue is going up you may want to get more staff.
Yes / no... For continuous action you'd want something more clever for that, like an indicator of wait over capacity, taking standard load during that time + prediction into account. You want an indicator not history to interpret.
On the other hand, for planning / long term analysis, you probably want something like daily heatmap, or similar.
I'm not sure where a plain graph of very recent history would be useful in practice in that scenario. Again, the main thing I'm trying to say is: who looks at the dashboard, why, from what distance, etc. all impact on what elements you want to use. None of them is bad/good in general. (Apart from 3d pie)
I was genuinely curious about what was done exactly, what part of the project is done in and with grafana exactly. In the end, without further detail, my guess is that everything useful is done by another service and Grafana is just used as a dashboard without much added value...