【容器云 UK8S】日志监控方案：什么是Prometheus？怎么部署Prometheus？

摘要：客户端库，为需要监控的服务生成相应的并暴露给。根据配置文件，对接收到的警报进行处理，发出告警。再创建一个来告诉需要监控带有为的背后的一组的。

什么是Prometheus

关于Prometheus

Prometheus 是一套开源的系统监控报警框架。它的设计灵感源于 Google 的 borgmon 监控系统，由SoundCloud 在 2012 年创建，后作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation(CNCF)，成为受欢迎度仅次于 Kubernetes 的项目，目前已广泛应用于Kubernetes集群监控系统中，大有成为Kubernetes集群监控标准方案的趋势。

Prometheus的优势

• 强大的多维度数据模型：

  • 时间序列数据通过 metric 名和键值对来区分。
  • 所有的 metrics 都可以设置任意的多维标签。
  • 数据模型更随意，不需要刻意设置为以点分隔的字符串。
  • 可以对数据模型进行聚合，切割和切片操作。
  • 支持双精度浮点类型，标签可以设为全 unicode。
• 灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
• 易于管理： Prometheus server 是一个多带带的二进制文件，可直接在本地工作，不依赖于分布式存储。
• 高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
• 动态获取：可以通过服务发现或者静态配置去获取监控的 targets。
• 使用 pull 模式采集时间序列数据，可以避免有问题的服务器推送坏的 metrics。
• 支持 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
• 多种可视化图形界面。

Prometheus架构及组件

图片源于Prometheus官方文档

上图为Prometheus的架构图，包含了Prometheus的核心模块及生态圈中的组件，简要介绍如下：

• Prometheus Server: 用于收集和存储时间序列数据。
• Client Library: 客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
• Push Gateway: 主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，建议使用 node exporter。
• Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
• Alertmanager: 从 Prometheus server 端接收到 alerts 后，会去除重复数据，分组，并路由到对应的接受方式，发出报警。

工作原理

如上图可见，Prometheus 的主要模块包括：Prometheus server exporters Pushgateway PromQL Alertmanager 以及图形界面，其大概的工作流程是：

1. Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
2. Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
3. Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
4. 在图形界面中，可视化采集数据。

Prometheus 工作的核心，是使用 Pull （抓取）的方式去搜集被监控对象的 Metrics 数据（监控指标数据），然后，再把这些数据保存在一个 TSDB （时间序列数据库，比如 OpenTSDB、InfluxDB 等）当中，以便后续可以按照时间进行检索。

适用场景

Prometheus非常适合记录纯时间序列的数据。它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。它的搭建过程对硬件和服务没有很强的依赖关系。

Prometheus重视可靠性，即使在故障情况下，您也可以随时查看有关系统的可用统计信息。如果您需要100％的准确度，例如按请求计费，Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整。

总之，在需要高可用性的业务场景，Prometheus是一个非常好的选择，但对于高精度、高准确率的业务场景，Prometheus并非最佳选择。

核心概念

为了在 Prometheus 的配置和使用中可以更加顺畅，我们对 Prometheus 中的数据模型、metric 类型以及 instance 和 job 等概念做个简要介绍。

数据模型

Prometheus 中存储的数据为时间序列，是由 metric 的名字和一系列的标签（键值对）唯一标识的，不同的标签则代表不同的时间序列。

• metric 名字：该名字应该具有语义，一般用于表示 metric 的功能，例如：http_requests_total 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 a-zA-Z_:*。
• 标签：使同一个时间序列有了不同维度的识别。例如 http_requests_total{method="Get"} 表示所有 http 请求中的 Get 请求。当 method="post" 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式 a-zA-Z_:*。
• 样本：实际的时间序列，每个序列包括一个 float64 的值和一个毫秒级的时间戳。
• 格式： 如http_requests_total{method="POST"endpoint="/api/tracks"}。

metric 类型

Prometheus 客户端库主要提供四种主要的 metric 类型，分别如下：

1. Counter

一种累加的 metric，典型的应用如：请求的个数，结束的任务数， 出现的错误数等等。
例如，查询 http_requests_total{method="get" job="kubernetes-nodes" handler="prometheus"} 返回 8，10 秒后，再次查询，则返回 14。

1. Gauge

一种常规的 metric，典型的应用如：温度，运行的 goroutines 的个数。例如：go_goroutines{instance="10.9.81.55" job="kubernetes-nodes"} 返回值 147，10 秒后返回 124。

1. Histogram

可以理解为柱状图，典型的应用如：请求持续时间，响应大小。可以对观察结果采样，分组及统计。
例如，查询 http_request_duration_microseconds_sum{job="kubernetes-nodes" handler="prometheus"} 时，返回结果如下：

1. Summary

类似于 Histogram 典型的应用如：请求持续时间，响应大小。提供观测值的 count 和 sum 功能。提供百分位的功能，即可以按百分比划分跟踪结果。

instance&job

instance: 一个多带带 scrape 的目标， 一般对应于一个进程。

jobs: 一组同类型的 instances

例如，一个 api-server 的 job 可以包含4个 instances：

• job: api-server

  • instance 1: 1.2.3.4:5670
  • instance 2: 1.2.3.4:5671
  • instance 3: 1.2.3.4:5672
  • instance 4: 1.2.3.4:5673

当 scrape 目标时，Prometheus 会自动给这个 scrape 的时间序列附加一些标签以便更好的分别，例如：instance，job。

部署Prometheus

前言

对于一套Kubernetes集群而言，需要监控的对象大致可以分为以下几类：

• Kubernetes系统组件：Kubernetes内置的系统组件一般有apiserver、controller-manager、etcd、kubelet等，为了保证集群正常运行，我们需要实时知晓其当前的运行状态。
• 底层基础设施： Node节点(虚拟机或物理机)的资源状态、内核事件等。
• Kubernetes对象： 主要是Kubernetes中的工作负载对象，如Deployment、DaemonSet、Pod等。
• 应用指标： 应用内部需要关心的数据指标，如httpRequest。

部署Prometheus

在Kubernetes中部署Prometheus，除了手工方式外，CoreOS开源了Prometheus-Operator以及kube-Prometheus项目，使得在K8S中安装部署Prometheus变得异常简单。下面我们介绍下如何在UK8S中部署Kube-Prometheus。

1、关于Prometheus-Operator

Prometheus-operator的本职就是一组用户自定义的CRD资源以及Controller的实现，Prometheus Operator这个controller有BRAC权限下去负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如Prometheus Server自身以及配置的自动化管理工作。

在K8S中，监控metrics基本最小单位都是一个Service背后的一组pod，对应Prometheus中的target，所以prometheus-operator抽象了对应的CRD类型" ServiceMonitor "，这个ServiceMonitor通过 sepc.selector.labes来查找对应的Service及其背后的Pod或endpoints，通过sepc.endpoint来指明Metrics的url路径。
以下面的CoreDNS举例，需要pull的Target对象Namespace为kube-system，kube-app是他们的labels，port为metrics。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    k8s-app: coredns
  name: coredns
  namespace: monitoring
spec:
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: metrics
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - kube-system
  selector:
    matchLabels:
      k8s-app: kube-dns

2、准备工作

ssh到任意一台Master节点，克隆kube-prometheus项目。该项目源自CoreOS开源的kube-prometheus，与原始项目相比，主要作为以下优化：

• 将Prometheus和AlbertManager的数据存储介质由emptyDir改为UDisk，提升稳定性，避免数据丢失；
• 将镜像源统一修改为UHub，避免镜像拉取失败的情况出现；
• 新增UK8S专属文件目录，用于配置监控controller-manager、schduler、etcd；
• 将执行文件按目录划分，便于修改及阅读。

yum install git -y
git clone --depth=1 -b kube-prometheus https://github.com/ucloud/uk8s-demo.git

3、修改UK8S专属文件配置参数

在manifests目录下有UK8S目录，这批配置文件主要用于为UK8S中的controller-manager、schduler、etcd手动创建endpoints和svc，便于Prometheus Server通过ServiceMonitor来采集这三个组件的监控数据。

cd /uk8s-demo/manifests/uk8s
# 修改以下两个文件，将其中的IP替换为你自己UK8S Master节点的内网IP
vi controllerManagerAndScheduler_ep.yaml
vi etcd_ep.yaml

4、 备注

上面提到要修改controllerManagerAndScheduler_ep.yaml和etcd_ep.yaml这两个文件，这里解释下原因。
由于UK8S的ETCD、Scheduler、Controller-Manager都是通过二进制部署的，为了能通过配置"ServiceMonitor"实现Metrics的抓取，我们必须要为其在K8S中创建一个SVC对象，但由于这三个组件都不是Pod，因此我们需要手动为其创建Endpoints。

apiVersion: v1
kind: Endpoints
metadata:
  labels:
    k8s-app: etcd
  name: etcd
  namespace: kube-system
subsets:
- addresses:
  - ip: 10.7.35.44 # 替换成master节点的内网IP
    nodeName: etc-master2
  ports:
  - name: port
    port: 2379
    protocol: TCP
- addresses:
  - ip: 10.7.163.60 # 同上
    nodeName: etc-master1
  ports:
  - name: port
    port: 2379
    protocol: TCP
- addresses:
  - ip: 10.7.142.140 #同上
    nodeName: etc-master3
  ports:
  - name: port
    port: 2379
    protocol: TCP

5、部署Prometheus Operator

先创建一个名为monitor的NameSpace，Monitor创建成功后，直接部署Operator，Prometheus Operateor以Deployment的方式启动，并会创建前面提到的几个CRD对象。

# 创建Namespace
kubectl apply -f  00namespace-namespace.yaml
# 创建Secret，给到Prometheus Server抓取ETCD数据时使用
kubectl -n monitoring create secret generic etcd-certs --from-file=/etc/kubernetes/ssl/ca.pem --from-file=/etc/kubernetes/ssl/etcd.pem --from-file=/etc/kubernetes/ssl/etcd-key.pem
# 创建Operator
kubectl apply -f operator/
# 查看operator启动状态
kubectl get po -n monitoring
# 查看CRD
kubectl get crd -n monitoring

6、部署整套CRD

比较关键的有Prometheus Server、Grafana、 AlertManager、ServiceMonitor、Node-Exporter等，这些镜像已全部修改为UHub官方镜像，因此拉取速度相对比较快。

kubectl apply -f adapter/ 
kubectl apply -f alertmanager/ 
kubectl apply -f node-exporter/ 
kubectl apply -f kube-state-metrics/ 
kubectl apply -f grafana/ 
kubectl apply -f prometheus/ 
kubectl apply -f serviceMonitor/
kubectl apply -f uk8s/

我们可以通过以下命令来查看应用拉取状态。

kubectl -n monitoring get po

由于默认所有的SVC 类型均为ClusterIP，我们将其改为LoadBalancer，方便演示。

 kubectl edit svc/prometheus-k8s -n monitoring
# 修改为type: LoadBalancer
[root@10-9-52-233 manifests]# kubectl get svc -n monitoring
# 获取到Prometheus Server的EXTERNAL-IP及端口

可以看到，所有K8S组件的监控指标均已获取到。

7、监控应用指标

我们先来部署一组Pod及SVC，该镜像里的主进程会在8080端口上输出metrics信息。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-app
        image: uhub.service.ucloud.cn/uk8s_public/instrumented_app:latest
        ports:
        - name: web
          containerPort: 8080
---
kind: Service
apiVersion: v1
metadata:
  name: example-app
  labels:
    app: example-app
spec:
  selector:
    app: example-app
  ports:
  - name: web
    port: 8080

再创建一个ServiceMonitor来告诉prometheus server需要监控带有label为app: example-app的svc背后的一组pod的metrics。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web

打开浏览器访问Prometheus Server，进入target发现已经监听起来了，对应的config里也有配置生成和导入。

8、说明

该文档只适用于kubernetes 1.14以上的版本，如果你的kubernetes版本为1.14以下，可以使用release-0.1.

实时文档欢迎访问https://docs.ucloud.cn/uk8s/monitor/prometheus/README