Kubernetes 监控方案:Prometheus+Grafana

  • A+
所属分类:Kubernetes

Prometheus是一款面向云原生应用程序的开源监控工具,作为第一个从CNCF毕业的监控工具而言,开发者对于Prometheus寄予了巨大的希望。在Kubernetes社区中,很多人认为Prometheus是容器场景中监控的第一方案,成为容器监控标准的制定者。在本文中,我们会为大家介绍如何快速部署一套Kubernetes的监控解决方案。 

Kubernetes 监控方案:Prometheus+Grafana

Prometheus方案的解析

在解析Prometheus容器监控方案之前,我们先要确定在Kubernetes中需要监控的对象包含什么?对于一个监控系统而言,常见的监控维度包括:资源监控和应用监控。资源监控是指节点、应用的资源使用情况,在容器场景中就延伸为节点的资源利用率、集群的资源利用率、Pod的资源利用率等。应用监控指的是应用内部指标的监控,例如我们会将应用在线人数进行实时统计,并通过端口进行暴露来实现应用业务级别的监控与告警。那么在Kubernetes中,监控对象会细化为哪些实体呢?

背景信息

在Kubernetes系统中,监控对象具体为:

  • 系统组件

Kubernetes集群中内置的组件,包括apiserver、controller-manager、etcd等。

  • 静态资源实体

主要指节点的资源状态、内核事件等

  • 动态资源实体 

主要指Kubernetes中抽象工作负载的实体,例如Deployment、DaemonSet、Pod等。

  • 自定义应用

主要指需要应用内部需要定制化的监控数据以及监控指标。

对于静态资源实体和系统组件而言,大家可能非常好理解,他们的监控方式也比较简单,只需要在配置文件中指明即可。

那么如何处理动态的资源实体监控呢?对于这种需要动态感知监控端点的场景,prometheus提出了自己的解决方案 - prometheus operator。prometheus operator是 CoreOS 开源的一套用于管理在 Kubernetes 集群上的 Prometheus 控制器,它是为了简化在 Kubernetes 上部署、管理和运行 Prometheus 和 Alertmanager 集群。

Kubernetes 监控方案:Prometheus+Grafana

简单的讲,prometheus operator的作用通过CRD的方式将需要动态监听的实体进行定义,并通过监听apiserver中实体的变化,实现prometheus中动态更新配置与报警规则。用更通俗的话讲就是,通过prometheus operator的方案,可以让prometheus的监控对象变成自动生成的,开发者无需额外配置监控任务,即可实现动态实体的监控。

Prometheus 组件

prometheus监控方案的主体是prometheus operator,为了满足Kubernetes中的监控场景,Prometheus方案在prometheus之上作了很多的扩展,主要包含如下组件:

  • prometheus-server:数据存储以及监控数据聚合

  • prometheus-config-reloader:动态更新prometheus配置

  • rules-configmap-reloader:动态更新prometheus报警配置

  • alert manager:报警组件

  • node-exporter:节点资源信息采集组件

  • kube-state-metrics:动态发现endpoint,三方监控的核心组件

  • prometheus-operator:prometheus配置的operator

  • grafana:数据展现

部署Prometheus

下载prometheus-operator代码

git clone https://github.com/AliyunContainerService/prometheus-operator

执行以下命令,部署Prometheus监控方案

cd prometheus-operator/contrib/kube-prometheus
kubectl apply -f manifests

说明:由于组件存在依赖顺序,首次执行此命令,可能部分组件无法成功。如果首次部署异常,请重新一执行此命令,再次部署即可。

如果报错:is forbidden: SecurityContext.RunAsUser is forbidden

删除:SecurityContextDeny 

# vim /kubernetes/cfg/kube-apiserver
--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota,NodeRestriction --authorization-mode=RBAC,Node \

重启kube-apiserver

systemctl restart kube-apiserver.service 
kubectl apply -f manifests

开放公网访问

默认情况下由于安全的原因,Prometheus、AlertManager与Grafana都没有开放公网访问,开发者可以通过本地的Proxy方式查看。

kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090
kubectl --namespace monitoring port-forward svc/grafana 3000
kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

局域网内,可以通过以下操作,直接开放公网访问。

kubectl --namespace monitoring edit svc/prometheus-k8s
kubectl --namespace monitoring edit svc/grafana
kubectl --namespace monitoring edit svc/alertmanager-main

三个service分别修改 type: ClusterIP ,保存退出,自动生效

type:NodePort

查看对方访问的随机端口

[root@k8s-M1 kube-prometheus]# kubectl -n monitoring  get svc
NAME                    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
alertmanager-main       NodePort    10.10.10.71    <none>        9093:36471/TCP      1h
alertmanager-operated   ClusterIP   None           <none>        9093/TCP,6783/TCP   1h
grafana                 NodePort    10.10.10.97    <none>        3000:38664/TCP      1h
kube-state-metrics      ClusterIP   None           <none>        8443/TCP,9443/TCP   1h
node-exporter           ClusterIP   None           <none>        9100/TCP            1h
prometheus-k8s          NodePort    10.10.10.149   <none>        9090:35796/TCP      1h
prometheus-operated     ClusterIP   None           <none>        9090/TCP            1h
prometheus-operator     ClusterIP   None           <none>        8080/TCP            1h

浏览器访问Prometheus

http://192.168.0.204:35796/targets

选择菜单栏Status下的Targets,查看所有采集任务。如果所有任务的状态为UP,表明所有采集任务均已正常运行。

Kubernetes 监控方案:Prometheus+Grafana

选择菜单栏 Alerts,即可查看当前的告警规则。

在Prometheus的Alerts类目中可以查看当前的报警规则,红色的规则表示正在触发报警,绿色的规则表示状态正常,默认prometheus operator会自动创建一批报警规则。

Kubernetes 监控方案:Prometheus+Grafana

设置告警压制

设置报警压制,需要访问Alter Manager点击Silence可以设置报警压制的内容。

http://192.168.0.204:36471

Kubernetes 监控方案:Prometheus+Grafana

浏览器访问Grafana

http://192.168.0.204:35796

默认用户名和密码都是admin,可以查看Dashboard

Kubernetes 监控方案:Prometheus+Grafana

定制Prometheus监控方案

到这里很多开发者会提出一个疑问,这么多内容是否可以进行定制?答案是肯定的,标准的Prometheus是通过配置文件来实现,传统中对于容器中的配置文件变化处理是非常麻烦的,因为配置的变化需要重启应用甚至容器,而且还需要提前将文件拷贝到主机上。我们先抛开Prometheus这件事情,先想想Kubernetes中是怎么解决的,在Kubernetes中所有的实体操作都可以通过Yaml变更来进行实现。那么Prometheus的配置是否可以通过类似的方式下发呢?

我们回到最开始部署的命令:

kubectl apply -f manifests

manifests是本次部署的所有内容文件,当我们深入到目录中的具体文件时,就会发现一些熟悉的内容。例如prometheus-rules.yaml这个文件,内容如下:

[root@k8s-M1 kube-prometheus]# vim manifests/prometheus-rules.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name: prometheus-k8s-rules
  namespace: monitoring
spec:
  groups:
  - name: k8s.rules
    rules:
    - expr: |
        sum(rate(container_cpu_usage_seconds_total{job="kubelet", image!="", container_name!=""}[5m])) by (namespace)
      record: namespace:container_cpu_usage_seconds_total:sum_rate

此处有一个特殊的抽象叫PrometheusRule,这就是prometheus-operator定义的的CRD,在rules字段中是定义的具体的报警规则与方式。因此,如果要修改prometheus中的报警规则,只需要修改这个yaml,并重新apply即可。

Prometheus 缺点

Prometheus的方案相比社区中Heapster(Metrics Server)的方案而言更加强大。但是也并非没有缺点,常常被开发者诟病的缺点主要有如下几个。

  • 性能差

首先对于Prometheus而言,是一个拉取模式的采集系统,而拉取式的系统通常会有一个通病,就是数据提供方的数据量级问题。推送数据的时候,我们可以根据数据的量级分批,分次进行推送。而拉取通常是全量数据的同步。此外相比传统的监控系统的数据存储Prometheus自身的存储数据格式性能还是很低下的。这会导致在集群量级比较大的情况下,Prometheus的CPU、内存、磁盘、网络都存在较高的利用率。Prometheus本身是单点的架构,虽然社区中已经有集群的模式,但是依然不够成熟,使用Promehteus的开发者要做好热备多活的思想准备,使用资源冗余的方式来保证系统稳定。

  • 组件过多

刚才我们已经看到一个标准的Prometheus方案会涉及的组件部分,这些组件大部分都是不可缺少的,这也会导致部署这个方案后,需要额外维护很多监控相关的组件,维护的成本较高。

  • 学习成本高 

Kubernetes的风格固然能够成为一种标准表达和执行的范式,但是对于监控而言,后续有些过于激进,本身Prometheus的学习成本已经较高,加入CRD的方式,会使学习的成本变得更高。

  • 扩展性差

表面上看Prometheus定义了CRD可以进行扩展,但是从Prometheus本身而言,缺乏插件的机制进行扩展,从代码外直接扩展则会增加整体架构的复杂,相比zabbix、grafana或者heapster等等监控相关工具的扩展方式,Prometheus还有很长的路要走。

  • 监控指标不准确 

这个问题是从Prometheus监控制定开始就存在的问题,由于kubelet的数据指标不是实时的,而Prometheus的数据采集会丢失时间戳,这会导致非常异常的利用率曲线。具体的描述,可以参考如下两个PR 2059与2028

总结

虽然Prometheus有很多的缺点,但是他依然是Kubernetes社区中监控领域的重要一环,开发者可以根据自己的需求来选择合适的方案。对于大部分的开发者而言,内置的Heapter(Metrics Server)与云监控集成的方案已经可以解决80%的基础问题了,未尝不是一个便捷的选择。Prometheus的未来依然是光明的,阿里云也会和社区一起,推进Prometheus的演进,提供更好的Prometheus监控方案。

参考文档:

https://help.aliyun.com/document_detail/94622.html?spm=a2c4g.11186623.6.674.20b43f59mmIr9i

https://yq.aliyun.com/articles/657142?spm=a2c4e.11153940.blogcont658890.40.348c1d4d7diM6I

使用Prometheus实现应用自定义监控

https://yq.aliyun.com/articles/658890?spm=a2c4e.11155435.0.0.6be55411h1KkWj

YaLei

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: