无论你是 Linux 系统管理员或是 DevOps 工程师,你都会在监控服务器性能指标的时候花费很长时间。
有时候实例运行非常慢但是哪里出的问题却没有任何线索。有一些不响应的实例会阻止你在这些实例上执行类似 top 或者 htop 的远程命令。
服务器有一个瓶颈存在,但是你并不能简单快速的找到问题所在。
如果我们有一个完整的仪表盘可以帮助我们跟踪整体性能以及独立的进程该怎么操作?
可以在该链接中实时查看: http://grafana.devconnected.com/d/nZMDMoiZk/grafana-top?orgId=1&refresh=5s
这篇入门文章旨在如何为 Linux 系统管理员创建一个完整的监控仪表盘
该仪表盘会展示完全可定制并且可扩展到分布式架构的多个实例的不同面板。
1
你将学到什么
在即将踏入技术旅途之前,让我们快速看下通过这篇文章你将学到哪些东西:
了解在 Unix 系统性能监控方面的最新技术;
怎样安装最新版本的 Prometheus v2.9.2、Pushgateway v0.8.0 以及 Grafana v6.2;
构建一个简单的 bash 脚本用来导出指标项到 Pushgateway;
构建一个完整的 Grafana 仪表盘包括最新的面板例如 ‘Gauge’ 和 ‘Bar Gauge’。
额外内容: 集成 ad-hoc 过滤器跟踪单个进程或实例。
现在我们大体浏览了将要学习哪些东西,让我们介绍一些当前 Unix 系统中目前已有的内容。
2
Unix 进程监控基础
当提到 Unix 系统进程监控时,在你脑海中出现的有好几个选项,最流行的或许就是 ‘top’ 。这个命令在系统管理员中间被广泛使用,当系统出现性能瓶颈或许是第一条执行的命令。
top 命令可读性已经是非常好了,但是仍有一条命令比 top 命令可读性更好:htop。
Htop 提供了与 top 相同的一些功能(CPU、内存、正常运行时间…)但是是以一种彩色并且很友好的方式展示出来的,Htop 还提供当前系统使用情况的仪表盘。
既然已经有这两个命令了,那为什么我们想要构建另一种监控进程的方法呢?
主要原因是系统可用性: 一旦系统过载,你或许没有办法从物理层面或者远程访问实例。通过外部监控进程,你可以在不需要访问服务器的前提下分析哪个地方出现的问题。另一个原因就是进程总是通过内核本身被创建以及被杀死。
因此,运行 top 命令你得不到任何信息,当你想要分析什么导致系统出现性能问题时已经为时已晚。你或许需要挖掘内核日志去查看哪个进程被杀死了。但使用监控仪表盘的话,你可以非常简单的回到过去查看哪个进程导致了这个问题。
现在已知道为什么要构建这样一个仪表盘,让我们看下为了构建它的架构是什么样的吧。
3
监控架构的细节
在我们查看我们将要使用的架构之前,我们想要使用一个这样的解决方案:
节省资源: 比如不会消耗我们主机上太多的资源;
易于安装: 不需要太多的时间进行实例化;
可扩展: 如果我们想要监控另一个主机,我们可以快速且高效的实现。
这些特点需要我们在这篇文章中始终需要牢记的。我们今天将要实践的具体细节是这样的:
我们的架构使用了四种不同的组件:
一个用来周期性提供指标到 Pushgateway 的 bash 脚本;
Pushga