监控改造之路4

·

1 min read

read the fucking manual

这本是去年就该完成的,但回顾来看,又觉得似乎不太值得,只因为:

read the fucking manual

历史背景

团队的监控可视化使用的是Grafana,我想,这应该是绝大部分人会使用的监控可视化方案吧。偶然,我发现在项目里面有一些奇怪的逻辑:

  • grafana的面板存放在团队自己的数据库内(grafana默认使用sqlite)

  • grafana是裸奔的;

  • 团队后端服务有从数据库中将模板同步到grafana的逻辑,原因是防止grafana模板丢失(eg: 模板被人从grafana中删除)

首先,模板存储在团队自己的DB中就让人很疑惑,特别是当我做快速部署时,看到KB级的字段时,对于崇尚精巧的笔者而言,那心情,真的无法用言语来形容。言归正传,我所理解的监控,跟主业务关系不大,没必要耦合在一起,它可以独立部署,也可能配合主服务一起使用,但终究是一个边缘的业务/平台/系统。将其与主服务强绑定,在贵司这个场景下,很容易做的多,反而错的多。

文档

本着相信社区一定已经将此事做好的原则,我再一次踏上了阅读官方文档的历程。就果然被我给找到了,这其中我经历了两个阶段

模板目录

You can manage dashboards in Grafana by adding one or more YAML config files in the provisioning/dashboards directory

一开始,我只是注意到可以将模板放置在该目录,但是并不十分清楚在grafana管理中心是否能删除我存放在该目录的模板

  • 若能删除,则无法平替原先的逻辑

  • 若不能删除,那又可以删一堆冗余代码了(开心)

其实这点很容易验证,直接在grafana管理端验证即可,找一个模板删除看看

Delete Dashboard

结果符合预期

Demo

目录结构


├── dashboards
│   └── zk.json
├── docker-compose.yml
└── provisioning
    └── dashboards

docker-compose.yml

services:
  grafana:
    environment:
      - GF_PATHS_PROVISIONING=/etc/grafana/provisioning
      # - GF_SECURITY_ADMIN_PASSWORD=newpassword
      # - GF_SECURITY_ADMIN_USER=newuser
      # 强烈不建议允许匿名登录,这就是我上面提到的裸奔
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_SECURITY_ALLOW_EMBEDDING=true
    image: grafana/grafana:10.2.2
    volumes:
      - ./provisioning/:/etc/grafana/provisioning/
      - ./dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
#cat provisioning/dashboards/dashboard.yml
apiVersion: 1
providers:
- name: Prometheus
  orgId: 1
  folder: ''
  type: file
  options:
    path: /var/lib/grafana/dashboards

dashboards/zk.json从grafana模板市场下载的zookeeper的dashboard模板

总结

我已经记不清这是第几次借力第三方平台,通过文档、配置减少耦合与业务冗余代码了,但是看文档真的是需要耐心和专注……借用最近看的推文来结束吧

据我观察,主要是因为,一些技术人员不思进取,获取信息的能力也有限。调研能力不足的情况下,就只能重复发明纸糊的轮子。实际上是一种惰性。


参考: