结构化日志中的指标,怎么输出给 prometheus?

2023-03-17 08:18:19 +08:00
 1800x
程序主要是 go 写的。
程序中已经准备好结构化日志。绝大部分日志中有下面字段:traceid 、时间、耗时、查询入口、错误,等。
现在要收集这些数据,形成监控。

我猜大概两种方案:
一、每个节点部署某个专用服务收集日志,提取日志中的指标数据,输出给 prometheus 。
二、不增加服务,结构化日志后端 /输出端,通过某个开源库,处理后,直接通过网络输出给 prometheus

但具体自己没操作过,请教各位 v 友。还望指教。

日志系统暂定使用 LOKI 。
2617 次点击
所在节点    Kubernetes
18 条回复
q1angch0u
2023-03-17 08:51:40 +08:00
前司是按一定格式输出到硬盘,之后由 sre 使用方案 1 汇报至时序数据库。原因我猜测是因为此方案对代码的侵入性相对较小,且不用限制项目实现语言。
JoDragon
2023-03-17 09:18:02 +08:00
pushgateway 满足你的需求
cxshun
2023-03-17 09:20:07 +08:00
可以考虑用 fluentd/logstash 直接处理日志数据后再通过 push gateway 给到 prometheus
seers
2023-03-17 09:24:58 +08:00
通过接口暴露,然后 Prometheus 抓取
saka0609
2023-03-17 09:35:32 +08:00
既然用了 Loki ,那就可以把你输出的日志给 Loki ,让 loki 帮你转成 metrics
saka0609
2023-03-17 09:37:47 +08:00
ql562482472
2023-03-17 09:44:43 +08:00
我觉得你遇到的问题有两个,一个是 log 怎么转化为 metric 。就是 logs 怎么转化为 Counter (计数器)、Gauge (仪表盘)、Histogram (直方图)、Summary (摘要)
另一个是如何进行 metric 的定义
pkoukk
2023-03-17 10:15:51 +08:00
第一点,确认需求,日志里的东西能满足现在以及后续的全部监控需求么?
一定有部分核心业务是单独需要监控指标的吧,所以还不如直接在 go 里接 prom ,让 prom 从 go 服务直接采集 metric
BQsummer
2023-03-17 11:33:51 +08:00
1. 日志转指标需求是合理的,是应用通用指标的一部分。
2. 我司是有专门的应用和 Flink 消费所有应用的日志,统一处理并产出指标,对于单体应用可能不合适。
3. 部分应用日志在 sls ,我们平台可以定时查询 sls 产出指标。
joesonw
2023-03-17 12:30:23 +08:00
你用的什么日志库,大部分日志库都可以自己实现 Collector ,记录相关 metrics ,prometheus.Register 一下,就一起采走了。
killva4624
2023-03-17 12:34:22 +08:00
把 log 转成 prometheus 的识别样式,生成和刷新文件到指定目录,然后 node-exporter 加上 --collector.textfile.directory 参数,再走常规的 prometheus 数据采集就可以。
lanjz
2023-03-17 15:49:25 +08:00
1800x
2023-03-18 07:49:27 +08:00
@ql562482472 谢谢。查询了有关信息。
如果我要收集同一接口处理逻辑的处理量、耗时分布、错误率,好像还得定义不同的 Observer ?
winglight2016
2023-03-18 12:32:19 +08:00
1. 把日志写到 ES
2. 用 grafana 连接,然后自己定义 dashboard
我们就是这样处理 log 的,其他有 Prometheus 的服务,也可以接入 grafana
ql562482472
2023-03-18 14:40:15 +08:00
@1800x 我不太清楚其他回答者的身份,然后我个人也做过短暂的半年多 devops ,后来的感受就是,ops 角色其实并不关心业务,只有 dev 在关心业务。
我现在回来继续做 dev ,感觉很多指标光凭 ops 从业务无关的地方抽,抽死都抽不出有深度的信息。想要具有深度,还是得开发自行定义 metric ,比如你要的这个处理量,耗时分布,错误率,我感觉是需要有 metric 的埋点:

key = biz.usage 的累加器,tag 是 method-full-name
key = biz.cost.time 的直方图或者 Summary ,tag 也是 method-full-name
key = biz.success 的累加器
key = biz.fail 的累加器

我的认知也很浅,也没有大厂的实践参考,我觉得可能需要自行定义一些 metric ,也许专业的 ops 或者 Prometheus 开发者有其他的方案,仅供参考
1800x
2023-03-18 15:56:30 +08:00
@ql562482472
以前公司,搞了一套监控,有业务层的指标,也有运维层的指标。我们主要看的是业务层的指标。
想在目前公司重新搞一套,目前已经在业务层收集了有关指标,但接下来的处理细节,我并不清楚。
ql562482472
2023-03-18 15:58:55 +08:00
@1800x 如果指标已经有了 那就是套到 metric 上去,然后用 http 之类的 /metrics 接口暴露出去,prometheus 去定时拉这一个接口,然后用 grafana 做 dashboard 了么
1800x
2023-03-19 07:05:28 +08:00
@ql562482472 还没到那步。
已经埋点,不需要再改业务代码。
现在需要在埋点代码里加 metric 输出

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/924710

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX