8、Prometheus集群

本文系朱政科《Prometheus云原生监控：运维与开发实战》学习笔记

联邦集群是比较难理解的知识点，需要下功夫才行。

前面章节学习过程中，Prometheus一直以单点形式提供服务，实际生产环境中，需要更多地考虑采集能力、存储能力、可靠性、可扩展性、健壮性、容错性等，这就需要采用Prometheus集群的方式。

Prometheus单点形式在生产环境中是不够稳妥的，但构建Prometheus集群所需投入以及维护集群节点间数据一致性成本较高，有很多挑战。

本章节将会围绕Prometheus集群的架构问题，讨论多种集群解决方案的理念、方法及优化手段，探究如何更好地构建具有扩展性、可靠性的Prometheus集群。

一、时间校对

1.1、前言

在部署Prometheus前，必须对服务器之间进行时钟同步，比如使用NTP服务器。这是因为Prometheus是基于时间序列的存储及监控系统，对系统时间的准确性要求非常高，必须保证服务器之间的时间保持实时同步。

在计算机世界里，时间准确性非常重要，比如金融系统、发射火箭飞船的科研系统，时间一旦有一点点的误差，都将导致不可想象的灾难。NTP用处就是来解决这个问题，NTP全称Network Time Protocol，用来同步网络中各主机的时间的协议，它可以令主机基于服务器或者其它来源的时钟源进行同步，可以提供高准度的时间校正（局域网中时间差小于1ms，互联网中几十毫秒），且可通过加密确认的方式来防止恶意的协议攻击。

更多关于NTP的概念可以自行搜索查阅，此处不再叙述。

Linux系统通常采用计算机元年1970-01-01 00:00:00开始计数的时间戳和BIOS记录的硬件时间来表示时间。Linux可以通过网络进行时间校正，最常见的网络校时方案就是使用NTP服务器，其采用的是UDP协议，监听于123端口，其连接状态可以使用ntpstat和ntpqp等进行查询。世界上有很多NTP服务器，几乎所有的基础设施服务商都会提供NTP服务，比如国内的阿里云NTP服务器。

Linux部署NTP服务器也比较简单，比如使用Chrony作为时间服务器。Chrony是一款开源软件，在RHEL 7+/CentOS 7+是自带的，其默认配置在/etc/chrony.conf，其它系统需要自行安装chrony。

Chrony由chronyd和chronyc两部分组成：

chronyd：守护进程，可调整内核中运行的系统时钟使其与时钟服务器同步。
chronyc：用户界面GUI，可监控chrony性能并进行多样化配置。

1.2、部署chrony服务器

本次实验系统环境：宿主机：Deepin 20.5，两台虚拟机：CentOS 7.9

可以参考阿里云官方文档来配置Chrony服务

1.2.1、修改时区

将两台新装的CentOS 7.9时区都校正一下

修改时区

# 设置时区为上海
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
# 同步硬件时钟
sudo hwclock -w

查看状态

timedatectl status

查询结果如下所示，已修改为上海时区，时间不准则一会通过chrony同步解决。

      Local time: 一 2022-05-30 02:55:38 CST
  Universal time: 日 2022-05-29 18:55:38 UTC
        RTC time: 日 2022-05-29 18:55:32
       Time zone: Asia/Shanghai (CST, +0800)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

1.2.2、安装chrony

因为两台虚拟机都是CentOS 7.9自带chrony不用安装，需要安装的是作为chrony服务器的宿主机。

sudo apt install chrony -y

1.2.3、配置chrony

配置非常简单，就是写写NTP服务器即可。

1.2.3.1、chrony服务器配置

sudo vim /etc/chrony/chrony.conf

参考配置如下：

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
#pool 2.debian.pool.ntp.org iburst
server ntp.aliyun.com  minpoll 4 maxpoll 10 iburst
server ntp1.aliyun.com  minpoll 4 maxpoll 10 iburst
server ntp2.aliyun.com  minpoll 4 maxpoll 10 iburst
server ntp.tencent.com  minpoll 4 maxpoll 10 iburst
server ntp1.tencent.com  minpoll 4 maxpoll 10 iburst

# 允许局域网中的主机同步时间
allow 192.168.69.0/24

1.2.3.2、chrony客户端配置

客户端配置更简单，只需要指向局域网中的chronyd服务器即可。

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
#pool 2.debian.pool.ntp.org iburst
server 192.168.69.1 iburst

1.2.4、放通防火墙规则

在三台服务器上都放通对应的防火墙规则，两台CentOS 7.9主机防火墙规则添加如下：

sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

1.2.5、启动chrony

三台主机上都启动chronyd

# 启动chronyd
sudo systemctl start chronyd
# 开机启动chronyd
sudo systemctl enable chronyd

此时再去看两台CentOS 7.9主机就可以看到时间已同步

二、常见HA集群方案

单点模式存在着单点故障后系统无法正常运转的情况，且随着监控规模的扩张，大量数据的读写也容易让单点模式响应变慢、过度消耗系统资源。因此，在实际生产环境汇总，有必要构建Prometheus高可用集群HA（High Available）。Prometheus有三种常见的HA架构，分别是：

简单HA
基本HA+远程存储
基本HA+远程存储+联邦集群

2.1、简单HA

如下图所示。Nginx是众所周知的一款轻量级的异步高并发的web应用，也可充当反向代理、负载均衡服务器，可以很好地为Prometheus集群提供负载均衡功能。Alertmanager是Prometheus官方提供的告警管理模块，监控各种资源时可以配置告警、预警等规则。

在这种简单的HA架构下，由于Prometheus pull模式的特性，我们只需要部署多套Prometheus server，并采集相同的target即可。图中两个Prometheus的配置是完全一致的，Nginx可以路由到任意一台，这样即使有一台发送故障无法提供服务，另一台也可以正常对外提供服务的。

但这种HA架构存在Prometheus server间数据一致性问题，因为Prometheus采用pull模式，即使多个实例采集的是相同的监控指标，也不能保证采集过来的数据就是一致的，实际可能还会有网络延迟等问题；而且这种方案中的数据丢失以后无法恢复，如何Prometheus server经常迁移或者动态扩展，这种架构显得灵活性差。因为没有远程存储，所以也不能长期保存海量数据。所以说，这种高可用方案仅适用规模不大且不需要长期保存监控数据的场景

总结：此方案在一致性、存储容灾、迁移、动态扩展、远程存储等方面均不足。

Prometheus简单HA

2.2、简单HA+远程存储

简单HA+远程存储在简单HA基础上增加了远程存储的方式，可以通过Prometheus自带的远程读写接口去对接诸如：InfluxDB、OpenTSDB、TDengine等远程存储。Prometheus存储以及查询时均为合并本地数据后再对数据进行远程处理，这就解决了简单HA架构存在的数据一致性、持久性、迁移性、扩展性等问题。简单HA+远程存储架构示意图如下图所示：

简单HA+远程存储

开启远程存储后，Prometheus所需内存可能会大幅提升。因为Prometheus的Commiter认为25%-35%内存占用是比较合理的，还有人建议将最大shard数量降到50来降低内存占用率。这也是因为远程存储往往需要先把WAL中的数据写完，一般来说WAL会保存大约2小时内产生的数据，所以会启动很多进程，因此需要对它进行一定程度的限制。

这种方式能满足大部分中小企业的需求，短期内数据可以从本地读取，长期的数据可以从远程存储汇总读取。因为有了远程存储，Prometheus服务器也可以很好地进行迁移，当Prometheus server发生宕机或数据丢失等情况时也可以快速进行恢复。

同样的，这个方案也有一定的缺陷，主要就是监控规模较大时，Prometheus有限的服务器节点在采集能力上有着明显的瓶颈。海量的数据，对于远程存储来说也有巨大的挑战。Prometheus使用远程存储会比本地存储占用更多的内存和CPU，此时可以通过减少Label和采集间隔来降低资源占用，或者加大Prometheus资源投入。

2.3、HA+远程存储+联邦集群

简述

HA+远程存储+联邦集群是在HA+远程存储的基础上进一步扩展而来，主要解决单台Prometheus无法处理大量的采集任务的问题。联邦集群可以将监控系统的采集任务以分治法的形式划分给不同的Prometheus实例分别进行处理，以实现功能分区，这种架构有益于水平扩展，甚至有点像微服务。

如图所示：

HA+远程存储+联邦集群

优点

此联邦集群的架构方式大大提高了单个Prometheus的采集能力和存储能力，图中最下层的Prometheus可以分别在不同的区域、机房进行数据采集，上级Prometheus作为联邦节点，负责定时从下级Prometheus节点获取数据并汇总。多个联邦节点大大保证了高可用性。需要注意的是。部分敏感报警尽量不要通过Global节点触发，毕竟从Shard节点到Global节点传输链路的稳定性会影响数据到达的效率，进而导致告警实效性降低。例如，服务的UpDown状态、API请求异常这类告警我们一般放在Shard节点进行。

缺点

此方案在降低单个Prometheus采集负载过大问题、通过联邦节点汇聚核心数据来降低本地存储压力、避免单点故障时都能体现出不错的优势，但是凡事有利必有弊！如下所示：

每个集群都需要部署一套独立的Prometheus，再通过Grafana之类的展示工具查看每个集群的资源，会造成缺少全局统一视图的问题。
配置越来越复杂
需要完整的数据备份方案、历史数据存储方案来保证监控存储的高可用性。
缺少对历史数据的降准、采样能力。
面对海量监控数据洪峰，也需要进行一系列的优化改造。
数据的一致性和正确性可能会降低。工作节点根据预设的间隔采集数据，而主节点要采集工作节点上的数据，这会导致到达主节点的结果出现延迟，并可能导致数据倾斜或告警延迟。
据统计，实际使用过程中联邦节点对采集点大约会有5%的额外内存开销，需要认证评估。

扩展

联邦集群可以实现Prometheus监控Prometheus，但需要遵循以下原则：

采用网格模式，即在同一个数据中心，每个Prometheus都可以监控其它的Prometheus。
采用上下级模式，上一级的Prometheus用来监控数据中心级别的Prometheus

那么，为了避免下级Prometheus的单点故障，可以部署多套Prometheus节点，但在效率上会降低，每个监控对象都会被重复采集，数据也会重复保存。

在联邦集群的主备架构中，通常采用keepalived来作为主备切换工具。Master节点获取各个采集节点的Prometheus的数据，Slave节点不去查询数据；如果Master节点发生故障，会关闭本机的keepalived，VIP会自动切换到Slave节点，同时去除Master节点中采集Target的相关设置，然后开启Slave节点中采集Target的相关设置。

此方案适用于中大型企业，尤其是单数据中心、大数据量的采集任务以及多数据中心的场景。针对这些问题，Improbable开源的Prometheus高可用解决方案Thanos更为精妙，后面会详细介绍。

知识拓展

近几年，随着微服务、容器化、云原生等新的概念涌入，企业的IT架构逐渐从物理服务器迁移到以虚拟机为主的IaaS和PaaS平台，也就是上云，这给监控系统带来越来越多的挑战和更高的要求。2019年淘宝“双十一”活动中，订单创建峰值高达54.5万笔/秒，单日数据处理量达到970PB，面对世界级流量洪峰，阿里巴巴展示了一份亮眼的云原生技术成果，阿里云上万个Kubernetes集群全球跨数据中心的可观测性就是基于Prometheus Federation（联邦）实现的。

如何在复杂的网络环境中高效、合理、安全、可扩展地采集各个数据中心的目标集群实时状态指标，是可观测性设计的关键与核心。阿里云的方案兼顾区域化数据中心、单元化集群范围内可观测性数据的收集，以及全局视图的可观测性和可视化。基于这种设计理念和客观需求，全球化可观测性必须使用多级联合方式，也就是边缘层的可观测性实现应下沉到需要观测的集群内部；中间层的可观测性用于在若干区域内实现监控数据的汇聚；中心层的可观测性应进行汇聚并形成全局化视图以及告警。

这样设计好处在于：

可以灵活地在每一级内进行扩展和调整。
在集群规模不断增长时，其它级别调整参数即可
层次结构清晰
网络结构简单
可以实现内网数据穿透到公网并汇聚

上述的架构设计理念是在全球范围内将各个数据中心的数据实时收集并聚合，实现全局视图查看和数据可视化、故障定位、告警通知等功能。针对每个集群，主要采集指标如下表所示：

指标	举例
OS指标	硬件资源（CPU、内存、磁盘）、网络吞吐
元集群和用户集群K8S Master指标	kube-apiserver、kube-controller-manager、kube-scheduler等
K8S组件	通过kubernetes-state-metrics、cadvisor等采集的K8S集群状态
etcd指标	etcd写磁盘时间、DB大小、Peer之间的吞吐量等

为合理将监控压力分担到多个层次的Prometheus并实现全局聚合，阿里云使用了联邦功能。在联邦集群中，每个数据中心部署的单独Prometheus都可用于采集当前数据中心的监控数据，并由一个中心的Prometheus负责聚合多个数据中心的监控数据。

基于联邦功能设计的全球监控架构图如下所示，包括监控体系、告警体系、展示体系。

阿里云全球监控架构图

站在从元集群监控向中心监控汇聚的角度看，监控体系呈现为树形结构，并可以分为3层：

边缘Prometheus：为了有效监控元集群K8S和用户集群K8S的指标，避免网络配置的复杂性，将Prometheus下沉到每个元集群内。
级联Prometheus：级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域，比如北京、上海、香港等。随着每个大区域内集群规模的增长，大区域可以拆分成多个新的大区域，并始终维持着每个大区域内有一个级联Prometheus，通过这种策略可以灵活扩展和演进架构。
中心Prometheus：中心Prometheus用于连接所有级联Prometheus，实现最终的数据聚合、全局视图和告警。为提供可靠性，中心Prometheus使用双活架构，也就是在不同可用区布置两个Prometheus中心节点，且都连接相同的下一级Prometheus。

Prometheus是一款优秀的开源监控系统在，除了阿里巴巴这样的巨型互联网公司之外，京东、宜信等主流的互联网公司也都在采用它作为监控系统。其中，阿里云采用联邦集群架构方案，京东采用以Thanos为主的架构方案，后面也会对此进行介绍。

2.4、联邦集群配置方式

针对三种集群方案的不同，可以梳理出下表：

架构方式	采集能力	数据持久化	水平扩展
简单HA	低	低	低
HA+远程存储	低	高	低
HA+远程存储+联邦集群	高	中(需要备份方案)	高

联邦集群比较适合用于公司业务规模大、团队分工明确、多机房、多服务、多层次等需要分组的场景，可通过联邦的形式分开单独采集数据，再让上层抓取单独的数据之后再做聚合和展示。

在Prometheus服务器中，federate(联邦)节点允许获取服务中被选中的时间序列的集合的值。至少一个match[]URL参数必须被指定为要暴露的序列，每个match[]变量需要被指定为一个不变的维度选择器，比如up或者{job="apiserver"}。如果有多个match[]参数，那么所有符合要求的时序数据的集合都会被选择。

从一个Prometheus服务器联邦到另一个Prometheus服务器，配置目标Prometheus服务器从源服务器的federate节点采集指标数据，同时使用honor_labels采集选项（不重写源Prometheus服务暴露的标签）并且传递需要的match[]参数。

如下所示的scrape_configs联邦了source-prometheus{1,2,3}:9090三台Prometheus服务器，上级Prometheus采集并汇总了它们暴露的所有带job="prometheus"标签的序列或名称中以job:开头的指标。

scrape_configs:
  - job_name: "federate"
    scrape_interval: 15s
    
    honor_labels: true
    metrics_path: "/metrics"  # 指标默认路径为 '/metrics'
    
    params:
      match[]:
        - "{job=linux_server}"
        - "{__name__=~'job:.*'}"

    # 静态配置
    static_configs:
    - targets:
    	- "source-prometheus-1:9090"
    	- "source-prometheus-2:9090"
    	- "source-prometheus-3:9090"]

为了有效减少不必要的时间序列，通过params参数可以指定仅采集某些时间序列的样本数据，具体请求如下所示：

curl "http://192.168.69.42:9090/federate?match[]={job%3D'prometheus'}&match[]={__name__%3D~'job%3A.*'}&match[]={__name__%3D~'node.*'}"

通过URL中的match[]参数，可以指定需要采集的时间序列。match[]必须是一个瞬时向量选择器，例如up或者{job="xxxxxx"}。配置多个match[]参数，用于获取多组时间序列的监控数据。

将honor_labels设置为true可确保当采集到的监控指标有冲突时，能够自动忽略冲突的序列；否则，Prometheus会自动将冲突的标签替换为exported_的形式。更多配置解释请参考配置文档！

2.5、功能分区配置方式

此处内容比较重要，因此多用笔墨描述。

当采集任务的target数量过于庞大时，简单联邦集群1台Prometheus server采集所有target可能无法有效处理，此时可以考虑继续在实例级别进行功能划分。

可以按照任务的不同实例进行划分，通过Prometheus的relabel功能，通过Hash取模的方式确保当前Prometheus只采集当前任务的一部分实例的监控指标。

以下配置意思为：假设有4台采集用的Prometheus server，那么以4作为系数对web这个job下的所有地址进行hash计算，并对每个地址添加临时标签__tmp_hash（__tmp开头都被视为临时标签而不会写入target，仅作为下个匹配的变量），其值为0-3（0 1 2 3共4）中的一个；接着下一个匹配但凡是__tmp_hash值为1的地址，都被该Prometheus采集。这样就实现了1台Prometheus server仅采集部分target的目标！

当然，配置文件也可以直接写死只采集哪些target，但仅适合没有用到consul等服务发现的时候。

global:
  external_labels:
    slave: 1  # 这是第二个备用服务，可防止备用服务器之间冲突
  scrape_configs:
    - job_name: web
      relabel_configs:
        - source_labels: [__address__]  # __address__代表所有地址
          modulus: 4  # 有几台作为采集用的Prometheus server就写几
          # __tmp开头皆为临时标签，不会写入target，仅传递给下个匹配作为变量
          target_label: __tmp_hash
          action: hashmod  # 匹配到的target处理方式为进行hash计算
        - source_labels: [__tmp_hash]
          regex: ^1$  # 但凡__tmp_hash值为1的都算匹配
          action: keep

通过当前数据中心的一个中心Prometheus Server将监控数据聚合到任务级别，配置如下所示：

scrape_configs:
  - job_name: slaves
    honor_labels: true
    metrics_path: /metrics
    params:
      match[]:
        - '{__name__=~"slave:.*"}'  # 请求所有备用服务器的时间序列
    static_configs:
      - targets:
          - "slave0:9090"
          - "slave1:9090"
          - "slave2:9090"
          - "slave3:9090"

2.6、K8S单点故障

为避免Prometheus单机出现单点故障而引发一连串问题，往往会采用集群的形式提供主备切换，以提高可靠性。故障切换的时长是主备切换的时间（如5-30秒）加上漂移到数据开始上报的时间（如15-60秒）。但是在利用K8S进行切换、POD漂移到另一个节点之后，之前节点存储在数据库的指标数据是无法被查询到的，尤其是双实例的情况下，因为多个节点的指标数据虽然存放在数据库中，但无法共享，这就是单点故障引发的POD漂移问题。

针对这种问题，首先要进行健康检查，当Prometheus出现故障时，通过K8S进行POD漂移。我们要第一时间确认POD漂移时间，通过对接到远程存储实现数据共享。默认情况下，Prometheus会将本地存储块的开始时间与查询时间区域的左边界（即开始时间）进行比较，如果本地存储块的时间比查询的左边界时间还要小，Prometheus会认为本地有数据，则不从远程存储读取。这种情况可以将read_recent选项设置为true，强制每次查询从数据库拉取。

还有一种轻量级的解决方式：通过NFS文件目录共享持久化数据。

三、Prometheus集群采集优化方案

对于简单的应用程序，如缓存几乎没有逻辑而且只做一件事，一般预期可达上百种指标数据。Prometheus中的Pushgateway组件，除了客户端库和依赖项提供的各种指标之外，通常会添加少量指标（大约120条时间序列）。对于具有许多活动部件的复杂应用程序，一般预期可达上千种指标数据，比如Prometheus Server本身就会公开大约七百种指标数据，具体数量取决于所使用的版本和功能。当应用程序暴露的指标内容过多时，比如上升到上万种指标数据，就很有可能出现指标过多的问题，从而引发其它问题。

Prometheus采集数据一个重要原则就是：尽早去除维度过高的坏指标。这意味着，并不是业务方所有的指标都可以直接放入Label。可以通过如下告警规则找出维度（时序条数）过高的"坏指标"，然后在scrape配置里用metric_relabel_config的drop操作删除掉有问题的label（比如userID、email这些一看就有问题）

# 统计每个指标的时间序列数，超过10000就告警。
count by (__name__)({__name__=~".+"}) > 10000

3.1、Cardinality（基数）

3.1.1、概述

在以Prometheus为代表的指标监控系统中，有一个很重要的概念：Cardinality（基数），它代表Label的可能取值。监控指标同样遵循二八原则，即80%的指标对开发者来说并不重要，而剩下的20%的指标的异常往往会导致监控系统的崩溃，因此合理设置监控指标非常重要。每新增一个Label值就等于在存储时多存一条时间序列，所以Label过多会对存储造成压力，另一方面在聚合时也会影响计算性能。正常来说，单实例的Cardinality基数值应该在10以内。像email地址、用户地址、IP地址、HTTP path等都不适合作为Label，因为海量的请求会导致存储中产生大量的时间序列。

举个例子，如果在网关上对HTTP path进行埋点[^收集用户行为数据]，那么大量的HTTP请求可能会导致Prometheus相关的系统变得缓慢甚至宕机。因此，除了减少基数的数量，还需要避免使用任何因其标签值而使metrics的基数可能超过10的度量标准。因为如果一个指标都已经增长到10个，那么一年后可能会达到15个。

所以说，对于被监控的系统，一定要重点关注最需要关注的20个以内的指标。如果你有高Cardinality基数需求，推荐使用log日志的架构方案。

千万不要对所有指标都进行采集，因为这一定会对系统造成很大影响。

3.1.2、各应用指标统计

像之前介绍的一样，阿里巴巴全球可观察性Prometheus针对每个集群，对主要采集的指标进行梳理，以及kubernetes集群上的Spring boot的微服务指标进行梳理后，得到以下表格，分别是：

Prometheus联邦集群的指标
Prometheus自身信息，这些指标对于排查线上环境的Prometheus内部问题很有帮助
kubernetes集群的指标
M3DB的指标
微服务的指标

Prometheus联邦集群

Prometheus联邦集群架构下每个集群采集的指标

指标	举例
OS指标	节点资源（CPU、内存、磁盘）及网络吞吐
元集群以及用户集群K8S Master指标	kube-apiserver、kube-controller-manager、kube-scheduler等
K8S组件	kubernetes-state-metrics、cadvisor等关于集群状态的指标
etcd组件	etcd写磁盘时间、数据库大小、Peer之间吞吐量等

Prometheus自身信息

指标	说明即数量
Go自身的信息	如GC信息、汇总信息、线程信息，大约有30个指标。
网络追踪模块的信息	与net_conntrack相关的，大约有6个。
Prometheus自身指标	up关键指标，1个
	TSDB相关指标，约62个，默认14天，线上3集群，目前调整为7天
	自动发现相关指标，约50个。
	rule规则相关指标，约14个。
	scrape及up相关指标，约4个。
	notify和alert相关指标，约11个。
	HTTP相关指标，约6个
	engine和metrics相关指标，约11个

kubernetes集群指标

指标	数量
apiserver指标	约45个（admission/audit/request/response/storage）
container指标	约57个（cpu/file/fs/memory/network/spec）
coredns指标	约27个
etcd指标	约7个
node指标	约300个(cpu/disk/file/load/memory/netstat/network/nfs/socketstat/timex/vmstat)
kube指标	约120个(configmap/daemonset/deployment/endpoint/ingress/job/namespace/nod/pod/persistentvolumeclaim/secret/service/statefulset/cgroup/container/docker/http_request/metwork_plugin/pleg/runtime/volume)

M3DB指标

指标	说明及数量
coordinator	约50个，协调上游系统和M3DB之间的读写操作，长期存储其它监控系统的多DC（数据库集群）设置

微服务指标

指标	说明及数量
JVM信息&Tomcat	约40个
业务指标	业务自定制

3.1.3、指标优化推荐

关于指标采集优化，可以考虑先在scrape_configs里面的relabel_configs先配置过滤掉某个类别的指标采集，然后在远程存储时write_relabel_configs里面具体到仅保留某个类别的某些指标。

比如，go_.*但凡是go开头的指标都不采集，这就可以直接在Relabeling阶段处理；node_memory开头有很多指标，里面有我们需要的指标，所以不能在Relabeling阶段把它剔除，只能在存储阶段仅存储我们需要的几个字段，如node_memory_MemTotal_bytes等几个字段，其它node_memory均不作保留。

上面几个表所示的指标比较多，但并不代表我们都需要采集，因为对Prometheus服务器来说压力会太大。某些指标是否有必要采集，技术人员应当根据自身业务场景和需求进行分析。

降低采集指标的数量，是对Prometheus集群部署时进行的最佳优化，可以大大减少Prometheus相关服务器的数量，节约成本。以下是推荐配置和不推荐配置的指标：

不建议配置

已被占用或保留的标签

instance：实例信息标签
prometheus prometheus：数据源标签
job prometheus：采集数据的任务名
kubernetes_namespace：K8S的命名空间
cluster：集群信息标签

建议配置

某些指标的特定标签（不可被使用）

group：分组信息标签
type：服务类型标签

3.1.5、sample_limit

当出现一些PromQL强烈不推荐的做法，比如带有用户ID或电子邮件地址的标签添加到指标中时，就会产生由于大量指标而导致的Prometheus性能问题。为防止应用程序指标在基数上过多，可以使用sample_limit参数。sample_limit属于prometheus.yml中scrape_configs配置模块，默认是禁用的，作用是返回的时间序列数量超过给定的数量将导致采集失败，即丢弃。如下所示：

scrape_configs:
  - job_name: "prometheus"
    scrape_interval: 15s
    sample_limit: 1000

    honor_labels: true
    metrics_path: /metrics  # 指标默认路径为 '/metrics'

    static_configs:
            - targets: ["localhost:9090", "localhost:9100"]

上述配置代表采集阈值，以防止基数的突然增加。如果开启了sample_limit功能，有两个指标可以用来分析处理基数问题，它们分别为：

scrape_samples_scraped：采集的样本数
scrape_samples_post_metric_relabeling：重新标记后剩下的样本数，与sample_limit一致。

四、如何推广Prometheus

要想在企业中从零开始推广Prometheus，首先需要得到企业的认可，参与团队主要有研发团队、运维团队、测试团队。每个团队需要合理分工、紧密配合，按照时间点、里程碑拿结果。以下通过一个中大型企业接入Prometheus的案例，来给读者展示这项工作该如何推进。

4.1、研发团队

研发团队分三部分

4.1.1、中间件团队

中间件团队分工如下所示：

实现并完成接入文档“Prometheus支持Spring Boot 1.5.x”
实现并完成接入文档“Prometheus支持Spring Boot 2.x”
实现并完成接入文档“Prometheus支持micrometer-jvm-extras”
实现并完成含监控告警方法的文档“基于Prometheus搭建Spring Cloud全方位立体监控体系”，其中主要包含Spring Boot代码的接入方式、可视化大盘的配置方式、告警的设置方式等。
梳理需要监控的中间件在全公司上线的标配，如Dubbo、DB、MQ、Redis等信息。
大数据架构，梳理Flink、ClickHouse、Presto、HBASE等技术接入Prometheus监控的文档。
梳理可以高配的中间件监控可选列表（含exporter），方便应用上线使用。
针对公司核心系统，定制相应的exporter。

如上所示，中间件团队的职责是跟着业务走，以结果为导向，相应业务团队的有序推进是其最终目标。可以以订单支付团队的应用为开端，再辅以三四个业务项目进行首批接入

4.1.2、业务团队

订单支付团队开发人员与测试人员一起梳理订单、支付需要埋点的核心场景，如实时订单曲线（商户维度、店铺维度、设备维度）、实时订单支付成功曲线（同前面的三维度）、累计待支付订单曲线（同前三维度）告警，以及个别商户累计待支付订单数达到5笔。
用于订单支付的Spring boot应用接入Prometheus、micrometer-jvm-extras，并配置好Grafana JVM监控大盘。
订单、支付业务场景按照规范配置好Prometheus埋点（含HTTP和RPC接入方式）
测试订单支付主流程上线
对于其它可以配合测试的业务应用，可像订单支付一样梳理业务指标，接入Prometheus并配置监控大盘及告警，按照项目时间点上线。

4.2、运维团队

运维团队的工作包括环境搭建、数据治理、监控告警及优化工作等。

4.2.1、搭建环境

Prometheus交叉HA集群
Prometheus远程存储M3DB
Prometheus高可用联邦集群/Thanos二选一
Prometheus监控告警，ALertmanager高可用集群
除Grafana监控告警外，Prometheus自身还要支持邮件与钉钉告警。
Prometheus支持基于K8S的服务发现
ALertmanager支持HA，通过deadman’s switch方式定义一条永远会触发的告警，即其可不断发出通知，假如哪天这条通知停了，那么说明告警链路出问题了。
多个环境pro/test/pre数据标签分组隔离（订单、支付为主）

4.2.2、数据治理

采集时就过滤掉K8S不重要指标（labelkeep或labeldrop），在生产过程中很多指标都是可以省去的，譬如K8S中的Sandbox容器的指标。
与中间件团队一起制定基于K8S指标的采集规范和采集需求
梳理和安装运维监控标配软件（如node_exporter采集主机数据）
通过Relabeling获取target默认标签数据等方式做运维专属数据监控大盘

4.2.3、监控告警

运维人员配合业务人员按需对Grafana告警和业务告警进行相关配置
Prometheus告警和运维告警，需要使用分组、抑制、静默等手段避免集群告警轰炸的出现，节点的告警可以抑制因节点崩溃而导致的一系列系统、中间件告警问题。
绘制K8S指标的Prometheus监控大盘

4.2.4、其它优化

Prometheus operator管理Prometheus（rancher自带）
Prometheus占用内存过大，45万个指标大概要占用8GB内存，故经常出现Prometheus容器OOM[^Linux系统因进程占用内存过高被内核强制杀死]，数据指标如果确实比较大可以考虑Prometheus的散列分集来分摊压力。
安装Prometheus Pushgateway（如Flink接入必须安装Pushgateway）

4.3、使用K8S推进上线

Prometheus和kubernetes是密不可分的，推广Prometheus的工作实际上可以借助K8S进行。

在企业云环境中应用K8S时，公司一般会给各个部门制定进度表，分批、有序安排相关工作。这时运维部门可以提前准备好Prometheus环境，中间件部门可以准备好通用的监控软件和接入文档。对于试点业务项目，可以优先配置并上线定制化大盘；对于其它没有特定需求的项目，可以先完成针对基本中间件、系统等指标的采集，等待后续业务方有特定需求后再协助指导搭建业务并定制Grafana监控大盘。

五、简单HA+远程存储集群

本节要介绍的是一个简单的可以支持上百个微服务的Prometheus集群结构，基于M3DB的简单HA
+远程存储Prometheus的K8S集群。

5.1、架构说明

目标环境为K8S环境，每个K8S环境中都伴有一个Prometheus集群，由一个外部Prometheus系统通过Federate（联邦）采集Prometheus数据，并将数据写入远程TSDB数据库：M3DB。通过外部Grafana系统查询Prometheus数据，ALertmanager采用gossip协议部署高可用双节点，Pushgateway负责接收端节点的exporter数据。

此架构瓶颈在于外部Prometheus出现资源不足时，会造成数据采集异常；M3DB的coordinator io资源不足时容易造成数据读写堵塞。目前可以优化的是，Prometheus的K8S集群采用operator方式，利用K8S sidecar模式，将Prometheus的数据写入时序数据库，这将会大大减少单点故障的影响，并且Thanos支持更多的功能特性，后面会介绍。

简单K8S下Prometheus集群架构

下面是一种简单的K8S下基于Thanos的Prometheus集群架构

简单的K8S下基于Thanos的Prometheus集群架构

5.2、K8S内部Prometheus

因本人还没学过K8S，故此无法提供案例，待后续补充。

在这种架构下，K8S内部自带的Prometheus集群和K8S外部搭建的Prometheus集群会进行联邦。

如果采用的是rancher，那么K8S的Prometheus集群都可以通过rancher的应用商店下载官方配置文件。需要注意的是：Prometheus端口可以通过nodeport或者ingress的方式暴露出来，在此可以假设域名为prom01.domain.com和prom02.domian.com（后续外部Prometheus federate会用到）。考虑到安全性，可以用basic-auth等方式对端口/域名进行访问加密。

5.3、K8S外部Prometheus

外部Prometheus可以采用docker-compose方式部署，docker-compose.yml配置参考如下：

version: "3"
services:
  prom:
    image: prom/prometheus:v2.14.0
    hostname: prom.domain.com
    container_name: prometheus
    restart: always
    volumes:
      - /opt/prometheus.yml:/etc/prometheus/prometheus.yml
      - /opt/rules.yml:/etc/prometheus/rules.yml
      - /opt/rules:/etc/prometheus/rules
      - /opt/prometheus:/prometheus
    environment:
      - STORAGE.TSDB.RETENTION=7d  # 本地TSDB数据保留7天
    posts:
      - 9090:9090

  alertmanager01:
    image: prom/alertmanager:v0.19.0
    hostname: alert1.domain.com
    container_name: alertmanager01
    restart: always
    volumes:
      - /opt/alertmanager.yml:/etc/alertmanager/config.yml
    command:
      - "--web.listen-address=:9093"
      - "--cluster.listen-address=0.0.0.0:8001"  # 开启gossip协议
      - "--config.file=/etc/alertmanager/config.yml"
    ports:
      - 9093:9093
      - 8001:8001

  alertmanager02:
    image: prom/alertmanager:v0.19.0
    hostname: alert2.domain.com
    container_name: alertmanager02
    restart: always
    depends_on:
      - alertmanager01
    volumes:
      - /opt/alertmanager.yml:/etc/alertmanager/config.yml
    command:
      - "--web.listen-address=:9094"
      - "--cluster.listen-address=0.0.0.0:8002"
      - "--cluster.peer=172.16.18.6:8001"  # Slave需要指向主节点
      - "--config.file=/etc/alertmanager/config.yml"
    ports:
      - 9094:9094
      - 8002:8002
  
  pushgateway:
    image: prom/pushgateway:v1.0.0
    container_name: pushgateway
    restart: always
    ports:
      - 9091:9091
        
  grafana:
    image: grafana/grafana:6.4.4
    hostname: grafana.domain.com
    container_name: grafana
    restart: always
    volumes:
      - /opt/grafana-storage:/var/lib/grafana
    ports:
      - 3000:3000
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=xxx
      - GF_SMTP_ENABLE=true
      - GF_SMTP_HOST=smtp.qq.com:465
      - GF_SMTP_USER=xxx
      - GF_SMTP_PASSWORD=xxx
      - GF_SMTP_FROM_ADDRESS=xxx
      - GF_SERVER_ROOT_URL=http://grafana.domain.com

prometheus.yml配置参考如下：

global:
  scrape_interval: 60s  # pushgateway采集间隔
  evaluation_interval: 30s  # 规则计算频率
  external_labels:
    cid: "1"

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            ["172.16.18.6::9093", "172.16.18.6:9094"]  # alertmanager主从节点

rule_files:
  - /etc/prometheus/rules.yml
  - /etc/prometheus/rules/*.rules

remote_write:
  - url: "http://172.16.10.12:7201/api/v1/prom/remote/write"  # M3DB远程写
    queue_config:
      batch_send_deadline: 60s
      capacity: 40000
      max_backoff: 600ms
      max_samples_per_send: 8000
      max_shards: 6
      remote_timeout: 30s
    write_relabel_configs:  # 可按实际需求仅保留某个类别中需要的指标，其余全部不存储。
      - source_labels: [__name__]
        regex: go_.*
        action: drop
      - source_labels: [__name__]
        regex: http_.*
        action: drop
      - source_labels: [__name__]
        regex: prometheus_.*
        action: drop
      - source_labels: [__name__]
        regex: scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: net_.*
        action: drop
      - source_labels: ["kubernetes_name"]
        regex: prometheus-node-Exporter
        action: drop
      - source_labels: [__name__]
        regex: rpc_.*
        action: drop
      - source_labels: [__name__]
        regex: jvm_.*
        action: keep
      - source_labels: [__name__]
        regex: crd.*
        action: drop
      - source_labels: [__name__]
        regex: kube_.*
        action: drop
      - source_labels: [__name__]
        regex: etcd_.*
        action: drop
      - source_labels: [__name__]
        regex: coredns_.*
        action: drop
      - source_labels: [__name__]
        regex: apiserver_.*
        action: drop
      - source_labels: [__name__]
        regex: admission_.*
        action: drop
      - source_labels: [__name__]
        regex: DiscoveryController_.*
        action: drop
      - source_labels: [__name__]
        regex: kubernetes-apiservers
        action: drop
      - source_labels: [__name__]
        regex: container_.*
        action: drop

remote_read:
  - url: "http://172.16.7.172:7201/api/v1/prom/remote/read"  # M3DB远程读
      read_recent: true  # 强制每次查询从数据库读取最新的数据

scrape_configs:
  # 基于consul的服务发现
  # - job_name: "consul-prometheus"
  #  metrics_path: /metrics
  #  scheme: http
  #  consul_sd_configs:
  #    - server: "172.16.18.6:8500"
  #      scheme: http
  #      services: ['ops']
  #      refresh_interval: 1m

  # 基于文件的服务发现
  - job_name: "file_ds"
    file_sd_configs:
      - refresh_interval: 30s
        files:
          - /prometheus/*.json
  - job_name: "federate"
    scrape_interval: 15s
    honor_labels: true
    metrics_path: "/metrics"  # 可自定义路径
    params:
      "match[]":
        - "{job=~kubernetes-.*}"
    static_configs:
      - targets:
          - "prom-01.domain.com"  # K8S的prometheus域名或ip:port
          - "prom-02.domain.com"
      basic_auth:
        username: xxx
        password: xxxma
    static_configs:
      - targets: ["192.168.69.1:9100"]
      relabel_configs:  # relabel_configs阶段仅剔除可以完全不要的类别的指标
        - source_labels: [__name__]
          regex: prometheus_.*
          action: drop
        - source_labels: [__name__]
          regex: scrape_.*
          action: drop
        - source_labels: [__name__]
          regex: node_scrape_.*
          action: drop
        - source_labels: [__name__]
          regex: go_.*
          action: drop
        - source_labels: [__name__]
          regex: node_hwmon_.*
          action: drop
        - source_labels: [__name__]
          regex: node_softnet_.*
          action: drop
        - source_labels: [__name__]
          regex: node_power_.*
          action: drop
        - source_labels: [__name__]
          regex: node_schedstat_.*
          action: drop
        - source_labels: [__name__]
          regex: node_cooling_.*
          action: drop

alertmanager.yml配置参考如下：

参考第五章节的8.3小节中关于告警推送至企业微信的配置即可

rule.yml配置参考如下：

参考第五章节的8.3小节中关于告警推送至企业微信的配置即可

5.4、Tdengine

原文作者是推荐使用M3DB的，从上面提到这么多次就可以得知，但是Tdengine是国产自研的时序数据库，除了情怀，它也很轻量、高效、简单。

待续

六、Prometheus即服务Cortex

除了原文作者推荐的M3DB与本人推荐的Tdengine，Prometheus在集群上还有一些竞品方案，比如Prometheus+influxDB、Prometheus+Thanos、多副本全局视图的Timbala以及本节将要介绍的Cortex等。

Prometheus官方本身没有提供成熟的服务平台，例如多租户、身份验证、授权以及内置的长期存储。2018年9月，Cortex作为沙箱项目加入CNCF，这是一个开源的Prometheus即服务平台，提供完整、安全、多租户的Prometheus体验。

6.1、Cortex特点

在2018年的kubecon大会上，有人提到，可不直接运行Prometheus，而是结合使用Cortex，这么做的原因有以下几点：

支持多租户作为服务的Cortex可提供鉴权和访问控制等功能。Prometheus本身没有租户的概念，这意味着它无法对特定租户的数据访问和资源使用配额等提供任何形式的比较细的颗粒度控制。但通过Cortex将所有Prometheus指标与特定租户相关联，实现资源按租户进行隔离。从本质上将，每个租户都有自己的系统“视图”或者说“监控大盘”，其自身以Prometheus为中心。如果以单租户的方式使用Cortex，租户群可以随时扩展到无限大。
数据永久保留，状态可管理。Cortex支持4种开箱即用的长期存储系统：
- AWS DynamoDB
- AWS S3
- Apache Cassandra
- Google cloud bigtable
通过Prometheus远程写入API将采集到的数据持久化存储到Cortex中，从而实现跨节点复制和自动修复等功能。
高可用、伸缩性。通过服务实例的水平扩展、联邦集群等方式最大化利用Prometheus。
提供更好的查询效率及全局视图，尤其是长查询。通过自身的长期存储，极大方便了通过PromQL用于分析，从而实现了时间序列数据的单一而且一致的“全局”视图。

Cortex具有基于服务的设计功能，其基本功能多有单个用户的组件组成，每个组件都可以独立扩展和管理，这是Cortex实现可扩展性和高可运营性的关键。Cortex各组件功能如下所示：

Distributor：使用Prometheus的远程写入功能将采集到的数据写入Cortex，传入的数据会自动复制和分片，并且会并行发送到多个Cortex Ingester
Ingester：从Distributor节点接收时间序列数据，然后将该数据写入长期存储后端，压缩数据到Prometheus块以提高效率。
Ruler：执行规则并生成告警，将警报发送到ALertmanager（Cortex安装包中包含ALertmanager）。
Querier：处理来自客户端（包括Grafana仪表盘）的PromQL查询，对短期时间序列数据和长期存储中的样本进行抽象。

在实际生产中，可考虑使用如下的部署架构实现Cortex的水平自适应扩展，如下所示：

图片来源于网络

Cortex水平自适应扩展架构图

上图中，若要实现高可用，Cortex可以通过集群的方式部署多个Prometheus实例，每个Prometheus可以采集某类指标，从而实现横向扩展的目的。随着节点规模的增加，可以增加Prometheus的实例数量。Cortex底层通过consul实现数据的一致性，即一个实例写入，每个实例均可以查询；如果其中一个实例异常，其它实例不受影响。不同Prometheus实例将同样目标的数据上报给Cortex，然后Cortex进行去重等操作，Grafana等可视化系统也可直接对接Cortex进行数据读取。集群中的Cortex可以实现数据的共享，任意一个Cortex实例都可以查询到其它Cortex写入的数据。

6.2、Cortex存储引擎

Cortex主要支持两个存储引擎来存储和查询时间序列：

Chunks：大块存储，也是默认的存储引擎，比较稳定。
Blocks：块存储，试验性，此方式类似于HDFS中的Block存储。

针对第一项，Cortex对Chunks数据和Index数据支持的数据库类型如下表所示：

数据库类型	Index类型	Chunks数据
Inmemory	√	√
AWS	√	√
S3	√	√
gcp	√	√
gcp-columnkey	√	√
bigtable	√	√
bigtable-hashed	√	√
gcs		√
cassandra	√	√
filesystem	×	√
bolthdb	√	×

在使用Cortex时要注意其性能问题，Cortex会在本地创建大量文件，而后续3.0版本的Prometheus将不再这么做。如果数据量很大，系统的iNode会存在耗尽的可能性。通常来说，Cortex单节点默认每秒能接收25000个指标，并发量大的时候会回收超出的指标，可以通过修改ingestion_rate默认值的方式增加指标接收量。

七、Prometheus联邦集群部署

宿主机操作系统：Deepin 20.6（Debian）；IP地址：192.168.179.1

虚拟机2台，其IP地址分别为：192.168.179.42、192.168.179.43

根据上面的理论学习后，需要来进行一次演练巩固所学知识，实验环境主机信息如下表所示：

名称	IP地址	端口	说明
Prometheus Server中心节点	192.168.179.1	9090	聚合联邦节点数据
Prometheus Server联邦节点1	192.168.179.42	9090	负责采集目标数据
Prometheus Server联邦节点2	192.168.179.43	9090	负责采集目标数据
Tdengine集群主节点	192.168.179.1	6030
Tdengine集群从节点1	192.168.179.42	6030
Tdengine集群从节点2	192.168.179.43	6030
Tdengine taosadapter服务	192.168.179.1	6041	直接启动即可
Tdengine taosadapter服务	192.168.179.42	6041	直接启动即可
Tdengine taosadapter服务	192.168.179.43	6041	直接启动即可

本次集群部署架构为：Prometheus联邦集群+远程存储（Tdengine集群）+ALertmanager集群，如下图所示：

7.1、Tdengine集群部署

集群部署参考自TDengine官方文档：https://www.taosdata.com/cn/documentation/cluster

Prometheus接入参考自TDengine官方文档：https://docs.taosdata.com/third-party/prometheus

Tdengine是国人自研的时序数据库，轻量、高效、快速。

Tdengine依赖hostname解析，所以必须提前配置好hosts文件，Linux的hosts文件位于/etc/hosts。

7.1.1、端口说明

需要申请开通TDengine服务器之间6020，6030-6042端口的TCP/UDP访问权限

协议	默认端口	用途说明	修改方法
TCP	6030	客户端与服务端之间通讯。	由配置文件设置 serverPort 决定。
TCP	6035	多节点集群的节点间通讯。	随 serverPort 端口变化。
TCP	6040	多节点集群的节点间数据同步。	随 serverPort 端口变化。
TCP	6041	客户端与服务端之间的 RESTful 通讯。	随 serverPort 端口变化。
TCP	6042	Arbitrator 的服务端口。	随 Arbitrator 启动参数设置变化。
TCP	6043	TaosKeeper 监控服务端口。	随 TaosKeeper 启动参数设置变化。
TCP	6044	支持 StatsD 的数据接入端口。	随 taosadapter 启动参数设置变化（2.3.0.1+以上版本）。
TCP	6045	支持 collectd 数据接入端口。	随 taosadapter 启动参数设置变化（2.3.0.1+以上版本）。
TCP	6060	企业版内 Monitor 服务的网络端口。
UDP	6030-6034	客户端与服务端之间通讯。	随 serverPort 端口变化。
UDP	6035-6039	多节点集群的节点间通讯。	随 serverPort 端口变化。

7.1.2、下载安装

本文以2.6.0.6为例

7.1.2.1、下载

自行去涛思数据官网下载安装包

7.1.2.2、解压

tar -zxf TDengine-server-2.6.0.0-Linux-x64.tar.gz

7.1.2.3、安装

执行安装脚本后，会自动解压taos.tar.gz并将其安装至/usr/local/，同时自动开机启动taosd服务，出现下面的添加节点时，第一次则直接回车创建新集群。

cd TDengine-server-2.6.0.6
sudo bash install.sh 
# 应该会打印类似下面的信息
验证成功
 osinfo: Deepin 20.6
Deepin
apricot
 This is an officially unverified linux system,
 if there are any problems with the installation and operation, 
 please feel free to contact taosdata.com for support.
Start to install TDengine...
Created symlink /etc/systemd/system/multi-user.target.wants/taosd.service → /etc/systemd/system/taosd.service.

System hostname is: sanxi-PC

Enter FQDN:port (like h1.taosdata.com:6030) of an existing TDengine cluster node to join
OR leave it blank to build one:

Enter your email address for priority support or enter empty to skip: 

To configure TDengine : edit /etc/taos/taos.cfg
To configure taosadapter (if has) : edit /etc/taos/taosadapter.toml
To start TDengine     : sudo systemctl start taosd
To access TDengine    : taos -h sanxi-PC to login into TDengine server

TDengine is installed successfully!

7.1.3、集群配置

提前配置好名称解析，可以参照官方文档，其实就是做好/etc/hosts名称解析的配置，配置好集群所有节点的名称解析，确保网络通信无问题。

7.1.3.1、修改配置

修改配置文件/etc/taos/taos.cfg，只有两处是必改的，即firstEp与fqdn，其它看需求。

firstEp必须全部节点保持一致，即选择一台机器当主节点，比如我选择sanxi-PC作为集群主节点，那么其它从节点的firstEp必须是sanxi-PC:6030

fqdn，完全限定域名，即填各节点自身的hostname。

以下为从节点test1的配置示意：

# first fully qualified domain name (FQDN) for TDengine system
firstEp                   sanxi-PC:6030

# local fully qualified domain name (FQDN)
fqdn                      test1
# 三个数据库副本，节点数必须大于等于副本数
replica						3

7.1.3.2、启动服务

7.1.3.2.1、启动taosadapte

TDengine 集群和应用程序之间的桥梁和适配器。它提供了一种易于使用和高效的方式来直接从数据收集代理软件（如 Telegraf、StatsD、collectd 等）摄取数据。它还提供了 InfluxDB/OpenTSDB 兼容的数据摄取接口，允许 InfluxDB/OpenTSDB 应用程序无缝移植到 TDengine。

注意：taosadapter必须在taosd启动前启动，如果先启动taosd再启动taosadapter，则需要重启taosd。

# 集群中所有节点都要启动taosadapter
systemctl start taosadapter

7.1.3.2.2、启动taosd

此为Tdengine主进程

注意，最好修改好配置文件后再启动服务，且必须先启动主节点，再启动别的节点，否则从节点加入集群也是显示离线状态。

# 启动所有节点的taosd
systemctl start taosd

7.1.3.3、查看节点

命令行键入taos进入taosd命令行界面

TDengine跟MySQL语法类似，也是在语句最后加分号。

SHOW DNODES，查看集群所有节点，此时因为还没配置集群，所以显示只有此主节点。

sanxi@sanxi-PC:/usr/local/taos/cfg$ taos

Welcome to the TDengine shell from Linux, Client Version:2.6.0.6
Copyright (c) 2022 by TAOS Data, Inc. All rights reserved.

taos> SHOW DNODES;
   id   |           end_point            | vnodes | cores  |   status   | role  |       create_time       |      offline reason      |
======================================================================================================================================
      1 | sanxi-PC:6030                  |      1 |     12 | ready      | any   | 2022-06-27 18:09:23.318 |                          |                     |
Query OK, 3 row(s) in set (0.001093s)

7.1.3.4、添加节点

CREATE DNODE，为集群添加新节点，语法为新节点主机名+端口（默认6030），添加完毕后再次使用SHOW DNODES;确认是否成功添加并处于ready状态。

也可以在从节点部署时，在执行install.sh进入交互式界面后根据提示键入主节点地址如sanxi-PC:6030可直接加入Tdengine集群。

taos> CREATE DNODE "test1:6030";
Query OK, 0 of 0 row(s) in database (0.001149s)

taos> CREATE DNODE "test2:6030";
Query OK, 0 of 0 row(s) in database (0.001267s)

taos> SHOW DNODES;
   id   |           end_point            | vnodes | cores  |   status   | role  |       create_time       |      offline reason      |
======================================================================================================================================
      1 | sanxi-PC:6030                  |      1 |     12 | ready      | any   | 2022-06-27 18:09:23.318 |                          |
      2 | test1:6030                     |      0 |      1 | ready      | any   | 2022-06-27 18:10:20.174 |                          |
      3 | test2:6030                     |      0 |      1 | ready      | any   | 2022-06-27 18:10:23.926 |                          |
Query OK, 3 row(s) in set (0.000788s)

7.1.3.5、故障处理

如果发现从节点加入集群后显示为offline离线状态，请检查名称解析配置是否无误且网络互通；更重要的是先停止所有节点的taosd服务，然后rm -rf /var/lib/taos/*，删除所有数据文件（即删库，谨慎操作！如果自定义了数据目录，就删除自动目录下的数据文件），再启动主节点然后启动从节点。

此时，问题应该就解决了。

7.1.3.6、创建用户

先在Tdengine创建一个Prometheus专用的用户作为安全验证，默认拥有写权限。

taos> CREATE USER prometheus PASS 'xxxxxx';
Query OK, 0 of 0 row(s) in database (0.003302s)

7.1.3.7、创建数据库

为Prometheus创建专用的数据库，后面Prometheus远程存储会用到。

taos> CREATE DATABASE prometheus_data;
Query OK, 0 of 0 row(s) in database (0.003627s)

7.2、Prometheus集群配置

Prometheus安装部署请参考第一篇博客《Grafana基础》

7.2.1、中心节点配置

上游Prometheus Server中心节点配置参考如下：

# 全局配置
global:
  scrape_interval: 1m  # 采集间隔，默认1分钟。
  evaluation_interval: 30s  # 告警检测时间，即多久检查一次是否达到告警的条件，默认1分钟。
  scrape_timeout: 5s  # 采集超时时间的间隔为10秒。

# 告警配置
alerting:
  alertmanagers:
    # 静态配置alertmanager地址，也可以使用服务动态识别。
    - static_configs:
        - targets:  # 可以有多个地址
          - localhost:9093
          - 192.168.179.42:9093
          - 192.168.179.43:9093

# prometheus自定义的规则主要有recording rule和alerting rule两类
rule_files:
  - "alert_rules.yml"
  - "rules/first_rules.yml"
  - "rules/first_alerts.yml"

scrape_configs:
  - job_name: "federate"
    scrape_interval: 1m
    honor_labels: true  # 保留冲突标签
    metrics_path: /metrics  # 指标默认路径为 '/metrics'
    # params这块配置是上游Prometheus Server专用配置，也是联邦集群的核心。
    params:
      'match[]':
        - '{job=linux_server}'
        - '{job=prometheus}'
        - '{__name__=~"job:.*"}'
        - '{__name__=~"node.*"}'

    # 静态配置
    static_configs:
    - targets:  # 中心节点采集下游Prometheus Server
        - '192.168.179.42:9090'
        - '192.168.179.43:9090'
        - '192.168.179.1:9090'  # 自身
    relabel_configs:  # 过滤掉部分不重要的指标，即不采集这部分。
      - source_labels: [__name__]
        regex: scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: node_scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: go_.*
        action: drop
      - source_labels: [__name__]
        regex: node_hwmon_.*
        action: drop
      - source_labels: [__name__]
        regex: node_softnet_.*
        action: drop
      - source_labels: [__name__]
        regex: node_power_.*
        action: drop
      - source_labels: [__name__]
        regex: node_schedstat_.*
        action: drop
      - source_labels: [__name__]
        regex: node_cooling_.*
        action: drop


remote_write:
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_write/prometheus_data"
    basic_auth:
      username: prometheus
      password: sanxi666.
    queue_config:
      batch_send_deadline: 60s
      capacity: 40000
      max_backoff: 600ms
      max_samples_per_send: 8000
      max_shards: 6
    write_relabel_configs:  # 可按实际需求仅保留某个类别中需要的指标，其余全部不存储。
      - source_labels: [__name__]
        regex: go_.*
        action: drop
      - source_labels: [__name__]
        regex: scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: node_scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: net_.*
        action: drop
      - source_labels: [__name__]
        regex: node_hwmon_.*
        action: drop
      - source_labels: [__name__]
        regex: node_softnet_.*
        action: drop
      - source_labels: [__name__]
        regex: node_power_.*
        action: drop
      - source_labels: [__name__]
        regex: node_schedstat_.*
        action: drop
      - source_labels: [__name__]
        regex: node_cooling_.*
        action: drop

remote_read:
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_read/prometheus_data"
    basic_auth:
      username: prometheus
      password: sanxi666.
    remote_timeout: 10s
    read_recent: true

7.2.2、采集节点配置

下游采集用的Prometheus Server有两台，配置一模一样，跟中心节点的配置差别就只有缺少parms和target不同。

global:
  scrape_interval: 1m # 采集间隔，默认1m。 
  evaluation_interval: 30s # 告警监测时间 
  scrape_timeout: 5s  # 采集超时时间 


alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - '192.168.179.1:9093'
          - '192.168.179.42:9093'
          - '192.168.179.43:9093'


rule_files:
  - "alert_rules.yml"
  - "rules/first_rules.yml"
  - "rules/first_alerts.yml"


scrape_configs:
  - job_name: "linux_server"
    scrape_interval: 1m
    metrics_path: "/metrics"  # metrics_path defaults to '/metrics'
    honor_labels: true 
    scheme: http   # scheme defaults to 'http'.

    static_configs:
    - targets: 
        - "192.168.179.1:9100"
    relabel_configs:
      - source_labels: [__name__]
        regex: prometheus_.*
        action: drop
      - source_labels: [__name__]
        regex: scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: node_scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: go_.*
        action: drop
      - source_labels: [__name__]
        regex: node_hwmon_.*
        action: drop
      - source_labels: [__name__]
        regex: node_softnet_.*
        action: drop
      - source_labels: [__name__]
        regex: node_power_.*
        action: drop
      - source_labels: [__name__]
        regex: node_schedstat_.*
        action: drop
      - source_labels: [__name__]
        regex: node_cooling_.*
        action: drop

remote_write:
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_write/prometheus_data"
    basic_auth:
      username: prometheus
      password: xxxxxx
    write_relabel_configs:
      - source_labels: [__name__]
        regex: prometheus_.*
        action: drop
      - source_labels: [__name__]
        regex: scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: node_scrape_.*
        action: drop
      - source_labels: [__name__]
        regex: go_.*
        action: drop
      - source_labels: [__name__]
        regex: node_hwmon_.*
        action: drop
      - source_labels: [__name__]
        regex: node_softnet_.*
        action: drop
      - source_labels: [__name__]
        regex: node_power_.*
        action: drop
      - source_labels: [__name__]
        regex: node_schedstat_.*
        action: drop
      - source_labels: [__name__]
        regex: node_cooling_.*
        action: drop

remote_read:
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_read/prometheus_data"
    basic_auth:
      username: prometheus
      password: xxxxxx
    remote_timeout: 10s  # 超时时间
    read_recent: true  # 强制每次读取数据都从数据库读取最新数据

7.2.3、接入Tdengine

修改所有节点的prometheus.yml配置，添加如下配置，然后重启或重载Prometheus使之生效即可！

指向运行 taosAdapter 服务的服务器域名或 IP 地址，REST 服务端口（taosAdapter 默认使用 6041），以及希望写入 TDengine 的数据库名称，并确保相应的 URL 形式如下：

remote_write:
  # prometheus_data为自定义数据库
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_write/prometheus_data"
    basic_auth:
      username: prometheus
      password: xxxxxx

remote_read:
  # prometheus_data为自定义数据库
  - url: "http://sanxi-PC:6041/prometheus/v1/remote_read/prometheus_data"
    basic_auth:
      username: prometheus
      password: xxxxxx
    remote_timeout: 10s
    read_recent: true