容器监控实践—Prometheus部署方案

37次阅读

共计 3943 个字符,预计需要花费 10 分钟才能阅读完成。

一. 单独部署

二进制安装各版本下载地址:https://prometheus.io/download/

Docker 运行

运行命令:docker run –name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus 暴露服务:http://localhost:9090/
二. 在 K8S 中部署
如果在 Kubernetes 中部署 Prometheus,可以使用 prometheus in kubernetes,含 exporter、grafana 等组件。
安装方式:
kubectl apply \
–filename https://raw.githubusercontent.com/giantswarm/kubernetes-prometheus/master/manifests-all.yaml
卸载方式:
kubectl delete namespace monitoring
该方式为大多数用户和云厂商使用的方式,可以基于 Prometheus 的服务发现:在 annotation 中设置 prometheus.io/scrape 为 true,就可以把 K8S 的所有服务都加入到监控中,但在使用的过程中会有一些问题:

1. 如果增加了新的 exporter,如 nginx-exporter,需要修改 prometheus 配置并重启
2. 服务本身和监控配置没有分离
3. 监控集群多实例的状态不好管理
4. 报警配置也包含在 prometheus 的配置中,监控与报警没有分离,添加规则麻烦

以上问题一般的处理方式为:在 prometheus 上加一个控制台,来动态配置 target、报警规则,并向后端 server 发起修改、重启操作。同时有权限控制、日志审计、整体配置过期时间等功能。
但如果使用了 Prometheus Operator,就可以将以上大多数操作抽象为 k8s 中的资源提交、修改,减少上层封装的工作量。
三.Prometheus Operator 部署
Prometheus-Operator 是一套为了方便整合 prometheus 和 kubernetes 的开源方案,使用 Prometheus-Operator 可以非常简单的在 kubernetes 集群中部署 Prometheus 服务,用户能够使用简单的声明性配置来配置和管理 Prometheus 实例,这些配置将响应、创建、配置和管理 Prometheus 监控实例。

官方地址:https://github.com/coreos/pro…

目前状态:beta 状态,还不够完整,但向后兼容。将成为趋势
前置条件:要求 k8s 的版本 >=1.8.0(应该是因为 metric api 和 CRD 支持的限制)

Operator 的核心思想是将 Prometheus 的部署与它监控的对象的配置分离,做到部署与监控对象的配置分离之后,就可以轻松实现动态配置。使用 Operator 部署了 Prometheus 之后就可以不用再管 Prometheus Server 了,以后如果要添加监控对象或者添加告警规则,只需要编写对应的 ServiceMonitor 和 Prometheus 资源就可以,不用再重启 Prometheus 服务,Operator 会动态的观察配置的改动,并将其生成为对应的 prometheus 配置文件其中 Operator 可以部署、管理 Prometheus Service

四种 CRD 作用如下:

Prometheus: 由 Operator 依据一个自定义资源 kind: Prometheus 类型中,所描述的内容而部署的 Prometheus Server 集群,可以将这个自定义资源看作是一种特别用来管理 Prometheus Server 的 StatefulSets 资源。
ServiceMonitor: 一个 Kubernetes 自定义资源 (和 kind: Prometheus 一样是 CRD),该资源描述了 Prometheus Server 的 Target 列表,Operator 会监听这个资源的变化来动态的更新 Prometheus Server 的 Scrape targets 并让 prometheus server 去 reload 配置 (prometheus 有对应 reload 的 http 接口 /-/reload)。而该资源主要通过 Selector 来依据 Labels 选取对应的 Service 的 endpoints,并让 Prometheus Server 通过 Service 进行拉取(拉)指标资料 (也就是 metrics 信息),metrics 信息要在 http 的 url 输出符合 metrics 格式的信息,ServiceMonitor 也可以定义目标的 metrics 的 url。
Alertmanager:Prometheus Operator 不只是提供 Prometheus Server 管理与部署,也包含了 AlertManager,并且一样通过一个 kind: Alertmanager 自定义资源来描述信息,再由 Operator 依据描述内容部署 Alertmanager 集群。
PrometheusRule: 对于 Prometheus 而言,在原生的管理方式上,我们需要手动创建 Prometheus 的告警文件,并且通过在 Prometheus 配置中声明式的加载。而在 Prometheus Operator 模式中,告警规则也编程一个通过 Kubernetes API 声明式创建的一个资源. 告警规则创建成功后,通过在 Prometheus 中使用想 servicemonitor 那样用 ruleSelector 通过 label 匹配选择需要关联的 PrometheusRule 即可。

安装方式:

创建命名空间:monitoring
执行 yaml 文件:https://github.com/coreos/pro…

prometheus 的 target 列表:

grafana 的自带监控图列表:

常见问题:
因为要 operator 中要支持聚合 api,在某些版本的集群上可能需要一些配置,如下:

安装 cfssl 证书生成工具:http://www.cnblogs.com/xuling…

生成证书

cfssl gencert -ca=/etc/kubernetes/pki/ca.pem -ca-key=/etc/kubernetes/pki/ca-key.pem -config=/etc/kubernetes/pki/ca-config.json -profile=jpaas metrics-server-csr.json | cfssljson -bare metrics-server

{
“CN”: “aggregator”,
“host”: [],
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “k8s”,
“OU”: “cloudnative”
}
]
}
配置 master 组件参数,以支持 metric-server
vim /etc/systemd/system/kube-apiserver.service

–requestheader-client-ca-file=/etc/kubernetes/pki/ca.pem \
–requestheader-allowed-names=”aggregator” \
–requestheader-extra-headers-prefix=”X-Remote-Extra-” \
–requestheader-group-headers=X-Remote-Group \
–requestheader-username-headers=X-Remote-User \
–proxy-client-cert-file=/etc/kubernetes/pki/metrics-server.pem \
–proxy-client-key-file=/etc/kubernetes/pki/metrics-server-key.pem \
–runtime-config=api/all=true \
–enable-aggregator-routing=true \

systemctl daemon-reload
systemctl restart kube-apiserver.service
systemctl status kube-apiserver.service

vim /etc/systemd/system/kube-controller.service
–horizontal-pod-autoscaler-use-rest-clients=true
systemctl daemon-reload
systemctl restart kube-controller.service
systemctl status kube-controller.service
启动成功后,prometheus 的 target 中,kubelet 没有值,401 报错
vim /etc/systemd/system/kubelet.service

–authentication-token-webhook=true
–authorization-mode=Webhook

systemctl daemon-reload

systemctl restart kubelet.service

参考文档:

https://github.com/coreos/pro…
https://www.yinjk.cn/2018/09/…
http://www.servicemesher.com/…

本文为容器监控实践系列文章,完整内容见:container-monitor-book

正文完
 0