Categraf是一个监控采集Agent，类似Telegraf、Grafana-Agent、Datadog-Agent，希望对所有常见监控对象提供监控数据采集能力，采用All-in-one的设计，不但支持指标采集，也希望支持日志和调用链路的数据采集。来自快猫研发团队，和Open-Falcon、Nightingale的研发是一拨人。
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-agentimport了大量exporters的代码，没有裁剪，没有优化，没有最佳实践在产品上的落地，有些中间件，仍然是一个grafana-agent一个目标实例，管理起来也很不方便。datadog-agent确实是集大成者，但是大量代码是python的，整个发布包也比较大，有不少历史包袱，而且生态上是自成一派，和社区相对割裂。categraf确实又是一个轮子，categraf希望：支持remote_write写入协议，支持将数据写入promethues、M3DB、VictoriaMetrics、InfluxDB指标数据只采集数值，不采集字符串，标签维持稳态结构采用all-in-one的设计，所有的采集工作用一个agent搞定，未来也可以把日志和trace的采集纳入agent纯Go代码编写，静态编译依赖少，容易分发，易于安装尽可能落地最佳实践，不需要采集的数据无需采集，针对可能会对时序库造成高基数的问题在采集侧做出处理常用的采集器，不但提供采集能力，还要整理出监控大盘和告警规则，用户可以直接导入使用未来希望作为快猫SaaS产品的重要组成部分，引入快猫团队的研发力量持续迭代，当然，希望更多的公司、更多人研发人员参与共建，做成国内最开放、最好用的采集器安装可以直接去categrafreleases页面，下载编译好的二进制，也可自行编译，编译只需要一条命令：gobuild当然，前提是机器上有Go环境。如果是从老版本升级，也是建议大家查看categrafreleases页面，每个版本改动了什么，升级时注意什么，都会在这里写清楚。在目标机器部署，只需要categraf二进制、以及conf目录，conf下有一个主配置文件：config.toml，定义机器名、全局采集频率、全局附加标签、remotewritebackend地址等；另外就是各种采集插件的配置目录，以input.打头，如果某个采集器xx不想启用，把input.xx改个其他前缀，比如bak.input.xx，categraf就会忽略这个采集器。测试我们经常会需要测试某个采集器的行为，临时看一下这个采集器输出哪些监控指标，比如配置好了conf/input.mysql/mysql.toml想要看看采集了哪些mysql指标，可以执行命令：./categraf--test--inputsmysql这个命令会去连接你配置的mysql实例，执行SQL收集输出，将输出的内容做格式转换，最终打印到stdout，如果我们在stdout正常看到了mysql相关监控指标，则说明一切正常，否则就是哪里出了问题，大概率是conf/input.mysql/mysql.toml配置的有问题。如果修改了某个采集器的配置，需要重启categraf或者给categraf进程发送HUP信号，发送HUP信号的命令，举例：kill-HUPpidofcategraf”另外，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，是因为remotewrite协议使用ms作为时间戳的单位precision="ms"#全局采集频率，15秒采集一次interval=15#全局附加标签，一行一个，这些写的标签会自动附到时序数据上#[global.labels]#region="shanghai"#env="localhost"#发给后端的时序数据，会先被扔到categraf内存队列里，每个采集插件一个队列#chan_size定义了队列最大长度#batch是每次从队列中取多少条，发送给后端backend[writer_opt]#default:2000batch=2000#channel(asqueue)sizechan_size=10000#后端backend配置，在toml中[[]]表示数组，所以可以配置多个writer#每个writer可以有不同的url，不同的basicauth信息[[writers]]url="https://127.0.0.1:19000/prometheus/v1/write"#Basicauthusernamebasic_auth_user=""#Basicauthpasswordbasic_auth_pass=""#timeoutsettings,unit:mstimeout=5000dial_timeout=2500max_idle_conns_per_host=100对于每个采集器的配置，不在这里一一赘述，只讲一些相对通用的配置项。interval每个插件的配置中，一开始通常都是interval配置，表示采集频率，如果这个配置注释掉了，就会复用config.toml中的采集频率，这个配置如果配置成数字，单位就是秒，如果配置成字符串，就要给出单位，比如：interval=60interval="60s"interval="1m"上面三种写法，都表示采集频率是1分钟，如果是使用字符串，可以使用的单位有：秒：s分钟：m小时：hinstances很多采集插件的配置中，都有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_timesinstances下面如果有interval_times配置，表示interval的倍数，比如ping监控，有些地址采集频率是15秒，有些可能想采集的别太频繁，比如30秒，那就可以把interval配置成15，把不需要频繁采集的那些instances的interval_times配置成2或者：把interval配置成5，需要15秒采集一次的那些instances的interval_times配置成3，需要30秒采集一次的那些instances的interval_times配置成6labelsinstances下面的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@master01categraf]#findinputs-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还需要继续开发的包括：[]k8ssolution[]nginxvts[]mongodb[]rocketmq[]activemq[]kafka[]elasticsearch[]prometheusdiscovery[]windows[]mssql[]iis[]weblogic[]was[]hadoop[]ad[]zookeeper[]statsd[]snmp[]ipmi[]smartctl[]logging[]trace
评论