![df93aa823abd4c968892c67860f7a532.png](https://img-blog.csdnimg.cn/img_convert/df93aa823abd4c968892c67860f7a532.png)
说到查看系统进程资源占用率,大家会想到top、htop或是glances,确实很方便。
既然有现成的工具为啥还要做成看板呢?
主要不是每次有故障的时间点,你都能正好在那台主机上。所以故障点的历史记录对于故障定位是尤其重要的。
这就好比在玩儿一个侦探游戏,你要根据犯罪现场进行事件还原,缩小嫌疑人范围,并最终发现凶手是谁。证据越多,越细致,你定位的速度和误判就越少。
一般监控系统能提供的监控数据都是一个总量监控,没有细化到单个进程。所以你从图中一眼看不出罪犯是谁,如下图所示:
![817f98af8dca8709cd69493859a45f7b.png](https://img-blog.csdnimg.cn/img_convert/817f98af8dca8709cd69493859a45f7b.png)
![0f10652d65c341ba24039895fa077f34.png](https://img-blog.csdnimg.cn/img_convert/0f10652d65c341ba24039895fa077f34.png)
而我想知道的是,每个进程用掉了多少cpu、多少内存。那个犯罪嫌疑人到底是谁?
想回答这个问题,就需要下边这组图了:
![2a528189835d8d5b0c4bc0c5622d8266.png](https://img-blog.csdnimg.cn/img_convert/2a528189835d8d5b0c4bc0c5622d8266.png)
![366768e29b89d381735205abcb6d1279.png](https://img-blog.csdnimg.cn/img_convert/366768e29b89d381735205abcb6d1279.png)
如图上所示,已经将总量数据细化到单个进程了,不仅能提供你案发时间,还定位了凶手。
所以基于总量的细化历史记录的优势就完全体现出来了。
作为运维来讲,如果你不能协助研发进行故障定位的话,那么背锅在所难免。
为了改变运维背锅侠的命运,成为能缉拿犯罪凶手的英雄。 我讲一下如何制作系统进程占用率的的grafana看板。
1、安装并修改telegraf的配置:
vi /etc/telegraf/telegraf.conf
2、添加如下信息:
[[inputs.procstat]]
user = "nginx|daemon|root|sysop|ubuntu|telegraf|mysql"
[[outputs.graylog]]
## UDP endpoint for your graylog instance(s).
servers = ["127.0.0.1:12201"]
user是系统中已创建的用户串联成的正则表达式,根据线上的实际情况做改动。
3、graylog采集telegraf的日志,并创建名为telegraf_log的索引:
![505a6e6510c81260f7e575848c73ad7b.png](https://img-blog.csdnimg.cn/img_convert/505a6e6510c81260f7e575848c73ad7b.png)
具体操作可以参考我之前的两篇文章:
酒局下饭:Telegraf采集Kubernetes指标并发送到Graylogzhuanlan.zhihu.com![91bb8edc0e22e9a2f74aac979405edef.png](https://img-blog.csdnimg.cn/img_convert/91bb8edc0e22e9a2f74aac979405edef.png)
![5e266975ff9d1505d4448124a52deeec.png](https://img-blog.csdnimg.cn/img_convert/5e266975ff9d1505d4448124a52deeec.png)
4、grafana添加telegraf_log的数据源并制作看板:
![e1ecd8694fd533e57e483aecb0357dd6.png](https://img-blog.csdnimg.cn/img_convert/e1ecd8694fd533e57e483aecb0357dd6.png)
总结:
本人只是提供一个思路,抛砖引玉。大家可以根据实际的应用场景扩展一下,比如接口耗时、应用服务连接数等等。思考怎样才不会成为背锅侠,怎样把技术和经验变成价值,服务于业务。