手机下载视频网站模板,yangdesign工业设计公司,网站流量工具,wordpress 新添加页面模板又一项看似技术需求驱动#xff0c;最终发现还是业务需求驱动的体系化建设。 0. 目录结构 1. 中拔出溜公司的特点2. 达成共识3. 推荐落地路线3.1 理论解析3.2 Loki Promtail Grafana 轻量级零侵入方案3.3 接入traceId3.4 基础设施监控 后记相关 1. 中拔出溜公司的特点
在传… 又一项看似技术需求驱动最终发现还是业务需求驱动的体系化建设。 0. 目录结构 1. 中拔出溜公司的特点2. 达成共识3. 推荐落地路线3.1 理论解析3.2 Loki Promtail Grafana 轻量级零侵入方案3.3 接入traceId3.4 基础设施监控 后记相关 1. 中拔出溜公司的特点
在传统软件行业中技术团队的发展(现状篇)中我专门针对中拔出溜公司特点进行过系统阐述。但就今天的主题我再针对性补充一下
业务场景要求低。 这个是根因之后介绍的一系列特点最终都能落回这一视角上。 1.1 业务停止系统重启这些都不是事而且系统基本就工作时间使用其他时间还得被研发吐槽 都下班了积极个毛线。 1.2 出现了问题之后都不要用系统了我这日志翻看不过来是的研发人员都是登录服务器之后使用文本工具打开日志文件翻找原因的 —— 你想想 只有其他操作都停止我这边重放报错接口错误日志的最后几条才会是我想要关注的。 1.3 功能做出来就行诸如系统稳定性易操作性等非功能性需求无所谓啦。CRUD研发。上述背景下对于相应研发的要求自然不会高技术方面会CRUD堆代码就完事了重点是业务知识和经验。至于什么微服务化那更多是业务/标书需求别太认真。无专业运维。就上面这个要求还要毛线的专业运维研发和售后你们自己内部把相应职责分一下就完了。
以上背景之下对于监控这种收益滞后的纯成本支出肯定是能省就省
优先级严重滞后叠加上人员认知不足一般情况下除了日志之外没有其他系统运行时的常驻监控手段。即使日志这东西也是写的时候嫌麻烦用到的那一刻才嫌少当时赌咒发誓事后就是事情都过去了你还纠缠有意思吗除此之外其它的监控手段基本都被用成了事后监控也就是接到用户反馈的问题别问我为什么不是接到系统告警三板斧用完发现还是没有头绪才会病急乱投医地临时找一堆监控软件给装上。但往往是此刻问题已经发生而最关键的问题出现前后的监控数据无法获取这导致在面对一些偶发性问题时非常被动。
2. 达成共识
传统软件公司对于监控的推进其实最重要的是取得均衡找到那个动态变化的平衡点
一开始各方对于监控毫无概念只是限于当前出现的棘手问题迫切希望能够通过纳入某些新鲜事物(例如监控)来缓解困境。这个时候你需要借助前期的大量积累和预演能够在短期内帮助它们解决/至少让各方相信你的这步推进是让问题在向好的方向变化如此在之后的合作中让对方愿意遵从你的建议做出一些改变最终进入一个改进计划稳定迭代优化的良性发展中。这一点不仅仅针对监控体系的落地而这里面非常重要的一点就是你的方案不能要求对方对自身现状做出过多的调整和适应 —— 直接给出一个粗略的标准就是这样的要求每多一条推进成功率下降30%起步阶段最好是对方不需要任何改动。毕竟对方直到现在都对监控投入不多那说这一块并没有那么痛。在他们目前的认知里当前属于极端情况偶尔一两次可以接受。
我们的终极目标是在尽量少的团队阻力之下以尽量低的成本维持一个能够长期运行的监控体系加快问题排查效率增强系统稳定性最终增加研发人员的工作价值感幸福感。而这需要多方面努力除了技术本身团队现状业务场景需求等等的考量更重要。
3. 推荐落地路线
3.1 理论解析
a. 监控的用途 抛开照本宣科地给出一大段监控或可观测性的基本定义这里我更愿意给出自己对于中拔出溜的公司这个一限定条件下对于监控功能的理解 —— 主要分两大块
尽快解决发现的问题。 被告知问题发生之后能够快速介入、定位、解决实现高效排错。 1.1 这个时间越短越好。 1.2 这个在标准理论体系下意味着一个专有名词 MTTR (Mean Time To Repair平均修复时间)指系统从发生故障到维修结束之间的时间段的平均值。这里我们暂时将系统问题发生时间和被发现时间等同借助统计分析和专家知识挖掘系统里隐藏在海面之下的冰山。 2.1 相较于上面的排错已知问题这应该才是监控的更大价值体现。 2.2 可惜对于业务导向的中拔出溜公司而言因为项目周期等原因对于这一块的重视基本等同于零。
b. 监控的五个层级
端监控。 即客户端例如APP浏览器等。业务层监控。 例如QPS每日订单量每日注册用户数量等。应用层监控。应用监控。例如JVM链路追踪等。本场景下的重点中间件监控。MQMysqlredis等等。本场景下的次重点系统层监控。CPU网速磁盘IO内存等等。本场景下的次重点
c. 可观测性的三支柱
Log。本场景下的重点Trace。本场景下的次重点Metrics 。 “通过查看和分析高维度和高基数数据发现埋藏在复杂系统架构中的隐藏问题而且不需要事先预测问题可能发生在哪里以及问题发生的模式”
本小节接下来的部分我就给出自己多年实践后的思考总结 - 起步三板斧
从日志入手辅助进行问题排查以及尽力而为的Metrics。 1.1 因为日志的普及性相关人员即使再想偷懒出于自身利益考虑他也得打印一些系统运行日志所以将日志作为监控落地起步的第一阶段非常合适 —— 在不需要对方调整的情况下先让对方看到一些好处这会让之后的继续推进减少很多阻力。 1.2 作为自下而上推动监控体系落地的起步阶段你需要尽量做到一鸣惊人为之后的进一步推进打下基础。接入traceId。 2.1 初期只做到这一步不要去想什么酷炫的链路图表展示自下而上的方案推进最忌讳的就是冒进小步前进并且持续监控改进措施执行时的相关表现。 2.2 这一步在上一步打下的基础上推进会简单一些一来你已经获得了基础的信任二来这一项改动对于相关团队的工作量不高都不会涉及业务代码的调整。纳入基础设施 / 中间件监控。对于无法稳定复现的问题我们往往需要更多的监控信息来辅助我们的决策这个时候就需要考虑其他层面的监控了。关于这个选择可就相当多了。在接下来的小节里再作专门介绍。
3.2 Loki Promtail Grafana 轻量级零侵入方案
相较于ELK的笨重Linux-Grep命令的简陋Loki这一套解决方案正好位于中间位置
既足够轻量Loki和Promtail都只是一个独立运行的exe应用无额外依赖这就意味着相当低的运维成本又有足够的颜值(Grafana的图表化展示对领导汇报和效果呈现有奇效)操作便捷性、相当低的入门门槛(LogQL官方文档拢共只有寥寥数页)。
这非常适合在对于监控基本概念都缺失的团队打开缺口为监控的进一步落地开个好头
即使1-3月周期的项目型团队他们出于自身利益的考量也肯定会记录日志。这类团队肯定是采取脚手架 业务代码的模式而且日志这一块投入精力绝对是能省则省属于最开始配置一次之后职业生涯结束都很可能不会再关注的东西所以即使是这样的天崩开局的团队里也是可以找到优势的 只要你编写出一个针对性的Loki Promtail Grafana配置那么可以应用到该团队所接手的每个项目里而且随着采用你这套方案解决的问题越来越多整个团队都会因此进入对监控知识的主动了解中。即使团队规模/脚手架千差万别但基本的日志格式可以肯定只有少数几种甚至对于绝大部分小型团队都属于是网上直接抄的你不强制要求他都不会去主动了解曲中的含义这样所造成的意外好处就是 —— 本方法只要做一次就意味大部分的工作基本完成了接入的团队数量和需要投入的精力并不是线性关系。以点打面的神奇效果。
3.3 接入traceId
上面的这一套Loki方案其实已经满足绝大部分问题排查需求了。不过考虑到ROI非常推荐在此基础上马上再进一步 —— 推动研发团队实现日志中traceId的注入。
建议简单项目可以自己写或者借助TLog - 一个轻量级的分布式日志标记追踪神器这类专职的轻量级第三方库复杂的项目推荐Skywalking等。
如此的好处是能够快速从冗杂的日志中快速筛选出自己真正感兴趣的那部分内容实现在大海中精确定位每一滴水滴。
3.4 基础设施监控
上面的方案对于绝大部分团队其实都已经满足90%以上的监控需求。但是对于少数疑难杂症你需要结合应用所在的环境也即是操作系统容器虚拟机等等一并进行考虑这个时候你就要考虑接入基础设施等的监控以更全面的监控数据来辅助问题定位和排查。
关于这一块的工具选型过往我做过很多尝试但最终落地经验并不说以下就列出一些用过或者关注时间比较长的
PrometheusWGCloud - 极简高效的主机监控系统HertzBeat - 无需Agent的实时监控工具Phoenix - 开源监控平台Flashcat (这个属于一直在关注但未投入生产)
后记
以上路线属于最标准的自下而上推进 —— 完全兼容现状属于晓之以理不如诱之以利先让对方看到效果然后反向推进改良。
然后我需要特意强调一下我们对于监控工具的选型不要陷入刘姥姥进大观园困境 —— 觉得这个牛逼、那个更好。选适合你们的够用就行最重要的是部署方便运维成本低深入进去用好一个工具而不是狗熊掰棒子。
最后在落地过程中要进行持续性评估切勿存在一劳永逸的想法。
相关
【DEVOPS】关于“可观测性“【DEVOPS】现状篇【DEVOPS】技术团队角色分工高级研发的基本素养传统软件行业中技术团队的发展(现状篇)传统软件行业中技术团队的发展(团队破局篇)传统软件行业中技术团队的发展(个人破局篇)《极客时间 - 深入浅出可观测性》《极客时间 - 运维监控系统实战笔记》Github - google/mtail - extract internal monitoring data from application logs for collection in a timeseries databaseGithub - grok_exporter - Export Prometheus metrics from arbitrary unstructured log data.
