夜莺-Nightingale
夜莺V7
项目介绍 功能概览
部署升级 部署升级
数据接入 数据接入
告警管理 告警管理
数据查看 数据查看
功能介绍 功能介绍
API FAQ
夜莺V6
项目介绍 架构介绍
快速开始 快速开始
黄埔营
安装部署 安装部署
升级
采集器 采集器
使用手册 使用手册
API API
数据库表结构 数据库表结构
FAQ FAQ
开源生态
Prometheus
版权声明
第1章:天降奇兵 第1章:天降奇兵
第2章:探索PromQL 第2章:探索PromQL
第3章:Prometheus告警处理 第3章:Prometheus告警处理
第4章:Exporter详解 第4章:Exporter详解
第5章:数据与可视化 第5章:数据与可视化
第6章:集群与高可用 第6章:集群与高可用
第7章:Prometheus服务发现 第7章:Prometheus服务发现
第8章:监控Kubernetes 第8章:监控Kubernetes
第9章:Prometheus Operator 第9章:Prometheus Operator
参考资料

Telegraf调研笔记2:CPU、MEM、DISK、IO相关指标采集

Telegraf大家有了基本了解了,但是能否用好,未必喽,今天我着重调研了一下Telegraf对CPU、内存、硬盘相关指标的采集,大部分指标还算容易理解,硬盘IO相关的有点麻烦,好,下面开始介绍。

CPU

CPU相关的指标比较简单,配置也比较简单,在inputs.cpu这个section,具体如下:

# Read metrics about cpu usage
[[inputs.cpu]]
  ## Whether to report per-cpu stats or not
  percpu = true
  ## Whether to report total system cpu stats or not
  totalcpu = true
  ## If true, collect raw CPU time metrics
  collect_cpu_time = false
  ## If true, compute and report the sum of all non-idle CPU states
  report_active = false

percpu默认设置为true,表示每个core都采集,建议维持默认配置,totalcpu默认为true,表示采集整体情况,平时配置告警策略就靠这个呢,所以要维持默认配置true,collect_cpu_time表示采集cpu耗费的时间,因为已经采集了各种percent指标了,time相关的感觉没有必要,可以不用打开,维持false配置,report_active相当于要采集cpu使用率,但是默认是false,建议改成true,有些人还是习惯用util的视角看待cpu使用情况。

MEM

内存相关的指标更简单,默认配置里啥都没有,如下:

[[inputs.mem]]
  # no configuration

看来作者觉得内存相关的指标没啥需要配置的。具体采集的时候,就是把/proc/meminfo中的数据都拿出来解析上报了,就这样就好,没啥要改的,如果觉得有些指标不想上报,这里介绍给大家一个技巧,每个input插件下都可以配置一些通用的过滤规则,过滤field或者tag,比如这里我不想采集inactive这个指标,那可以这么配置:

# Read metrics about memory usage
[[inputs.mem]]
  # no configuration
  fielddrop = ["inactive"]

fielddrop就表示要干掉某些field,与之相反的是fieldpass,表示只保留哪些,而且支持通配符,假设我只想采集percent和total相关的指标,就可以用fieldpass+通配符来解决:

# Read metrics about memory usage
[[inputs.mem]]
  # no configuration
  fieldpass = ["*percent", "*total"]

这个例子可能不具备生产意义,主要是用于演示,大家了解即可。

DISK

这个采集插件主要是采集磁盘使用率相关的指标,配置如下:

# Read metrics about disk usage by mount point
[[inputs.disk]]
  ## By default stats will be gathered for all mount points.
  ## Set mount_points will restrict the stats to only the specified mount points.
  # mount_points = ["/"]

  ## Ignore mount points by filesystem type.
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

这个ignore_fs可以屏蔽掉一些不想采集的文件系统类型,很有价值,mount_points这个感觉用的会比较少,大部分情况是希望自动探测所有分区的,mount_points的作用注释说的很清楚了,不再赘述。

我们测试一下看看有哪些指标:

[root@10-255-0-34 telegraf-tmp]# ./usr/bin/telegraf --config etc/telegraf/telegraf.conf --test --input-filter disk
2021-11-06T10:29:05Z I! Starting Telegraf 1.20.2
> disk,device=vda1,fstype=xfs,host=10-255-0-34,mode=rw,path=/ free=34200436736i,inodes_free=20858317i,inodes_total=20970992i,inodes_used=112675i,total=42938118144i,used=8737681408i,used_percent=20.34947451282508 1636194546000000000

硬盘使用率重点关注的指标是used_percent和inodes_free,前者表示磁盘使用率,后者表示inode剩余量。

利用上面的例子再介绍一个技巧,上面例子中有个mode=rw的标签,如果这个标签我觉得没用想干掉,应该如何配置呢,用tagexclude,如下:

# Read metrics about disk usage by mount point
[[inputs.disk]]
  ## By default stats will be gathered for all mount points.
  ## Set mount_points will restrict the stats to only the specified mount points.
  # mount_points = ["/"]

  ## Ignore mount points by filesystem type.
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

  tagexclude = ["mode"]

上面的配置达到的效果,就是干掉了mode这个标签,相反的是taginclude,表示只保留某个标签,taginclude感觉场景较少,tagexclude场景应该较多。

DISKIO

截取部分配置如下:

# Read metrics about disk IO by device
[[inputs.diskio]]
  ## By default, telegraf will gather stats for all devices including
  ## disk partitions.
  ## Setting devices will restrict the stats to the specified devices.
  # devices = ["sda", "sdb", "vd*"]

devices这个字段后面可能会用到,大家最好有个印象。

硬盘IO相关的指标主要来自/proc/diskstats这个内核文件,每个字段都采集了,但是真正使用的话,其实不够用,与iostat的输出相比,少了不少内容,比如io.util、队列长度、read和write的await等,这些指标如何计算呢?

下面我们使用promql来输出这些指标,夜莺v5开始,后续版本都拥抱了Prometheus生态,所以无论是配置大盘还是告警规则,都支持promql,相关写法如下(今天刚调研这块,可能拿捏的不准,如有疏漏请读者帮忙指正):

IO使用率(iostat %util)

rate(diskio_io_time[1m])/10

diskio_io_time表示io占用的时间,单位是毫秒,rate之后,表示每秒有多少毫秒用于io,把毫秒换算成秒,即:

rate(diskio_io_time[1m])/1000

这个query表示每秒有多少零点几秒是用于io,即io的时间占比,比率一般用%单位,所以上面的值要再乘以100,即:

rate(diskio_io_time[1m])/1000*100

所以就相当于rate之后除以10即可。

队列长度(iostat avgqu-sz)

rate(diskio_weighted_io_time[1m])/1000

diskio_weighted_io_time中包含了backlog的时间,用于表示IO队列长度。

每个写请求平均耗费时间(iostat w_await)

rate(diskio_write_time[1m])/rate(diskio_writes[1m])

单位是ms

每个读请求平均耗费时间(iostat r_await)

rate(diskio_read_time[1m])/rate(diskio_reads[1m])

单位是ms

从上面IO相关的指标可以有感受了,如果我们无法控制采集侧(很多时候就是如此), 服务端就必须要支持QL能力!

如果有使用Telegraf+Prometheus的小伙伴可以在生产环境验证一下,对比一下iostat的输出,看看是否正确(值不会和iostat完全一致,采样数据差不多就行)。

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat