Prometheus的配置与服务发现

本文将分析Prometheus的常见配置与服务发现,分为概述、配置详解、服务发现、常见场景四个部分进行讲解。

一. 概述

Prometheus的配置可以用命令行参数、或者配置文件,如果是在k8s集群内,一般配置在configmap中(以下均为prometheus2.7版本)

查看可用的命令行参数,可以执行 ./prometheus -h

也可以指定对应的配置文件,参数:--config.file 一般为prometheus.yml

如果配置有修改,如增添采集job,Prometheus可以重新加载它的配置。只需要向其 进程发送SIGHUP或向/-/reload端点发送HTTP POST请求。如:

curl -X POST http://localhost:9090/-/reload

二. 配置详解

2.1 命令行参数

执行./prometheus -h 可以看到各个参数的含义,例如:

--web.listen-address="0.0.0.0:9090"   监听端口默认为9090,可以修改只允许本机访问,或者为了安全起见,可以改变其端口号(默认的web服务没有鉴权)

--web.max-connections=512  默认最大连接数:512

--storage.tsdb.path="data/"  默认的存储路径:data目录下

--storage.tsdb.retention.time=15d  默认的数据保留时间:15天。原有的storage.tsdb.retention配置已经被废弃

--alertmanager.timeout=10s  把报警发送给alertmanager的超时限制 10s

--query.timeout=2m  查询超时时间限制默认为2min,超过自动被kill掉。可以结合grafana的限时配置如60s

--query.max-concurrency=20 并发查询数 prometheus的默认采集指标中有一项prometheus_engine_queries_concurrent_max可以拿到最大查询并发数及查询情况

--log.level=info 日志打印等级一共四种:[debug, info, warn, error],如果调试属性可以先改为debug等级

.....

在prometheus的页面上,status的Command-Line Flags中,可以看到当前配置,如promethues-operator的配置是:

2.2 prometheus.yml

从官方的download页下载的promethues二进制文件,会自带一份默认配置prometheus.yml

prometheus.yml配置了很多属性,包括远程存储、报警配置等很多内容,下面将对主要属性进行解释:

2.3 scrape_configs配置

prometheus的配置中,最常用的就是scrape_configs配置,比如添加新的监控项,修改原有监控项的地址频率等。

最简单配置为:

完整配置为(附prometheus-operator的推荐配置):

三. 服务发现

上边的配置文件中,有很多*_sd_configs的配置,如kubernetes_sd_configs,就是用于服务发现的采集配置。

支持的服务发现类型:

因为prometheus采用的是pull方式来拉取监控数据,这种方式需要由server侧决定采集的目标有哪些,即配置在scrape_configs中的各种job,pull方式的主要缺点就是无法动态感知新服务的加入,因此大多数监控都默认支持服务发现机制,自动发现集群中的新端点,并加入到配置中。

Prometheus支持多种服务发现机制:文件,DNS,Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂,通过第三方提供的接口,Prometheus查询到需要监控的Target列表,然后轮询这些Target获取监控数据。

对于kubernetes而言,Promethues通过与Kubernetes API交互,然后轮询资源端点。目前主要支持5种服务发现模式,分别是:Node、Service、Pod、Endpoints、Ingress。对应配置文件中的role: node/role:service

如:动态获取所有节点node的信息,可以添加如下配置:

就可以在target中看到具体内容

对应的service、pod也是同样的方式。

需要注意的是,为了能够让Prometheus能够访问收到Kubernetes API,我们要对Prometheus进行访问授权,即serviceaccount。否则就算配置了,也没有权限获取。

prometheus的权限配置是一组ClusterRole+ClusterRoleBinding+ServiceAccount,然后在deployment或statefulset中指定serviceaccount。

ClusterRole.yaml

ClusterRoleBinding.yaml

ServiceAccount.yaml

prometheus.yaml

完整的kubernete的配置如下:

配置成功后,对应的target是:

四. 常见场景

  • 1.获取集群中各节点信息,并按可用区或地域分类

如使用k8s的role:node采集集群中node的数据,可以通过"meta_domain_beta_kubernetes_io_zone"标签来获取到该节点的地域,该label为集群创建时为node打上的标记,kubectl decribe node可以看到。

然后可以通过relabel_configs定义新的值

后面可以直接通过node{zone="XX"}来进行地域筛选

  • 2.过滤信息,或者按照职能(RD、运维)进行监控管理

对于不同职能(开发、测试、运维)的人员可能只关心其中一部分的监控数据,他们可能各自部署的自己的Prometheus Server用于监控自己关心的指标数据,不必要的数据需要过滤掉,以免浪费资源,可以最类似配置;

action: drop代表丢弃掉符合条件的指标,不进行采集。

  • 3.搭建prometheus联邦集群,管理各IDC(地域)监控实例

    如果存在多个地域,每个地域又有很多节点或者集群,可以采用默认的联邦集群部署,每个地域部署自己的prometheus server实例,采集自己地域的数据。然后由统一的server采集所有地域数据,进行统一展示,并按照地域归类

配置:

Last updated