监控是基础设施，监控的重要性可想而知，但在平常工作中，很多监控做的大而全，指标繁杂，告警颇多，其实抓住重要的黄金指标，保持简单的架构就是最好的，今天来研究一番prometheus。
前面文章已经提及过了，可二进制、源码、包管理工具（yum、helm）安装。
因为prometheus是基于mertric的监控，所以不适用于日志logs、事件event、调用链tracing等监控，默认是pull模型，需要合理规划网络，最好不要转发，对于集群化以及水平扩展需要合理选择方案，查询范围过长需要降低采样，会导致精度降低，时序数据无法很好避免这一点，也是区别于日志系统的地方。
Prometheus属于CNCF项目，有比较丰富的开源生态，和传统zabbix监控不同，提供了丰富的exporter满足各种业务需求，可以看到官方以及第三方的exporter，也可以自己编写exporter，可以定制化，这是优势，但是太开放就会导致试错成本的增加，zabbix几行配置的事情，prometheus里就得搭配很多exporter才能完成，非官方的还会有不少的bug，当然设计之初也没想着像zabbix，就是开放自由。
k8s里那些组件会提供mertric接口呢，以下来介绍一番：
cadvisor: 集成在 Kubelet 中。
kubelet: 10255为非认证端口，10250为认证端口。
apiserver: 6443端口，监控请求数、延迟等。
scheduler: 10251端口
controller-manager: 10252端口
etcd: 如etcd 可以监控写入读取延迟、存储容量等
kube-proxy: 默认 127.0.0.1暴露10249端口,外部采集时可以修改为 0.0.0.0 监听，会暴露：写入
iptables 规则的耗时等指标
kube-state-metrics: K8S 官方项目，采集pod、deployment等资源的元信息。
node-exporter: Prometheus 官方项目，采集机器指标如 CPU、内存、磁盘。
blackbox_exporter: Prometheus 官方项目，网络探测，dns、ping、http监控
process-exporter: 采集进程指标
node-problem-detector: 即 npd，准确的说不是 exporter，但也会监测机器状态，上报节点异常打 taint
应用层 exporter: mysql、nginx、mq等，看业务需求JIANKONG1
这些组件监控展示一般用grafana，监控核心组件的状态、性能，如kubelet、apiserver等，现在kubesphere就是集成了这些监控，核心组件的模板可以在grafana市场参考dashboards-for-kubernetes-administrators。但是采集组件一多，exporter的集合是个问题，运维的压力就会变大，相关的资源控制以及版本升级都需要关注，可以用telegraf支持N合一。例如node-exporter不支持进程的监控，就可以使用telegraf，使用procstat的input采集进程指标。
google的sre手册中提出四个黄金指标：延迟、流量、错误数、饱和度。这里介绍比较简单的USE和REd标准。针对资源提供系统，可以使用utilization资源使用百分比、saturation资源使用的饱和度或过载程度、errors资源的出错率或出错数量。针对服务型系统，rate单位时间内完成请求的能力、errors错误率或者错误数量，单位时间内服务出错率或数量，duration单次服务持续实践，响应时延。
随着规模变大，prometheus的cpu和内存都会升高，内存一般会达到瓶颈、要么减少指标，要么加内存，单机版内存过大的原因，一个是隔一段时间作数据落盘，落盘之前数据在内存，所以和采集量有关，加载历史数据时候，是从磁盘到内存，查询范围越大，内存越大，不合理的查询条件也会造成增加内存。相关研究可以去官方github查看。
（1）基本HA：两套采集完全一样的指标，外挂负载均衡
（2）HA 外部存储，进行数据持久化
（3）联邦集群，按功能区分，采集数据由global节点统一存放，解决数据规模问题
还有很多需要学习，在实践中不断优化总结，相信一定可以将监控做得更好。快去实践，祝学习顺利！
END
作者｜希里安
