Grafana Checkmk Datasource
You set up a grafana checkmk datasource by linking the official plugin to your monitoring server API. This link lets your dashboards pull live host and service metrics right from your monitoring site. Teams often create one shared automation account to make this link work fast. When that shared role has too many rights, any dashboard editor can see all system metrics. How the grafana checkmk datasource works Checkmk tracks the health of your servers, apps, and network gear in real time. Grafa
Grafana Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a grafana checkmk datasource by linking the official plugin to your monitoring server API. This link lets your dashboards pull live host and service metrics right from your monitoring site. Teams often create one shared automation account to make this link work fast. When that shared role has too many rights, any dashboard editor can see all system metrics.
How the grafana checkmk datasource works
Checkmk tracks the health of your servers, apps, and network gear in real time. Grafana turns that raw metric data into clear charts for your team. The datasource plugin bridges these two tools over standard web requests.
To start, an admin installs the Checkmk plugin inside the Grafana server. Next, the admin creates a dedicated automation user inside the Checkmk site. This user gets a secret key instead of a normal login password. The admin enters the server URL, site name, username, and secret key into the plugin settings.
When a user opens a dashboard, Grafana sends a query to the Checkmk REST API. Checkmk checks the user role and returns the matching host and service numbers. The plugin formats those numbers so the dashboard panels can draw graphs. Teams can filter these views by host groups, service states, or custom labels.
Managing permissions and role limits
Checkmk uses roles and contact groups to control what each user can read. A basic monitoring user only sees hosts tied to their specific contact group. An admin role sees every host, service, and metric across the whole site.
Most teams link the datasource with a single automation user account. Every person who can edit a dashboard in Grafana shares that one account. If you give that account admin rights, every dashboard editor can query all servers. They can pull data from production databases, core routers, and internal apps alike.
You can limit this risk by giving the automation account a guest or custom role. You assign that account only to the contact groups that need public dashboards. If three teams need different views, you can set up three separate datasources. Each datasource uses its own automation user with tight contact group rules.
Grafana Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native setup solves and where gaps remain
Native roles and contact groups control which server sets the plugin can reach. They stop a team from seeing hosts outside their assigned group. They also stop the dashboard tool from making changes to your monitoring rules. A read-only role keeps your check settings safe from bad edits.
Still, the native setup only checks who logs in when the link starts. It does not check what each query asks for while in flight. Once the plugin logs in, all users in that Grafana workspace share the same power. You cannot see which engineer ran a heavy query inside the Checkmk logs. Every API call looks like it came from the same shared automation user.
Also, status strings and log outputs can hold sensitive data like emails or phone numbers. Native monitoring roles do not rewrite or mask those fields inside metric labels. If a check outputs a customer email or card number, the dashboard displays it.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Which Checkmk edition do I need for the Grafana plugin?
You can use either the Raw edition or the Enterprise editions. Both types include the web API that the datasource needs to pull metrics. Some graph filters work in a different way depending on your edition.
Should I use a normal user or an automation user?
Always use an automation user for your datasource link. Normal users have to change passwords and can get locked out. Automation users log in with a secret key built for machine calls.
Why can my dashboard not see any hosts after linking?
Check the contact groups assigned to your automation user inside Checkmk. By default, a normal monitoring user only sees hosts linked to its own contact group. Assign the user to the right host contact group to fix the empty view.