监控改造之路4
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/dashboardsdirectory
一开始，我只是注意到可以将模板放置在该目录，但是并不十分清楚在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模板
总结
我已经记不清这是第几次借力第三方平台，通过文档、配置减少耦合与业务冗余代码了，但是看文档真的是需要耐心和专注……借用最近看的推文来结束吧
据我观察，主要是因为，一些技术人员不思进取，获取信息的能力也有限。调研能力不足的情况下，就只能重复发明纸糊的轮子。实际上是一种惰性。
参考：