![]() Code review for dashboards, and reviewers who are application experts (who understand the meaning of the displayed metrics), are essential to keep up good quality and really make the dashboards plain simple to use without explanations.įor medium to large companies in terms of head count, introducing such a consistent concept will be impossible unless technical leadership supports the full switch from the old or non-existing monitoring solution to Grafana with dashboards-as-code. Therefore, I recommend you present the dashboards on screen during incidents, so that other users see the capabilities they offer, and less obvious features such as the hyperlinks that can be added to the clickable top-left corner of each visualization. Training for incidents anyway mostly happens through practice. Yes, you heard right! A well-designed dashboard is 100% obvious and requires no explanation to use it, given the user knows the relevant terminology of your monitored system. Those get automatically deployed, for example by a CI pipeline. They should however be trained that changes should not be saved, and any saved changes will regularly be overwritten by the dashboards committed as code. Users nevertheless get write access to Grafana, since that allows temporarily adapting a dashboard for own usage, such as special investigation during incidents. ![]() The high-level dashboard links to those.įrom each visualization (those are the rectangles on your dashboard, such as graphs), link to detailed dashboards, prepared log queries, debugging tools on your intranet, the system/website itself, etc.Ĭreate dashboards solely through code, to avoid having a mess of manually created, unreviewed, inconsistent dashboards after a few weeks, and the need for a company-wide "tooling switch" after a few months or years, only to clean up all of that. Represent each component or microservice of a system in the high-level overviewįor fine-grained analysis, it also often makes sense to create a separate, detailed (low-level) dashboard for each component. The scope could be one system, service, product domain, or for small companies even the whole landscape at once. It depends on your company how many of those make sense. On the same note: great dashboards help in many ways, such as against following red herrings, but nevertheless you need application experts to resolve incidents, so those should definitely be part of the audience.Ĭreate a high-level overview dashboard. Most importantly, you as author should be part of the audience yourself, or else you are not a good fit to develop a reasonable dashboard. If however your organization looks totally different and dashboards are for sales, management, compliance, information security, then the goals can be different - the article may still be helpful nevertheless. This article will focus on examples how to monitor the health of software systems (easy to apply to network and infrastructure likewise). Or it may be multiple technical departments (operations + engineering). For other organizational concepts, it might be SREs or infrastructure engineers. Think of your company: who is the main audience of the dashboards? If you are using the "you build it, you run it" concept, it may be mostly developers (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |