Buyer’s Guide - August 2026

The best CoreDNS monitoring tools, ranked

Q: What is the CoreDNS metrics endpoint and port?

The default is localhost:9153/metrics, configured by the prometheus plugin in the Corefile. The plugin exports CoreDNS metrics plus default Go runtime metrics. The endpoint must be reachable by your scraper; in Kubernetes that usually means a ServiceMonitor or a pod annotation.

Q: How do I monitor CoreDNS in Kubernetes or EKS?

The common paths are kube-prometheus-stack with a ServiceMonitor targeting CoreDNS pods, Grafana Alloy or the Kubernetes Monitoring Helm chart for Grafana Cloud, and the CloudWatch agent or ADOT for EKS-native monitoring. Netdata’s Kubernetes integration collects CoreDNS alongside kubelet, kube-proxy, and container metrics, which puts DNS signals and their likely causes in the same view.

Q: Prometheus vs commercial tools for CoreDNS monitoring: which is better?

Prometheus plus Grafana gives full control and no license cost, but you operate the stack and default to 1-minute resolution. Commercial SaaS tools such as Datadog, Dynatrace, New Relic, and Grafana Cloud offer prebuilt dashboards and alerts but charge per host, per GB, or per custom metric. Netdata sits between the two: per-second resolution and per-node pricing without running Prometheus.

Q: How do I alert on CoreDNS failures?

Alert on the SERVFAIL and NXDOMAIN rate as a percentage of total responses, on p99 latency crossing a sustained threshold (for example 50ms), on coredns_panics_total increasing, and on replica count dropping via coredns_build_info. Grafana Cloud and New Relic ship prebuilt CoreDNS alerts; Netdata requires custom alert configuration.

Q: Is CoreDNS monitoring free?

CoreDNS itself and the Prometheus plus Grafana stack are open source, but you pay to run and operate them in storage, compute, and time. Commercial SaaS tools offer free tiers with limits on host count, data ingest, or usage. Netdata’s agent is open source with a free Cloud tier for up to 5 nodes.

CoreDNS is the default DNS server in Kubernetes, and when it slows down every workload in the cluster feels it. It exposes a native Prometheus metrics endpoint on port 9153, which means the real buying decision is how you scrape, store, alert on, and correlate those metrics. We ranked 10 tools on CoreDNS metric depth, collection resolution, Kubernetes integration, shipped dashboards and alerts, and how predictable the bill is.

Start with Netdata (free) Jump to rankings

The best CoreDNS monitoring tools, ranked product interface

Why this list exists

CoreDNS monitoring is really Kubernetes DNS monitoring. CoreDNS ships as the default cluster DNS for Kubernetes and exposes a native Prometheus metrics endpoint on port 9153 via its prometheus plugin. Every serious tool in this category collects from that endpoint. The differences are in how fast they collect, how much of the coredns_* metric set they actually ingest, and what the surrounding platform costs to run.

The mistake buyers make is treating this as a generic DNS monitoring problem. That leads to two failure modes: over-provisioning a full APM suite to watch one subsystem, or hand-rolling a Prometheus setup with no dashboards, no alerts, and no correlation with the node and container signals that explain why DNS is slow.

Three dimensions decide the outcome:

Metric depth and resolution. Does the tool ingest request rates, per-rcode breakdowns, latency histograms, cache hits and misses, and panics, and at what interval? A 1-minute default scrape misses most DNS latency spikes; a 1-second collector catches them.
Kubernetes fit. How does the tool discover CoreDNS pods, and does it correlate DNS metrics with kubelet, kube-proxy, conntrack, and container metrics in the same view?
Cost shape. Per-node and per-host pricing scales predictably with cluster size. Per-GB, per-custom-metric, and per-active-series pricing can grow fast because CoreDNS metrics carry per-zone, per-server, and per-rcode labels that multiply cardinality.

A note on pricing: we do not quote competitor list prices in this guide. Vendor pricing changes, varies by region and contract, and list numbers rarely match the negotiated bill. Instead we describe the pricing shape, what actually makes the bill grow, and link each vendor’s official pricing page so you can check current numbers yourself. For hands-on setup material, see the operator runbooks in our CoreDNS guides hub. For Netdata’s current per-node costs, see our pricing page.

We assembled the shortlist from tools with documented CoreDNS support: a native collector, a maintained integration or extension, a published quickstart, or official vendor guidance for scraping the CoreDNS Prometheus endpoint. Tools with no verifiable CoreDNS path were excluded. Every factual claim on this page is drawn from vendor documentation, integration references, Helm chart defaults, or official pricing pages linked in the sources below.

CoreDNS metric depth carries the most weight because DNS incidents are diagnosed from the details: per-rcode response breakdowns, latency histograms, and cache efficiency, not just an up/down check. Collection resolution ranks second because DNS latency spikes are short-lived, and a coarse scrape interval hides them. Kubernetes integration, shipped alerting content, and pricing predictability round out the scoring; ecosystem portability matters but is table stakes for any Prometheus-compatible tool.

Tester credit

Compiled by the Netdata team. Updated August 12, 2026.

Scoring criteria

CoreDNS metric depth 25%
Coverage of the full coredns_* set: request/response rates, per-rcode, latency histograms, cache, panics, Go runtime.
Collection resolution 20%
How fast the tool detects a DNS outage or latency spike. Per-second beats 15-60 second SaaS scrapes and 1-minute defaults.
Kubernetes integration 15%
Pod discovery, ServiceMonitor or annotation support, and correlation with kubelet, kube-proxy, and container metrics.
Alerting and dashboards 15%
Prebuilt CoreDNS dashboards and alert rules versus assembling community mixins and dashboard JSON yourself.
Deployment and pricing predictability 15%
Self-hosted versus SaaS, and whether the bill grows per-node or in surprising ways (per-GB, per-custom-metric, per-series).
Ecosystem and extensibility 10%
Prometheus remote_write and scrape config support, and fit with Grafana, Alertmanager, and OpenTelemetry.

Vendor 01 / 10 · #netdata

Netdata

Real-time, per-second monitoring for CoreDNS and the rest of your infrastructure with an open-source agent and per-node cloud pricing.

Best for

Teams that want per-second CoreDNS visibility without running and operating a Prometheus stack
Kubernetes operators who want DNS metrics correlated with node, container, kubelet, and kube-proxy signals
Buyers who want predictable per-node pricing with no usage-based surprises

Pricing

Netdata Cloud Business starts at $4.50/node/month on annual plans, and the per-node price decreases as node count grows
Free Cloud tier for small fleets (Community plan, up to 5 nodes, non-commercial)
Netdata Agent is open source (AGPL) and free; you run and operate it
No per-GB, per-metric, or per-user charges; the bill grows with node count only

Pros

Dedicated go.d coredns collector scrapes the CoreDNS Prometheus endpoint (default http://127.0.0.1:9153/metrics) at a default 1-second interval, the fastest in this list
Collects request/response rates, processed versus dropped counts, and per-protocol, per-IP-family, per-type, per-rcode, and per-zone breakdowns
No Prometheus server to run; the agent streams metrics to Netdata Cloud or a Netdata Parent
Correlates CoreDNS metrics with Kubernetes cluster state, kubelet, kube-proxy, and container metrics, which is how you catch conntrack exhaustion behind a SERVFAIL storm
800+ integrations and built-in anomaly detection for reducing alert noise
Supports multiple CoreDNS instances and remote endpoints from a single agent

Where teams pair it

The CoreDNS collector ships with no default alert rules; operators configure alerts themselves, whereas some hosted platforms ship prebuilt CoreDNS alerts
The collector does not currently ingest CoreDNS latency histograms (coredns_dns_request_duration_seconds) or cache hit/miss metrics, so teams needing p99 latency and cache-efficiency dashboards often pair it with Datadog or Dynatrace
UI-based collector configuration requires a paid Netdata Cloud plan; file-based configuration is free on every tier

Verdict

Netdata leads this list because it is the only tool here with a purpose-built CoreDNS collector running at a default 1-second interval, which is the difference between seeing a DNS latency spike and averaging it away. There is no Prometheus server to operate, and CoreDNS metrics sit next to node, container, kubelet, and kube-proxy signals in the same UI, which shortens the path from SERVFAIL alert to root cause. Per-node pricing means the bill never moves with metric cardinality or log volume. The honest caveats: latency histograms and cache metrics are not yet in the collector, and you write your own alert rules. For most Kubernetes teams, the resolution and correlation advantages outweigh both gaps, and the open-source agent makes evaluation free.

Start free -> CoreDNS collector docs ->

Vendor 02 / 10 · #prometheus-grafana

Prometheus + Grafana

The open-source stack that CoreDNS natively speaks: Prometheus scrapes the /metrics endpoint and Grafana visualizes and alerts on it.

Best for

Teams already running kube-prometheus-stack who want CoreDNS in the same PromQL world
SREs who want full control over scrape config, recording rules, and alerting
Organizations that prefer open-source self-hosted tooling

Pricing

Open source and self-hosted: you run and operate Prometheus, Alertmanager, and Grafana yourself
Operating cost grows with storage, retention, and the compute needed to run the stack
Managed variants such as Grafana Cloud and Amazon Managed Prometheus are billed separately on usage

Pros

CoreDNS exports Prometheus metrics natively on port 9153 via the prometheus plugin; no agent required on the CoreDNS side
Default 1-minute scrape interval is tunable down to seconds
Mature ecosystem: coredns-mixin, kube-prometheus-stack, and community Grafana dashboards (IDs 15762, 14981, 12382)
PromQL and Alertmanager give full control over CoreDNS alerting
Every managed observability vendor accepts Prometheus remote_write, so the stack is portable

Cons

You operate the whole stack: storage, retention, HA, and upgrades
Default 1-minute scrape resolution is coarse for DNS latency spikes
No built-in correlation with logs or traces without adding Loki or Tempo
Dashboards and alerts are community-maintained, not vendor-supported

Verdict

This is the reference implementation: CoreDNS exposes Prometheus metrics by design, so the native stack fits with zero impedance. If your team already runs kube-prometheus-stack, adding a ServiceMonitor for CoreDNS takes minutes and the community mixin supplies solid dashboards and alert rules. The tradeoff is operational. You own storage, retention, HA, and upgrades, the default 1-minute scrape hides short latency spikes, and everything vendor-supported elsewhere is community-maintained here. For teams with Prometheus maturity, it remains the benchmark every other tool is measured against.

Read full Netdata vs Prometheus -> Prometheus site ->

Vendor 03 / 10 · #grafana-cloud

Grafana Cloud

Managed Grafana with a prebuilt CoreDNS integration that scrapes the Prometheus endpoint and ships a dashboard plus nine alerts.

Best for

Teams that want the Prometheus/Grafana experience without operating the stack
Kubernetes shops using Grafana Alloy or the Kubernetes Monitoring Helm chart
Organizations already standardized on Grafana dashboards

Pricing

Usage-based: billed on active series, log volume, and users
Free tier with limited usage and short retention
Bill grows with the number of scraped series and log ingestion, and CoreDNS per-zone, per-server, and per-rcode labels multiply series count

Pros

Official CoreDNS integration with 1 prebuilt dashboard and 9 alerts covering CoreDNS down, high latency, SERVFAIL errors, and forward healthcheck failures
Supports CoreDNS 1.7.0 or greater; requires the prometheus and cache plugins enabled
Scrapes via Grafana Alloy with Kubernetes service discovery
Prometheus-compatible querying and alerting throughout
Correlates CoreDNS metrics with logs and traces in the same platform

Cons

Usage-based pricing on active series can grow with CoreDNS label cardinality
Requires the cache plugin enabled for full dashboard coverage
SaaS-only; metric data leaves your cluster
Scrape interval typically sits at 15-60 seconds, not per-second

Verdict

Grafana Cloud is the managed version of the Prometheus+Grafana approach, and its CoreDNS integration is one of the most complete packaged offerings here: a vendor-maintained dashboard and nine alert rules out of the box. For Grafana shops, it removes the operational burden of rank 2 while keeping PromQL. The watch item is cost mechanics. Active-series billing means CoreDNS’s per-zone and per-rcode label cardinality has a direct price, and data residency is whatever the SaaS offers. A strong turnkey choice if you accept usage-based billing.

Read full Netdata vs Grafana -> Grafana Cloud pricing ->

Vendor 04 / 10 · #datadog

Datadog

SaaS observability platform with a deep OpenMetrics-based CoreDNS integration covering 60+ coredns_* metrics.

Best for

Enterprises already standardized on Datadog for APM, logs, and infrastructure
Teams that want CoreDNS metrics correlated with the full application stack
Organizations that prefer a single-vendor SaaS platform

Pricing

Per-host for infrastructure monitoring plus per-GB for logs and per-custom-metric overages
Limited free tier capped by host count and short retention
Bill grows across several dimensions at once: host count, log volume, custom metrics, and APM spans

Pros

OpenMetrics integration in the Datadog Agent scrapes http://host:9153/metrics with no separate install
Collects 60+ metrics including cache hits/misses, forward healthchecks, DNSSEC, panics, Go runtime, and per-rcode and per-type breakdowns
Autodiscovery via Docker labels, Kubernetes annotations, and the DatadogInstrumentation CRD
Optional log collection from CoreDNS with source ‘coredns’
Service check coredns.prometheus.health monitors endpoint availability

Cons

No prebuilt CoreDNS dashboard or monitor templates documented in the integration
Multi-dimensional pricing (hosts plus logs plus custom metrics) can grow quickly and is hard to forecast
SaaS-only; metrics leave your cluster
Default collection interval is tied to the Agent check interval, typically 15 seconds or more

Verdict

Datadog has the deepest CoreDNS metric catalog of the commercial SaaS tools, covering cache and latency dimensions that several rivals skip. Autodiscovery makes rollout across clusters genuinely easy, and correlation with APM is excellent if you already live in Datadog. Two things hold it back for this specific job: the integration documents no out-of-the-box CoreDNS dashboard or monitors, so you build the content yourself, and the pricing model has enough independent growth dimensions that CoreDNS label cardinality can become a billing question. Best value when Datadog is already your platform.

Read full Netdata vs Datadog -> Datadog pricing ->

Vendor 05 / 10 · #dynatrace

Dynatrace

Enterprise observability platform with a CoreDNS 2.0 extension that scrapes the Prometheus endpoint and includes a monitoring overview dashboard.

Best for

Large enterprises with existing Dynatrace Full-Stack or Kubernetes monitoring
Teams that want automated topology and root-cause analysis around CoreDNS
Organizations needing OneAgent or ActiveGate-based remote collection

Pricing

Per-host (per 8 GiB memory) for Full-Stack; per-pod for Kubernetes Platform Monitoring
Custom metrics consume Davis Data Units (DDUs) or Grail DPS on top of host licensing
Logs billed per GiB ingested; bill grows with host memory, pod count, and metric ingestion

Pros

CoreDNS 2.0 extension collects the full default metric set plus 29 Go runtime metrics and calculated metrics like cache hit rate and average request duration
Supports CoreDNS 1.0.0 through 1.11.x, including the forward plugin metric changes in 1.11.0
Ships a CoreDNS Monitoring Overview dashboard and a preconfigured CoreDNS Panics Detected event
Local (OneAgent) or remote (ActiveGate) activation
Creates CoreDNS process entities with runs_on host relationships for topology-driven root cause

Cons

Extension requires OneAgent/ActiveGate 1.279+ and manual activation via Hub or Extensions Manager
Custom metric ingestion consumes DDUs/DPS, adding cost on top of host licensing
SaaS platform; metric data leaves the cluster
Extension is version-locked to CoreDNS 1.11.x

Verdict

Dynatrace offers the broadest CoreDNS metric set among the commercial tools here, including latency and cache-efficiency calculated metrics, plus a shipped dashboard and a panics alert, which is more packaged content than Datadog provides. The topology model, where CoreDNS appears as an entity with host relationships, is genuinely useful for automated root-cause analysis. The costs are licensing complexity (host licensing plus DDU-based custom metric consumption) and an activation path that requires current OneAgent or ActiveGate versions. For existing Dynatrace estates it is an easy yes; as a standalone CoreDNS purchase it is heavy.

Read full Netdata vs Dynatrace -> Dynatrace pricing ->

Vendor 06 / 10 · #newrelic

New Relic

Usage-based observability SaaS with a CoreDNS quickstart that ingests Prometheus metrics via remote_write and ships a dashboard plus four alerts.

Best for

Teams already using New Relic for APM who want CoreDNS in the same UI
Organizations comfortable with Prometheus remote_write to a SaaS backend
Buyers who want a free tier to start

Pricing

Usage-based: per-GB data ingest with per-seat plan tiers
Free tier with a monthly ingest allowance
Bill grows with data volume, full-platform users, and retention; high-cardinality CoreDNS metrics push ingest up

Pros

CoreDNS quickstart installs a curated dashboard and 4 alerts covering request rate, request duration p95, panics, and error rate
Ingests via Prometheus Agent or Prometheus Server remote_write, so no proprietary agent is required for CoreDNS
Alerts use anomaly-style thresholds (2 standard deviations) to reduce noise
Correlates CoreDNS metrics with New Relic APM, logs, and traces

Cons

You run and configure the Prometheus Agent or Server that does the scraping
No documented CoreDNS version support matrix
Ingest-based pricing can grow with high-cardinality CoreDNS metrics
SaaS-only; telemetry leaves the cluster

Verdict

New Relic’s CoreDNS quickstart is a genuinely useful on-ramp: a curated dashboard and four anomaly-thresholded alerts that take minutes to stand up once metrics flow. The architectural catch is that New Relic does not scrape CoreDNS itself; you operate a Prometheus Agent or Server and remote_write into the platform, which means you carry part of rank 2’s operational burden to get rank 6’s convenience. Ingest-based pricing makes the bill sensitive to how much of the coredns_* set you forward. A sensible destination for teams already on New Relic APM.

Read full Netdata vs New Relic -> New Relic pricing ->

Vendor 07 / 10 · #victoriametrics

VictoriaMetrics

Prometheus-compatible time-series database with a Kubernetes stack that scrapes CoreDNS out of the box.

Best for

Teams that want Prometheus-style scraping with lower storage overhead than vanilla Prometheus
Kubernetes operators using the VictoriaMetrics k8s-stack Helm chart
Organizations that want a self-hosted TSDB with a managed cloud option

Pricing

Open source and self-hosted: you run and operate it
VictoriaMetrics Cloud billed on deployment compute and storage plus external traffic per GB
Bill grows with cluster size, storage, and data transfer

Pros

k8s-stack Helm chart enables CoreDNS scraping by default (coreDns.enabled: true) on port 9153
VMServiceScrape CRD and operator support Kubernetes-native service discovery
Prometheus-compatible queries and remote_write, so existing CoreDNS dashboards and alerts work unchanged
Lower RAM and disk footprint than vanilla Prometheus for high-cardinality metrics
Managed cloud option with deployment-based pricing

Cons

No vendor-maintained CoreDNS dashboard or alert pack; you import community Grafana dashboards
Self-hosted operation means managing storage, retention, and HA
CoreDNS-specific documentation is thinner than Datadog or Dynatrace
Cloud pricing adds external traffic charges

Verdict

VictoriaMetrics is the strongest Prometheus-compatible backend in this list for CoreDNS at scale: the k8s-stack chart scrapes port 9153 out of the box, and the storage engine handles CoreDNS label cardinality more efficiently than vanilla Prometheus. Everything PromQL-based, including community CoreDNS dashboards and mixins, works unchanged. What it lacks is CoreDNS-specific content of its own: no vendor dashboards, no alert pack, thin docs. Choose it as a better Prometheus engine, not as a turnkey CoreDNS solution.

Read full Netdata vs VictoriaMetrics -> VictoriaMetrics Cloud pricing ->

Vendor 08 / 10 · #sysdig

Sysdig

Kubernetes-native monitoring and security platform with out-of-the-box CoreDNS dashboards and no Prometheus server to run.

Best for

Kubernetes platform teams that want CoreDNS plus control-plane monitoring in one tool
Organizations using Sysdig Secure who want Monitor alongside
Teams that want dashboards without operating Prometheus

Pricing

Per-host/per-node licensing for Monitor; cloud logs billed per event processed
No permanent free tier documented
Bill grows with the number of monitored hosts and cloud log volume

Pros

Out-of-the-box CoreDNS dashboards in Sysdig Monitor; no Prometheus server instrumentation required
Covers the four golden signals: errors by rcode, p99 latency from histograms, request-rate traffic, and CPU/memory saturation
Prometheus-compatible PromQL queries for CoreDNS
Advisor tool accelerates Kubernetes troubleshooting
Monitors CoreDNS replica count via coredns_build_info

Cons

CoreDNS guidance is blog and docs based; no dedicated integration page with a full metric catalog
Per-host licensing plus cloud log event pricing
SaaS platform; telemetry leaves the cluster
No documented CoreDNS version support matrix

Verdict

Sysdig’s Kubernetes-first approach pays off for CoreDNS: golden-signal dashboards ship out of the box, latency comes from real histograms, and there is no Prometheus server to babysit. If your organization runs Sysdig Secure, adding Monitor for DNS visibility is a natural consolidation. The limitations are depth and documentation: CoreDNS coverage is described in blog posts rather than a formal integration catalog, so validating exact metric support takes a proof of concept. A good Kubernetes-native option that stops short of Datadog or Dynatrace-level CoreDNS specificity.

Visit Sysdig -> Sysdig pricing ->

Vendor 09 / 10 · #site24x7

Site24x7

SaaS IT monitoring platform with agent-based Kubernetes CoreDNS monitoring covering latency, cache, and forwarding health.

Best for

IT teams that want CoreDNS monitoring alongside website, server, and network monitoring in one SaaS
Organizations already using Site24x7 for infrastructure monitoring
Teams that prefer agent-based setup over Prometheus configuration

Pricing

Per-monitor/per-host plans with tiers
Free 30-day trial; no permanent free tier
Bill grows with the number of monitors, hosts, and advanced features

Pros

Dedicated CoreDNS view under Kubernetes monitoring: K8s > cluster > CoreDNS
Covers request latency, DNS response errors, cache hit rates, forward max concurrent rejects, and health check failures
Also tracks Kubernetes DNS programming duration for record propagation timing
Agent-based collection via the Linux server monitoring agent 21.0.0+ and updated Kubernetes agent
Correlates CoreDNS with Kubernetes control-plane coverage

Cons

Requires agent version upgrades for full control-plane coverage
No public metric catalog or CoreDNS version support matrix
SaaS-only; data leaves the cluster
No PromQL flexibility for custom CoreDNS queries

Verdict

Site24x7 is the practical choice for IT generalists: CoreDNS appears as a first-class view inside a broader monitoring platform that also covers websites, servers, and networks, and the agent model avoids touching Prometheus configuration entirely. The metric coverage, including cache hit rates and forward health, is better than its low profile suggests. The tradeoffs are opacity and flexibility: no public metric catalog to evaluate against, no PromQL, and collection intervals that are not documented. Right for mixed IT estates; limiting for Kubernetes-native platform teams.

Read full Netdata vs Site24x7 -> Site24x7 pricing ->

Vendor 10 / 10 · #cloudwatch

Amazon CloudWatch

AWS-native monitoring with EKS CoreDNS metrics collected by the CloudWatch agent or Container Insights Prometheus support.

Best for

AWS/EKS shops that want CoreDNS metrics in the AWS console
Teams already using Container Insights for cluster monitoring
Organizations that prefer native AWS tooling over third-party SaaS

Pricing

Per custom metric per month, per GB of logs ingested, and per alarm
Free tier includes limited custom metrics, alarms, and log ingestion
Bill grows with custom metric count, log volume, and alarm count; CoreDNS label cardinality multiplies metric count

Pros

Official EKS guidance for collecting CoreDNS metrics via Prometheus or the CloudWatch agent
Container Insights Prometheus support scrapes CoreDNS and ingests as CloudWatch metrics
No additional vendor to procure for AWS-centric teams
Correlates CoreDNS with EKS control-plane and pod metrics
Works with AWS Distro for OpenTelemetry (ADOT) for metric collection

Cons

Per-custom-metric pricing adds up quickly with CoreDNS cardinality
No prebuilt CoreDNS dashboard; you build CloudWatch dashboards from scraped metrics
Default CloudWatch resolution is 1 minute for custom metrics
AWS-only; not useful for multi-cloud or on-prem CoreDNS fleets

Verdict

For EKS-only teams, CloudWatch is the path of least procurement resistance: official AWS guidance covers scraping CoreDNS via Container Insights or the agent, and the metrics land next to the rest of your cluster telemetry. Beyond that the fit is thin. There is no prebuilt CoreDNS dashboard, custom metrics resolve at 1 minute, and per-metric pricing means CoreDNS’s per-rcode and per-zone label expansion is a direct cost multiplier. Choose it when staying inside AWS matters more than dashboard quality or resolution.

Read full Netdata vs CloudWatch -> CloudWatch pricing ->

Frequently asked questions

How do I monitor CoreDNS metrics?

CoreDNS exposes a native Prometheus metrics endpoint on port 9153 via its prometheus plugin, so any Prometheus-compatible scraper can collect it. That includes Prometheus itself, Grafana Alloy, VictoriaMetrics, the Datadog Agent, the Dynatrace extension, and Netdata’s go.d coredns collector. The difference is resolution: Netdata collects at 1-second intervals by default, while Prometheus defaults to 1-minute scrapes.

What CoreDNS metrics should I watch?

Start with request rate (coredns_dns_requests_total) and response rate (coredns_dns_responses_total). Track error response codes, SERVFAIL, NXDOMAIN, and REFUSED, via the rcode label on coredns_dns_responses_total. Watch latency through the coredns_dns_request_duration_seconds histogram for p95 and p99, cache efficiency via coredns_cache_hits_total and coredns_cache_misses_total, panics via coredns_panics_total, and replica count via coredns_build_info.

What is the CoreDNS metrics endpoint and port?

How do I monitor CoreDNS in Kubernetes or EKS?

Prometheus vs commercial tools for CoreDNS monitoring: which is better?

How do I alert on CoreDNS failures?

Is CoreDNS monitoring free?

What causes CoreDNS latency spikes and how do I detect them?

The usual causes are upstream forwarder latency, conntrack exhaustion, cache miss storms, and node CPU or memory pressure. Detect them via the coredns_dns_request_duration_seconds histograms and forward healthcheck metrics, then correlate with node-level signals: conntrack utilization, TCP retransmits, and pod CPU and memory. Netdata correlates CoreDNS SERVFAIL rates with conntrack saturation and kube-proxy sync latency, which is where most DNS mysteries end.

The best CoreDNS monitoring tools, ranked

How we evaluated CoreDNS monitoring tools

Netdata

Prometheus + Grafana

Grafana Cloud

Datadog

Dynatrace

New Relic

VictoriaMetrics

Sysdig

Site24x7

Amazon CloudWatch

Frequently asked questions

Book Your Free Demo