查看原文
其他

Categraf - 夜莺监控发布新轮子

GoCN 2022-09-09

The following article is from 快猫Flashcat Author 秦晓辉UlricQin

简介

Categraf 是夜莺监控的默认数据采集 Agent,主打开箱即用和all-in-one,同时支持对metrics、log、trace 的收集,由夜莺监控核心开发团队开发。


Categraf的代码托管在两个地方:

  • 中国计算学会确实开源平台:

      • https://www.gitlink.org.cn/flashcat/categraf 

  • Github:

      • https://github.com/flashcatcloud/categraf


对比

categraf和telegraf、exporters、grafana-agent、datadog-agent 有什么异同?


telegraf 是 influxdb 生态的产品,因为 influxdb 是支持字符串数据的,所以 telegraf 采集的很多 field 是字符串类型;另外 influxdb 的设计,允许 labels 是非稳态结构,比如 result_code 标签,有时其 value 是 0,有时其 value 是 1,在 influxdb 中都可以接受而在 prometheus 中不能很好支持;第三,telegraf从根本上缺乏对于service discovery 和 relabel 的支持。 这些都导致 telegraf 与 prometheus 生态的兼容性不佳。


prometheus 生态有各种 exporters,但是设计逻辑都是一个监控类型一个 exporter,甚至一个实例一个 exporter,生产环境可能会部署特别多的 exporters,管理起来略麻烦。同时社区维护的很多exporter数据采集质量参差不齐,缺乏治理,给后续使用带来了很大的不便。


grafana-agent import 了大量 exporters 的代码,没有裁剪,没有优化,没有最佳实践在产品上的落地,有些中间件,仍然是一个 grafana-agent 一个目标实例,管理起来也很不方便。


datadog-agent确实是集大成者,但是大量代码是 python 的,整个发布包也比较大,有不少历史包袱,而且生态上是自成一派,和社区相对割裂。


Categraf 确实又是一个轮子,目标:

  • 采用 all-in-one 的设计,所有的采集工作使用一个 agent 来解决,包括metrics、log 和 trace ,并从数据采集的源头建立起三者的关联关系,保障好数据的质量;
  • 开箱即用:针对常用的采集对象,在提供采集能力的同时,配套有默认的监控大盘和告警规则模板,用户可以直接导入并使用;
  • 知识沉淀,尽可能落地最佳实践,不需要采集的数据无需采集,针对可能会对时序库造成高基数的问题在采集侧做出处理;
  • 兼容prometheus生态,支持 remote_write 写入协议,支持将数据写入 promethues、M3DB、VictoriaMetrics、InfluxDB;
  • 指标数据只采集数值,不采集字符串,标签维持稳态结构;
  • 纯 Go 代码编写,静态编译依赖少,容易分发,易于安装;


Categraf 会作为快猫星云 SaaS 产品的重要组成部分,快猫星云技术团队也会投入研发力量,持续迭代。同时,欢迎更多的公司、更多研发人员参与共建,做成国内最开放、最好用的采集器。


安装


可以直接去 [categraf releases](https://www.gitlink.org.cn/flashcat/categraf/releases) 页面,下载编译好的二进制,也可自行编译,编译只需要一条命令:`go build` 当然,前提是机器上有 Go 环境。


如果是从老版本升级,也是建议大家查看 [categraf releases](https://www.gitlink.org.cn/flashcat/categraf/releases) 页面,每个版本改动了什么,升级时注意什么,都会在这里写清楚。


在目标机器部署,只需要 categraf 二进制、以及 conf 目录,conf 下有一个主配置文件:config.toml,定义机器名、全局采集频率、全局附加标签、remote write backend地址等;另外就是各种采集插件的配置目录,以input.打头,如果某个采集器 xx 不想启用,把 input.xx 改个其他前缀,比如 bak.input.xx,categraf 就会忽略这个采集器。


conf 目录下还提供了 categraf.service 文件样例,便于大家使用 systemd 托管 categraf。如果对 systemd 不熟悉,建议学习一下课程:


- [Linux进阶知识]( https://edu.51cto.com/course/31049.html )


测试

我们经常会需要测试某个采集器的行为,临时看一下这个采集器输出哪些监控指标,比如配置好了 `conf/input.mysql/mysql.toml` 想要看看采集了哪些 mysql 指标,可以执行命令:`./categraf --test --inputs mysql`


这个命令会去连接你配置的 mysql 实例,执行SQL收集输出,将输出的内容做格式转换,最终打印到 stdout,如果我们在 stdout 正常看到了 mysql 相关监控指标,则说明一切正常,否则就是哪里出了问题,大概率是 `conf/input.mysql/mysql.toml` 配置的有问题。


如果修改了某个采集器的配置,需要重启 categraf 或者给 categraf 进程发送HUP信号,发送HUP信号的命令,举例:`kill -HUP `pidof categraf``


另外,categraf 支持哪些命令行参数,可以通过 `./categraf --help` 查看。


插件说明


采集插件的代码,在代码的 inputs 目录,每个插件一个独立的目录,目录下是采集代码,以及相关的监控大盘JSON(如有)和告警规则JSON(如有),Linux相关的大盘和告警规则没有散在 cpu、mem、disk等采集器目录,而是一并放到了 system 目录下,方便使用。


插件的配置文件,放在conf目录,以input.打头,每个配置文件都有详尽的注释,如果整不明白,就直接去看 inputs 目录下的对应采集器的代码,Go 的代码非常易读,比如某个配置不知道是做什么的,去采集器代码里搜索相关配置项,很容易就可以找到答案。


配置说明


这里对 config.toml 的每项配置做出解释:

[global]# 启动的时候是否在stdout中打印配置内容print_configs = false# 机器名,作为本机的唯一标识,会为时序数据自动附加一个 agent_hostname=$hostname 的标签# hostname 配置如果为空,自动取本机的机器名# hostname 配置如果不为空,就使用用户配置的内容作为hostname# 用户配置的hostname字符串中,可以包含变量,目前支持两个变量,# $hostname 和 $ip,如果字符串中出现这两个变量,就会自动替换# $hostname 自动替换为本机机器名,$ip 自动替换为本机IP# 建议大家使用 --test 做一下测试,看看输出的内容是否符合预期hostname = ""# 是否忽略主机名的标签,如果设置为true,时序数据中就不会自动附加agent_hostname=$hostname 的标签omit_hostname = false# 时序数据的时间戳使用ms还是s,默认是ms,是因为remote write协议使用ms作为时间戳的单位precision = "ms"# 全局采集频率,15秒采集一次interval = 15
# 全局附加标签,一行一个,这些写的标签会自动附到时序数据上# [global.labels]# region = "shanghai"# env = "localhost"
# 发给后端的时序数据,会先被扔到 categraf 内存队列里,每个采集插件一个队列# chan_size 定义了队列最大长度# batch 是每次从队列中取多少条,发送给后端backend[writer_opt]# default: 2000batch = 2000# channel(as queue) sizechan_size = 10000
# 后端backend配置,在toml中 [[]] 表示数组,所以可以配置多个writer# 每个writer可以有不同的url,不同的basic auth信息[[writers]]url = "http://127.0.0.1:19000/prometheus/v1/write"# Basic auth usernamebasic_auth_user = ""# Basic auth passwordbasic_auth_pass = ""# timeout settings, unit: mstimeout = 5000dial_timeout = 2500max_idle_conns_per_host = 100


对于每个采集器的配置,不在这里一一赘述,只讲一些相对通用的配置项。


interval

每个插件的配置中,一开始通常都是 interval 配置,表示采集频率,如果这个配置注释掉了,就会复用 config.toml 中的采集频率,这个配置如果配置成数字,单位就是秒,如果配置成字符串,就要给出单位,比如:

interval = 60interval = "60s"interval = "1m"

上面三种写法,都表示采集频率是1分钟,如果是使用字符串,可以使用的单位有:


  • 秒:s

  • 分钟:m

  • 小时:h


instances

很多采集插件的配置中,都有 instances 配置段,用 `[[]]` 包住,说明是数组,即,可以出现多个 [[instances]] 配置段,比如 ping 监控的采集插件,想对4个IP做PING探测,可以按照下面的方式来配置:

[[instances]]targets = [ "www.baidu.com", "127.0.0.1", "10.4.5.6", "10.4.5.7"]

也可以下面这样子配置:

[[instances]]targets = [ "www.baidu.com", "127.0.0.1"]
[[instances]]targets = [ "10.4.5.6", "10.4.5.7"]


interval_times

instances 下面如果有 interval_times 配置,表示 interval 的倍数,比如ping监控,有些地址采集频率是15秒,有些可能想采集的别太频繁,比如30秒,那就可以把interval配置成15,把不需要频繁采集的那些instances的interval_times配置成2。


或者:把interval配置成5,需要15秒采集一次的那些instances的interval_times配置成3,需要30秒采集一次的那些instances的interval_times配置成6。


Labels

instances 下面的 labels 和 config.toml 中的 global.labels 的作用类似,只是生效范围不同,都是为时序数据附加标签,instances 下面的 labels 是附到对应的实例上,global.labels 是附到所有时序数据上。


工作计划

categraf 已经完成了一些常用的采集插件,还有很多需要继续开发,欢迎大家共建补充,已经完成的采集插件包括:

- [x] system

- [x] kernel

- [x] kernel_vmstat

- [x] linux_sysctl_fs

- [x] cpu

- [x] mem

- [x] net

- [x] netstat

- [x] disk

- [x] diskio

- [x] ntp

- [x] processes

- [x] exec

- [x] ping

- [x] http_response

- [x] net_response

- [x] procstat

- [x] mysql

- [x] redis

- [x] oracle

- [x] rabbitmq

- [x] prometheus

- [x] tomcat

- [x] nvidia_smi


部分采集器不但提供了采集能力,还提供了监控大盘的配置和告警规则的配置,将JSON导入夜莺就可以使用,至于有哪些插件提供了JSON配置,可以通过下面的方式找到:

[root@master01 categraf]# find inputs -name "*.json"inputs/redis/alerts.jsoninputs/redis/dashboard.jsoninputs/system/dashboard.jsoninputs/system/alerts-linux.jsoninputs/oracle/dashboard.jsoninputs/ping/alerts.jsoninputs/ping/dashboard.jsoninputs/ntp/alerts.jsoninputs/procstat/alerts.jsoninputs/mysql/alerts.jsoninputs/mysql/dashboard.jsoninputs/tomcat/dashboard.jsoninputs/rabbitmq/dashboard.jsoninputs/http_response/alerts.jsoninputs/http_response/dashboard.jsoninputs/net_response/alerts.jsoninputs/net_response/dashboard.json
继续开发中的包括:

- [ ] k8s solution

- [ ] nginx vts

- [ ] mongodb

- [ ] rocketmq

- [ ] activemq

- [ ] kafka

- [ ] elasticsearch

- [ ] prometheus discovery

- [ ] windows

- [ ] mssql

- [ ] iis

- [ ] weblogic

- [ ] was

- [ ] hadoop

- [ ] ad

- [ ] zookeeper

- [ ] statsd

- [ ] snmp

- [ ] ipmi

- [ ] smartctl

- [ ] logging

- [ ] trace


往期推荐



范型下,优雅的 Lodash 风


API设计中性能提升的10个建议‍


直播预约 | JetBrains 码上道:Go 语言的 netpoll 抽象与常见问题

想要了解Go更多内容,欢迎扫描下方👇 关注 公众号,回复关键词 [实战群]  ,就有机会进群和我们进行交流~

分享、在看与点赞,至少我要拥有一个叭~

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存