客观的来说 每⼀款监控⼯具 都有⾃⼰的优点缺点
并不是越 新的就⼀定越好 就拿 nagios 和 prometheus来说，虽然nagios它的年头很⽼了 ⽽且很多功能已经⽐较落后了
但是 nagios即便在今天 ， 运维⼯作中 依然有它独⽴存在的意 义 ⽐如说： 我之前所在的⼀家公司，我们核⼼监控使⽤的是 promethues ，
但是发现 prometheus这个⾼⼤上的监控⼯具 在 某些很基本的监控项⽬中 反⽽不如nagios好⽤ ⽐如 我们对⼀个整机的监控 ping 和 telnet port promethues 对这两项 最简单的监控 反⽽做的不够好
(promethues 有⼀个up 功能函数 ⽤来实现这种 ping port 的持 续监控，但是由于这种 ping类的监控 ，是⼀次性的发⽣ 并切 只有两个状态 up and down， 这样以来 就只有 0 1 两个数值会 显⽰在promethues(不能直接连接服务器， exporter pushgateway GET POST)上，很多时候 汇总出来的图形 会有 误差)
所以 我们后来 针对这种最简单的 ping and port 直接就迁移进⼊ nagios ， 发现nagios对这种 状态⽐较少的简 单监控 是最优秀的 ⽽且还⾮常省时省⼒ prometheus呢，就专门⽤来应付 ⽐较难的监控业务逻辑需 求，最简单的监控 交给nagios。 这样集联的来使⽤ 反⽽更能 让监控体系完善 所以说 也证实了 我刚才提到的 并不是越新的⼯具 就越好， ⽽且最合适的⼯具 使⽤在最合适的地点 才是最好的 这也是 我们作为⼀个运维架构师 在给企业 做综合框架设计时 的⼀种 专业态度 ⼀句话 不要⼀味的只知道追新
另外，prometheus 当前在国外 尤其是欧美国家 是⾮常流⾏了 带起了⼀股 ⽤数学家的头脑做监控的风潮 国外 （讲座） promethues经过充分学习和练习之后，它的搭建速度 神⼀般 的快速 下载和安装 就不⽤说了 很简单快速 ⽽对于 它的监控采集脚本开发 其重复利⽤的成本⾮常的低 尤 其是系统基础层的监控 ⼏乎不⽤做什么修改 直接放上去就可 以再利⽤ grafana也是⼀样 还记得咱们学过的 json导出吗 也是⼀样的优 点
另外 随着对 prometheus各种函数 以及Linux系统底层的深⼊ 理解， 我们能⾃⾏实现的监控项⽬ 会越来越丰富 越来越精细 ⽽这种精细 让我们未来的 实现真实链路监控的⽬标 变得越来 越近了
监控 在我们运维⼯作当中 保证线上的稳定（运维⾃动化开发 devops） 可以说是第⼀优先级 记得有⼀个⽼运维说过这么⼀句话， 监控如果真的做的完美 了，我们运维也就可以⾼枕⽆忧了 每天可以就看看监控 然后 各种的去 '挑刺⼉’ 就⾏了 ???? 可以看出来 监控在运维中的这种核⼼地位 不可动摇
