当前位置:首页 >焦点 >【夜莺监控】海王——Categraf 监控采用 All-in-one 的海王设计

【夜莺监控】海王——Categraf 监控采用 All-in-one 的海王设计

2024-06-30 21:36:11 [百科] 来源:避面尹邢网

【夜莺监控】海王——Categraf

作者:乔克 运维 Categraf 是夜莺一个监控采集 Agent,类似 Telegraf、监控Grafana-Agent、海王Datadog-Agent,夜莺希望对所有常见监控对象提供监控数据采集能力,监控采用 All-in-one 的海王设计,不但支持指标采集,夜莺也希望支持日志和调用链路的监控数据采集。

有没有人和我一样,海王遇到同样的夜莺困惑:当我使用 Prometheus 来搭建监控体系的时候,每当有一个组件需要监控,监控我就要为其增加一个 exporter,海王如果有 10 个组件,夜莺我就要增加 10 个 exporter,监控先不说这 10 个 exporter 的海王质量如何(因为大部分 exporter 都是广大网友自己开发的),光学习成本、部署成本以及维护成本都让人头疼。

【夜莺监控】海王——Categraf 监控采用 All-in-one 的海王设计

有没有一个组件,就能搞定大部分指标采集的?

【夜莺监控】海王——Categraf 监控采用 All-in-one 的海王设计

Categraf 就是这样的一个采集器。

【夜莺监控】海王——Categraf 监控采用 All-in-one 的海王设计

惊不惊喜,意不意外?

什么是 Categrf

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

相比于其他采集器,Categraf 的优势在于:

  • 支持 remote_write 写入协议,支持将数据写入 promethues、M3DB、VictoriaMetrics、InfluxDB
  • 指标数据只采集数值,不采集字符串,标签维持稳态结构
  • 采用 all-in-one 的设计,所有的采集工作用一个 agent 搞定,未来也可以把日志和 trace 的采集纳入 agent
  • 纯 Go 代码编写,静态编译依赖少,容易分发,易于安装
  • 尽可能落地最佳实践,不需要采集的数据无需采集,针对可能会对时序库造成高基数的问题在采集侧做出处理
  • 常用的采集器,不但提供采集能力,还要整理出监控大盘和告警规则,用户可以直接导入使用
  • 未来希望作为快猫 SaaS 产品的重要组成部分,引入快猫团队的研发力量持续迭代,当然,希望更多的公司、更多人研发人员参与共建,做成国内最开放、最好用的采集器

安装

安装很简单,下面简单介绍二进制安装的方式。

# 下载$ wget https://download.flashcat.cloud/categraf-v0.2.38-linux-amd64.tar.gz# 解压$ tar xf categraf-v0.2.38-linux-amd64.tar.gz# 进入目录$ cd categraf-v0.2.38-linux-amd64/

修改配置文件,在 conf/config.toml 中,修改的部分如下:

[[writers]]url = "http://127.0.0.1:17000/prometheus/v1/write"[heartbeat]enable = true

然后启动 Categraf。

$ nohup ./categraf &>categraf.log &

配置详解我们上面部署 Categraf 的时候没有指定配置文件,它就会默认读取 conf 目录下的配置文件,conf 目录的结构如下:

  • config.toml # 主配置
  • logs.toml # logs-agent 配置
  • prometheus.toml # prometheus agent 配置
  • traces.yaml # trace-agent 配置
  • conf/input./.toml 插件配置文件

主配置 config.toml 详解

[global]# 是否打印配置内容print_configs = false# 机器名,作为本机的唯一标识,会为时序数据自动附加一个 agent_hostname=$hostname 的标签# hostname 配置如果为空,自动取本机的机器名# hostname 配置如果不为空,就使用用户配置的内容作为hostname# 用户配置的hostname字符串中,可以包含变量,目前支持两个变量,# $hostname 和 $ip,如果字符串中出现这两个变量,就会自动替换# $hostname 自动替换为本机机器名,$ip 自动替换为本机IP# 建议大家使用 --test 做一下测试,看看输出的内容是否符合预期# 这里配置的内容,再--test模式下,会显示为 agent_hostname=xxx 的标签hostname = ""# 是否忽略主机名的标签,如果设置为true,时序数据中就不会自动附加agent_hostname=$hostname 的标签omit_hostname = false# 时序数据的时间戳使用ms还是s,默认是ms,是因为remote write协议使用ms作为时间戳的单位precision = "ms"# 全局采集频率,15秒采集一次interval = 15# 配置文件来源,目前支持local和http两种配置,如果配置为local就读取本地的配置,如果配置为http,需要在[http]模块配置http来源providers = ["local"]# 全局附加标签,一行一个,这些写的标签会自动附到时序数据上# [global.labels]# region = "shanghai"# env = "localhost"# 日志模块[log]# 默认的log输出,到标准输出(stdout)# 如果指定为文件, 则写入到指定的文件中file_name = "stdout"# 当日志输出到文件时该配置生效,用于限制日志文件大小max_size = 100# 日志保留天数max_age = 1# 备份日志个数max_backups = 1# 是否使用本地时间格式化日志local_time = true# 是否用gzip对日志进行压缩compress = false# 发给后端的时序数据,会先被扔到 categraf 内存队列里,每个采集插件一个队列# chan_size 定义了队列最大长度# batch 是每次从队列中取多少条,发送给后端backend[writer_opt]batch = 1000chan_size = 1000000# 后端backend配置,在toml中 [[]] 表示数组,所以可以配置多个writer# 每个writer可以有不同的url,不同的basic auth信息[[writers]]url = "http://127.0.0.1:17000/prometheus/v1/write"# 认证用户,默认为空basic_auth_user = ""# 认证密码,默认为空basic_auth_pass = ""## 请求头信息# headers = ["X-From", "categraf", "X-Xyz", "abc"]# 超时配置:单位是 mstimeout = 5000dial_timeout = 2500max_idle_conns_per_host = 100# 如果providers配置为http,就需要在这个地方进行配置[http]# 是否开启enable = false# 地址信息address = ":9100"print_access = falserun_mode = "release"# ibex配置,用于配置ibex-server的地址,用于实现故障自愈[ibex]enable = false## ibex刷新频率interval = "1000ms"## ibex server 地址servers = ["127.0.0.1:20090"]## 脚本临时保存目录meta_dir = "./meta"# 心跳上报给n9e[heartbeat]enable = true# 上报 os version cpu.util mem.util 等元信息url = "http://127.0.0.1:17000/v1/n9e/heartbeat"# 上报频率,单位是 sinterval = 10# 认证用户basic_auth_user = ""# 认证密码basic_auth_pass = ""## header 头信息# headers = ["X-From", "categraf", "X-Xyz", "abc"]# 超时配置,单位 mstimeout = 5000dial_timeout = 2500max_idle_conns_per_host = 100

日志采集 logs.toml 配置

[logs]# api_key http模式下生效,用于鉴权, 其他模式下占位符api_key = "ef4ahfbwzwwtlwfpbertgq1i6mq0ab1q"# 是否开启log-agentenable = false# 日志接收地址,可以配置tcp、http以及kafkasend_to = "127.0.0.1:17878"# 日志发送协议:http/tcp/kafkasend_type = "http"# kafka模式下的topictopic = "flashcatcloud"# 是否进行压缩use_compress = false# 是否使用tlssend_with_tls = false# 批量发送的等待时间batch_wait = 5# 日志偏移量记录,用于断点续传run_path = "/opt/categraf/run"# 最大打开文件数open_files_limit = 100# 扫描目录日志评论scan_period = 10# udp采集的buffer大小frame_size = 9000# 是否采集pod的stdout/stderr日志collect_container_all = true  # 全局处理规则, 该处不支持多行合并。多行日志合并需要在logs.items中配置  # [[logs.Processing_rules]]  # 日志采集配置  [[logs.items]]  # 日志类型,支持file/journald/tcp/udp  type = "file"  # 日志路径,支持统配符,用统配符,默认从最新位置开始采集  ## 如果类型是file,则必须配置具体的路径; 如果类似是journald/tcp/udp,则配置端口  path = "/opt/tomcat/logs/*.txt"  # 日志的label 标识日志来源的模块  source = "tomcat"  # 日志的label 标识日志来源的服务  service = "my_service"

其中,日志采集规则可以在全部logs.Processing_rules中配置,也可以在logs.items.logs_processing_rules中进行配置。

规则类型主要分为以下几种:

  • exclude_at_match:表示不发送匹配到的日志行。
  • include_at_match:表示只发送匹配到的日志行。
  • mask_sequences:可以在日志发送前对日志进行处理,比如替换日志内容。
  • multi_line:多行合并,不支持全局配置。

(1)不发送匹配到的日志行

type = "exclude_at_match"name = "exclude_xxx_users"pattern="\\w+@flashcat.cloud"表示日志中匹配到@flashcat.cloud 的行 不发送

(2)只发送匹配到的日志行

type = "include_at_match"name = "include_demo"pattern="^2022*"表示日志中匹配到2022开头的行 才发送

(3)对日志内容进行替换处理

type = "mask_sequences"name = "mask_phone_number"replace_placeholder = "[186xxx]"pattern="186\\d{ 8}"表示186的手机号会被[186xxx] 代替

(4)多行合并

type = "multi_line"name = "new_line_with_date"pattern="\\d{ 4}-\\d{ 2}-\\d{ 2}" (多行规则不需要添加^ ,代码会自动添加)表示以日期为日志的开头,多行的日志合并为一行进行采集

指标采集 prometheus.toml 配置

Categraf 本身以及可以完成很多指标的采集,如果你本身已经有了完整的 Promtheus 体系,但是想用 N9e,Categraf 也支持采集 Prometheus 指标。

[prometheus]# 是否启动prometheus agentenable=false# 原来prometheus的配置文件# 或者新建一个prometheus格式的配置文件scrape_config_file="/path/to/in_cluster_scrape.yaml"## 日志级别,支持 debug | warn | info | errorlog_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

比如这里配置 Prometheus 自动采集 kube-state-metrics 指标的 scrape 配置:

global:  scrape_interval: 15s  external_labels:    scraper: ksm-test    cluster: testscrape_configs:  - job_name: "kube-state-metrics"    metrics_path: "/metrics"    kubernetes_sd_configs:      - role: endpoints        api_server: "https://172.31.0.1:443"        tls_config:          ca_file: /etc/kubernetes/pki/ca.crt          cert_file: /etc/kubernetes/pki/apiserver-kubelet-client.crt          key_file: /etc/kubernetes/pki/apiserver-kubelet-client.key          insecure_skip_verify: true    scheme: http    relabel_configs:      - source_labels:          [            __meta_kubernetes_namespace,            __meta_kubernetes_service_name,            __meta_kubernetes_endpoint_port_name,          ]        action: keep        regex: kube-system;kube-state-metrics;http-metricsremote_write:  - url: "http://172.31.62.213/prometheus/v1/write"

然后在prometheus.toml配置中使用scrape_config_file加载上面的文件即可。

链路指标 traces.toml 配置

链路指标配置只是对 OpenTelemetry Collector 做了简单的封装,用户可以对接各种系统。

这里不做多的解释。

插件配置

采集配置

假如我们服务器上有一个 nginx 进程,我们要对其进程监控,我们要修改conf/input.procstat/procstat.toml配置,如下:

# # collect intervalinterval = 15[[instances]]# # executable name (ie, pgrep <search_exec_substring>)search_exec_substring = "nginx"# # pattern as argument for pgrep (ie, pgrep -f <search_cmdline_substring>)# search_cmdline_substring = "n9e server"# # windows service name# search_win_service = ""metrics_name_prefix="nginx"# # search process with specific user, option with exec_substring or cmdline_substring# search_user = ""# # append some labels for serieslabels = {  region="cloud", product="n9e" }# # interval = global.interval * interval_times# interval_times = 1# # mode to use when calculating CPU usage. can be one of 'solaris' or 'irix'# mode = "irix"# sum of threads/fd/io/cpu/mem, min of uptime/limitgather_total = true# will append pid as taggather_per_pid = false#  gather jvm metrics only when jstat is ready# gather_more_metrics = [#     "threads",#     "fd",#     "io",#     "uptime",#     "cpu",#     "mem",#     "limit",#     "jvm"# ]

我们指定了进程名,并且为指标增加了nginx的前缀和label。

配置完成后,重启 Categraf 即可。

然后就可以看到指标数据,如下:

图片

如果想给采集的目标增加标签,直接修改 labels 标签,比如增加group="ops",如下:

图片

然后重启 Categraf 即可。

其他插件的配置类似,可以自行实验。

最后

到目前位置,Categraf 支持的插件非常多,粗略数了一下,大概有 60 种,涵盖大部分的中间件、云平台,可以说功能非常丰富。

从能力上将,大部分场景都可以只使用 Categraf 替代,但是对于插件需求很多的情况,对于 Categraf 的整体性能是否会有影响以及 Categraf 会不会很耗系统资源还未可知。

责任编辑:姜华 来源: 运维开发故事 Categraf监控采集

(责任编辑:焦点)

    推荐文章
    热点阅读