Skip to main content

Command Palette

Search for a command to run...

(空想场景)使用 Prometheus 监控特定日志行数

Updated
2 min read

感谢 @云原生小白 提供线索

在系统的监控过程中,有时我们只是想要知道一些特定内容的出现数量或者频度,并不关心他的具体内容,而且也不想特意部署一个 Loki 或者 Elasticsearch,这时就可以使用 Fluentd 花里胡哨的插件功能来完成任务了。

Fluentd 有一个 Prometheus 插件,能够提供 Prometheus 接口提供采集数据,插件需要用 fluent-gem 进行安装,如果在 Docker 中的话,可以使用下列 Dockerfile:

FROM fluentd:v1.9.1-1.0
USER root
RUN fluent-gem install fluent-plugin-prometheus
USER fluent

这个插件的基本配置方式是,提供一个 promethues 的类型,包含一个 <metric> 元素用于对指标结构进行定义。例如文档中使用的:

  @type prometheus
  <metric>
    name fluentd_input_status_num_records_total
    type counter
    desc The total number of incoming records
    <labels>
      tag ${tag}
      hostname ${hostname}
    </labels>
  </metric>

这种指标放在 <filter> 用于指示输入数量,而放在 <match> 中则可以监控输出数量。

这里定义了一个名为 fluentd_input_status_num_records_total 的指标,其类型为 counter

定义指标之后,还要将其暴露给 Prometheus:

<source>
  @type prometheus
  bind 0.0.0.0
  port 24231
  metrics_path /metrics
</source>

这段配置定义了一个监听 24231 端口的 Prometheus 端点,路径为 /metrics

举个栗子

接下来用一个完整场景来展示这个例子,假设我们要监控 /logs/input.txt 中的 warning 数量,会采用文末的完整配置,分段解释如下:

  1. <source> 段定义采集文件名称
  2. 第一个 <filter> 中使用 @type promethues 来监控输入数量,生成指标 fluentd_input_status_num_records_total,类型为 counter
  3. 第二个 <filter>@type grep 的正则表达式插件对输入进行过滤
  4. <match> 节中使用 @type copy 对输出进行分流
  5. 第一个 <store> 输出 fluentd_output_status_num_records_total 的 Promethues 指标,对过滤出来的文本进行计数
  6. 第二个 <store> 将输出内容展示在 stdout

配置结束之后启动采集过程,可以使用类似如下脚本:

#!/bin/sh
docker run -it --rm \
        -v $(pwd)/etc:/etc/fluentd \
        -v $(pwd)/log:/data \
        -p 12345:12345 \
        fluentd:prom \
        fluentd -c /etc/fluentd/fluentd.conf

启动之后,我们向日志中输出内容,例如 echo "warn" >> input.txt,会看到 fluentd 日志输出了类似 2021-08-14 07:06:55.688191458 +0000 custom.log: {"message":"warn"} 的内容,如果使用 curl 访问开放出来的 :12345/metrics,会看到输出中的如下内容:

fluentd_input_status_num_records_total{tag="custom.log",hostname="757214c8a91a"} 2.0      │➜  log  vim fluentd.conf
fluentd_output_status_num_records_total{tag="custom.log",hostname="757214c8a91a"} 1.0

这是很常见的指标格式,如果在 Kubernetes 中,对 Pod 进行注解,纳入采集范围,就可以像其它监控指标一样使用了。

fluentd.conf

<source>
  @type tail
  path /data/input.txt
  pos_file /data/input.pos
  tag custom.log
  <parse>
    @type none
  </parse>
</source>
<filter custom.**>
  @type prometheus
  <metric>
    name fluentd_input_status_num_records_total
    type counter
    desc The total number of incoming records
    <labels>
      tag ${tag}
      hostname ${hostname}
    </labels>
  </metric>
</filter>
<filter custom.**>
  @type grep
  <regexp>
    key message
    pattern /warn/
  </regexp>
</filter>
<match custom.**>
  @type copy
  <store>
    @type prometheus
    <metric>
      name fluentd_output_status_num_records_total
      type counter
      desc The total number of outgoing records
      <labels>
        tag ${tag}
        hostname ${hostname}
      </labels>
    </metric>
  </store>
  <store>
    @type stdout
</match>

<source>
  @type prometheus
  bind 0.0.0.0
  port 12345
  metrics_path /metrics
</source>

<source>
  @type prometheus_output_monitor
  interval 10
  <labels>
    hostname ${hostname}
  </labels>
</source>

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts