一谈到监控，想必脑袋里面的词会以你从事的岗位为中心轴，喷出不少词语，比如面向系统运维的 zbbix、Cacti、Nagios，比如基于 ELK 的产品系列 - 日志易、袋鼠云，比如…
不多费口舌，自从有 ‘微服务’ 这个名词以来，在架构师、研发的小伙伴大声叫喊着 “微服务架构可以给你带来好处”的同时，运维与测试同学的内心应该是拔凉拔凉的，为啥？因为原本‘IOE 时代’的大集成，突然变成了一堆小碎片，环境怎么搭？出问题怎么排查？链路关系怎么整理？
尤其当产线出现异常或错误时，快速发现、定位、解决就变得尤其重要，相信很多同学都有过“出现问题，老板站在你背后看着你解决问题”的惨痛经历，而且还会问你“为什么我们不能早于客户发现问题呢？”
分久必合，合久必分
还是以微服务作为背景，去中心化变得很重要，但在很多系统的发展史中，基本路径都是“从系统孤岛 ——> 大一统或一大坨 ——>子系统系统拆分 ——> 微服务”
很难找到一套解决方案，伴随着这样一个路径成长或演化（本来监控就不是研发重视的视角），虽然 DevOPS 理念满天飞，而且方式也显得非常合体，但执行中，不是人的问题，就是这样那样的问题，很难短期达到效果
为什么要建这套监控平台，我们现状痛点是什么？
to 运维
系统往分布式系统的方向发展、系统和系统的依赖难以知晓
故障排查成本高
系统的压力和系统的水位分析
to 测试
压力分布测试难
to 开发
系统排查错误成本高
这套监控平台，能为我们提供什么呢？
一张清晰的系统概况 &网络拓扑
系统接口的依赖关系
针对请求的调用链关系
这套监控平台，我们如何实现他呢？
应用埋点
基于谷歌的 Google Dapper 为架构参照物
应用需按照要求输出日志
本文转载自头哥侃码公众号。
原文链接：https://mp.weixin.qq.com/s/NEmgMNfv2ytQGIQg3tY5yw
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论