# Grafana Grafana is an open source data visualization platform which is primarily used for displaying metrics dashboards. It can aggregate, query, and display data from multiple sources such as Graphite, Prometheus, or MySQL. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## ClickHouse Cloud Announces Private Preview of PromQL Support and Time-Series Table Engine DevFeed: [ClickHouse Cloud Announces Private Preview of PromQL Support and Time-Series Table Engine]() Original publisher: [Read original article]() Author: James Cunningham Published: 2026-09-15T14:00:00Z Content type: release Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Prometheus](), [Time Series](), [Cloud](), [Grafana](), [telemetry](), [Traces]() Tags: [clickhouse](), [cloud](), [grafana](), [logs](), [metrics](), [prometheus](), [time-series](), [traces]() ### AI overview ClickHouse announces a private preview of PromQL support and a time-series table engine in ClickHouse Cloud, allowing Prometheus metrics to be stored in ClickHouse and queried with existing PromQL. ### Source excerpt ClickHouse PromQL support lets you store Prometheus metrics in ClickHouse Cloud, query them using familiar PromQL, and bring metrics together with your logs and traces without rewriting queries in SQL. ## How to monitor Cypress tests with Grafana Cloud DevFeed: [How to monitor Cypress tests with Grafana Cloud]() Original publisher: [Read original article]() Author: Rajesh Mahalingaswamy Published: 2026-09-12T11:22:06.456390Z Content type: tutorial Language: en Sources: [Grafana Labs blog on Grafana Labs]() Topics: [Grafana](), [Node.js](), [ci]() Tags: [analytics](), [cypress](), [grafana](), [grafana-alloy](), [grafana-cloud](), [grafana-cloud-metrics](), [how-to](), [logs](), [metrics](), [monitoring](), [node-js](), [observability](), [prometheus](), [traces]() ### AI overview A tutorial for monitoring Cypress test results by converting them to Prometheus metrics, pushing them through a Pushgateway, scraping them with Alloy, and forwarding them to Grafana Cloud Metrics. ### Source excerpt If your Cypress suite has tests that fail more often or run slower, you know it can be hard to figure out the pattern from a single job. It could be one spec that slowed down, or a single test that fails, or maybe the entire suite is trending slower. The root cause could be a bug in the app, or a flaky test, or something else. Your terminal output and CI log will tell you what happened on a single run, but that doesn't help you spot any larger trends--especially since you lose that data as soon as the job finishes. Thankfully, Cypress, a front-end automated test framework built for web applications, already exposes everything you need through its plugin hooks. After each spec finishes, Cypress hands you a results object with pass and fail counts, per-test durations, and states. You just need to turn that into metrics and ship it somewhere durable. In this post, you'll learn how to monitor your Cypress tests by converting those results into Prometheus metrics inside a Cypress hook, pushing them to a Prometheus Pushgateway, and letting Alloy scrape the gateway and forward everything to Grafana Cloud Metrics--using nothing but the free tiers. By the end you'll have a pipeline running with the following architecture: What you'll need This walkthrough runs everything alongside your existing Cypress project. Before you start, make sure you have: A Cypress project (this example uses Cypress 14.x) with a cypress.config.js you can edit A Prometheus Pushgateway. Cypress runs are short-lived batch jobs, so they can't be scraped directly--the Pushgateway holds the metrics between runs so a scraper can pick them up. Set up a Prometheus Pushgateway in your infrastructure Alloy, our open source collector we use to scrape the Pushgateway and remote-write to Grafana Cloud A Grafana Cloud account. The free tier includes Grafana Cloud Metrics and a Prometheus remote-write endpoint. If you don't have an account, you can sign up here Your Grafana Cloud remote-write URL, numeric user ID, an ## Grafana 13.2 release: easier ways to query and explore your data DevFeed: [Grafana 13.2 release: easier ways to query and explore your data]() Original publisher: [Read original article]() Author: Grafana Labs Team Published: 2026-09-12T11:22:06.456390Z Content type: release Language: en Sources: [Grafana Labs blog on Grafana Labs]() Topics: [Grafana](), [dashboards]() Tags: [analytics](), [dashboards](), [enterprise](), [explore](), [grafana](), [grafana-cloud](), [logs](), [metrics](), [monitoring](), [observability](), [release](), [sql](), [traces]() ### AI overview Grafana 13.2 introduces generally available saved queries for Grafana Cloud and Grafana Enterprise, letting organizations store, discover, and reuse vetted queries across dashboards, Explore, and annotation queries. The release also highlights a new View panel sidebar for exploring busy panels. ### Source excerpt Grafana 13.2 is here, bringing more improvements to help you and your team explore your data and get to insights faster. In this post, we'll highlight the latest updates to saved queries, a feature that lets teams share, discover, and reuse queries to get to trusted answers faster and help new teammates get up to speed. We'll also explore how the new View panel sidebar makes exploring busy panels a breeze. If you want to read about all the latest updates in Grafana 13.2, please refer to the changelog or our What's New documentation. Saved queries: reuse trusted queries across dashboards and teams Good queries are hard-won. Writing one means knowing both the query language and your own data, like which of four similarly named metrics is the one you can trust. That knowledge usually sits with a few experienced people, or is gradually learned through exploration (increasingly AI-assisted), validation, and revision. Often teams end up rebuilding the same Grafana queries over and over, and the best ones live in pinned Slack messages or get copy-pasted from old dashboards. New team members feel it most, since their first weeks are often spent reverse-engineering existing dashboards just to work out how to ask a question of their own. The query history in Grafana Explore helps, keeping a couple of weeks of your own queries and letting you "star" the keepers. It's private to you, though. Until recently, there hasn't been a built-in way to take a query you trust and put it somewhere your whole organization can find it. How teams use saved queries We built saved queries, which is now generally available in Grafana Cloud and Grafana Enterprise, to address this challenge by providing a shared query library for your organization. When you write a query worth keeping, you can save it with a title, description, and tags. Saving works from dashboard panels, Explore, and annotation queries. This means teammates who don't know PromQL or SQL can still build dashboards from queries tha ## Custom labels in Grafana Cloud Synthetic Monitoring: New updates for consistency and ease-of-use DevFeed: [Custom labels in Grafana Cloud Synthetic Monitoring: New updates for consistency and ease-of-use]() Original publisher: [Read original article]() Author: Anant Sharma Published: 2026-09-12T11:22:06.456390Z Content type: article Language: en Sources: [Grafana Labs blog on Grafana Labs]() Topics: [Grafana Cloud](), [synthetic monitoring](), [Grafana](), [Monitoring](), [telemetry](), [dashboards]() Tags: [analytics](), [dashboards](), [grafana](), [grafana-cloud](), [how-to](), [logs](), [metrics](), [monitoring](), [observability](), [synthetic-monitoring](), [telemetry](), [traces](), [update]() ### AI overview Grafana Cloud Synthetic Monitoring is updating custom labels so they attach directly to every check metric and log, rather than only sm_check_info. The label_ prefix will be removed, and labels will appear exactly as defined. Existing users must migrate dashboards, SLOs, alerts, and queries that reference these labels by March 1, 2027. ### Source excerpt Labels are a powerful way to organize telemetry and define policies across Grafana Cloud, helping to streamline alerting, attribution, access control, and more. But traditionally, custom labels in Synthetic Monitoring have worked a little differently: they only lived on a single sm_check_info metric, and Grafana Cloud prefixed each one with label_. To make custom labels in Synthetic Monitoring work consistently with the rest of Grafana Cloud--without extra joins, naming conventions, or workarounds--we're rolling out an update that lets your custom labels attach directly to every check metric, not just sm_check_info, and removes the label_ prefix. Starting today, labels appear exactly as you write them, making Synthetic Monitoring data easier to navigate and use with label-based policies across Grafana Cloud. If you currently use custom labels in Synthetic Monitoring, read on to learn how to migrate to the new labels. We are asking users to migrate by March 1, 2027 to ensure their custom dashboards, SLOs, alerts, and queries that reference Synthetic Monitoring metrics do not break, and continue to work as expected. If you do not use custom labels in Synthetic Monitoring, you don't need to do anything to prepare for this update. How custom labels work in Synthetic Monitoring Until now, if you wanted to filter a dashboard, scope an alert, or attribute cost by team or service within Synthetic Monitoring, you had to join sm_check_info against the check metric you actually want to query. You also had to remember that team is really label_team in this context. That approach worked to ensure your custom labels were never at odds with system-defined labels. However, it broke down as usage scaled up and dozens of teams started running hundreds of checks across services, environments, and regions. Teams rely on consistent schemas to direct label-based workflows, and this update brings Synthetic Monitoring further into the fold of your existing policies. With the update, labels i ## How to scale Alloy as a central telemetry gateway: capacity planning, load testing, and production lessons DevFeed: [How to scale Alloy as a central telemetry gateway: capacity planning, load testing, and production lessons]() Original publisher: [Read original article]() Author: Fatjon Nebiu Published: 2026-09-12T11:22:06.456390Z Content type: tutorial Language: en Sources: [Grafana Labs blog on Grafana Labs]() Topics: [Grafana]() Tags: [analytics](), [auth](), [best-practices](), [cloud](), [cost](), [data](), [deployment](), [enterprise](), [grafana](), [grafana-alloy](), [grafana-cloud](), [how-to](), [kubernetes](), [logs](), [metrics](), [monitoring](), [observability](), [opentelemetry](), [platform](), [production](), [prometheus](), [scale](), [telemetry](), [testing](), [traces]() ### AI overview A practical guide to scaling Grafana Alloy as a centralized telemetry gateway. It covers capacity planning, load testing, and production considerations for collecting metrics, logs, and traces and forwarding them to Grafana Cloud. ### Source excerpt Running Alloy as a single-instance sidecar is simple. Running it as a centralized gateway that absorbs the full telemetry stream of an enterprise platform--tens of millions of active series, terabytes of logs per day, and tens of thousands of trace spans per second--is a different challenge altogether. To get it right, you need deliberate capacity planning, honest load testing, and a monitoring setup that doesn't rely on the very thing you're testing. As part of the Professional Services team here at Grafana Labs, we've seen this firsthand working with customers. In this post, we'll walk you through the best practices we follow to help them find success, and we'll do so using real, anonymized data from a recent engagement. We'll cover how we sized and load tested a production Alloy central collector deployment on Kubernetes, what the numbers looked like under real stress, and how the cluster behaves today handling the full production telemetry workload for a large enterprise platform. By the end, you should have a better sense for how you can create your own central gateway for collecting telemetry in Grafana Cloud. Why a central gateway? Before diving into numbers, it's worth explaining the pattern. In a central gateway setup, all telemetry from application teams--metrics, logs, and traces--flows to a shared Alloy fleet via OTLP or native Prometheus/Loki write protocols. Alloy buffers, processes, batches, and forwards everything to Grafana Cloud. This gives you several things that per-team sidecar deployments struggle to provide: A single control plane: Auth, rate limiting, and routing in one place so application teams don't need to manage Grafana Cloud credentials Centralized buffering: Ensure a transient Grafana Cloud slowdown doesn't immediately cause data loss at the source Cost visibility: Configure the gateway to only accept telemetry data containing the label or attribute that is mandatory for cost-attribution Protocol normalization: Send OTLP, Prometheus Remote ## Beyond embedding: How to secure AI/BI Dashboards for every viewer DevFeed: [Beyond embedding: How to secure AI/BI Dashboards for every viewer]() Original publisher: [Read original article]() Author: Sonakshi Pandey Published: 2026-09-09T14:04:44Z Content type: tutorial Language: en Sources: [Databricks]() Topics: [databricks](), [Authorization](), [Grafana](), [SDKs](), [Back end](), [data]() Tags: [authorization](), [backend](), [dashboards](), [databricks](), [embedded](), [guide](), [idp](), [mapping](), [platform](), [product](), [sdk](), [sql]() ### AI overview This guide presents a Databricks design pattern for securing embedded AI/BI Dashboards for different viewers. It uses scoped embed tokens, __aibi_external_value, Unity Catalog row filters and column masks, and identity-provider-synchronized groups so one dashboard can show each viewer only the authorized regions and fields. The same entitlement table governs embedded dashboard access and direct Databricks SQL queries. ### Source excerpt The challengeEmbedding a Databricks AI/BI Dashboard in a customer-facing application is relatively straightforward... ## pgwatch v6: dashboards reimagined, and a reaper that doesn't choke DevFeed: [pgwatch v6: dashboards reimagined, and a reaper that doesn't choke]() Original publisher: [Read original article]() Author: Pavlo Golub Published: 2026-08-28T03:00:58Z Content type: release Language: en Sources: [CYBERTEC PostgreSQL | Services & Support]() Topics: [Grafana](), [PostgreSQL](), [Prometheus](), [incident]() Tags: [blog](), [clusters](), [dashboards](), [features](), [grafana](), [incident](), [linux](), [network](), [news](), [patroni](), [pgwatch](), [postgresql](), [production](), [prometheus](), [release]() ### AI overview This release article describes pgwatch v6.0.0-beta, including a Grafana dashboard overhaul, first-class dashboards for Prometheus sources, Patroni cluster views, four new metrics, and fixes for collection hangs caused by production infrastructure failures. ### Source excerpt This is an extended blog, and talks about the features of pgwatch v6.0.0 beta in more details. Read to know and contribute. The post pgwatch v6: dashboards reimagined, and a reaper that doesn't choke appeared first on CYBERTEC PostgreSQL | Services & Support. ## nixos-telemetry: A NixOS flake for opt-in observability pipelines DevFeed: [nixos-telemetry: A NixOS flake for opt-in observability pipelines]() Original publisher: [Read original article]() Author: palo Published: 2026-08-23T08:27:36Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [telemetry](), [OpenTelemetry](), [Tooling](), [log management](), [Prometheus](), [Grafana](), [Grafana Alloy]() Tags: [announcements](), [collector](), [config](), [grafana](), [grafana-alloy](), [loki](), [opentelemetry](), [prometheus](), [telemetry]() ### AI overview A discussion introduces nixos-telemetry, a NixOS flake that uses an OpenTelemetry collector to connect opt-in scrapers, storage, and visualization components. It supports local stacks, remote forwarding, and fan-out to multiple sinks through a unified option tree. ### Source excerpt Hi everyone, I'd like to share nixos-telemetry, a NixOS flake that makes setting up observability in your infrastructure easy. An OpenTelemetry collector sits at the center of each machine. Scrapers, storage, and visualization are all opt-in. You enable what you need; the collector wires the pipeline together automatically. Why? Wiring up telemetry in NixOS today means gluing together Telegraf, Prometheus, Loki, Grafana, Alloy, each with its own config format, ports, and inter-service dependencies. nixos-telemetry puts all of that behind a single telemetry.* option tree: Turn on the system with telemetry.enable = true. Every app is opt-in. Nothing starts that you didn't ask for. The collector starts automatically once a complete pipeline exists, a matching source and sink for the same signal type. No sink? It waits. Forward to a remote collector, run a full local stack, or both. Fan-out to multiple sinks is supported. What it looks like Full local stack on one machine: { telemetry.enable = true; telemetry.telegraf.enable = true; # host metrics telemetry.alloy.enable = true; # journald logs telemetry.prometheus.enable = true; # metrics storage telemetry.loki.enable = true; # logs storage telemetry.grafana.enable = true; # visualization (datasources auto-provisioned) } Forward to a remote collector: # machine 1 { telemetry.enable = true; telemetry.telegraf.enable = true; telemetry.opentelemetry.exporter.endpoints.remote = "100.64.0.1:4317"; } # machine 2 { telemetry.enable = true; telemetry.opentelemetry.receiver.endpoint = "0.0.0.0:4317"; } Full option reference: OPTIONS.md Thanks! Regarding Discourse LLM Policy : I must disclose that substantial parts of this project are llm generated. And because I coppied parts of the README in this post, substantial parts of this announcmement too. 27 posts - 7 participants Read full topic ## What's new in the ClickHouse Grafana plugin DevFeed: [What's new in the ClickHouse Grafana plugin]() Original publisher: [Read original article]() Author: Alex Fedotyev Published: 2026-08-13T16:14:40Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Grafana](), [OpenTelemetry](), [User Experience](), [dashboards]() Tags: [clickhouse](), [dashboards](), [grafana](), [logs](), [metrics](), [open-source](), [opentelemetry](), [pull-request](), [traces](), [user-experience]() ### AI overview ClickHouse Grafana plugin 4.20 improves log investigation with compact query mode, click-to-filter workflows, guided configuration, and a live SQL preview. It is designed for users sending OpenTelemetry data to ClickHouse and keeps full SQL available for advanced queries. ### Source excerpt ClickHouse Grafana plugin 4.20 brings compact query mode, click-to-filter log investigation, guided variable and annotation editors, and OpenTelemetry dashboards ## Monitor Your Drive Health with Performance Co-Pilot on Fedora DevFeed: [Monitor Your Drive Health with Performance Co-Pilot on Fedora]() Original publisher: [Read original article]() Author: Paul Evans Published: 2026-08-10T08:00:00Z Content type: article Language: en Sources: [Fedora Magazine]() Topics: [Fedora](), [Monitoring](), [Grafana](), [telemetry]() Tags: [data](), [diagnostics](), [drive](), [farm](), [fedora-project-community](), [grafana](), [hdd](), [health](), [home-server](), [metrics](), [monitor](), [monitoring](), [nvme](), [open-source](), [performance](), [performance-metrics](), [self-hosted](), [server](), [smart](), [ssd](), [telemetry](), [wwid]() ### AI overview This article explains how to monitor drive health on Fedora using Performance Co-Pilot (PCP). It covers SMART metric collection for HDDs, SSDs, and NVMe drives, NVMe error-log decoding, WWID-based tracking, Seagate FARM telemetry, continuous metric collection, and Grafana dashboards for viewing drive-health trends. ### Source excerpt You wake up one morning to find your home server unresponsive, after some investigation you discover a failed NVMe drive taking your self-hosted services and data with it. Perhaps you're a system administrator and a workstation's SSD has been silently accumulating errors for months, and now a user is reporting corrupted files. Drive failures are [...] ## Automate Incident Intake with AI SRE Runbooks DevFeed: [Automate Incident Intake with AI SRE Runbooks]() Original publisher: [Read original article]() Author: Ryan Taylor Published: 2026-08-10T00:00:00Z Content type: tutorial Language: en Sources: [Harness Blog]() Topics: [SRE](), [incident](), [Automation](), [Slack](), [zoom](), [Grafana](), [datadog](), [Artificial Intelligence]() Tags: [ai](), [automation](), [build](), [datadog](), [grafana](), [harness](), [incident](), [integrations](), [jira](), [open](), [services](), [slack](), [sre](), [workflow](), [zoom]() ### AI overview This article explains how Harness AI SRE runbooks automate incident intake and early response. Triggered by alerts, manual actions, or incident changes, a runbook can create tickets, open Slack channels, start Zoom bridges, set incident fields, and record actions in the incident timeline. ### Source excerpt Automate incident intake with Harness AI SRE runbooks: auto-create tickets, open Slack channels, start Zoom bridges, and cut response time to seconds. | Blog ## The dashboard that finally told me what my rack was doing DevFeed: [The dashboard that finally told me what my rack was doing]() Original publisher: [Read original article]() Author: Shed Stack Published: 2026-08-06T15:00:00Z Content type: opinion Language: en Sources: [Shed Stack]() Topics: [Grafana](), [Homelab](), [Monitoring](), [dashboards](), [Hardware](), [telemetry](), [Database]() Tags: [database](), [grafana](), [hardware](), [homelab](), [metrics](), [monitoring](), [self-hosted](), [storage]() ### AI overview A personal account of building a self-hosted homelab monitoring stack with Telegraf, InfluxDB, and Grafana. The setup detected a failing disk early enough to replace it without data loss, and the article recommends starting with a small set of actionable metrics rather than monitoring everything. ### Source excerpt Telegraf, InfluxDB, and Grafana on the homelab. It caught a dying disk within a week. ## Choosing Between ClickStack and Grafana for ClickHouse Observability DevFeed: [Choosing Between ClickStack and Grafana for ClickHouse Observability]() Original publisher: [Read original article]() Author: Alex Fedotyev; David Ryder Published: 2026-07-30T14:32:50Z Content type: comparison Language: en Sources: [ClickHouse Blog]() Topics: [Grafana](), [dashboards]() Tags: [agentic](), [clickhouse](), [dashboards](), [grafana](), [logs](), [mcp](), [metrics](), [observability](), [sre](), [traces]() ### AI overview The article compares ClickStack and Grafana with the ClickHouse plugin as observability interfaces for teams that have already selected ClickHouse as their backend. ### Source excerpt Using ClickHouse for observability and wondering which interface best fits your workflows? We explore ClickStack, Grafana, and when it makes sense to use both. ## How to Self-Host a Validated AI Coding Assistant with NVIDIA NeMo Guardrails DevFeed: [How to Self-Host a Validated AI Coding Assistant with NVIDIA NeMo Guardrails]() Original publisher: [Read original article]() Author: Tanya Lenz Published: 2026-07-29T16:46:45Z Content type: tutorial Language: en Sources: [NVIDIA Developer](), [NVIDIA Technical Blog]() Topics: [AI Chat](), [ai observability](), [Grafana]() Tags: [agentic-ai-generative-ai](), [ai](), [ai-agent](), [ai-coding](), [audit-trail](), [ci](), [developer-tools-techniques](), [docker](), [featured](), [git](), [gpu](), [grafana](), [how-to](), [metrics](), [nemo](), [nim](), [nvidia](), [policy](), [prometheus](), [python](), [supply-chain](), [tutorial]() ### AI overview Tutorial for self-hosting a validated AI coding assistant on NVIDIA infrastructure. It combines a StarCoder2-7B NIM endpoint, NeMo Guardrails, CI dependency checks, commit traceability, and a Prometheus/Grafana metrics loop. ### Source excerpt Deploying an AI coding assistant in a regulated, sovereign, or source-sensitive environment, often comes with challenges. Three common issues are: the source... ## Rewiring incident response, with AI in the loop DevFeed: [Rewiring incident response, with AI in the loop]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-07-25T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [incident](), [Incident response](), [Slack](), [Artificial Intelligence](), [Grafana](), [jira]() Tags: [ai](), [engineering](), [grafana](), [incident](), [incident-management](), [incident-response](), [jira](), [operations](), [slack](), [sre](), [startups]() ### AI overview An account of restructuring incident response at a growing company, moving from a single Slack thread to a durable incident stack. The article describes gaps in paging, Grafana alerts, and Jira visibility, and explains how AI helped draft SLAs, build dashboards, and write boilerplate while human judgment remained central. ### Source excerpt Six weeks in at a new company, rewiring incident response from one Slack thread to a working stack, with AI compressing the parts that used to take a quarter. ## Observability for every Supabase project with Grafana Cloud DevFeed: [Observability for every Supabase project with Grafana Cloud]() Original publisher: [Read original article]() Author: Alex Hall; Matt Linkous; Raminder Singh Published: 2026-07-23T07:00:00Z Content type: release Language: en Sources: [Supabase Blog]() Topics: [Grafana](), [dashboards](), [debugging]() Tags: [api](), [dashboards](), [debugging](), [grafana-cloud](), [integration](), [metrics](), [observability]() ### AI overview Supabase now offers one-click Grafana Cloud setup, including authentication, metric scraping, and pre-built dashboards on all plans. The integration uses the Supabase Metrics API to monitor over 200 metrics, with log-drain support in progress. ### Source excerpt Connect your Supabase project to Grafana Cloud in one click. A pre-built dashboard, alerting, and metrics: available on every plan, including free. ## Diagnosing a 28,232-Connection SSE Limit in a Go Leaderboard DevFeed: [Diagnosing a 28,232-Connection SSE Limit in a Go Leaderboard]() Original publisher: [Read original article]() Author: Pranshu Raj Published: 2026-07-23T00:00:00Z Content type: tutorial Language: en Sources: [Pranshu Raj - blog on backend systems, performance and sidequests]() Topics: [Server-sent events (SSE)](), [Go Language](), [Docker Compose](), [Redis](), [Grafana](), [Prometheus]() Tags: [docker-compose](), [go](), [grafana](), [prometheus](), [redis](), [sse]() ### AI overview A tutorial on testing and diagnosing the SSE connection limit of a Go leaderboard service. It describes the service architecture, Docker Compose deployment, and monitoring with Prometheus and Grafana. ### Source excerpt Why my Go leaderboard's capped at exactly 28,232 SSE connections, how Docker networking got me to 150k, and the path toward millions. ## Broadcasting to 28K SSE Clients (and learning about Go channels) DevFeed: [Broadcasting to 28K SSE Clients (and learning about Go channels)]() Original publisher: [Read original article]() Author: Pranshu Raj Published: 2026-07-23T00:00:00Z Content type: tutorial Language: en Sources: [Pranshu Raj - blog on backend systems, performance and sidequests]() Topics: [Go Language](), [Server-sent events (SSE)](), [Concurrency](), [backpressure](), [real-time](), [observability](), [Redis](), [Grafana](), [Prometheus]() Tags: [architecture](), [backpressure](), [concurrency](), [go](), [grafana](), [observability](), [prometheus](), [real-time](), [redis](), [sse]() ### AI overview The article describes building a real-time leaderboard in Go that reached 28,232 concurrent SSE connections before exposing a broken broadcast design. It explains the fix using centralized polling, deduplication, fan-out, backpressure handling, and observability with Prometheus and Grafana. ### Source excerpt A post on progressively getting my server to 28k SSE connections, finding a bug in my implementation of fan out using Go channels and the resulting mental model update. ## Runtime logs now show cache reasons DevFeed: [Runtime logs now show cache reasons]() Original publisher: [Read original article]() Author: Shina Patel Published: 2026-07-17T01:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [telemetry](), [Grafana]() Tags: [cache](), [cdn](), [cli](), [debug](), [logs](), [metrics](), [vercel]() ### AI overview Vercel runtime logs now display cache reasons for cacheable CDN responses, helping developers diagnose cache misses and improve hit rates. The reason is available in the Logs tab and through selected CLI commands. ### Source excerpt Runtime logs now show a Cache Reason explaining why a request wasn't a fresh cache hit, for example a time-based or tag-based revalidation. Use cache reasons to debug misses and improve your hit rate. Cache reasons appear for any response the CDN can cache, including ISR, Partial Prerendering, and functions that set a Cache-Control header with directives like stale-while-revalidate. Responses rendered dynamically on every request don't have a cache reason. Cache status Possible reasons MISS Cold, Request collapsed, Error BYPASS Draft Mode, Prerender Bypass, Crawler STALE Time-based revalidation, Tag-based invalidation, Revalidation error REVALIDATED Tag-based deletion Open the Logs tab and select a request to see the reason alongside its cache status. Each status and reason links to its entry in the Cache Status and Reasons reference. From the CLI Cache reason is available in vercel logs, vercel metrics, and Vercel plugin's cdn-caching skill: Learn more about cache statuses and reasons. Read more ## Logging, Metrics, and Distributed Tracing in .NET with OpenTelemetry and ClickStack DevFeed: [Logging, Metrics, and Distributed Tracing in .NET with OpenTelemetry and ClickStack]() Original publisher: [Read original article]() Author: Alex Soffronow Pagonidis Published: 2026-06-03T09:21:38Z Content type: tutorial Language: en Sources: [ClickHouse Blog]() Topics: [ASP.NET](), [OpenTelemetry](), [tracing](), [Grafana](), [telemetry](), [Instrumentation](), [SQLite](), [API](), [gRPC](), [SQL]() Tags: [api](), [instrumentation](), [logging](), [metrics](), [observability](), [opentelemetry](), [sql](), [sqlite](), [traces](), [tracing]() ### AI overview A practical walkthrough of instrumenting two ASP.NET services with OpenTelemetry and sending traces, logs, and metrics to ClickStack. The example uses an Order API and a Payment Service, with SQLite persistence and cross-service trace correlation. ### Source excerpt A walkthrough of adding OpenTelemetry instrumentation to two ASP.NET services -- an Order API and a Payment Service -- and shipping traces, logs, and metrics to ClickStack, with auto-correlated signals and cross-service trace waterfalls out of the box. ## Building Blocks for Foundation Model Training and Inference on AWS DevFeed: [Building Blocks for Foundation Model Training and Inference on AWS]() Original publisher: [Read original article]() Author: Keita Watanabe; Pavel Belevich; Aman Shanbhag Published: 2026-05-11T23:18:26Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [foundation-models](), [Amazon Web Services](), [Training AI Models](), [Inference](), [distributed-training](), [cloud-infrastructure](), [Orchestration](), [PyTorch](), [Kubernetes](), [Grafana](), [Prometheus](), [Monitoring]() Tags: [ai](), [aws](), [building](), [distributed-training](), [frameworks](), [grafana](), [hardware](), [inference](), [infrastructure](), [kubernetes](), [latency](), [low-latency](), [model](), [model-development](), [monitoring](), [networking](), [observability](), [open-source](), [prometheus](), [training]() ### AI overview An introductory technical article about the infrastructure and open-source software building blocks required for foundation-model pre-training, post-training, and inference on AWS. It discusses accelerator compute, low-latency networking, distributed storage, orchestration, ML frameworks, and observability tools. ### Source excerpt Figure: Adapted from "AI's Three Scaling Laws, Explained" (NVIDIA Blog). Taken together, these scaling regimes push the foundation-model lifecycle--pre-training, post-training, and inference--toward convergent infrastructure requirements: tightly coupled accelerator compute, a high-bandwidth low-latency network, and a distributed storage backend. ## Powering self-driving vehicle analytics at Avride with ClickHouse Cloud DevFeed: [Powering self-driving vehicle analytics at Avride with ClickHouse Cloud]() Original publisher: [Read original article]() Author: ClickHouse Published: 2026-05-11T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [data](), [Apache Iceberg](), [telemetry](), [Grafana]() Tags: [analytics](), [apache-iceberg](), [autonomous](), [aws](), [clickhouse](), [cloud](), [data-infrastructure](), [driving](), [grafana](), [latency](), [lidar](), [metrics](), [robots](), [storage](), [streams](), [telemetry](), [tooling](), [visualization]() ### AI overview Avride uses ClickHouse Cloud as the data backbone for its autonomous vehicles and delivery robots, supporting ride-data indexing, metrics, analytics, and internal tooling. Its migration from Apache Iceberg reduced index lookup and ingestion latency. ### Source excerpt Avride replaced Apache Iceberg with ClickHouse Cloud, cutting index lookup latency from 20 seconds to under 100ms and ingestion from hours to seconds. ## Why Prometheus couldn't see Cilium metrics at 2 a.m. DevFeed: [Why Prometheus couldn't see Cilium metrics at 2 a.m.]() Original publisher: [Read original article]() Author: Rishi Mondal Published: 2026-05-10T14:00:00Z Content type: article Language: en Sources: [Kubernetes Overview, News and Trends | The New Stack]() Topics: [Prometheus](), [Cilium](), [Grafana](), [Kubernetes](), [Cloud Native Ecosystem](), [Monitoring]() Tags: [cilium](), [cloud-native-ecosystem](), [cncf](), [grafana](), [kubernetes](), [monitoring](), [network](), [networking](), [platform-engineering](), [post-contributed](), [prometheus](), [sponsor-cncf](), [sponsored-post-contributed](), [tls]() ### AI overview This article examines the integration tax that platform teams encounter when combining CNCF projects in production. It uses Prometheus and Cilium metrics as an example, and discusses integration failures involving Hubble, Grafana, cert-manager, ingress controllers, and cloud DNS configuration. ### Source excerpt I still remember the first time we lost sleep over something that wasn't a bug. It was a Tuesday. Grafana The post Why Prometheus couldn't see Cilium metrics at 2 a.m. appeared first on The New Stack. ## Our vision for the ClickHouse Grafana plugin DevFeed: [Our vision for the ClickHouse Grafana plugin]() Original publisher: [Read original article]() Author: Alex Fedotyev Published: 2026-04-15T15:02:01Z Content type: opinion Language: en Sources: [ClickHouse Blog]() Topics: [Grafana](), [telemetry]() Tags: [analytics](), [clickhouse](), [grafana](), [observability](), [sql](), [traces](), [vision]() ### AI overview ClickHouse outlines an experimental vision for improving its Grafana plugin, aiming to make observability and analytics workflows easier to use and reduce the need for users to write SQL. ### Source excerpt We see ClickHouse and Grafana as a key part of the observability experience. Here's our vision for making the plugin more powerful and easier to use. [Next page]()