prometheus简介

一、prometheus简介

1.1 什么是prometheus

prometheus是一个最初在SoundCloud上构建的开源系统监控和警报工具包 。
从2012年开始，许多公司和组织开始使用Prometheus，该项目拥有非常活跃的开发人员和用户社区。
目前它是一个独立的开源项目，并且不依赖与任何公司。
为了强调这一点，并澄清项目的治理结构，Prometheus在2016年加入Cloud Native Computing Foundation，作为kubernetes之后的第二个托管项目。

1.2 主要特征

• 多维数据模型(时序列数据有metric和一组key/value组成)
• 在多维度上灵活的查询语言(PromQl)
• 不依赖分布式存储，单主节点工作.
• 可以通过pushgateway进行时序列数据推送(pushing)
• 可以通过服务发现或者静态配置去获取要采集的目标服务器
• 多种可视化图表及仪表盘支持

1.3 组件及架构

组件

prometheus生态系统由多个组件组成，其中许多组件是可选的。

• promethues server：主要获取和存储时间序列数据
• exporters：主要是作为agent收集数据发送到prometheus server，不同的数据收集由不同的exporters实现，如监控主机有node-exporters，mysql有MySQL server exporters。更多exporters
• pushgateway：允许短暂和批处理的jobs推送它们的数据到prometheus；由于这类工作的存在时间不够长，所以需要他们主动将数据推送到pushgateway，然后由pushgateway将数据发送的prometheus。
  总结：类似于zabbix proxy
• alertmanager：实现prometheus的告警功能。

架构

该图说明了Prometheus及其生态系统组件的一些架构

prometheus 直接或通过pushgateway抓取数据。将数据存储在本地，并对这些数据运行规则，以便从现有数据聚合和记录新时间序列，或者生成警报。grafana等可用于可视化数据。

二、安装server

2.1下载prometheus

下载最新版，然后解压它

# wget https://github.com/prometheus/prometheus/releases/download/v2.3.1/prometheus-2.3.1.linux-amd64.tar.gz
# tar xvfz prometheus-*.tar.gz
# cd prometheus-*

./prometheus --help使用该命令查看帮助

2.2 配置prometheus

配置文件为prometheus.yml，删除注释后配置文件如下

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']

该配置文件有三个模块：global、rule_files、scrape_configs
1. global：prometheus的全局配置，主要有两个属性

 scrape_interval：控制多久一次收集目标数据 ​ 
 evaluation_interval：评估规则时间间隔

2. rule_files

指定加载规则的位置 

3. scrape_configs

扫描二维码关注公众号，回复： 3274534 查看本文章

配置prometheus监视的数据。
默认的job prometheus监控着prometheus公开的数据，数据是通过url：http://localhost:9090/metrics 来抓取的。
返回的时间序列数据说明了prometheus server的状态信息。

2.3 运行prometheus

./prometheus --config.file=prometheus.yml

通过 http://ip:9090访问，现在页面上可以看到prometheus server的数据

可以通过http://ip:9090/metrics验证prometheus server是否提供自身数据

三、安装exporters

node exporter与prometheus server安装在同一台主机上

3.1 下载exporter

以node exporter为例，下载最新的node exporter

# wgethttps://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-0.16.0.linux-amd64.tar.gz
# tar xvfz node_exporter-*.tar.gz
# cd node_exporter-*

node exporter用户收集各种基于主机的度量。默认情况下，收集CPU、内存、磁盘等

3.2 启动 exporter

./node_exporter

Node Exporter的metrics使用主机的9100端口和/metrics路径。在本实例中的路径为：http://localhost:9100/metrics

3.3 配置监控

配置prometheus以监控主机

在prometheus server的配置文件prometheus.yml中增加如下job代码

- job_name: node
  static_configs:
    - targets: ['localhost:9100']   # 替换为监控主机的ip地址或域名

重启prometheus server

使用浏览器访问http://ip:9090，在界面的execute旁边的下拉列表中，可以看到node_开头的度量指标，这些就是node_exporter收集的数据。

一个有用的指标是up指标。该up度量标准可用于跟踪目标的状态。如果该度量标准具有值，1则目标的scrape成功，如果0失败。这可以帮助您指示目标的状态。

Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。主要监控：

• Node:如主机CPU，内存，网络吞吐和带宽占用，磁盘I/O和磁盘使用等指标。node-exporter采集。
• 容器关键指标:集群中容器的CPU详细状况，内存详细状况，Network，FileSystem和Subcontainer等。通过cadvisor采集。
• Kubernetes集群上部署的应用：监控部署在Kubernetes集群上的应用。主要是pod，service，ingress和endpoint。通过black-box和kube-apiserver的接口采集。

prometheus自身提供了一些资源的自动发现功能，下面是我从官方github上截图，罗列了目前提供的资源发现：

由上图可知prometheus自身提供了自动发现kubernetes的监控目标的功能。相应，配置文件官方也提供了一份，今天我们就解读一下该配置文件。

配置文件解读

首先直接上官方的配置文件：

# A scrape configuration for running Prometheus on a Kubernetes cluster.
# This uses separate scrape configs for cluster components (i.e. API server, node)
# and services to allow each to use different authentication configs.
#
# Kubernetes labels will be added as Prometheus labels on metrics via the
# `labelmap` relabeling action.
#
# If you are using Kubernetes 1.7.2 or earlier, please take note of the comments
# for the kubernetes-cadvisor job; you will need to edit or remove this job.

# Scrape config for API servers.
#
# Kubernetes exposes API servers as endpoints to the default/kubernetes
# service so this uses `endpoints` role and uses relabelling to only keep
# the endpoints associated with the default/kubernetes service using the
# default named port `https`. This works for single API server deployments as
# well as HA API server deployments.
scrape_configs:
- job_name: 'kubernetes-apiservers'

  kubernetes_sd_configs:
  - role: endpoints

  # Default to scraping over https. If required, just disable this or change to
  # `http`.
  scheme: https

  # This TLS & bearer token file config is used to connect to the actual scrape
  # endpoints for cluster components. This is separate to discovery auth
  # configuration because discovery & scraping are two separate concerns in
  # Prometheus. The discovery auth config is automatic if Prometheus runs inside
  # the cluster. Otherwise, more config options have to be provided within the
  # <kubernetes_sd_config>.
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    # If your node certificates are self-signed or use a different CA to the
    # master CA, then disable certificate verification below. Note that
    # certificate verification is an integral part of a secure infrastructure
    # so this should only be disabled in a controlled environment. You can
    # disable certificate verification by uncommenting the line below.
    #
    # insecure_skip_verify: true
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  # Keep only the default/kubernetes service endpoints for the https port. This
  # will add targets for each API server which Kubernetes adds an endpoint to
  # the default/kubernetes service.
  relabel_configs:
  - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
    action: keep
    regex: default;kubernetes;https

# Scrape config for nodes (kubelet).
#
# Rather than connecting directly to the node, the scrape is proxied though the
# Kubernetes apiserver.  This means it will work if Prometheus is running out of
# cluster, or can't connect to nodes for some other reason (e.g. because of
# firewalling).
- job_name: 'kubernetes-nodes'

  # Default to scraping over https. If required, just disable this or change to
  # `http`.
  scheme: https

  # This TLS & bearer token file config is used to connect to the actual scrape
  # endpoints for cluster components. This is separate to discovery auth
  # configuration because discovery & scraping are two separate concerns in
  # Prometheus. The discovery auth config is automatic if Prometheus runs inside
  # the cluster. Otherwise, more config options have to be provided within the
  # <kubernetes_sd_config>.
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  kubernetes_sd_configs:
  - role: node

  relabel_configs:
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+)
  - target_label: __address__
    replacement: kubernetes.default.svc:443
  - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics

# Scrape config for Kubelet cAdvisor.
#
# This is required for Kubernetes 1.7.3 and later, where cAdvisor metrics
# (those whose names begin with 'container_') have been removed from the
# Kubelet metrics endpoint.  This job scrapes the cAdvisor endpoint to
# retrieve those metrics.
#
# In Kubernetes 1.7.0-1.7.2, these metrics are only exposed on the cAdvisor
# HTTP endpoint; use "replacement: /api/v1/nodes/${1}:4194/proxy/metrics"
# in that case (and ensure cAdvisor's HTTP server hasn't been disabled with
# the --cadvisor-port=0 Kubelet flag).
#
# This job is not necessary and should be removed in Kubernetes 1.6 and
# earlier versions, or it will cause the metrics to be scraped twice.
- job_name: 'kubernetes-cadvisor'

  # Default to scraping over https. If required, just disable this or change to
  # `http`.
  scheme: https

  # This TLS & bearer token file config is used to connect to the actual scrape
  # endpoints for cluster components. This is separate to discovery auth
  # configuration because discovery & scraping are two separate concerns in
  # Prometheus. The discovery auth config is automatic if Prometheus runs inside
  # the cluster. Otherwise, more config options have to be provided within the
  # <kubernetes_sd_config>.
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  kubernetes_sd_configs:
  - role: node

  relabel_configs:
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+)
  - target_label: __address__
    replacement: kubernetes.default.svc:443
  - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

# Scrape config for service endpoints.
#
# The relabeling allows the actual service scrape endpoint to be configured
# via the following annotations:
#
# * `prometheus.io/scrape`: Only scrape services that have a value of `true`
# * `prometheus.io/scheme`: If the metrics endpoint is secured then you will need
# to set this to `https` & most likely set the `tls_config` of the scrape config.
# * `prometheus.io/path`: If the metrics path is not `/metrics` override this.
# * `prometheus.io/port`: If the metrics are exposed on a different port to the
# service then set this appropriately.
- job_name: 'kubernetes-service-endpoints'

  kubernetes_sd_configs:
  - role: endpoints

  relabel_configs:
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
    action: replace
    target_label: __scheme__
    regex: (https?)
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
    action: replace
    target_label: __address__
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
  - action: labelmap
    regex: __meta_kubernetes_service_label_(.+)
  - source_labels: [__meta_kubernetes_namespace]
    action: replace
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_service_name]
    action: replace
    target_label: kubernetes_name

# Example scrape config for probing services via the Blackbox Exporter.
#
# The relabeling allows the actual service scrape endpoint to be configured
# via the following annotations:
#
# * `prometheus.io/probe`: Only probe services that have a value of `true`
- job_name: 'kubernetes-services'

  metrics_path: /probe
  params:
    module: [http_2xx]

  kubernetes_sd_configs:
  - role: service

  relabel_configs:
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_probe]
    action: keep
    regex: true
  - source_labels: [__address__]
    target_label: __param_target
  - target_label: __address__
    replacement: blackbox-exporter.example.com:9115
  - source_labels: [__param_target]
    target_label: instance
  - action: labelmap
    regex: __meta_kubernetes_service_label_(.+)
  - source_labels: [__meta_kubernetes_namespace]
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_service_name]
    target_label: kubernetes_name

# Example scrape config for probing ingresses via the Blackbox Exporter.
#
# The relabeling allows the actual ingress scrape endpoint to be configured
# via the following annotations:
#
# * `prometheus.io/probe`: Only probe services that have a value of `true`
- job_name: 'kubernetes-ingresses'

  metrics_path: /probe
  params:
    module: [http_2xx]

  kubernetes_sd_configs:
    - role: ingress

  relabel_configs:
    - source_labels: [__meta_kubernetes_ingress_annotation_prometheus_io_probe]
      action: keep
      regex: true
    - source_labels: [__meta_kubernetes_ingress_scheme,__address__,__meta_kubernetes_ingress_path]
      regex: (.+);(.+);(.+)
      replacement: ${1}://${2}${3}
      target_label: __param_target
    - target_label: __address__
      replacement: blackbox-exporter.example.com:9115
    - source_labels: [__param_target]
      target_label: instance
    - action: labelmap
      regex: __meta_kubernetes_ingress_label_(.+)
    - source_labels: [__meta_kubernetes_namespace]
      target_label: kubernetes_namespace
    - source_labels: [__meta_kubernetes_ingress_name]
      target_label: kubernetes_name

# Example scrape config for pods
#
# The relabeling allows the actual pod scrape endpoint to be configured via the
# following annotations:
#
# * `prometheus.io/scrape`: Only scrape pods that have a value of `true`
# * `prometheus.io/path`: If the metrics path is not `/metrics` override this.
# * `prometheus.io/port`: Scrape the pod on the indicated port instead of the
# pod's declared ports (default is a port-free target if none are declared).
- job_name: 'kubernetes-pods'

  kubernetes_sd_configs:
  - role: pod

  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
    action: replace
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
    target_label: __address__
  - action: labelmap
    regex: __meta_kubernetes_pod_label_(.+)
  - source_labels: [__meta_kubernetes_namespace]
    action: replace
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_pod_name]
    action: replace
    target_label: kubernetes_pod_name

当然该配置文件，是在prometheus部署在k8s中生效的,即in-cluster模式。

kubernetes-apiservers

该项主要是让prometheus程序可以访问kube-apiserver，进而进行服务发现。看一下服务发现的代码可以看出，主要服务发现：node，service，ingress，pod。

    switch d.role {
    case "endpoints":
        var wg sync.WaitGroup

        for _, namespace := range namespaces {
            elw := cache.NewListWatchFromClient(rclient, "endpoints", namespace, nil)
            slw := cache.NewListWatchFromClient(rclient, "services", namespace, nil)
            plw := cache.NewListWatchFromClient(rclient, "pods", namespace, nil)
            eps := NewEndpoints(
                log.With(d.logger, "role", "endpoint"),
                cache.NewSharedInformer(slw, &apiv1.Service{}, resyncPeriod),
                cache.NewSharedInformer(elw, &apiv1.Endpoints{}, resyncPeriod),
                cache.NewSharedInformer(plw, &apiv1.Pod{}, resyncPeriod),
            )
            go eps.endpointsInf.Run(ctx.Done())
            go eps.serviceInf.Run(ctx.Done())
            go eps.podInf.Run(ctx.Done())

            for !eps.serviceInf.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            for !eps.endpointsInf.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            for !eps.podInf.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            wg.Add(1)
            go func() {
                defer wg.Done()
                eps.Run(ctx, ch)
            }()
        }
        wg.Wait()
    case "pod":
        var wg sync.WaitGroup
        for _, namespace := range namespaces {
            plw := cache.NewListWatchFromClient(rclient, "pods", namespace, nil)
            pod := NewPod(
                log.With(d.logger, "role", "pod"),
                cache.NewSharedInformer(plw, &apiv1.Pod{}, resyncPeriod),
            )
            go pod.informer.Run(ctx.Done())

            for !pod.informer.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            wg.Add(1)
            go func() {
                defer wg.Done()
                pod.Run(ctx, ch)
            }()
        }
        wg.Wait()
    case "service":
        var wg sync.WaitGroup
        for _, namespace := range namespaces {
            slw := cache.NewListWatchFromClient(rclient, "services", namespace, nil)
            svc := NewService(
                log.With(d.logger, "role", "service"),
                cache.NewSharedInformer(slw, &apiv1.Service{}, resyncPeriod),
            )
            go svc.informer.Run(ctx.Done())

            for !svc.informer.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            wg.Add(1)
            go func() {
                defer wg.Done()
                svc.Run(ctx, ch)
            }()
        }
        wg.Wait()
    case "ingress":
        var wg sync.WaitGroup
        for _, namespace := range namespaces {
            ilw := cache.NewListWatchFromClient(reclient, "ingresses", namespace, nil)
            ingress := NewIngress(
                log.With(d.logger, "role", "ingress"),
                cache.NewSharedInformer(ilw, &extensionsv1beta1.Ingress{}, resyncPeriod),
            )
            go ingress.informer.Run(ctx.Done())

            for !ingress.informer.HasSynced() {
                time.Sleep(100 * time.Millisecond)
            }
            wg.Add(1)
            go func() {
                defer wg.Done()
                ingress.Run(ctx, ch)
            }()
        }
        wg.Wait()
    case "node":
        nlw := cache.NewListWatchFromClient(rclient, "nodes", api.NamespaceAll, nil)
        node := NewNode(
            log.With(d.logger, "role", "node"),
            cache.NewSharedInformer(nlw, &apiv1.Node{}, resyncPeriod),
        )
        go node.informer.Run(ctx.Done())

        for !node.informer.HasSynced() {
            time.Sleep(100 * time.Millisecond)
        }
        node.Run(ctx, ch)

    default:
        level.Error(d.logger).Log("msg", "unknown Kubernetes discovery kind", "role", d.role)
    }   

kubernetes-nodes

发现node以后，通过/api/v1/nodes/${1}/proxy/metrics来获取node的metrics。

kubernetes-cadvisor

cadvisor已经被集成在kubelet中，所以发现了node就相当于发现了cadvisor。通过 /api/v1/nodes/${1}/proxy/metrics/cadvisor采集容器指标。

kubernetes-services和kubernetes-ingresses

该两种资源监控方式差不多，都是需要安装black-box，然后类似于探针去定时访问，根据返回的http状态码来判定service和ingress的服务可用性。
PS：不过我自己在这里和官方的稍微有点区别，

- target_label: __address__
      replacement: blackbox-exporter.example.com:9115

官方大致是需要我们要创建black-box 的ingress从外部访问，这样从效率和安全性都不是最合适的。所以我一般都是直接内部dns访问。如下

- target_label: __address__
      replacement: blackbox-exporter.kube-system:9115

当然看源码可以发现，并不是所有的service和ingress都会健康监测，如果需要将服务进行健康监测，那么你部署应用的yaml文件加一些注解。例如：
对于service和ingress：
需要加注解：prometheus.io/scrape: 'true'

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
  name: prometheus-node-exporter
  namespace: kube-system
  labels:
    app: prometheus
    component: node-exporter
spec:
  clusterIP: None
  ports:
    - name: prometheus-node-exporter
      port: 9100
      protocol: TCP
  selector:
    app: prometheus
    component: node-exporter
  type: ClusterIP

kubernetes-pods

对于pod的监测也是需要加注解：

• prometheus.io/scrape，为true则会将pod作为监控目标。
• prometheus.io/path，默认为/metrics
• prometheus.io/port , 端口

所以看到此处可以看出，该job并不是监控pod的指标，pod已经通过前面的cadvisor采集。此处是对pod中应用的监控。写过exporter的人应该对这个概念非常清楚。通俗讲，就是你pod中的应用提供了prometheus的监控功能，加上对应的注解，那么该应用的metrics会定时被采集走。

kubernetes-service-endpoints

对于服务的终端节点，也需要加注解：

• prometheus.io/scrape，为true则会将pod作为监控目标。
• prometheus.io/path，默认为/metrics
• prometheus.io/port , 端口
• prometheus.io/scheme 默认http，如果为了安全设置了https，此处需要改为https

这个基本上同上的。采集service-endpoints的metrics。

个人认为：如果某些部署应用只有pod没有service，那么这种情况只能在pod上加注解，通过kubernetes-pods采集metrics。如果有service，那么就无需在pod加注解了，直接在service上加即可。毕竟service-endpoints最终也会落到pod上。

总结

配置项总结

• kubernetes-service-endpoints和kubernetes-pods采集应用中metrics，当然并不是所有的都提供了metrics接口。
• kubernetes-ingresses 和kubernetes-services 健康监测服务和ingress健康的状态
• kubernetes-cadvisor 和 kubernetes-nodes，通过发现node，监控node 和容器的cpu等指标

自动发现源码

参考client-go和prometheus自动发现k8s，这种监听k8s集群中资源的变化，使用informer实现，不要轮询kube-apiserver接口。