DNS-Server
    Aktualisiert am Mai 2026
    CoreDNS logo

    CoreDNS Überwachung

    Überwachen Sie CoreDNS-Abfragefrequenzen, Cache-Trefferquoten, Auflösungslatenzzeiten und Fehlerquoten in Echtzeit – ganz ohne Konfiguration.

    Warum überwachen Sie CoreDNS?

    CoreDNS ist der Standard-DNS-Server für Kubernetes und Cloud-native Umgebungen. Durch die Überwachung von CoreDNS werden eine schnelle DNS-Auflösung, eine einwandfreie Cache-Leistung und eine zuverlässige Dienstermittlung für Ihre Infrastruktur gewährleistet.

    Automatische Erkennung über Xitogent
    Überwachung der Abfragefrequenz
    Cache-Treffer-/Fehltreffer-Verhältnis
    Verfolgung der Latenz bei der Auflösung
    Fehler- und SERVFAIL-Raten
    Kennzahlen pro Zone
    Überwachung auf Plugin-Ebene
    1-Minuten-Erfassungsintervalle
    Anpassbare Alert-Schwellenwerte für jede Metrik
    Standardmäßig 1-Minuten-Intervalle für die Metrik-Erfassung
    Was ist CoreDNS-Monitoring?

    CoreDNS-Monitoring, erklärt

    CoreDNS-Monitoring erkennt SERVFAIL-Spitzen, sinkende Cache-Trefferraten, Latenz im Forward-Plugin und panikbedingte Neustarts, bevor sie zu clusterweiten DNS-Auflösungsfehlern eskalieren. Da jeder Microservice für die Service-Discovery von DNS abhängt, ist ein nicht überwachter CoreDNS ein unüberwachter Ausfallmodus für Ihren gesamten Kubernetes-Cluster — DNS-Probleme tauchen überall als „zufällige Connection-refused-Fehler“ auf. Xitoring erkennt Ihr CoreDNS automatisch, scrapt :9153/metrics und leitet Alerts an Slack, PagerDuty, Telegram oder Ihre bestehende Rufbereitschaft weiter.

    Kennzahlen

    Was wir überwachen

    Abfragen/Sek.

    DNS-Abfragefrequenz.

    Cache-Trefferquote

    Prozentsatz der aus dem Cache bedienten Abfragen.

    Auflösungslatenz

    Durchschnittliche DNS-Auflösungszeit.

    SERVFAIL-Rate

    Prozentsatz der nicht gelösten Fälle.

    NXDOMAIN-Rate

    Anzahl der Abfragen für nicht existierende Domains.

    Upstream-Latenz

    Antwortzeit bei weitergeleiteten Anfragen.

    Latenz des Forward-Plugins

    `coredns_forward_request_duration_seconds` pro Upstream-Resolver. Trennt CoreDNS-interne Latenz von der Latenz des Upstream-Resolvers — entscheidend für die Diagnose, ob 8.8.8.8 langsam ist oder CoreDNS selbst.

    Forward-Request-Rate

    `coredns_forward_request_count_total` pro Upstream. Kombiniert mit der Cache-Trefferquote zeigt es, wie viel Traffic tatsächlich CoreDNS Richtung Upstream verlässt.

    Proxy-Verbindungs-Cache

    `coredns_proxy_conn_cache_hits_total` / `_misses_total`. Erfasst die Wiederverwendung von TCP-Verbindungen zu Upstream-Resolvern — eine niedrige Trefferquote bedeutet Verbindungs-Churn und erhöht die Upstream-Latenz.

    Health-Plugin-Fehler

    `coredns_health_request_failures_total` — der eigene Fehlerzähler des `health:8080`-Plugins. Nicht-null bedeutet, dass die Liveness-Probe zeitweise fehlschlägt.

    Panics

    `coredns_panics_total` — jeder Wert ungleich null ist ein CoreDNS-Bug oder Plugin-Crash, der eine Goroutine-Panic ausgelöst hat. Kombinieren Sie ihn mit der Restart-Anzahl für vollständigen Post-Mortem-Kontext.

    Go-Runtime

    `process_resident_memory_bytes` (RSS), `go_goroutines` (Goroutine-Anzahl — erkennt Leaks), `go_gc_duration_seconds` (GC-Pause-Zeit). Speicherwachstum ohne Neustarts = Leak; wachsende Goroutine-Anzahl = blockiertes Plugin oder Upstream.

    Auslöser & Benachrichtigungen

    Konfigurierbare Alarmauslöser

    Richten Sie benutzerdefinierte Trigger in Ihrem Dashboard ein, um benachrichtigt zu werden, sobald die Kennzahlen von „CoreDNS“ Ihre festgelegten Schwellenwerte überschreiten.

    CoreDNS Dashboard zur Konfiguration von Überwachungsauslösern

    SERVFAIL-Rate

    entscheidend

    Fehlerschritte bei hoher Auflösung.

    Cache-Trefferquote

    Warnung

    Warnmeldungen, wenn die Cache-Effizienz nachlässt.

    Auflösungslatenz

    Warnung

    Auslöser bei langsamer DNS-Auflösung.

    Abfragehäufigkeit

    Warnung

    Löst bei ungewöhnlich hohem Abfrageaufkommen einen Alarm aus.

    01

    Bedeutung von CoreDNS-Überwachung

    DNS ist die Grundlage der Netzwerkkonnektivität. Eine langsame oder fehlerhafte DNS-Auflösung wirkt sich auf jeden Dienst in Ihrer Infrastruktur aus.

    • Sorgen Sie für eine schnelle DNS-Auflösung
    • SERVFAIL-Spitzen sofort erkennen
    • Cache überwachen, um eine optimale Leistung zu erzielen
    • Zustand des Upstream-Resolvers überwachen
    CoreDNS-Überwachung
    DNS-Analysen
    02

    Warum sich für uns entscheiden? Xitoring

    CoreDNS-Überwachung ohne Konfiguration.

    • Installation mit einem einzigen Befehl
    • Globale Knoten
    • Zentrales Dashboard
    • Benachrichtigungen über mehrere Kanäle
    Übersicht
    Benachrichtigungen
    Anwendungsfälle

    Häufige CoreDNS-Monitoring- Szenarien

    Wo CoreDNS heute typischerweise läuft – und was schiefgehen könnte, wenn niemand hinsieht.

    DNS innerhalb einer Kubernetes-Anwendung

    Jeder Teil einer Kubernetes-Anwendung verwendet CoreDNS, um jeden anderen Teil zu finden. Wenn es sich verlangsamt oder ausfällt, sehen Benutzer seltsame, intermittierende Fehler in der gesamten Anwendung. Wir erkennen die Verlangsamung in dem Moment, in dem sie beginnt, damit ein kleiner DNS-Schluckauf nicht als mysteriöser Ausfall bei den Kunden ankommt.

    Große Cluster mit lokalen DNS-Caches

    Größere Kubernetes-Setups platzieren einen kleinen DNS-Cache auf jedem Server, um die Geschwindigkeit zu gewährleisten. Wenn einer dieser Caches sich fehlerhaft verhält, bricht nur ein Teil des Traffics zusammen – was es schwer erkennbar macht. Wir stellen sicher, dass jeder seine Aufgabe erfüllt, damit ein einzelner fehlerhafter Knoten nicht unbemerkt einen Teil Ihrer Benutzer beeinträchtigen kann.

    Öffentlich zugängliches DNS für Ihre Domain

    Wenn CoreDNS die DNS-Anfragen für Ihre Domain im offenen Internet beantwortet, bedeutet ein Ausfall, dass Personen Ihre Website überhaupt nicht erreichen können. Wir überwachen die Signale, die beweisen, dass der Dienst fehlerfrei ist und reagiert, damit Marke und Umsatz nicht unbemerkt leiden, während DNS stillschweigend ausfällt.

    Bevor Sie beginnen

    Voraussetzungen für CoreDNS

    Stellen Sie sicher, dass diese Punkte erfüllt sind — danach ist die Installation eine Sache von 60 Sekunden.

    • CoreDNS 1.x läuft auf dem Server
    • Prometheus-Plugin in Ihrer Corefile aktiviert (Standardport 9153)
    • Netzwerkerreichbarkeit von Xitogent zum Metrics-Endpunkt
    Einrichtungsanleitung

    Erste Schritte in Minuten

    1

    Xitogent auf Ihrem Server installieren

    Falls noch nicht geschehen, installieren Sie den ressourcenschonenden Xitogent-Monitoring-Agenten auf dem Host, auf dem CoreDNS läuft.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Prometheus-Plugin in CoreDNS aktivieren

    CoreDNS stellt Metriken im Prometheus-Format über sein prometheus-Plugin bereit (Standard-Endpunkt :9153/metrics). Fügen Sie `prometheus :9153` zu Ihrer Corefile hinzu, laden Sie CoreDNS neu und prüfen Sie, dass der Metrics-Endpunkt vom Agent-Host aus erreichbar ist.

    sudo xitogent integrate
    3

    CoreDNS-Integration aktivieren

    Aktivieren Sie die CoreDNS-Integration über das Xitoring-Dashboard oder die CLI. Xitogent erkennt den Metrics-Endpunkt automatisch und beginnt mit der Erfassung von Query-, Cache- und Latenz-Metriken.

    4

    Alarmschwellen konfigurieren (optional)

    Legen Sie eigene Schwellenwerte für SERVFAIL-Rate, Cache-Trefferquote oder Auflösungslatenz fest, um benachrichtigt zu werden, sobald DNS-Zuverlässigkeit oder -Performance nachlässt.

    5

    Funktion überprüfen

    Führen Sie diesen Befehl auf dem Server aus, um zu bestätigen, dass Xitogent die Integration erkannt hat. Innerhalb von etwa 30 Sekunden werden frische Metriken in Ihr Dashboard gestreamt.

    sudo xitogent status

    Häufig gestellte Fragen

    Kubernetes CoreDNS?
    Ja, CoreDNS wird in Kubernetes vollständig unterstützt.
    Prometheus-Metriken?
    Xitogent liest den Prometheus-Metrik-Endpunkt von CoreDNS aus.
    Was macht das kubernetes-Plugin?
    Das `kubernetes`-Plugin beobachtet die Kubernetes-API auf Änderungen an Service-, Endpoint- und Pod-Objekten und synthetisiert DNS-Datensätze dafür — `..svc.cluster.local`-Auflösungen, ESS-Datensätze für Headless Services, Pod-IPs. Es ermöglicht außerdem Service-Discovery-Funktionen wie SRV-Datensätze für benannte Ports. Überwachen Sie es zusammen mit `forward` (das externes DNS handhabt), da beide die Request-Pipeline teilen.
    Wie überwache ich die Cache-Trefferquote von CoreDNS?
    Berechnen Sie sie aus Prometheus: `coredns_cache_hits_total / (coredns_cache_hits_total + coredns_cache_misses_total)` — Ziel 80%+ für Cluster-DNS, 95%+ für NodeLocal DNSCache. Niedrige Trefferquoten bedeuten meist, dass TTLs zu kurz sind (Cluster-DNS-TTL ist standardmäßig 30s — konfigurierbar) oder das Working Set eindeutiger Abfragen die Cache-Größe übersteigt.
    Was bedeutet NXDOMAIN in CoreDNS-Metriken?
    `NXDOMAIN` (non-existent domain) in `coredns_dns_response_rcode_count_total` bedeutet, dass ein abgefragter Name nicht existiert. Etwas NXDOMAIN ist normal (Tippfehler, Scanner); Spitzen weisen auf falsch konfigurierte Search-Domains, Anwendungen, die nicht existierende Services suchen, oder DNS-Amplification-Versuche hin. SERVFAIL ist bedenklicher — es bedeutet, dass CoreDNS überhaupt keine Antwort erhalten konnte (Upstream-Ausfall, Plugin-Fehler).
    Wie debugge ich CoreDNS in Kubernetes?
    Drei Ebenen: (1) Pod-Logs prüfen (`kubectl logs -n kube-system -l k8s-app=kube-dns`), (2) Auflösung aus einem Pod heraus testen (`kubectl exec... -- nslookup kubernetes.default`), (3) Prometheus-Metriken für die SERVFAIL-Rate pro Plugin lesen. Das `log`-Plugin kann vorübergehend ins Corefile aufgenommen werden, um Logausgaben pro Abfrage zu erhalten. Verwenden Sie `dnstap` für produktionssicheres, hochvolumiges Tracing ohne Auswirkungen auf die Abfragelatenz.
    Wie überwache ich die Latenz des Forward-Plugins in CoreDNS?
    Lesen Sie das Histogramm `coredns_forward_request_duration_seconds`, gelabelt nach Adresse des Upstream-Resolvers. Verfolgen Sie p95 und p99 pro Upstream — langsame Upstreams tauchen hier auf, getrennt von der CoreDNS-internen Latenz. Das `forward`-Plugin stellt außerdem `coredns_forward_responses_total` pro rcode für upstream-spezifische SERVFAIL-Raten bereit. Alarmieren Sie bei p99 > 500ms pro Upstream.
    Wann sollte ich NodeLocal DNSCache einsetzen?
    Clustergröße > ~100 Nodes oder jeder Cluster mit UDP-conntrack-Races (zeitweise DNS-Timeouts unter Last). NodeLocal DNSCache läuft als CoreDNS-Cache-Sidecar auf jedem Node und bindet `169.254.20.10:53`, wodurch der conntrack-Tabelleneintrag pro Abfrage entfällt. Die Cluster-CoreDNS-Last sinkt typischerweise um 70–90%, und die DNS-p99-Latenz fällt auf lokale Disk-Geschwindigkeit. Überwachen Sie die Trefferquote pro Node (Ziel 95%+).
    Welche CoreDNS-Versionen werden unterstützt?
    CoreDNS 1.11.x, 1.12.x und 1.13.x werden vollständig unterstützt. 1.12 brachte MCS-API-Multicluster-Service-Discovery, Startup-Timeout-Konfiguration und IPv6-Hostname-Handling im `kubernetes`-Plugin. 1.13.2 (Dez. 2025) ist der aktuelle Stable. K8s 1.30+ liefert CoreDNS 1.11.x standardmäßig aus; neuere Distributionen liefern 1.12.x. Xitogent erkennt die Version automatisch und passt sich an.

    CoreDNS überwachen heute

    In weniger als 60 Sekunden eingerichtet. Keine Kreditkarte erforderlich. Umfassende Kennzahlen vom ersten Tag an.

    Kostenlose Testversion starten

    Entdecke weiter

    Verwandte Themen Integrationen