解决方案:开源一款监控数据采集器，啥都能监控

　　解决方案:开源一款监控数据采集器，啥都能监控

　　介绍

　　Categraf 是一个监控和采集

代理，类似于 Telegraf、Grafana-Agent 和 Datadog-Agent。它希望为所有常见的监控对象提供监控数据采集能力。它采用一体化设计。不仅支持指标采集，还希望支持日志和调用链路数据采集。快猫的研发团队与Open-Falcon和Nightingale的研发团队相同。

　　categraf 的代码托管在两个地方：

　　比较的

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

　　Telegraf 是 influxdb 生态系统的产物。因为influxdb支持字符串数据，所以telegraf采集的很多字段都是字符串类型。另外，influxdb的设计允许标签是不稳定的结构，比如result_code标签。有时它的值为0，有时它的值为1，这在influxdb中是可以接受的。但是以上两点在prometheus这样的时序库中处理起来非常麻烦。

　　prometheus 生态系统中有各种导出器，但设计逻辑是每个监控类型一个导出器，甚至每个实例一个导出器。生产环境可能会部署大量的exporter，管理起来有点麻烦。

　　grafana-agent导入大量出口商的代码，没有剪裁，没有优化，没有在产品中实现最佳实践。有些中间件还是grafana-agent的一个目标实例，管理起来很不方便。

　　datadog-agent确实是高手，但是很多代码都是python的，而且整个release包比较大，历史包袱比较多，而且生态上自成一派，相对脱离社区。

　　categraf确实是另一个轮子，categraf希望：

　　安装

　　您可以直接转到 categraf 发布页面，下载已编译的二进制文件，或自行编译。编译只需要一个命令：go build 当然，前提是机器上有Go环境。

　　如果您是从旧版本升级，还建议您查看 categraf 发布页面。每个版本有什么变化，升级的时候要注意什么，这里都会写的很清楚。

　　部署在目标机器上，只需要categraf二进制文件和conf目录。conf下有一个主配置文件：config.toml，定义了机器名、全局采集频率、全局附加标签、远程写后端地址等；另外，各种采集插件的配置目录都是以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相关的监控指标正常，说明一切正常，否则就是where。如果有问题，很大概率是conf/input.mysql/mysql.toml的配置有问题。

　　如果修改了某个采集器的配置，需要重启categraf或者向categraf进程发送HUP信号，发送HUP信号的命令，例如：

　　kill -HUP `pidof categraf`<br />

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

　　插件说明

　　采集插件的代码，在代码的inputs目录下，每个插件都有一个独立的目录，目录下是采集代码，以及相关的监控大盘JSON（如果有）和告警规则JSON（如果有） ), Linux相关的dashboards和alarms规则并没有分散在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 的标签

<p>

" />

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

</p>

　　对于各个采集器的配置，这里不做赘述，只说一些比较常用的配置项。

　　间隔

　　

" />

　　在每个插件的配置中，开头通常会有一个interval配置，表示采集频率。如果注释掉该配置，将复用config.toml中的采集频率。如果此配置配置为数字，则单位为秒。如果配置为字符串时，必须给出单位，例如：

　　interval = 60

interval = "60s"

interval = "1m"

　　以上三种写法均表示采集频率为1分钟。如果使用字符串，可以使用的单位是：

　　实例

　　在很多采集插件的配置中，有一个instances配置段，用[[]]包裹起来，表示是一个数组，即可以出现多个[[instances]]配置段，比如ping监控采集插件。PING检测的IP可以配置如下：

　　[[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，不需要频繁那些采集到的instance的interval_times配置为2

　　或者：配置interval为5，将那些需要15秒采集一次的实例的interval_times配置为3，将那些需要30秒采集一次的实例的interval_times配置为6

　　标签

　　instances下的标签和config.toml中的global.labels类似，只是作用范围不同。它们都是时间序列数据。instances下的labels附在对应的instance上，global.labels附在所有时序数据上

　　工作计划

　　categraf已经完成了一些常用的采集插件，还有很多有待开发。欢迎搭建和补充。完成的采集插件包括：

　　有些采集器不仅提供采集能力，还提供监控配置和告警规则配置。您可以将 JSON 导入 Nightingale 并使用它。至于哪些插件提供了JSON配置，可以通过以下方式找到：

　　[root@master01 categraf]# find inputs -name "*.json"<br />inputs/redis/alerts.json<br />inputs/redis/dashboard.json<br />inputs/system/dashboard.json<br />inputs/system/alerts-linux.json<br />inputs/oracle/dashboard.json<br />inputs/ping/alerts.json<br />inputs/ping/dashboard.json<br />inputs/ntp/alerts.json<br />inputs/procstat/alerts.json<br />inputs/mysql/alerts.json<br />inputs/mysql/dashboard.json<br />inputs/tomcat/dashboard.json<br />inputs/rabbitmq/dashboard.json<br />inputs/http_response/alerts.json<br />inputs/http_response/dashboard.json<br />inputs/net_response/alerts.json<br />inputs/net_response/dashboard.json<br />

　　还需要继续开发的包括：

　　更多信息

　　解决方案:基于 PTS 压测轻松玩转问题诊断

　　为什么要定位压力测试的问题？

　　性能测试PTS（Performance Testing Service）是一个SaaS压测平台，具有强大的分布式压测能力，可以模拟海量用户的真实业务场景，全面验证业务站点的性能、容量和稳定性。

　　在持续测压服务器水位的过程中，我们可以从压测视图或者压测报告中看到更全面的压测指标，比如QPS、RT、TPS等，但仅仅从这些指标来看，它无法快速定位到服务器的具体问题。比如我们可以从整个场景的错误信息中心看到错误码对应的接口的响应体，但是下游是哪个环节错了，错误的栈是什么，你是看不到的这里简单的从report上看，但是接口下游有什么问题，error stack是什么，正是用户关心的问题。

　　借助问题诊断，我们可以理清被压接口的上下游调用。同时从链路视图中我们可以看到整个链路经过的消息组件（Kafka、RocketMQ等）、缓存（Redis、MongoDB等）。等），数据库（MySQL，Oracle等），RPC调用（Feign，Dubbo，HttpClient等），比如某个接口状态码异常或者其他错误，那么我们可以从调用链上看那就是rpc调用有问题，就是数据库读写有问题，从调用链可以看到对应的错误栈。根据这些信息，应该比较清楚问题出在哪里。

　　问题诊断基本介绍及核心优势

　　在进行问题诊断时，用户主要关心接入问题诊断是否需要对应用端代码进行一系列修改，是否需要复杂的配置等等。PTS提供的问题诊断基于JavaAgent，用户端无需修改业务代码。对于基于Tomcat的部署方式，用户只需在启动脚本中添加一些必要的参数即可接入问题诊断；对于 Kubernetes 用户，用户只需要在 Yaml 配置文件中添加一些必要的注解即可访问问题诊断。对于链接采集

规则，PTS会提供默认配置，用户也可以根据自己的需要进行更改。

　　PTS集成问题诊断在压测​​过程中，对于每一个请求，在压力引擎侧都会生成一个TraceId，通过TraceId关联请求中涉及的上下游环节，用户可以看到作为入口到本次请求结束所涉及的完整调用链，同时问题诊断会为调用链生成对应的应用拓扑视图，让用户清晰的看到应用之间的调用关系。

　　对于异常的接口，我们可以在调用链中看到相应的错误原因。同时，用户可以根据具体的错误堆栈对服务端问题进行排查和优化。压测过程中，用户可以实时查看指定请求的调用链。同时，压测结束后，还可以从压测报告中追溯问题。

　　核心优势

　　1. 零代码入侵：对于Java类业务，用户侧无需修改业务侧代码即可完成问题诊断的探针接入。

　　2、集成度高：压测、监控、问题诊断集成在同一个控制台，用户理解和操作成本较低。

　　3、监控指标全面：压测过程中，除了比较基础的监控指标外，还针对各个服务提供了接口、机器、应用层面的监控。

　　4、门槛低：只需要简单的配置参数即可完成问题诊断探针的接入。同时，探针还具备多协议mock、全链路压力测试等功能。

　　快速玩转问题诊断

　　接入问题诊断的基本流程如下：

　　

" />

　　访问探针，查看是否访问成功

　　首先，我们对压力场景涉及的应用进行梳理，将所有涉及的应用按照【问题诊断】-&gt;【探针接入[1]]文档中的步骤接入问题诊断探针。我们可以在PTS控制台中选择应用配置或应用监控、接口监控、机器监控中的一项来查看应用探针是否连接成功。我们这次演示的压测场景涉及五个应用，分别是petstore-web、petstore-user、petstore-order、petstore-catalog、petstore-cart。这里以应用监控为例，检查应用是否连接成功。点击【问题诊断】-&gt;【应用监控[2]]-&gt;依次选择我们在PTS控制台配置的Region和Namespace。

　　压测场景开启问题诊断开关

　　然后，我们在PTS控制台的【压测中心】-&gt;【创建场景【3】】创建一个压测场景。这里可以选择PTS场景或者JMeter场景。这里我们以PTS场景为例，因为本次演示主要是验证问题诊断的能力，所以需要在场景配置中的【高级设置】中打开问题诊断开关。对于具体的监控采集规则，PTS会将默认采集开关的配置推送给用户。同时采样率设置为1/1000，用户也可以根据自己的需要进行自定义。

　　开始压测，查看应用监控

　　完成以上步骤后，我们的压测场景就具备了诊断问题的能力。我们点击开始压测后，可以在应用监控、接口监控、机器监控中选择我们关心的服务，查看相应的监控情况。这里我们以应用监控[2]为例。其他类型监控的操作步骤类似。我们选择 petstore-user 这个服务来查看应用监控，如下图：

　　压测结束后，查看整个场景的错误信息

　　压测结束后，我们需要从压测报告中排查受压服务器的问题，打开对应场景的压测报告。具体步骤为：PTS控制台-&gt;【压测中心】-&gt;【报告列表[4]】，选择对应的压测报告，在概览页面可以看到整个场景的信息，如图下图：

　　选择探针采样查看具体的调用链

　　点击【查看采样日志】，采样类型选择“探针采样”，过滤出问题诊断探针采集到的调用链，如下图：

　　

" />

　　查看调用链的具体错误堆栈信息定位服务端问题

　　过滤掉探针端采集

到的调用链后，就可以分析出问题接口的调用链了。例如商品列表接口返回的状态码为500，点击查看详情可以查看具体原因，如下图：

　　从调用栈可以看出具体的错误原因，从而优化和修复服务端代码。同时，您可以通过应用拓扑视图和数据库视图查看服务之间的调用和数据库使用情况。这里以应用拓扑视图为例，如下图所示：

　　压测报告常见错误码汇总 问题诊断错误码汇总

　　问题诊断调用环节中常见的错误码总结如下：

　　压测报告错误码汇总

　　以下是压力测试报告中的常见错误列表。我们可以从整个场景的错误信息中看到相关的错误信息，如下：

　　相关链接

　　[1] 探测访问

　　[2] 应用监控

　　[3] 创建场景

　　[4] 报告清单

　　​​​​