几点原则
监控是基础设施，目的是为了解决问题，不要只朝着大而全去做，尤其是不必要的指标采集，浪费人力和存储资源（To B商业产品例外）。
需要处理的告警才发出来，发出来的告警必须得到处理。
简单的架构就是最好的架构，业务系统都挂了，监控也不能挂。Google Sre 里面也说避免使用 Magic 系统，例如机器学习报警阈值、自动修复之类。

prometheus的局限
Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。
Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。
对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos等方案。
监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。
Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果
查询范围过长要做降采样，势必会造成数据精度丢失，不过这是时序数据的特点，也是不同于日志系统的地方。

合理选择黄金指标
采集的指标有很多
Google 在“Sre Handbook”中提出了“四个黄金信号”：延迟、流量、错误数、饱和度。
实际操作中可以使用 Use 或 Red 方法作为指导，Use 用于资源，Red 用于服务。
Use 方法：Utilization、Saturation、Errors。如 Cadvisor 数据
Red 方法：Rate、Errors、Duration。如 Apiserver 性能指标

Prometheus 采集中常见的服务分三种：
在线服务：如 Web 服务、数据库等，一般关心请求速率，延迟和错误率即 RED 方法
离线服务：如日志处理、消息队列等，一般关注队列数量、进行中的数量，处理速度以及发生的错误即 Use 方法
批处理任务：和离线任务很像，但是离线任务是长期运行的，批处理任务是按计划运行的，如持续集成就是批处理任务，对应 K8S 中的 job 或 cronjob， 一般关注所花的时间、错误数等，
因为运行周期短，很可能还没采集到就运行结束了，所以一般使用 Pushgateway，改拉为推。