中拔出溜的公司如何落地监控体系

又一项看似技术需求驱动,最终发现还是业务需求驱动的体系化建设。

0. 目录结构

      • 1. 中拔出溜公司的特点
      • 2. 达成共识
      • 3. 推荐落地路线
        • 3.1 理论解析
        • 3.2 Loki + Promtail + Grafana 轻量级零侵入方案
        • 3.3 接入traceId
        • 3.4 基础设施监控
      • 后记
      • 相关

1. 中拔出溜公司的特点

在传统软件行业中技术团队的发展(现状篇)中我专门针对中拔出溜公司特点进行过系统阐述。但就今天的主题,我再针对性补充一下:

  1. 业务场景要求低。 这个是根因,之后介绍的一系列特点最终都能落回这一视角上。
    1.1 业务停止,系统重启,这些都不是事;而且系统基本就工作时间使用,其他时间还得被研发吐槽: 都下班了积极个毛线。
    1.2 出现了问题之后:都
    不要用系统了,我这日志翻看不过来(是的,研发人员都是登录服务器之后使用文本工具打开日志文件翻找原因的) —— 你想想, 只有其他操作都停止,我这边重放报错接口,错误日志的最后几条才会是我想要关注的。
    1.3 功能做出来就行,诸如系统稳定性,易操作性等非功能性需求无所谓啦。
  2. CRUD研发。上述背景下,对于相应研发的要求自然不会高,技术方面会CRUD堆代码就完事了,重点是业务知识和经验。至于什么微服务化那更多是业务/标书需求,别太认真。
  3. 无专业运维。就上面这个要求还要毛线的专业运维,研发和售后你们自己内部把相应职责分一下就完了。

以上背景之下,对于监控这种收益滞后的纯成本支出,肯定是能省就省:

  1. 优先级严重滞后,叠加上人员认知不足,一般情况下除了日志之外没有其他系统运行时的常驻监控手段。
  2. 即使日志这东西,也是"写的时候嫌麻烦,用到的那一刻才嫌少";当时赌咒发誓,事后就是"事情都过去了,你还纠缠有意思吗"
  3. 除此之外,其它的监控手段基本都被用成了事后监控,也就是接到用户反馈的问题(别问我为什么不是接到系统告警),三板斧用完发现还是没有头绪,才会病急乱投医地临时找一堆监控软件给装上。但往往是此刻问题已经发生,而最关键的"问题出现前后的监控数据"无法获取,这导致在面对一些偶发性问题时非常被动

2. 达成共识

传统软件公司对于监控的推进,其实最重要的是取得均衡,找到那个动态变化的平衡点

  1. 一开始各方对于监控毫无概念,只是限于当前出现的棘手问题迫切希望能够通过纳入某些新鲜事物(例如监控)来缓解困境。
  2. 这个时候你需要借助前期的大量积累和预演,能够在短期内帮助它们解决/至少让各方相信你的这步推进是让问题在向好的方向变化,如此在之后的合作中让对方愿意遵从你的建议做出一些改变,最终进入一个改进计划稳定迭代优化的良性发展中。(这一点不仅仅针对监控体系的落地)
  3. 而这里面非常重要的一点就是你的方案不能要求对方对自身现状做出过多的调整和适应 —— 直接给出一个粗略的标准就是:这样的要求每多一条,推进成功率下降30%,起步阶段最好是对方不需要任何改动。毕竟对方直到现在都对监控投入不多,那说这一块并没有那么痛。在他们目前的认知里,当前属于极端情况,偶尔一两次可以接受。

我们的终极目标是在尽量少的团队阻力之下,以尽量低的成本,维持一个能够长期运行的监控体系,加快问题排查效率,增强系统稳定性,最终增加研发人员的工作价值感,幸福感。而这需要多方面努力,除了技术本身,团队现状,业务场景需求等等的考量更重要。

3. 推荐落地路线

3.1 理论解析

a. 监控的用途
抛开照本宣科地给出一大段监控或可观测性的基本定义,这里我更愿意给出自己对于"中拔出溜的公司"这个一限定条件下,对于监控功能的理解 —— 主要分两大块:

  1. 尽快解决发现的问题。 被告知问题发生之后能够快速介入、定位、解决,实现高效排错。
    1.1 这个时间越短越好。
    1.2 这个在标准理论体系下意味着一个专有名词: MTTR (Mean Time To Repair,平均修复时间),指系统从发生故障到维修结束之间的时间段的平均值。(这里我们暂时将系统问题发生时间和被发现时间等同)
  2. 借助统计分析和专家知识挖掘系统里隐藏在海面之下的冰山。
    2.1 相较于上面的"排错已知问题",这应该才是监控的更大价值体现。
    2.2 可惜对于业务导向的"中拔出溜公司"而言,因为项目周期等原因,对于这一块的重视基本等同于零。

b. 监控的五个层级

  1. 端监控。 即客户端,例如APP,浏览器等。
  2. 业务层监控。 例如QPS,每日订单量,每日注册用户数量等。
  3. 应用层监控。应用监控。例如JVM,链路追踪等。(本场景下的重点)
  4. 中间件监控。MQ,Mysql,redis等等。(本场景下的次重点)
  5. 系统层监控。CPU,网速,磁盘IO,内存等等。(本场景下的次重点)

c. 可观测性的三支柱

  1. Log。(本场景下的重点)
  2. Trace。(本场景下的次重点)
  3. Metrics 。 “通过查看和分析高维度和高基数数据,发现埋藏在复杂系统架构中的隐藏问题,而且不需要事先预测问题可能发生在哪里,以及问题发生的模式”

本小节接下来的部分我就给出自己多年实践后的思考总结 - 起步三板斧:

  1. 从日志入手,辅助进行问题排查,以及尽力而为的Metrics。
    1.1 因为日志的普及性(相关人员即使再想偷懒,出于自身利益考虑他也得打印一些系统运行日志),所以将日志作为监控落地起步的第一阶段非常合适 —— 在不需要对方调整的情况下,先让对方看到一些好处,这会让之后的继续推进减少很多阻力。
    1.2 作为自下而上推动监控体系落地的起步阶段,你需要尽量做到一鸣惊人,为之后的进一步推进打下基础。
  2. 接入traceId。
    2.1 初期只做到这一步!不要去想什么酷炫的链路图表展示,自下而上的方案推进最忌讳的就是冒进,小步前进并且持续监控改进措施执行时的相关表现。
    2.2 这一步在上一步打下的基础上推进会简单一些,一来你已经获得了基础的信任,二来这一项改动对于相关团队的工作量不高,都不会涉及业务代码的调整。
  3. 纳入基础设施 / 中间件监控。对于无法稳定复现的问题,我们往往需要更多的监控信息来辅助我们的决策,这个时候就需要考虑其他层面的监控了。关于这个选择可就相当多了。在接下来的小节里再作专门介绍。
3.2 Loki + Promtail + Grafana 轻量级零侵入方案

相较于ELK的笨重,Linux-Grep命令的简陋,Loki这一套解决方案正好位于中间位置:

  1. 既足够轻量;(Loki和Promtail都只是一个独立运行的exe应用,无额外依赖,这就意味着相当低的运维成本)
  2. 又有足够的颜值;(Grafana的图表化展示,对领导汇报和效果呈现有奇效)
  3. 操作便捷性、相当低的入门门槛;(LogQL官方文档拢共只有寥寥数页)。

这非常适合在对于监控基本概念都缺失的团队打开缺口,为监控的进一步落地开个好头:

  1. 即使"1-3月周期"的项目型团队,他们出于自身利益的考量,也肯定会记录日志。
  2. 这类团队肯定是采取脚手架 + 业务代码的模式,而且日志这一块投入精力绝对是能省则省,属于最开始配置一次之后,职业生涯结束都很可能不会再关注的东西;所以即使是这样的天崩开局的团队里也是可以找到优势的: 只要你编写出一个针对性的Loki + Promtail + Grafana配置,那么可以应用到该团队所接手的每个项目里,而且随着采用你这套方案解决的问题越来越多,整个团队都会因此进入对监控知识的主动了解中。
  3. 即使团队规模/脚手架千差万别,但基本的日志格式可以肯定只有少数几种,甚至对于绝大部分小型团队,都属于是网上直接抄的,你不强制要求他都不会去主动了解曲中的含义;这样所造成的意外好处就是 —— 本方法只要做一次,就意味大部分的工作基本完成了,接入的团队数量和需要投入的精力并不是线性关系。以点打面的神奇效果。
3.3 接入traceId

上面的这一套Loki方案其实已经满足绝大部分问题排查需求了。不过考虑到ROI,非常推荐在此基础上马上再进一步 —— 推动研发团队实现日志中traceId的注入。

  1. 建议简单项目可以自己写或者借助TLog - 一个轻量级的分布式日志标记追踪神器这类专职的轻量级第三方库,
  2. 复杂的项目推荐Skywalking等。

如此的好处是能够快速从冗杂的日志中,快速筛选出自己真正感兴趣的那部分内容,实现"在大海中精确定位每一滴水滴"。

3.4 基础设施监控

上面的方案对于绝大部分团队其实都已经满足90%以上的监控需求。但是对于少数疑难杂症,你需要结合应用所在的环境(也即是操作系统,容器,虚拟机)等等一并进行考虑,这个时候你就要考虑接入基础设施等的监控,以更全面的监控数据来辅助问题定位和排查。

关于这一块的工具选型,过往我做过很多尝试,但最终落地经验并不说,以下就列出一些用过或者关注时间比较长的:

  1. Prometheus
  2. WGCloud - 极简&高效的主机监控系统
  3. HertzBeat - 无需Agent的实时监控工具
  4. Phoenix - 开源监控平台
  5. Flashcat (这个属于一直在关注,但未投入生产)

后记

以上路线属于最标准的自下而上推进 —— 完全兼容现状,属于"晓之以理,不如诱之以利",先让对方看到效果,然后反向推进改良。

然后我需要特意强调一下,我们对于监控工具的选型,不要陷入"刘姥姥进大观园"困境 —— 觉得这个牛逼、那个更好。选适合你们的,够用就行;最重要的是部署方便,运维成本低;深入进去用好一个工具,而不是狗熊掰棒子。

最后,在落地过程中要进行持续性评估,切勿存在"一劳永逸"的想法。

相关

  1. 【DEVOPS】关于“可观测性“
  2. 【DEVOPS】现状篇
  3. 【DEVOPS】技术团队角色分工
  4. 高级研发的基本素养
  5. 传统软件行业中技术团队的发展(现状篇)
  6. 传统软件行业中技术团队的发展(团队破局篇)
  7. 传统软件行业中技术团队的发展(个人破局篇)
  8. 《极客时间 - 深入浅出可观测性》
  9. 《极客时间 - 运维监控系统实战笔记》
  10. Github - google/mtail - extract internal monitoring data from application logs for collection in a timeseries database
  11. Github - grok_exporter - Export Prometheus metrics from arbitrary unstructured log data.

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/794332.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

力扣---删除链表的倒数第 N 个结点

给你一个链表,删除链表的倒数第 n 个结点,并且返回链表的头结点。 示例 1: 输入:head [1,2,3,4,5], n 2 输出:[1,2,3,5]示例 2: 输入:head [1], n 1 输出:[]示例 3&#xff1a…

解决Word文档中插入MathTypeca公式编号问题(适用于本科、硕士、博士论文编写)

公式编号 这写论文过程中,我们常用到的就是根据章节号要求每写一个公式就自动编号,而不是(1)、(2)之类的。那么如下图这样的是怎么实现的呢? 1.开启Mathtype右编号 这样你才能有一个编号的格式 2.对公式进行格式化…

C++入门(以c为基础)——学习笔记2

1.引用 引用不是新定义一个变量,而是给已存在变量取了一个别名,编译器不会为引用变量开辟内存空 间。在语法层面,我们认为它和它引用的变量共用同一块内存空间。 可以取多个别名,也可以给别名取别名。 b/c/d本质都是别名&#…

网络通信(二)

UDP服务器接收数据和发送数据 UDP协议时,不需要建立连接,只需要知道对方的IP地址和端口号,就可以直接发数据包。但是,能不能到达就不知道了。虽然用UDP传输数据不可靠,但它的优点是和TCP比,速度快&#xf…

C++的 stack和queue 的应用和实现【双端队列的理解和应用】

文章目录 stack的理解和应用栈的理解栈的模拟实现string实现stackvector实现stack queue的理解和应用队列的理解队列的模拟实现 双端队列原理的简单理解deque的缺陷为什么选择deque作为stack和queue的底层默认容器STL标准库中对于stack和queue的模拟实现stack的模拟实现queue的…

【LangChain学习之旅】—(19)CAMEL:通过角色扮演进行思考创作内容

【LangChain学习之旅】—(19)CAMEL:通过角色扮演进行思考创作内容 CAMEL 交流式代理框架股票交易场景设计场景和角色设置提示模板设计定义CAMELAgent类,用于管理与语言模型的交互预设角色和任务提示任务指定代理系统消息模板创建 Agent 实例头脑风暴开始总结大模型的成功,…

CSRF介绍及Python实现

CSRF 文章目录 CSRF1. CSRF是什么?2. CSRF可以做什么?3. CSRF漏洞现状4. CSRF的原理5. 举例说明6. CSRF的防御Python示例 1. CSRF是什么? CSRF(Cross-Site Request Forgery),中文名称:跨站请求…

来get属于你的达坦科技令人心动的offer吧!

我们是谁 达坦科技始终致力于打造高性能Al Cloud 基础设施平台DatenLord,积极推动AI应用的落地。DatenLord通过软硬件深度融合的方式,提供高性能存储和高性能网络。为AI 应用提供弹性、便利、经济的基础设施服务,以此满足不同行业客户对AICl…

网络规划(homework 静态路由 and Rip路由表更新)

1、写出下图路由器1和路由器3中的路由表(按直接交付、特定主机交付、特定网络交付、 默认交付的顺序放置路由项) 2、写出Ri更新后的路由表(rip路由协议) 1、将Rj广播的路由消息全部1 2、直接对照着更新Ri中的路由表

SQLite字节码引擎(十二)

返回:SQLite—系列文章目录 上一篇:SQLite的架构(十一)() 下一篇:SQLite—系列文章目录 1、 摘要 SQLite 的工作原理是将 SQL 语句转换为字节码和 然后在虚拟机中运行该字节码。本文档 …

关于地球内部猜想,火山和地震成因“之一”

地球内部是一个核反应堆,核反应堆向外释放能量。地面的火山和地震成因“之一”,太阳等能量可以通过辐射到达地球,南北极能量最强,因为磁场原因,地球上的四季是因为大气流动形成的,大气遵循涡流管的运动规律…

Python网络爬虫(五):b站弹幕

上一篇对b站的视频评论爬取进行了探讨,这一篇是弹幕。直接上代码: import csv import json import re import chardet import requestsheaders = {user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Saf…

车载电子电器架构 —— 工程EOL诊断

车载电子电器架构 —— 工程EOL诊断 我是穿拖鞋的汉子,魔都中坚持长期主义的汽车电子工程师。 老规矩,分享一段喜欢的文字,避免自己成为高知识低文化的工程师: 屏蔽力是信息过载时代一个人的特殊竞争力,任何消耗你的人和事,多看一眼都是你的不对。非必要不费力证明自己…

Navicat工具使用

Navicat的本质: 在创立连接时提前拥有了数据库用户名和密码 双击数据库时,相当于建立了一个链接关系 点击运行时,远程执行命令,就像在xshell上操作Linux服务器一样,将图像化操作转换成SQL语句去后台执行 一、打开Navi…

Object.hasOwn():判断该对象是否有某个属性

定义:判断该对象是否有某个指定的自定义属性。 不包含继承原型链的属性 返回值: 返回一个布尔值, 判断该对象有指定的属性,就会返回true,没有就返回false ;语 法:Object.hasOwn(Object,prop) 示…

设计模式-单例模式(懒汉式)

1. 概念 保证一个类只有一个实例并为该实例提供一个全局唯一的访问节点 2. 懒汉式-方式一 2.1 代码示例(方式一) 示例 public class Singleton03 {/*** 构造器私有化*/private Singleton03() {}/*** 成员变量*/private static Singleton03 INSTANCE;…

CCF-CSP19<2020-06>-第1/2题

本次难度: 202006-1 线性分类器 题目:202006-1 题目分析: 给定n个点,并标记为AB两类,问给定直线是否能将其分为两个点集。 简单数学知识,点在直线上满足axbyc0,点在直线割平面所得的上下其…

云备份day02

📟作者主页:慢热的陕西人 🌴专栏链接:C云备份项目 📣欢迎各位大佬👍点赞🔥关注🚓收藏,🍉留言 主要内容介绍了第三方库jsoncpp和bundle库的使用 文章目录 云备…

android 使用ollvm混淆so

使用到的工具 ndk 21.4.7075529(android studio上下载的)cmake 3.10.2.4988404(android studio上下载的)llvm-9.0.1llvm-mingw-20230130-msvcrt-x86_64.zipPython 3.11.5 环境配置 添加cmake mingw环境变量如下图: 编译 下载…

Codeforces Round 836 (Div. 2) D. Range = √Sum

题目 思路&#xff1a; #include <bits/stdc.h> using namespace std; #define int long long #define pb push_back #define fi first #define se second #define lson p << 1 #define rson p << 1 | 1 const int maxn 1e6 5, inf 1e18, maxm 4e4 5; c…