Everyone's pushing Elastic for endpoint monitoring. Kibana's a bloated mess for this. Dashboard loads slow, agents chew CPU just to report basic health. Grafana's agent is leaner, but no built-in endpoint dashboard.
Wrote a plugin to scrape and visualize key metrics Kibana obscures. Uses the Elasticsearch API directly, bypassing Kibana's overhead.
```yaml
# plugin's main query for endpoint status
- name: endpoint_health
prometheus:
metrics:
- metric: elastic_endpoint_last_seen_seconds
query: |
max by (host.name) {
metricset.name: "process"
} - max by (host.name) {
metricset.name: "process"
} offset 5m
```
Now I get a clean, fast dashboard for agent last check-in, system load, and threat alerts. No more waiting for Kibana's discover page to render. If your primary stack is already Grafana, this cuts out a whole layer of complexity.
Don't panic, have a rollback plan.
Love this approach. Kibana's overhead for basic health checks is real. I've seen teams spin up whole monitoring instances just for endpoints - your plugin cuts through that.
Curious, did you find the ES API stable enough for this? I've had issues with version-specific endpoints breaking, which is why I usually stick with a dedicated lightweight agent.
But the speed gain, especially on the dashboard load, must be game-changing.
The API stability concern is valid, especially with the move from the Elasticsearch SQL to EQL and the deprecation of certain monitoring endpoints. I've anchored the plugin queries against the `/metrics/` API endpoints, which have remained relatively stable across the 7.x to 8.x transition for the specific `metricset.name` and `event.module` fields. The key is avoiding the higher-level, often-changing Kibana-specific abstractions.
The speed gain is indeed significant, but the real benefit is deterministic load. Kibana's resource usage can spike unpredictably during dashboard renders, especially with live queries. Direct API calls via the Grafana agent give us a consistent, low-overhead scrape pattern.
That said, you're right about version-specific breaks. I now run a separate test pipeline that validates the core queries against each new minor version of Elasticsearch before we roll it out. It adds a step, but it's cheaper than maintaining a full separate monitoring stack.
—J
The ES API has been stable for my core metrics, but I wouldn't call it bulletproof. You're right about version-specific breaks.
I built a version check into the plugin's config. It pings the / endpoint on startup to get the ES version and disables certain queries if it's below 7.10. It's a stopgap, but it prevents silent failures.
The speed is the main win. Have you tried the same direct API approach with your lightweight agent, or are you locked into its own query format?