为什么使用 Prometheus 监控 Kubernetes?
Kubernetes 主要解决的是分布式服务调度的问题,目前的服务倾向于拆分成多个较为单一功能的服务(微服务), 而且微服务的变更和扩容也较为频繁,这就意味着监控系统需要频繁地变更采集目标,采集的指标也是各种各样。
再来看看Prometheus 的特性:
支持多维度的数据模型, 基于键值对的格式存储
PromQL,比较灵活的查询数据
可以主动拉取监控指标
通过中间网关推送监控指标
通过服务发现或者静态配置发现目标
图形界面和监控告警
这些特性都非常契合Kubernetes,可以解决大部分痛点。而且Prometheus-Operator 是基于K8s的自定义的控制器,通过Kubernetes Etcd 知道当前各个资源对象的状态,并生成Prometheus抓取配置,有效地解决了频繁变更的痛点;
Prometheus vs InfluxDB
InfluxDB 类似于 Prometheus :他们使用基于标签的维度和相同的数据压缩算法。然而,由于其纳秒级时间力度和合并不同事件日志的能力,Influx 更适合事件日志记录。Prometheus 更适合指标收集,并且有更强大的查询语言来检查它们。
Prometheus vs Nagios/Icinga/Sensu
正如我们之前提到的,像Nagios/Icinga/Sensu这样的工具适用于主机/网络/服务监控 这种经典的任务。例如,Nagios是基于主机的。如果你想获得有关微服务状态的内部细节,Prometheus更合适。
5个契合点:
Prometheus 可以通过以下这几种做服务发现:
Prometheus Kubernetes SD (service discovery)
The Prometheus operator and its Custom Resource Definitions
Consul SD
Azure SD for Azure VM
GCE SD for GCP instances
EC2 SD for AWS VM
File SD
除了应用指标外,我们希望Prometheus能收集与Kubernetes服务、节点和调度状态有关的指标:
Node exporter 用于传统的主机相关指标:CPU、内存、网络等。
Kube-state-metrics用于采集集群级别的指标。
Kubernetes控制面指标:kubelet、etcd、dns、调度器等
Prometheus 可以配置规则以使用 PromQL 触发警报。alertmanager 将负责管理警报通知、分组等
AlertManager 组件配置警报通知
Grafana 展示监控指标
参考
https://prometheus.io/docs/instrumenting/exporters/
https://sysdig.com/blog/kubernetes-monitoring-prometheus/
https://cloud.redhat.com/learn/topics/operators
https://zhuanlan.zhihu.com/p/379276513