I did not find much-organized information about Grafana configuration from the management point of view. There is this famous default setup, but it is not clear what its limits are. Also, for those who would want to take the next step to an actual application, what direction should it be, or in other words, what should be modified in the default Grafana installation package to convert it into the real deal?
This article consists of the notes I took during my research. I share them to save the reader's time and effort.
In any setup, Grafana can be installed directly on the host or in a Docker container. That's why every rectangle representing Grafana has the docker slash host symbol on the diagram below.
Let's review every level and who can benefit from each.
You get the default setup when you download Grafana and follow the simple installation steps.
Grafana configuration is a set of parameters describing
- Data sources.
- Installed plugins.
- Users and permissions, etc.
Grafana configuration is stored in a database. In the default setup, Grafana is bundled with the SQLite database.
Provisioning is a mechanism to push dashboards and data source configuration using JSON files into Grafana UI. This mechanism is a simplified way to create applications with embedded/preset data sources, plugins, and dashboards.
Users cannot introduce changes to the provisioned dashboard and data sources unless it's allowed in the configuration.
SQLite is designed explicitly for small applications and is widely employed in myriads of applications across the globe. The database is meant to be coupled with an application, ensuring high reliability and efficiency.
The database is so tiny and fast that some people do not even realize it exists side by side with their favorite applications on the phone or computer. The code of SQLite is open for anyone to use for any purpose.
The default setup suits beginners well since it eliminates the maintenance needs allowing them to start exploring Grafana instantly, literally minutes after they learned about Grafana's existence.
The skill level required for this setup is relatively minimal. An inquisitive beginner-to-intermediate developer or analyst can tackle the task with ease.
The next level setup is the lowest level you must be on for any commercial and industrial applications.
On that setup, the Grafana UI and the configuration storage (which is NOT the same as application data storage) are separated and dwell in two segregated containers and/or hosts. When Grafana users make any changes (for instance, adding data sources and visualizations), these changes go into a separate entity, namely, configuration storage.
You can choose between databases
We discussed how to update Grafana environment variables to use the PostgreSQL database in our recent video.
This architecture allows solving any challenging problems as long as developers are willing to think out of the box and do not tend to stay on the paved trail.
Your best bet is someone who knows Grafana deeply and is capable of following changes from one version to another.
Logically, this architecture should have at least two separate Grafana UI.
It is everything that the next level is, plus a load balancer. A load balancer will redirect the traffic between multiple Grafana UI depending on the load or other parameters.
The High-Availability configuration
- Allows connecting many Grafana UI to the same configuration storage. Therefore, to have a matching experience across all of Grafana UI.
- Requires maintaining only one configuration database instance, regardless of the Grafana UI number.
It would be best to have a whole team of tech pros to support the web application with high upstream/downstream traffic and unstoppable 24/7 user requests.
Any feedback and comments are welcome. Feel free to challenge us with your questions. It helps us to stay sharp!