腾讯云TKE-搭建prometheus监控（三）

原创

赵思晨

修改于 2020-11-09 14:35:25

5.1K1

修改于 2020-11-09 14:35:25

文章被收录于专栏：腾讯云容器专家服务的专栏腾讯云容器专家服务的专栏

文章《腾讯云TKE-搭建prometheus监控》基于prometheus，手把手教你如何在TKE上搭建全面的平台和业务监控，为业务保驾护航。这是系列文章的第三篇，前两篇链接如下：

腾讯云TKE-搭建prometheus监控（一）：在TKE上搭建prometheus、安装exporter和api server监控。

腾讯云TKE-搭建prometheus监控（二）：在TKE上搭建告警系统和图形监控界面。

本文主要介绍基于prometheus，手把手教你如何在TKE上使用telegraf和thanos。

一、什么是telegraf？为什么要用它？

Prometheus的生态中，Exporter扮演了重要的角色。对于“知名”应用程序，服务器或数据库，Prometheus官方提供了足够多的Exporters。这也是Prometheus监视目标的主要方式。

官方给出的插件有node_exporter、blackbox_exporter、mysqld_exporter、snmp_exporter等，第三方的插件有redis_exporter，cadvisor等。

当然当你需要监控的中间件或是数据库类型比较少的时候，并没有什么问题。

但是当你的监控系统扩展到一定规模的时候，你可能需要维护几百种exporter，数量甚至是到了几万个的时候，这时候你大多的精力浪费在维护和升级exporter，甚至是管理他们的部署。

此时，telegraf作为他们的集大成者就登场了。

什么是telegraf？

Telegraf是一种用Go语言编写的服务端采集，处理，聚合，输出metrics的组件。它由Influxdata开发，却不仅仅支持influxdb，Telegraf的输出很多，其中就包括了Prometheus。

设计目标是使插件系统的内存占用最小，以便社区中的开发人员可以轻松添加对收集指标的支持。

Telegraf是插件驱动的，具有4种不同的插件类型的概念：

输入插件从系统，服务或第三方API收集指标
处理器插件转换，修饰和过滤指标
聚合插件可创建聚合指标（例如，平均值，最小值，最大值，分位数等）
输出插件将指标写入各个目标

目前支持采集的数据源非常多，包括节点的各类基础指标，各类数据库、中间件的指标等。

具体可见链接：https://docs.influxdata.com/telegraf/v1.16/plugins/

使用Telegraf的好处

采用server端采集方式之后，运维将节省大量的维护工作，统一升级。
如果是场景更加丰富的话，Telegraf对接配置中心。相比更改诸多Exporter代码，简单很多。
Telegraf pipeline的架构，可以在processor这个环节，提前实现一下metrics的预聚合，可以很大程度上降低Prometheus的处理数据压力。

二、在TKE中安装telegraf

注意，由于要采集每个node上的数据，telegraf最好采用damonset形式运行。

和prometheus，telegraf启动也需要配置文件，用configmap存放telegraf.conf

yaml文件如下：

apiVersion: v1
data:
  telegraf.conf: |
    [global_tags]

    [agent]
      interval = "10s"
      round_interval = true
      metric_batch_size = 1000
      metric_buffer_limit = 10000
      collection_jitter = "0s"
      flush_interval = "10s"
      flush_jitter = "0s"
      precision = ""
      debug = false
      quiet = false
      logfile = ""
      hostname = ""
      omit_hostname = true

    [[outputs.prometheus_client]]
      listen = ":9273"

    [[inputs.cpu]]
      percpu = false
      totalcpu = true
      collect_cpu_time = true
      report_active = true
    [[inputs.disk]]
      ignore_fs = ["tmpfs","devtmpfs","devfs","overlay","aufs","squashfs"]
      fieldpass = ["free","inodes_free","used_percent"]
    [[inputs.diskio]]
    [[inputs.kernel]]
    [[inputs.mem]]
    [[inputs.processes]]
    [[inputs.procstat]]
      exe = "kubelet"
    [[inputs.swap]]
    [[inputs.system]]
    [[inputs.netstat]]
    [[inputs.net]]
    [[inputs.conntrack]]
      files = ["ip_conntrack_count","ip_conntrack_max",
               "nf_conntrack_count","nf_conntrack_max"]
      dirs = ["/proc/sys/net/ipv4/netfilter","/proc/sys/net/netfilter"]
kind: ConfigMap
metadata:
  annotations:
  name: telegraf-config
  namespace: grant-tcr-test

对其中的参数进行简单解释：

agent部分配置

interval：所有输入的默认数据收集间隔

round_interval: 采用轮询时间间隔。默认是使用interval里面的值进行轮询，比如interval = "10s",那采集时间将是:00, :10, :20, 等

metric_batch_size：输出数据大小最多为metric_batch_size度量。这控制Telegraf发送到输出插件的写入大小。

metric_buffer_limit：Telegraf将缓存metric_buffer_limit大小的每个输出的指标，并在成功写入时刷新此缓冲区。这应该是倍数，metric_batch_size不能少于2倍metric_batch_size。

collection_jitter：通过随机度量来对采集时间进行抖动。每个插件在采集数据之前将会有一个随机时间的休眠，但是这个时间应小于collection_jitter，这个设置是为了防止多个采集源数据同一时间都在队列

flush_interval：所有输出的默认数据刷新间隔。

debug：在调试模式下运行Telegraf。

quiet：以安静模式运行Telegraf（仅限错误消息）。

[[outputs.prometheus_client]]

设定暴露给prometheus的接口地址。比如9273表明是prometheus会去本地的9273拿telegraf收集的数据。

注意因此在prometheus的配置文件中，也需要加上这个job，这个后面会提到。

[[input.*]]：这些就是需要采集的指标了。里面有一些通用的

比如input.cpu

percpu = true：采集每个cpu的指标

totalcpu = true：采集总的cpu指标

input.disk

ignore_fs = ["tmpfs", "devtmpfs"]：通过文件系统类型来忽略一些挂载点，比如tmpfs

fieldpass = ["inodes*"]：#仅存储磁盘inode相关的度量值

telegraf的damonset yaml文件

apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
  labels:
    k8s-app: telegraf
    qcloud-app: telegraf
  name: telegraf
  namespace: grant-tcr-test
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: telegraf
      qcloud-app: telegraf
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: telegraf
        qcloud-app: telegraf
    spec:
      containers:
      - env:
        - name: PATH
          value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
        - name: TELEGRAF_VERSION
          value: 1.16.0
        image: ccr.ccs.tencentyun.com/grantzhao/my-telegraf:1.0
        imagePullPolicy: IfNotPresent
        name: telegraf
        resources:
          limits:
            cpu: 500m
            memory: 1Gi
          requests:
            cpu: 250m
            memory: 256Mi
        securityContext:
          privileged: false
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /etc/telegraf/telegraf.conf
          name: telegraf-config
          subPath: telegraf.conf
      dnsPolicy: ClusterFirst
      hostNetwork: true
      imagePullSecrets:
      - name: qcloudregistrykey
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - configMap:
          defaultMode: 420
          name: telegraf-config
        name: telegraf-config
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 25%
    type: RollingUpdate
status:
  currentNumberScheduled: 3
  desiredNumberScheduled: 3
  numberAvailable: 3
  numberMisscheduled: 0
  numberReady: 3
  observedGeneration: 2
  updatedNumberScheduled: 3

或者在tke页面上，新建damonset：

三、在promtheus中添加telegraf

需要在promtheus的配置文件中添加telegraf的job，配置如下：

      - job_name:       'influxdb-exporter'
        scrape_interval: 5s
        static_configs:
        - targets: ['172.16.32.15:9273','172.16.32.8:9273','172.16.32.16:9273']
          labels:
            group: 'production'

接着就可以在protheus的rules里找到telegraf：

然后在query可以找到指标：

四、什么是thanos？为什么要用它？

proometheus的目前存在几个问题。

1、单点故障

2、在面对多集群的时候，非常不友好。

3、在存储方面没有好的解决方案

thanos出现解决了这些问题。

准确的说 Thanos 只是监控套件，与原生 Prometheus 结合，满足了长期存储 + 无限拓展 + 全局视图 + 无侵入性的需求。

五、在promtheus基础上运行thanos

thanos 是无侵入的，只是上层套件，因此还是需要部署我们的 Prometheus。但对于prometheus的配置，还需要做如下改动：

这些参数作为args传入到pod中。

"./prometheus
--config.file=prometheus.yml \
--log.level=info \
--storage.tsdb.path=data/prometheus \
--web.listen-address='0.0.0.0:9090' \
--storage.tsdb.max-block-duration=2h \
--storage.tsdb.min-block-duration=2h \
--storage.tsdb.wal-compression \
--storage.tsdb.retention.time=2h \
--web.enable-lifecycle"

web.enable-lifecycle一定要开，用于热加载时 reload 你的配置，retention 保留 2 小时，Prometheus 默认 2 小时会生成一个 block，Thanos 会把这个 block 上传到对象存储。

采集配置：prometheus.yml

global:
  scrape_interval:     60s
  evaluation_interval: 60s
  external_labels:
     region: 'A'
     replica: 0

rule_files:
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['0.0.0.0:9090']

  - job_name: 'demo-scrape'
    metrics_path: '/metrics'
    params:
    ...

这里需要声明 external_labels，标注你的地域。如果你是多副本运行，需要声明你的副本标识，如 0号，1，2 三个副本采集一模一样的数据，另外2个 Prometheus 就可以同时运行，只是 replica 值不同而已。这里的配置和官方的 Federation方案差不多。

对 Prometheus 的要求：

2.2.1 版本以上
声明你的 external_labels
启用 –web.enable-admin-api
启用 –web.enable-lifecycle

部署thanos，作为prometheus的sidecar。

Sidecar 组件与 Prometheus server 部署于同一个 pod 中。他有两个作用：

它使用 Prometheus 的 Remote Read API，实现了 Thanos 的 Store API。这使后面要介绍的Query 组件可以将 Prometheus 服务器视为时间序列数据的另一个来源，而无需直接与 Prometheus API交互（这就是 Sidecar 的拦截作用）
可选配置：在 Prometheus 每2小时生成一次 TSDB 块时，Sidecar 将 TSDB 块上载到对象存储桶中。这使得 Prometheus 服务器可以以较低的保留时间运行，同时使历史数据持久且可通过对象存储查询。

sidecar配置：

./thanos sidecar \
--Prometheus.url="http://localhost:8090" \
--objstore.config-file=./conf/bos.yaml \
--tsdb.path=/home/work/opdir/monitor/Prometheus/data/Prometheus/
"

配置很简单，只需要声明 Prometheus.url 和数据地址即可。

objstore.config-file 是可选项。如果你要把数据存放在对象存储（这也是推荐做法），就配置下对象存储的账号信息。

也可以选腾讯云的cbs存储。--tsdb.path=/data/prometheus

部署store gateway组件

在上面的 sidecar 配置中，如果你配置了对象存储 objstore.config-file或者cbs存储，你的数据就会定时上传到 bucket 中，本地只留 2 小时，那么要想查询 2 小时前的数据怎么办呢？数据不被 Prometheus 控制了，应该如何从 bucket 中拿回来，并提供一模一样的查询呢？

Store gateway 组件：store gateway 主要与对象存储交互，从对象存储获取已经持久化的数据。与sidecar一样，store gateway也实现了 store api，query 组可以从 store gateway 查询历史数据。

配置如下：

./thanos store \
--data-dir=./thanos-store-gateway/tmp/store \
--objstore.config-file=./thanos-store-gateway/conf/bos.yaml \
--http-address=0.0.0.0:19904 \
--grpc-address=0.0.0.0:19914 \
--index-cache-size=250MB \
--sync-block-duration=5m \
--min-time=-2w \
--max-time=-1h \

grpc-address 就是 store api 暴露的端口，也就是 query 中–store 是 xxx:19914的配置。

放个示意图，一个 Thanos 副本，挂了多个地域的 store 组件