Prometheus 序章/第一/二讲
Prometheus 序章
1 Prometheus的整体框架图
2 监控对运维的重要性
运维是什么？说白了就是管理服务器，保证服务器给线上产品提供稳定运行的服务环境
在控是什么？说白了就是用一种形式去盯着观察服务器把服务器的各种行为表现都显示出来用以发现问题和不足
报警是什么？监控和报警这两个词一定要分开说分开理解！监控是监控，报警是报警。控是把行为表现展示出来，用来观察的。报警则是当监控获取的数据发生异常并且到达了某个临界点的时候，采用各种途徑来通知用户通知管理员通知运维人员甚至通知老板。
很多时候总是把监控和报警混在一起说这是不正确的需要纠正
如下图所示
3 监控组成部分和流程
4 Prometheus + Grafana 的一个数据监控釆集成图
5 报警
报警跟监控严格来说是需要分开对待的
因为报警也有专门的报警系统
报警系统包括几种主要的展现形式：短信报警，邮件报警，电话报警（语音播报），通讯软件
不像监控系统比较成型的报警系统目前大多数都是收费的商业化
报警系统中最重要的一个概念之一就是对报警阈值的理解
阈值 （trigger Value），是监控系统中对数据到达某一个临界值的定义
例如：通过监控发现，当前某一台机器的CPU突然升高，到达了99%的使用率，99就是作为一次报警的触发阔值
6 pagerduty 商业报警系统
pagerduty
Pagerduty拥有短信，电话，邮件所有的报警机制
Pagerduty还有非常实用的必要的运维值班管理制度和报警升级等等扩展功能往后我们会陆续介绍到
Pagerduty的优点非常多，使用率非常高（外企几乎清一色的使用，国内企业很多也在使用）
但是有优点就肯定也有不足
Pagerduty有几个小问题需要提高
对中文的支持不好或者说几乎不支持（指的是语音播报方面）
站点主要在美国和海外网速有时候不太给力∞可以走代理的方式加快速度
7 Prometheus 的优劣
- 相比其他老款监控的不可被替代的巨大优势，以及一些不足有待提高的地方
- 监控数据的精细程度绝对的第一可以精确到1~5秒的采集精度我们来算算采集精度
- 集群部署的速度监控脚本的制作（指的是熟练之后）非常快速大大缩短监控的搭建时间成本周边插件很丰富大多数都不需要自己开发了
- 本身基于数学计算模型，大量的实用函数可以实现很复杂规则的业务逻辑监控（例如QPs的曲线弯曲凸起下跌的比例等等模糊概念）
- 可以嵌入很多开源工具的内部进行监控数据更准时更可信（其他监控很难做到这一点）
- 本身是开源的，更新速度快，bug修复快·支持N多种语言做本身和插件的二次开发
- 图形很高大上很美观老板特别喜欢看这种业务图（主要是指跟 Grafana的结合）
一些不足的地方
- 因其数据采集的精度如果集群数量太大，那么单点的监控有性能瓶颈目前尚不支持集群只能 workaround
- 学习成本太大，尤其是其独有的数学命令行（非常强大的同时又极其难学《=自学的情况下），中文资料极少，本身的各种数学模型的概念很复杂
- 对磁盘资源也是耗费的较大，这个具体要看监控的集群量和监控项的多少和保存时间的长短
- 本身的使用需要使用者的数学不能太差要有一定的数学头脑
