性能文章>【云原生•监控】Categraf大一统的监控数据采集器>

【云原生•监控】Categraf大一统的监控数据采集器原创

268045

前言

「笔者已经在公有云上搭建了一套临时环境,可以先登录体验下:」

http://124.222.45.207:17000/login
账号:root/root.2020

简介

Categraf 是一个监控采集 Agent,类似 TelegrafGrafana-AgentDatadog-Agent,希望对所有常见监控对象提供监控数据采集能力,采用 All-in-one 的设计,不但支持指标采集,也希望支持日志和调用链路的数据采集。

Categraf组件将5个常用agent进行整合,采用 all-in-one 的设计,主要解决如每台机器可能需要部署很多个prometheus exporter导致运维困难的问题,所有的采集工作用一个 agent 搞定,也可以把日志和 trace 的采集纳入 agent

  • 「ibex agent:」故障自愈 agent,主要用于执行自愈脚本;
  • 「logs agent:」日志采集 agent
  • 「metrics agent:」指标采集 agent,采用插件模式设计;
  • 「prometheus agent:」嵌入 prometheus sdk,实现 prometheus agent模式;
  • 「traces agent:」链路采集agent;

编译运行

categraf 的代码托管在 github:https://github.com/flashcatcloud/categraf。

1、下载并编译:

# export GO111MODULE=on
# export GOPROXY=https://goproxy.cn
go build

2、打包:

tar zcvf categraf.tar.gz categraf conf

conf 目录下还提供了 categraf.service 文件样例,便于大家使用 systemd 托管 categraf。

3、运行

# test mode: just print metrics to stdout
./categraf --test

# test system and mem plugins
./categraf --test --inputs system:mem

# print usage message
./categraf --help

# run
./categraf

# run with specified config directory
./categraf --configs /path/to/conf-directory

# only enable system and mem plugins
./categraf --inputs system:mem

# use nohup to start categraf
nohup ./categraf &> stdout.log &

「测试」

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

[root@swarm-worker02 categraf-v0.3.3-linux-amd64]# ./categraf --test  --inputs mem                
2023/05/15 23:41:48 I! tracing disabled
2023/05/15 23:41:48 metrics_agent.go:269: I! input: local.mem started
2023/05/15 23:41:48 agent.go:47: I! [*agent.MetricsAgent] started
2023/05/15 23:41:48 agent.go:50: I! agent started
23:41:48 mem_free agent_hostname=swarm-worker02 1264836608
23:41:48 mem_high_free agent_hostname=swarm-worker02 0
23:41:48 mem_sreclaimable agent_hostname=swarm-worker02 279576576
23:41:48 mem_swap_cached agent_hostname=swarm-worker02 0
23:41:48 mem_available agent_hostname=swarm-worker02 5180682240
23:41:48 mem_used agent_hostname=swarm-worker02 520003584
23:41:48 mem_total agent_hostname=swarm-worker02 6017568768
23:41:48 mem_available_percent agent_hostname=swarm-worker02 86.09261380691878
23:41:48 mem_write_back agent_hostname=swarm-worker02 0
23:41:48 mem_used_percent agent_hostname=swarm-worker02 8.64142320674847
23:41:48 mem_high_total agent_hostname=swarm-worker02 0
23:41:48 mem_low_total agent_hostname=swarm-worker02 0

ibex agent

ibex agent主要用于告警自愈场景。故障自愈主要用于解决出现故障时,基于故障治理方案自动执行相关的操作,已达到故障自动修复能力。比如主机磁盘使用率高,可以执行脚本清理磁盘文件;还比如PaaS组件CPU、内存使用率居高不下,可以通过三方接口方式调用重启组件释放资源等等。

夜莺监控支持告警规则中关联回调地址方式,实现告警触发时通过调用三方接口方式实现告警自愈能力,见下图:

回调地址除了可以配置HTTP地址外,还支持基于ibex组件回调自愈脚本能力,见下图:

这里的1就是对应的自愈脚本ID,可以在【告警自愈】-【自愈脚本】页面查询对应ID信息:

自愈脚本通常有两种方式:基于ssh方式执行和客户端agent执行,夜莺采用基于后者方式,ibex-agent最新方式已经集成到categraf组件中:

categraf组件ibex相关配置示例如下:

# 是否启用告警自愈agent
[ibex]
enable = false
## ibex flush interval
interval = "1000ms"
## n9e ibex server rpc address
servers = ["127.0.0.1:20090"]
## temp script dir
meta_dir = "./meta"

故障自愈核心组件数据流如下图:

自愈脚本、告警配置都在n9e组件端,然后将其分发到ibex server组件,该组件单独管理故障自愈脚本执行分发,然后ibex agent组件定时周期性通过RPC接口方式拉取当前主机上执行的脚本任务执行,并同时将执行结果、执行输出等上报到ibex server组件,这样n9e管理端就可以从ibex server端查询到任务执行明细并进行展示。

ibex agent组件已经被集成到categraf组件中,所以,这里的ibex agent即为categraf。

ibex故障自愈详细的核心流程见下图:

prometheus agent

Prometheus Agent 是自 Prometheus v2.32.0 版本推出的实验性功能,当启用此功能后,将不会在本地文件系统上生成块,并且无法在本地查询。如果网络出现异常状态无法连接至远程端点,数据将暂存在本地磁盘,但是仅限于两个小时的缓冲。

prometheus开启agent模式时,prometheus.yml中必须配置"remote_write",不能配置alertmanagerrules,因为agent节点仅有采集指标功能,添加alertmanagerrules启动时会报错。

prometheus agent配置conf/prometheus.toml

[prometheus]
# 是否启动prometheus agent
enable=false
# 原来prometheus的配置文件
# 或者新建一个prometheus格式的配置文件
scrape_config_file="/path/to/in_cluster_scrape.yaml"
## 日志级别,支持 debug | warn | info | error
log_level="info"
# 以下配置文件,保持默认就好了
## wal file storage path ,default ./data-agent
# wal_storage_path="/path/to/storage"
## wal reserve time duration, default value is 2 hour
# wal_min_duration=2

categraf组件中prometheus agent就是使用prometheus sdk实现了prometheus agent模式,这样就可以把prometheus采集配置直接拿来使用:

如上图,我理解的categrafprometheus agent典型应用场景是借助prometheus强大的服务发现能力,对云原生集群node机器、cAdvisor容器、ksm集群和上层业务组件进行监控。

metrics agent

作为categraf组件的核心模块,metrics agent主要实现对各种组件的性能指标进行采集,类似于prometheus中的exporter,但是categraf组件采用All-in-one 的设计思想,并利用插件模式进行实现。

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

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

categraf大概实现了70+插件,每个插件怎么使用可以查看对应的插件的README文档,具体使用这里就不做过多介绍。下面主要来看下插件核心实现原理(见下图),方便我们进行二次开发:

heartbeat

categraf组件可以和n9e后端组件启用心跳功能,通过心跳模式上报集群节点的CPU、内存、OS等基础信息,配置如下:

# categraf心跳配置,启动心跳功能,categraf会定时周期将节点cpu、内存等信息通过心跳包发送给n9e后端服务
[heartbeat]
enable = true

# report os version cpu.util mem.util metadata
url = "http://127.0.0.1:17000/v1/n9e/heartbeat"

# interval, unit: s
interval = 10

# Basic auth username
basic_auth_user = ""

# Basic auth password
basic_auth_pass = ""

## Optional headers
# headers = ["X-From", "categraf", "X-Xyz", "abc"]

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

心跳包会将categraf组件服务器的基础信息发送到后端,具体信息如下:

data := map[string]interface{}{
 "agent_version": version,//categraf版本
 "os":            runtime.GOOS,//系统
 "arch":          runtime.GOARCH,//架构
 "hostname":      hostname,//主机名
 "cpu_num":       runtime.NumCPU(),//CPU核数
 "cpu_util":      cpuUsagePercent,//cpu使用率
 "mem_util":      memUsagePercent,//内存使用率
 "unixtime":      time.Now().UnixMilli(), //后端可以用于计算客户端和后端时间偏移
}

服务端收到心跳包后,基于req.Offset = (time.Now().UnixMilli() - req.UnixTime)计算出后端和categraf采集端时间偏移量,然后并将这些信息一起写入到内存,并定时1秒间隔刷新到Redis缓存中,keyn9e_meta_$hostname格式,见下图:

 

[更多云原生监控运维,请关注微信公众号:Reactor2020]

 

点赞收藏
云原生生态实验室

关注公众号@reactor_2020

请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步
5
4