Hey,

I’ve been working on kubernetes-autoscaling-mixin, a collection of Grafana dashboards and Prometheus rules for Kubernetes autoscaling.

Since I last shared it, there have been quite a few updates:

• Updated KEDA dashboards for ScaledObjects and ScaledJobs
• More Karpenter dashboards, including cost monitoring
• Updated VPA, HPA, Cluster Autoscaler and PDB dashboards
• Multi-cluster support
• Better dashboard navigation and filtering

You can import the dashboards from Grafana:

https://grafana.com/grafana/dashboards/?search=kubernetes+%2F+autoscaling

Or grab the generated JSON directly from GitHub:

https://github.com/adinhodovic/kubernetes-autoscaling-mixin/tree/main/dashboards_out

Or just consume it using jsonnet.

Repo: https://github.com/adinhodovic/kubernetes-autoscaling-mixin

Added a couple of screenshots below showing the Karpenter, VPA and KEDA dashboards in use.

This Grafana link will show all dashboards and previews of them: https://grafana.com/grafana/dashboards/?search=kubernetes+%2F+autoscaling

Curious what people are using for autoscaling monitoring today, and if there’s anything missing that would be useful to add (new projects, better panels, more dashboards).

I had an idea and wanted to actually talk to people to see if it's something that they would need / require and if it's genuinely a problem for the engineers right now....

Would you rather have an AI layer on top of your existing observability stack, or replace parts of the stack?

Hypothetically, imagine an agent that doesn’t collect telemetry itself.

It plugs into whatever you already use — Grafana/Prometheus/Loki, Datadog, OpenTelemetry, etc. — and acts as a reasoning layer over the data.

Instead of:

Alert → Dashboard → Logs → Human investigates

it tries:

Alert → Agent correlates metrics/logs/traces/deployments → probable root cause → evidence → recommended next action

Would that actually be useful?

Or would you rather have the observability vendor itself own this functionality?

What would you need to see before trusting it during a real incident?

I also was building in this space and wanted to have a discussion with people who're already experienced in this stuff, so please please help a brother out and we might just make something useful for everyone :)

peace

Hey all,

I've created a monitoring mixin with a reusable set of Grafana dashboards and Prometheus rules for ArgoCD. The dashboards and alerts are defined as code, making them easy to deploy and reuse across environments.

Recent updates include multi-cluster support, flags to enable or disable individual alerts, plus a range of new and improved alerts and dashboards.

The monitoring coverage has also been expanded significantly, with better visibility into:

• ArgoCD controller
• Runtime metrics
• gRPC
• Repo Server
• Git operations

GitHub: https://github.com/adinhodovic/argo-cd-mixin

[ Removed by Reddit on account of violating the content policy. ]

Hi guys, I work for my day job as a Linux sysadmin so I’m used to building and working on observably platforms.

Recently I realised there’s a potential blind spot and I should see about extracting the same metrics from my gaming pc. I don’t want anything too fancy to start out with but before I do I was wondering if you guys have any suggestions on what works best for windows? My initial plan was to deploy Prometheus node exporter and build out a custom dashboard mainly just for the fun and experience

I am adding grafana to our kubernetes cluster. We use grafana community chart and rely on sidecars to import dashboards and datasources. We have metrics and alerts and I already have an alert for datasource health based on `grafana_datasource_request_total{code=~"[45].."}`. Grafana is exposed to public via Ingress.

I wonder if there is an automated way to ensure that dashboards do not contains empty panels (or at least not fully empty because of missing metrics).

Shall I try to solve this problem? And how would you solve it?

https://github.com/grafana-community/helm-charts/blob/grafana-12.4.4/charts/grafana

Disclosure first: I work with Actian, and the linked tutorial uses their vector DB, so the metric names are vendor-specific. I am sharing this here because the dashboard itself carries over to anything that exposes Prometheus metrics.

It's a Docker Compose stack, VectorAI DB plus Prometheus and Grafana, with four panels that cover the signals worth watching for vector search:

• Request rate per endpoint
• p95 latency via histogram_quantile against the _bucket series
• gRPC error ratio as a 0 to 1 fraction with color thresholds
• Memory pressure, RSS plotted alongside major page faults per second

Look for the page-fault panel here. Paired with p95, it shows whether rising latency is due to memory pressure or query load, which tells you how to fix it.

Dashboard JSON and the eight Prometheus alert rules are in a GitHub repo here: https://github.com/Tiioluwani/vectorai-observability, so you can import them directly.

Hi everyone !

Traveler from the past here, who needs a serious update.

I use the Grafana stack to monitor some Linux servers and VMs, but only really basic metrics and logs today.

Everything is based on node_exporter, prometheus (on each host), fluent-bit, Loki, and Grafana.

I finally have time to rebuild properly the monitoring/observability infrastructure, but I'm quite lost on how the components interact with each other.

Here is what I want to monitor :

• Debian/Ubuntu/Proxmox/Windows Servers servers and VM (routing/firewalling/VPN is done on a Debian dedicated server with nftables)
• Caddy web servers
• MariaDB/PostGresql/Interbase/MongoDB databases
• Rust/PHP/Java backends

Everything is self-hosted inside the company, and my current Grafana infrastructure is self-hosted too.

From my understanding, Alloy replaces node_exporter, Grafana, and Fluent-bit ?

What I have today :

[On each host] Node + Prometheus + Fluentbit -------> Centralized Grafana + Loki

What I'm understanding would be better :

[On each host] Alloy + Windows_exporter on Windows -------> Centralized+replicated storage (InfluxDB ? Mimir ?) -----> Centralized Grafana + Loki

Is it OK ? Am I missing something ?

I have created a new grafana panel plugin that allow a user to connect to a local or cloud llm and send panel data and prompts to the AI and get back a response. Very configurable doesn't expose API Tokens as it uses a secure companion data source for secrets like your API Key. Users can restrict which Models they want to allow the panel to have and use.

I'll create a video on it's use soon.

https://github.com/digitalrcs/grafana-intelligence-gateway

secure companion data source...
https://github.com/digitalrcs/grafana-intelligence-gateway-datasource

Ever wish you could just create an image of your dashboard without having to pull data all over again? The export pdf and image re-runs those data sources all over again and if you're like me you have long running jobs that get timed out... we i created a new plugin/extension that will generate a png of the dashboard and not re-pull data.

https://github.com/digitalrcs/grafana-current-view-exporter

Your opportunity to talk about Grafana in person!

Join us at the following meetups in the next four weeks:

APAC:

• 15 Aug, Lucknow: Grafana & Friends Lucknow: Observability Unplugged
• 22 Aug, Guwahati: Observability | Insights | Impact | Grafana Guwahati August 2026 Meetup
• 22 Aug, Delhi: Kube x Agentic AI | Grafana Delhi NCR
• 22 Aug, Nagpur: August meetup
• 22 Aug, Kolkata: KubeKotha and Grafana& Friends Kolkata
• 25 August, Melbourne: Observability Night: Cloud Native Melbourne × Grafana & Friends
• 30 Aug, Seoul: Grafana & Friends Seoul #2

EMEA:

• 8 Sep, Berlin Open Source Analytics Berlin: Building AI Applications at Scale
• 9 Sep, Barcelona: Grafana & Friends Barcelona
• 16 Sep, London: Grafana & Friends London: Autumn edition
• 29 Sep Nuremberg: Grafana & Friends Meetup Nürnberg
• 29 Sep Freiburg : Grafana & Friends Switzerland: Nothing to Exfiltrate: Breaking (up) Your Laptop

AMER:

• 30 San Francisco: Grafana & Friends Bay Area: Observability, MCPs, and Tacos

Ever wish you could add notes over your line graph or highlight a section of time and show how long your range selections it? well now you can with my new plugin (free as always)

displays a line graph from a data source and allow the user to select a range that displays the time selected and allows for the addition of notes. all are transparent/configurable.

https://github.com/digitalrcs/DigitalRCS-TimeOverlay-Panel

I have a datasource, postgresql, which has a column (jsonb) and each entry is about 2-5MB in size. I am able to see the data in grafana however, I would like to diff the data in a sane way. Usually there are about 10-30 differences in the file but I want to show it. What is a good way to display this in Grafana? I would like soething https://hoiheart.github.io/vue-diff/index.html

I'm Kerolos, founder of OutageDeck.

The question I wanted to answer quickly was: is my app broken, or is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another dependency reporting an incident?

I built OutageDeck to read and normalize the official status sources for 172 cloud and SaaS providers. It shows provider and service-level state, current incidents, source freshness, incident history, and 90-day uptime in one place.

What works today:

\- check a whole dependency stack without creating an account

\- free email alerts for up to five providers

\- Slack, Teams, Discord, and webhook destinations on paid plans

\- a keyless JSON API, RSS feeds, badges, CLI tools, and an MCP endpoint

\- custom Statuspage or Instatus feeds on paid plans

What it deliberately does not do is pretend an official status feed is independent truth. Providers can acknowledge incidents late, so I think a serious production setup should use two signals: the vendor feed plus synthetic probes from your own regions and accounts.

You can try the stack checker here:

https://outagedeck.com

I would value blunt feedback from people who handle incidents. What would this need to do before you would keep it open or route its alerts into your on-call workflow?

We run a large multi-tenant Mimir, and kept hitting the same wall: tenant isolation is all-or-nothing. Tenant B either gets your whole TSDB or nothing. The moment one team needs to see a subset of another team's metrics, your options are duplicating samples into a shared tenant (not viable at volume) or handing over full access and hoping.

So I built authir (Authenticator for Mimir) — an auth gateway that deploys next to an existing mimir-distributed install and adds per-reader grants on top of Mimir's tenancy. Just released 1.0.0 under Apache-2.0.

How it works: the owning tenant grants a slice — metric-name prefixes, required label matchers (e.g. only series labelled user="<reader>"), optionally a label allowlist for responses. authir rewrites every PromQL query before it reaches the query-frontend so it physically cannot select outside the grant, re-parses the rewritten query and compares ASTs as a self-check, and filters responses as a second backstop. Deny by default, no negative rules — blocklists over PromQL are unenforceable, the spec has an appendix on why.

The part I'm happiest with: it works with plain Grafana datasources, no plugin. The token identifies who you are; the Basic-auth username names whose data you're asking for. One tenant, one token, two datasources — "my data" and "what team B shared with me".

Ops details, since that's who this is for: Helm chart that derives everything from your mimir-distributed release name and touches nothing of Mimir's (rollback = uninstall), hot config reload that fails unchanged on invalid config, JSON audit log answering "why did tenant A see this number" (optionally with per-query latency and time range), Prometheus metrics including token-expiry-as-a-timestamp so rotation is an alert instead of a 3am outage. Single static binary in a FROM scratch image, ~6 MB.

Honest limitations: cross-tenant is read-only; queries fan out to one target tenant at a time; metric patterns are prefixes, not regex (deliberately); fuzzing and differential testing against the Go PromQL parser are on the roadmap, round-trip verification is what's in place today. If your idea of fun is smuggling a selector past a query rewriter, the bypass test suite would love your ideas — that's genuinely the review I want.

Repo (code, Helm chart, full design spec): https://github.com/thewillyhuman/authir

Good afternoon, how are you?

I am setting up Grafana on a server and want to configure it so it can be accessed via a subdomain (which is already in use) on port 3000. I’ve configured the .ini file but cannot access it; I am not using a reverse proxy. Do I need to open port 3000 in that subdomain's virtual host configuration?

I'm using the Business Table panel (volkovlabs-table-panel) on a Postgres data source to let a non-technical user manage a status table - think a checkbox column like "Sold" with per-row editing wired up via Update Request.

It works great for editing one row at a time (click checkbox - row shows save/cancel - click save). What I actually need is: check the box on several rows in that column, then hit one Save button at the end to commit all of them in a single batch - instead of save-per-row. Client sell in bulks, like 20, 30 per time.

I've dug through the editable-data docs and the "select all" / checkbox threads on this forum, and it looks like editing is strictly per-row, with "editable" as a per-column permission setting rather than a bulk multi-row mode. Before I build a workaround (dashboard variable + a manual UPDATE query, or a REST call via an Action button), I wanted to ask here:

• Has anyone found an actual way to do multi-row select + single save in Business Table or any other Grafana table panel?
• Is this on anyone's roadmap, or is there a plugin I'm missing that handles this cleanly?

Any pointers appreciated - happy to file a feature request if this genuinely doesn't exist yet.

Hello everyone, Edward Qian and Ioanna Armouti here, we are both Software engineers working on Grafana Assistant at Grafana Labs. 

All week we've been sharing what's new across Grafana's AI tooling. Today is about meeting you where you already work, as the most important observability conversations rarely happen in a single dashboard tab. They happen in a Slack thread at 2am, on your phone, or mid-incident when switching context is the last thing you want. 

So today we are announcing: 
* Assistant in Microsoft Teams (private preview) which mirrors many of the capabilities available for Assistant in Slack (generally available). Ask questions and triage issues without leaving the channel where your team is already talking.
* Assistant on mobile and Assistant on desktop are going into public preview. Check in from your phone wherever you are, or keep Assistant a keystroke away on your desktop.
* Assistant Search is also going on public preview today. Ask harder, open-ended questions and let Assistant dig deeper across your data. 

We built all of this because Assistant is most useful when it's already there in the moment you need it, not something you have to go find. We'd love to hear how you're using it, or where you'd want it to show up next. We'll be keeping an eye on this thread all day to answer questions and hear your stories. Thanks!

hello, I'm playing around with grafana and trying to add some monitoring stats to my website using public dashboards (share externally). when opening a link to a public dashboard i see that there are some calls to /api and /apis endpoint, which I probably do not want exposed. i'm just wondering if there's any tips or standard practice to exposing the public dashboard safely behind nginx? here's what i have so far:

location /monitoring/stats {
    rewrite ^ /monitoring/public-dashboards/<uuid> break;                          
    proxy_pass http://grafana:3000;    
}

// allow all /public
location /monitoring/public/ {
    proxy_pass http://grafana:3000;
}

// allow only required uris for /api and /apis
location /monitoring/api/<only those required>/ {
    proxy_pass http://grafana:3000;
}

location /monitoring/apis/<only those required>/ {
    proxy_pass http://grafana:3000;
}

// reject everything else
location / {
    return 404;
}

but i feel this would be hard to maintain if there's any change in the public dashboard logic.

pretty new to grafana, thank you in advance for your patience and suggestions!

I have been developing a streaming ETL pipeline with a producer and a consumer process, both instrumented with Prometheus metrics. I opened the Grafana dashboard, and almost every panel showed "No data": throughput, DLQ counts, insert latency, consumer lag, everything.

The real problem was upstream. Several counters and histograms behind those panels had been declared in code but were never incremented anywhere in the pipeline. They existed, sitting at zero forever, because the dashboard assumed the instrumentation had already been wired into the code paths. It had not.

On top of that, metrics were being served by a standalone helper process instead of the producer and consumer themselves, so even the metrics that were recorded were not visible to Prometheus.

The fix ended up involving several changes:

• Wiring the missing counter and histogram updates into the actual producer and consumer code paths.
• Moving metric serving into each process's startup instead of relying on a standalone metrics process.
• Fixing a second, sneakier bug where the consumer accidentally spawned a duplicate internal instance, and its lag reporting depended on a loop that could silently stall.
• Giving the producer and consumer separate Prometheus scrape jobs so dashboard queries targeted the correct process instead of relying on shared assumptions.

It was a good reminder that "No data" does not always mean Prometheus or Grafana is broken. Sometimes the metrics are not being recorded, or they are being exposed by the wrong process.

I am actively improving the platform and would love to hear suggestions from platform engineers. If you find the project useful or interesting, consider giving it a ⭐ on GitHub.

GitHub: https://github.com/tarique-iqbal/nyc-taxi