关于程序员:开源一款监控数据采集器啥都能监控

Categraf 是一个监控采集 Agent，相似 Telegraf、Grafana-Agent、Datadog-Agent，心愿对所有常见监控对象提供监控数据采集能力，采纳 All-in-one 的设计，岂但反对指标采集，也心愿反对日志和调用链路的数据采集。来自快猫研发团队，和 Open-Falcon、Nightingale 的研发是一拨人。

categraf 的代码托管在两个中央：

github：https://github.com/flashcatcl…
gitlink：https://www.gitlink.org.cn/fl…

categraf 和 telegraf、exporters、grafana-agent、datadog-agent 等的关系是什么？

telegraf 是 influxdb 生态的产品，因为 influxdb 是反对字符串数据的，所以 telegraf 采集的很多 field 是字符串类型，另外 influxdb 的设计，容许 labels 是非稳态构造，比方 result_code 标签，有时其 value 是 0，有时其 value 是 1，在 influxdb 中都能够承受。然而下面两点，在相似 prometheus 的时序库中，解决起来就很麻烦。

prometheus 生态有各种 exporters，然而设计逻辑都是一个监控类型一个 exporter，甚至一个实例一个 exporter，生产环境可能会部署特地多的 exporters，治理起来略麻烦。

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

datadog-agent 的确是集大成者，然而大量代码是 python 的，整个公布包也比拟大，有不少历史包袱，而且生态上是自成一派，和社区绝对割裂。

categraf 的确又是一个轮子，categraf 心愿：

反对 remote_write 写入协定，反对将数据写入 promethues、M3DB、VictoriaMetrics、InfluxDB
指标数据只采集数值，不采集字符串，标签维持稳态构造
采纳 all-in-one 的设计，所有的采集工作用一个 agent 搞定，将来也能够把日志和 trace 的采集纳入 agent
纯 Go 代码编写，动态编译依赖少，容易散发，易于装置
尽可能落地最佳实际，不须要采集的数据无需采集，针对可能会对时序库造成高基数的问题在采集侧做出解决
罕用的采集器，岂但提供采集能力，还要整顿出监控大盘和告警规定，用户能够间接导入应用
将来心愿作为快猫 SaaS 产品的重要组成部分，引入快猫团队的研发力量继续迭代，当然，心愿更多的公司、更多人研发人员参加共建，做成国内最凋谢、最好用的采集器

能够间接去 categraf releases 页面，下载编译好的二进制，也可自行编译，编译只须要一条命令：go build 当然，前提是机器上有 Go 环境。

如果是从老版本升级，也是倡议大家查看 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 进阶常识

咱们常常会须要测试某个采集器的行为，长期看一下这个采集器输入哪些监控指标，比方配置好了 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: 2000
batch = 2000
# channel(as queue) size
chan_size = 10000

# 后端 backend 配置，在 toml 中 [[]] 示意数组，所以能够配置多个 writer
# 每个 writer 能够有不同的 url，不同的 basic auth 信息
[[writers]]
url = "http://127.0.0.1:19000/prometheus/v1/write"

# Basic auth username
basic_auth_user = ""

# Basic auth password
basic_auth_pass = ""

# timeout settings, unit: ms
timeout = 5000
dial_timeout = 2500
max_idle_conns_per_host = 100

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

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

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

下面三种写法，都示意采集频率是 1 分钟，如果是应用字符串，能够应用的单位有：

秒：s
分钟：m
小时：h

很多采集插件的配置中，都有 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"
]

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

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.json
inputs/redis/dashboard.json
inputs/system/dashboard.json
inputs/system/alerts-linux.json
inputs/oracle/dashboard.json
inputs/ping/alerts.json
inputs/ping/dashboard.json
inputs/ntp/alerts.json
inputs/procstat/alerts.json
inputs/mysql/alerts.json
inputs/mysql/dashboard.json
inputs/tomcat/dashboard.json
inputs/rabbitmq/dashboard.json
inputs/http_response/alerts.json
inputs/http_response/dashboard.json
inputs/net_response/alerts.json
inputs/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

如果还有问题，能够到 FAQ 中查找，咱们会继续补充 FAQ 的内容，如果想加交换群，能够加我的微信：UlricGO 备注：Categraf 加群 + 姓名 + 公司

本文由 mdnice 多平台公布

关于程序员:开源一款监控数据采集器啥都能监控

简介

比照

装置

测试

插件阐明

配置阐明

interval

instances

interval_times

labels

工作打算

更多信息