Servidor DNS
    Atualizado maio de 2026
    CoreDNS logo

    CoreDNS Monitorização

    Monitorize as taxas de consultas do CoreDNS, as taxas de acertos no cache, a latência de resolução e as taxas de erro em tempo real, sem necessidade de configuração.

    Por que monitorizar CoreDNS?

    O CoreDNS é o servidor DNS predefinido para o Kubernetes e ambientes nativos da nuvem. A monitorização do CoreDNS garante uma resolução DNS rápida, um bom desempenho do cache e uma descoberta de serviços fiável para a sua infraestrutura.

    Deteção automática via Xitogent
    Monitorização da taxa de consultas
    Rácio de cache hit/miss
    Acompanhamento da latência de resolução
    Taxa de erros e SERVFAIL
    Métricas por zona
    Monitorização ao nível dos plugins
    Intervalos de recolha de 1 minuto
    Limiares de alerta personalizáveis para cada métrica
    Intervalos de recolha de métricas de 1 minuto de raiz
    O que é a monitorização do CoreDNS?

    Monitorização do CoreDNS, explicada

    A monitorização do CoreDNS deteta picos de SERVFAIL, quedas no rácio de acertos da cache, latência do plugin forward e reinícios por panic antes que se transformem em falhas de resolução DNS em todo o cluster. Como todos os microsserviços dependem do DNS para descoberta de serviços, um CoreDNS não monitorizado é um modo de falha não monitorizado para todo o seu cluster Kubernetes — os problemas de DNS aparecem como "connection refused aleatórios" em toda a parte. O Xitoring deteta automaticamente o seu CoreDNS, faz scrape de :9153/metrics e encaminha alertas para Slack, PagerDuty, Telegram ou o seu on-call existente.

    Métricas

    O que monitorizamos

    Consultas/s

    Taxa de consultas DNS.

    Rácio de cache hit

    Percentagem de consultas servidas a partir da cache.

    Latência de resolução

    Tempo médio de resolução DNS.

    Taxa de SERVFAIL

    Percentagem de resoluções falhadas.

    Taxa NXDOMAIN

    Taxa de consultas a domínios inexistentes.

    Latência upstream

    Tempo de resposta das consultas reencaminhadas.

    Latência do plugin Forward

    `coredns_forward_request_duration_seconds` por resolver upstream. Separa a latência interna do CoreDNS da latência do resolver upstream — crítico para diagnosticar se o lento é o 8.8.8.8 ou o próprio CoreDNS.

    Taxa de pedidos Forward

    `coredns_forward_request_count_total` por upstream. Combinado com o rácio de acertos da cache, mostra quanto tráfego sai efetivamente do CoreDNS para resolução upstream.

    Cache de ligações do Proxy

    `coredns_proxy_conn_cache_hits_total` / `_misses_total`. Acompanha a reutilização de ligações TCP para resolvers upstream — um rácio de acertos baixo significa churn de ligações, aumentando a latência upstream.

    Falhas do plugin Health

    `coredns_health_request_failures_total` — a contagem de falhas do próprio plugin `health:8080`. Um valor diferente de zero significa que a sonda de liveness está a falhar de forma intermitente.

    Panics

    `coredns_panics_total` — qualquer valor diferente de zero é um bug do CoreDNS ou um crash de plugin que provocou um panic de goroutine. Combine com a contagem de reinícios para obter contexto completo de post-mortem.

    Runtime do Go

    `process_resident_memory_bytes` (RSS), `go_goroutines` (contagem de goroutines — deteta fugas), `go_gc_duration_seconds` (tempo de pausa do GC). Crescimento de memória sem reinícios = fuga; crescimento da contagem de goroutines = plugin ou upstream bloqueado.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dCoreDNS ultrapassarem os limites que definiu.

    CoreDNS painel de controlo da configuração dos gatilhos de monitorização

    Taxa de SERVFAIL

    crítico

    Dispara em caso de alta taxa de falhas de resolução.

    Rácio de cache hit

    aviso

    Alerta quando a eficácia da cache cai.

    Latência de resolução

    aviso

    Dispara em caso de resolução DNS lenta.

    Taxa de consultas

    aviso

    Dispara em volumes de consultas inusitados.

    01

    Importância da monitorização do CoreDNS

    O DNS é a base da conectividade de rede. Uma resolução DNS lenta ou falhada afeta todos os serviços na sua infraestrutura.

    • Garantir uma resolução DNS rápida
    • Detetar picos de SERVFAIL imediatamente
    • Monitorizar a cache para um desempenho ótimo
    • Acompanhar a saúde dos resolvers upstream
    Monitorização do CoreDNS
    Analítica DNS
    02

    Porquê escolher Xitoring

    Monitorização CoreDNS sem configuração.

    • Instalação num único comando
    • Nós globais
    • Dashboard unificado
    • Alertas multicanal
    Visão geral
    Alertas
    Casos de uso

    Cenários comuns de monitorização do CoreDNS

    Onde o CoreDNS normalmente é executado hoje — e o que poderia correr mal se ninguém estivesse a monitorizar.

    DNS dentro de uma aplicação Kubernetes

    Cada parte de uma aplicação Kubernetes usa o CoreDNS para encontrar todas as outras partes. Quando ele desacelera ou começa a falhar, os utilizadores veem erros estranhos e intermitentes em toda a aplicação. Detetamos a desaceleração no momento em que começa, para que um pequeno soluço de DNS não apareça para os clientes como uma interrupção misteriosa.

    Grandes clusters com caches DNS locais

    Configurações maiores de Kubernetes colocam uma pequena cache DNS em cada servidor para manter as coisas rápidas. Quando uma dessas caches se comporta mal, apenas uma fatia do tráfego falha — tornando difícil de detetar. Garantimos que cada uma está a fazer o seu trabalho para que um único nó defeituoso não degrade silenciosamente uma fração dos seus utilizadores.

    DNS público para o seu domínio

    Quando o CoreDNS é o que responde às consultas DNS para o seu domínio na internet aberta, uma interrupção significa que as pessoas não conseguem aceder ao seu site de todo. Monitorizamos os sinais que provam que o serviço está saudável e a responder, para que a marca e a receita não estejam a sangrar silenciosamente enquanto o DNS falha em silêncio.

    Antes de começar

    Pré-requisitos para CoreDNS

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • CoreDNS 1.x em execução no servidor
    • Plugin Prometheus ativado no seu Corefile (porta predefinida 9153)
    • Acessibilidade de rede do Xitogent ao endpoint de metrics
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent no seu servidor

    Se ainda não o fez, instale o leve agente de monitorização Xitogent no host que executa o CoreDNS.

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

    Ativar o plugin prometheus no CoreDNS

    O CoreDNS expõe métricas em formato Prometheus através do seu plugin prometheus (endpoint predefinido :9153/metrics). Adicione `prometheus :9153` ao seu Corefile, recarregue o CoreDNS e confirme que o endpoint de metrics é acessível a partir do host do agente.

    sudo xitogent integrate
    3

    Ativar a integração do CoreDNS

    Use o painel do Xitoring ou a CLI para ativar a integração do CoreDNS. O Xitogent deteta automaticamente o endpoint de metrics e começa a recolher métricas de queries, cache e latência.

    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para taxa de SERVFAIL, rácio de cache hit ou latência de resolução para ser notificado assim que a fiabilidade ou desempenho do DNS se degradar.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status

    Frequentemente perguntas feitas

    CoreDNS do Kubernetes?
    Sim, o CoreDNS no Kubernetes é totalmente compatível.
    Métricas do Prometheus?
    Xitogent lê o ponto final de métricas do CoreDNS no Prometheus.
    O que faz o plugin kubernetes?
    O plugin `kubernetes` observa a API do Kubernetes para alterações em Service, Endpoint e Pod, e sintetiza registos DNS para eles — resoluções `..svc.cluster.local`, registos ESS para serviços headless, IPs de pods. Também ativa funcionalidades de descoberta de serviços, como registos SRV para portas com nome. Monitorize-o em paralelo com o `forward` (que trata do DNS externo), uma vez que partilham o pipeline de pedidos.
    Como monitorizo o rácio de acertos da cache do CoreDNS?
    Calcule-o a partir do Prometheus: `coredns_cache_hits_total / (coredns_cache_hits_total + coredns_cache_misses_total)` — alvo de 80%+ para DNS de cluster, 95%+ para NodeLocal DNSCache. Rácios de acertos baixos geralmente significam que os TTLs são demasiado curtos (o TTL do DNS de cluster é 30s por omissão — ajustável) ou que o conjunto de queries únicas excede o tamanho da cache.
    O que significa NXDOMAIN nas métricas do CoreDNS?
    `NXDOMAIN` (domínio inexistente) em `coredns_dns_response_rcode_count_total` significa que um nome consultado não existe. Algum NXDOMAIN é normal (typos, scanners); picos sinalizam search domains mal configurados, aplicações a procurar serviços inexistentes ou tentativas de amplificação de DNS. SERVFAIL é mais preocupante — significa que o CoreDNS não conseguiu obter resposta nenhuma (falha upstream, erro de plugin).
    Como faço debug ao CoreDNS no Kubernetes?
    Três camadas: (1) verificar logs do pod (`kubectl logs -n kube-system -l k8s-app=kube-dns`), (2) testar resolução de dentro de um pod (`kubectl exec... -- nslookup kubernetes.default`), (3) ler métricas Prometheus para a taxa de SERVFAIL por plugin. O plugin `log` pode ser adicionado temporariamente ao Corefile para output por query no log. Use `dnstap` para tracing de alto volume seguro em produção, sem afetar a latência das queries.
    Como monitorizo a latência do plugin forward do CoreDNS?
    Leia o histograma `coredns_forward_request_duration_seconds`, etiquetado pelo endereço do resolver upstream. Acompanhe p95 e p99 por upstream — upstreams lentos aparecem aqui, separados da latência interna do CoreDNS. O plugin `forward` também expõe `coredns_forward_responses_total` por rcode para taxas de SERVFAIL específicas de cada upstream. Alerte quando p99 > 500ms por upstream.
    Quando devo usar o NodeLocal DNSCache?
    Cluster com mais de ~100 nós, ou qualquer cluster com corridas UDP no conntrack (timeouts de DNS intermitentes sob carga). O NodeLocal DNSCache corre um sidecar de cache CoreDNS em cada nó com bind em `169.254.20.10:53`, eliminando a entrada da tabela conntrack por query. A carga no CoreDNS do cluster cai tipicamente 70-90% e a latência p99 do DNS cai para a velocidade do disco local. Monitorize a taxa de acertos por nó (alvo 95%+).
    Que versões do CoreDNS são suportadas?
    CoreDNS 1.11.x, 1.12.x e 1.13.x são totalmente suportadas. A 1.12 adicionou descoberta de serviços multicluster MCS-API, configuração de startup timeout e tratamento de hostnames IPv6 no plugin `kubernetes`. A 1.13.2 (dez. 2025) é a estável atual. O K8s 1.30+ inclui CoreDNS 1.11.x por omissão; distros mais recentes incluem 1.12.x. O Xitogent deteta automaticamente a versão e adapta-se.

    Comece a monitorizar CoreDNS hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações