0 - 通过本文你会获得什么

如何监控CoreDNS，通过了解它的几个关键指标，查询历史趋势、服务负载，可以反馈出运行的状态，及早预知可能出现的异常，做到心中有数，保证服务的稳定。

涉及知识点：kubernetes prometheus coredns

1 - 开始前准备

需有一套K8S集群，使用CoreDNS作为内部的域名解析系统，同时集群内设置了Prometheus作为指标收集。

在k8s 1.9之前，可选的dns服务只有kube-dns（实际由3个容器组成的Pod），在1.10之后可选coredns替换kube-dns作为集群内解析服务，同时官方也推荐后续均由coredns替代kube-dns组件。

CoreDNS在k8s 1.11的时候GA，正式引入集群作为默认服务是在k8s的1.13版本，DNS在集群中的作用也是至关重要的，负责集群内服务发现以及外部域名解析，如果出现异常，对业务也会造成较大影响。

2 - 开启CoreDNS性能指标

通过在Corefile配置文件中开启prometheus插件，语法格式：

. {
    prometheus 0.0.0.0:9253
}

默认监听的地址为: 127.0.0.1:9253，由于需从外部进行数据抓取，所以必须监听在0.0.0.0否则Prometheus无法获取coredns性能数据。

3 - CoreDNS性能指标列表

这里主要关注这6个指标：

• coredns_dns_request_count_total
• coredns_dns_request_duration_seconds
• coredns_dns_request_type_count_total
• coredns_dns_response_size_bytes
• coredns_dns_response_rcode_count_total
• coredns_panic_count_total

在下一步我们将会通过它们进行数值展示。

3.1 - 几个通用维度

大部分指标都存在server、zone这两个维度

server 有时候会设置监听多个，这样就有多个server维度值，格式为：

<scheme>://[<bind>]:<port>

例如：dns://:53 或者 dns://127.0.0.1:53 或者 dns://:9153

3.2 - 指标：coredns_dns_request_count_total

3.3 - 指标：coredns_dns_request_duration_seconds

是一个histogram类型的指标，所以存在三个具体的指标名：

• coredns_dns_request_duration_seconds_bucket
• coredns_dns_request_duration_seconds_sum
• coredns_dns_request_duration_seconds_count

其中le维度只有X_bucket才有。

le维度取值范围：0.00025，0.0005，..., 后一个以前值的2被数增加，最多16个，最后一个为无穷大。

3.4 - 指标：coredns_dns_request_size_bytes

是一个histogram类型的指标，所以存在三个具体的指标名：

• coredns_dns_request_size_bytes_bucket
• coredns_dns_request_size_bytes_sum
• coredns_dns_request_size_bytes_count

其中le维度只有X_bucket才有

le维度取值范围：0, 100, 200, 300, 400, 511, 1023, 2047, 4095, 8291, 16000, 32000, 48000, 64000

3.5 - 指标：coredns_dns_request_do_count_total

有时候可能会看不到这个指标，可能没有存在dnssec的请求，你可以通过以下dig命令

dig www.google.com +dnssec @127.0.0.1 -p 53

通过该DNS查询，这样该指标值累加1次

3.6 - 指标：coredns_dns_request_type_count_total

可支持大部分主流的记录类型，如下表：

3.7 - 指标：coredns_dns_response_size_bytes

是一个histogram类型的指标，所以存在三个具体的指标名：

• coredns_dns_response_size_bytes_bucket
• coredns_dns_response_size_bytes_sum
• coredns_dns_response_size_bytes_count

le维度取值范围：0, 100, 200, 300, 400, 511, 1023, 2047, 4095, 8291, 16000, 32000, 48000, 64000

3.8 - 指标：coredns_dns_response_rcode_count_total

常见的几个响应状态码，如下表：

3.8 - coredns_panic_count_total

进程出现中断的次数，这个比较严重，需判断是否新加了什么插件导致的，需要关注了。

3.9 - 指标：coredns_plugin_enabled

当前各个server下的zone开启了哪些插件功能。

3.10 - 指标：coredns_build_info

记录coredns编译时的版本

4 - 关键指标展示

同时制作了一个视图模版，可在Grafana官方地址：https://grafana.com/grafana/dashboards/10639 下载，

以下通过展示几个promQL查询语句，示例均以维度server=172.23.243.136:9153。

4.1 - 请求时间耗时

示例1: 以维度server,zone,le分组，最近5分钟内，平均每秒耗时小于le维度的变化数量

sort_desc(
    avg(
        rate(
            coredns_dns_request_duration_seconds_bucket{instance="172.23.243.136:9153"}[5m]
            )
    ) by(server,zone,le)
)

示例2：计算示例1结果90%的范围小于多少，也就是第90百分位数

百分位数: 用99个数值或99个点，将按从小到大顺序排列的观测值划分为100个等分，则这99个数值或99个点就称为百分位数，比如：第90百分位数的值，表示有90%的值均小于该数值。

histogram_quantile(0.90,
    sum(
        rate(
            coredns_dns_request_duration_seconds_bucket{instance="172.23.243.136:9153"}[5m]
        )
    ) by(server,zone,le)
)

4.2 - 客户端数据包大小

示例1：以维度proto,server,zone,le分组，最近5分钟内，平均每秒数据包大小小于le维度的变化数量

sort_desc(
    avg(
        rate(
            coredns_dns_response_size_bytes_bucket{instance="172.23.243.136:9153",zone!="dropped"}[5m]
        )
    ) by (proto,server,zone,le)
)

示例2：计算示例1结果90%的范围小于多少，也就是第90百分位数

histogram_quantile(0.90,
    avg(
        rate(
            coredns_dns_response_size_bytes_bucket{instance="172.23.243.136:9153",zone!="dropped"}[5m]
        )
    ) by (proto,server,zone,le)
)

4.3 - 服务端处理请求数

示例1：最近5分钟内，平均每秒处理的请求次数

sort_desc(
    avg(
        rate(
            coredns_dns_request_count_total{instance="172.23.243.136:9153"}[5m]
        )
    ) by (proto,server,zone)
)

4.4 - 客户端请求记录类型

示例1：最近5分钟内，各请求记录类型，平均每秒处理的次数

sort_desc(
    avg(
        rate(
            coredns_dns_request_type_count_total{instance="172.23.243.136:9153"}[5m]
        )
    ) by (server,zone,type)
)

4.5 - 服务端响应状态码分布

示例1：最近5分钟，平均每秒响应状态码的次数

sort_desc(
    avg(
        rate(
            coredns_dns_response_rcode_count_total{instance="172.23.243.136:9153"}[5m]
        )
    ) by(server,zone,rcode)
)

4.6 - 服务异常统计

• 出现panic时候，记录drop
• 不存在dns question section（向DNS请求的部分）
• 其他原因被拒绝解析的

所以不需要关注 zone=droped 的数据，可以通过rcode其他指标反应出来

示例1：响应状态码非正常的处理请求，平均每秒次数，单位：次/秒

sort_desc(
    avg(
        rate(
            coredns_dns_response_rcode_count_total{instance="172.23.243.136:9153",rcode!="NOERROR"}[10m]
        )
    ) by(server,zone,rcode)
)

示例2: 进程出现panic的次数

avg(coredns_panic_count_total{instance="172.23.243.136:9153"})

5 - 总结讨论

在配合prometheus的alertmanager组件，根据以上指标设置告警规则，做到及时预警。Kubernetes是分布式系统，带来了一定的维护复杂度，必须有一套完善的监控体系去做支撑。

本人关注云原生生态，今天这里只是针对DNS服务的内容，后续还会有其他相关的分享，如有兴趣，欢迎关注我，对于存在的疑问点，欢迎留言讨论。