我的监控故事我做了两年多的运维工作，然后转做运维平台开发，眼看着监控系统一步步变得越来越无用。1.有用的监控我在运维负责oncall的时候，一直觉得监控系统还行，不是因为我做的东西太多，而是因为运维的业务还是单体应用，监控不多需要添加。记得当时公司还在用Nagios（估计新人知道的不多），但是监控和维护工作真的很费劲。后来开始研究zabbix。最大的优点是可以发现&自动添加监控。后来我又搭了一套ELK，把所有的业务日志收集在一起，监控一起来。由于没有添加太多告警，所以基本上每个告警都要处理。最常见的问题是百度抓取数据。我有一套久经考验的处理流程：看指标：如果xx业务负载高，有90%的概率是爬虫造成的。查看日志：查看kibana上的访问记录，找出topx的IP段。密封访问：用iptables密封。这是我唯一的运维监控经验。因为业务简单，监控也比较原始，所以感觉告警有用。2.无用的dashboards1）疯狂的自动化当我转做运维开发的时候，发现运维的监控需求也变了。因为自动化能力的提升，各种开源的监控系统也逐渐完善，运维也开始拼命给平台增加各种自动化需求。对于监控系统，各种监控模板、告警模板、grafana自动与业务绑定。仪表板。结果也可想而知，因为告警太多，运维直接屏蔽了公司的告警短信。大多数情况下，问题是在业务端发现的，然后运维介入调查。2）好看但无用的仪表板。由于收集的指标太多，为了输出到业务端，运维创建了一个grafanadashboard。但是由于grafanadashboard上的指标太多，导致页面经常会卡顿。业务研发一个页面看几十个指标，不知道哪个有用，最后只好来运维了。为了方便研发查看日志，运维还开发了ELK来收集各种日志，然后把kibana留给业务研发。结果也可想而知，除了少数爱折腾的人，看kibana上的dashboard的人不多。我一直认为，运维的初衷是好的，但是从结果来看，只有运维才是爆笑的。毕竟运维很少看自己做的dashboard……3.没有质变。魏似乎找到了最后一根稻草，毕竟这是谷歌的运维方法论。于是，运维团队开始和研发一起制定各种SLO和SLI指标，并根据四大黄金指标（延迟、流量、错误、饱和度）不断丰富自己的告警库，制定了P0、P1、P2等告警分类，试图改变目前的困境。但是由于业务架构的微服务化以及敏捷开发模式的采用，业务的迭代速度其实是非常快的。大部分sres本身就不是开发出身，同时配比严重不足（研发和运维的配比），导致各种指标随着时间的推移快速失效。结果是这个告警还是没用，每次恢复盘的时候又加一个告警。当然，这个警报几乎从不触发。这就是我经历过的监控故事，你有哪些故事呢？监督偏差在总结这些失败的监督经验的过程中，我发现了两个本质问题：我一直试图通过概括过去发生的个别问题来预测未来可能发生的普遍问题，而忽略了未来是复杂的在时间和空间上的变化。一直专注于优化传统的探针模型（使用脚本测试、检查恢复和告警）、图形化趋势展示、告警模型，不断提高相关流程的自动化程度。以上问题仅代表我目前对监控的理解，不知道对错，也没有答案。以下是我对目前监控系统建设的一些看法。1、人工智能或人机交互喝咖啡运维。这句话是我以前的同事给我印象最深的一句话。说完这句话半年后，他开始研究AIOps，又过了半年就离职了，群里就没人再提AIOps了。大部分运维对AIOPS最大的需求可能就是根因分析，但这就像一座站在AIOps门外的大山，大部分运维团队连攀登的勇气都没有。一直想弄明白一个问题：连运维自己都不一定能查出问题的原因，为什么会指望机器能做到这一点。与人和机器相比，机器更擅长分析海量数据，而人类更擅长做决策。所以相比aiops，我觉得人机交互可能更靠谱一些。机器对海量数据进行综合分析，运维人员根据分析结果进行人脑决策。但是我觉得这并不容易，因为现在的sre都在沉迷于开发，顾不上这些事情。决策本身也需要对数据有一定的敏感性。2.监控要注重能力建设以往的监控体系建设，人们普遍喜欢按照结构做垂直切分，可能看起来是这样的：我认为造成这种分层的主要原因是：组织结构（康威定律）和职责分离。在这种分层下，运维通常只负责下面两层。对于上层问题的处理，定位到具体的URL后可能就结束了，剩下的留给研发。如果要解决目前的困境，我觉得应该摒弃过去按职责分工建设体系的方式，比如建设基础监控体系、网络监控体系、业务监控体系，转而围绕各地分阶段进行能力建设。业务价值，如基本的数据采集、传输、分析、存储、展示等能力。转变为提供海量数据采集和集中规则计算、统一分析和报警能力的现代监控系统[googlesre]TVP），并在团队中分享最佳实践并积极为用户赋能，逐步成就优秀用户。同时，要避免共享未实现的方法论，毕竟大家都很忙。3、力求有效在处理问题的时候，你会发现公司的监控系统比你知道的要多。运维、研发、DBA、redis等各个部门都有自己的监控系统和dashboard。我个人看的是我自己部门的监控。为了能够建立统一的视角，有能力的公司会想出类似统一监控的东西：从不同的系统获取各种数据，进行统一的汇总分析和存储，最后统一监控带来数据的实时性和准确性，存储成本、海量数据处理等新问题，这件事一时半会儿解决不了。但这真的有意义吗？收集、分析和存储这些基础数据实际上有很多商业解决方案。为什么你觉得几个人的小团队和一堆开源软件比几十人的专业团队做得更好？更好的是，这件事离业务这么远，除了让你的KPI看起来更好之外，可能不会带来任何其他变化。随着造轮子越来越多，我渐渐发现自己越来越不灵了，一直在基本问题上徘徊。通常问题越基础，解决方案越通用，解决这类问题的ROI越低，所做的工作就越无效。不要过分强调自己场景的特殊性，除非你只是想做一些虚荣心指标，而没有解决本质问题。那么什么有效？我认为核心是：以用户和业务为中心，摒弃过去通过经验归纳来解决共性问题，尝试用数据分析的人机交互来聚焦核心业务，用AI/自动化处理来支撑业务和通用商业。但这很难。幸运的是，我不监视它。展望去年，与监控相关的方向有一个很火的方向：可观察性。我对可观察性没有太多的实践，但是在和朋友谈论可观察性时发现了一些问题。在这里我想写下我的困惑：1）可观察性解决了哪些问题？每当我谈到可观察性时，我发现大家都一致认为可观察性可以解决所有问题，就像屠龙刀一样，所过之处不长草。但是如果你细问Observability做了什么，你会觉得时间有点落后，又回到了各种仪表盘和全屏指标的时代。您有关于可观察性的故事吗？2）数据采集全面开花。感觉可观察性技术的发展非常快，相关的开源项目也越来越多。但是，在数据采集中有一个问题让我很吃惊：有一天有人告诉我可以在生产环境中采集。Profiling做可观察性定位业务代码问题。惊奇的地方不在于技术实现，而在于什么样的业务需要这种级别的可观察性，这种可观察性的用户是谁，要解决的问题是什么？你有答案吗？3）新瓶装旧酒如果你跟同事介绍可观察性由metric、log、tracing三部分组成，很容易被老运维diss，他会告诉你我们已经有了现在。就是不太好用，充实一下就好了。这不是什么新鲜事，只是新瓶装旧酒。这个时候我通常会提出之前Google发的<
