微服务监控规范有哪些

云杉 世纪

2023年12月26日

产品资讯

微服务监控是确保微服务系统正常运行和发现问题的关键组成部分,对于微服务系统的可观察性和可靠性至关重要。下面是一些常见的微服务监控规范:

  1. 监控指标:监控系统必须能够收集重要的指标数据,如响应时间、错误率、请求量、系统资源利用率等,并将其存储在可查询的数据存储中。
  2. 日志收集:监控系统需要能够收集和存储业务应用的日志数据,并使用相关的工具和平台来对其进行分析和处理。
  3. 分布式追踪:监控系统应该实现分布式追踪功能,可以跟踪请求在微服务系统中的传播路径和执行情况,帮助诊断问题的根源。
  4. 告警和通知:一些监控指标需要触发告警和通知机制,以便及时处理潜在的问题。告警设定应当明确,包括告警类型、优先级、负责人等信息,并能及时通知到相关人员。
  5. 数据可视化:监控系统需要能够将收集的指标数据和分布式追踪信息可视化,从而为监控人员提供直观的展示和分析。
  6. 可扩展性:监控系统应该能够适应不同的微服务系统规模和复杂性,并支持横向和纵向扩展,以容纳不断增长的数据量和高速增长的业务需求。
  7. 可定制化和扩展性:监控系统应该具备一定的定制化和扩展性,以满足不同场景下的监控需求。可以通过增加自定义的指标、修改监控规则等方式实现。

总之,微服务监控规范需要定义合适的指标、监控日志、分布式追踪、告警通知、数据可视化等方面的规范,以实现全面的微服务监控。同时,监控系统需要具备可扩展性和定制化扩展性等特点,以满足不断增长的数据与业务需求。业务零侵扰模式即DeepFlow无需应用代码插码,仅部署一个标准采集器即可完成秒级粒度的微服务数据采集,再通过DeepFlow界面来进行数据可视化。

Related Posts

金融银行业可观测性方案

金融信创是金融机构重点投入以及技术迭代的方向,经过多年阶段迭代,进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。

Read More

根因分析假 running 真故障 记一次电力行业的 SRE 实践

用户:某省级电网企业 挑战 定界困难:当发生故障,业务部门和网络部门互相推诿,而不是解决问题; 监控颗粒度不足:运维难以深入到POD维度,大量微服务的业务交互在虚拟机内已经完成业务交互; 全栈链路追踪难:电网要求运维能力覆盖整个业务链条,在微服务架构下,难以看到完整跨容器节点的全链条追踪数据; 定位方法单一:大部分运维工具功能单一,比如日志只可以查询日志,没办法进行指标,追踪、日志等联动定位。 用户期望 期望1分钟发现问题、15分钟研判问题、1小时内解决问题; 监控体系完成业务全覆盖、系统全覆盖; 全业务链条可追踪、可溯源。 这里交代了背景 经济发展,电力先行。作为国家电网旗下最年轻的某省级电网企业,链接东北和华北电网,承担着京津冀北区域电力供应的重要使命。于2012年2月9日正式成立,2017年实施了全业务数据中心的建设,并陆续完成四大数据中心的建设,实现了统一的数据共享与业务融合。 随着信息技术在电力行业经营管理中的广泛应用,越来越多的业务系统从传统的物理环境迁移上云,导致诸多电力业务系统如:营销系统、BPM、PMS2.0、各类6000系统,成分布式微服务化部署,系统环境也多为异构场景,混合云和云上云下的场景尤为凸显。网络分层导致电力行业的业务系统很难用传统的运维手段探测到全局的网络,网络故障发生时很难快速做到端到端的定位等等。 事件起因从这里开始 我(作为现场支撑人员也是小编本身)和电网企业的故事要从一次联合故障定位开始,在往常巡检的过程发现其中一个业务系统,内部微服务(POD)间有大量的建连失败,在 DeepFlow 中输入更多关于建连失败的指标量,如建连客户端 SYN 结束、建连服务端 SYN 结束、建连服务端直接重置等,下钻到流日志后发现了主要建连失败的原因:即客户端 SYN 结束表现形式为客户端多次尝试建连,但是服务端无回应,于是服务端口未放行或者服务端口失效。 为了验证是否下沉到业务侧,与南瑞 I6000 运维同事进行联合定位,在交流过程中用户并没有发现有任何问题,用户随即手动输入 POD 健康检查的命令发现没有响应,与我判断一致,表面上看所有业务都在正常 running,但是 POD 实际没有启动好,监控端口已经失联。为了缓解尴尬的场景用户调侃道“假 running,真故障”。 接着与用户进一步讨论时,发现使用的是 Livceness,可以制定检测规则,如果检测失败就会重启 POD ,全部是以 K8s 被动触发,手动检测会变的很复杂,甚至会出现一种假活现象。根据这次联合定位,我和用户运维部门做了一次深入的沟通,同时也从内心深刻的体会到:一个运维人员面对微服务场景下缺失可观测性能力的无力感。 首先 K8s 的产生是面向业务的,最大限度的保证服务的高可用,但是很多流量都是瞬发的,微服务(POD)在不停的自动化运转,根据工作负载,随时可能发生业务 POD 剔除或者重建的情况,导致微服务场景的监控变得非常复杂。 还有就是以目前的运维手段用户更在乎业务的可读性,也就是电力行业常说的小绿泡,绿色代表正常,红色代表异常,但这远远不能达到实际的运维要求。在和用户深入沟通的同时,我也根据产品能力,建立较为完善的应对措施,帮助用户提升整体运维能力。 首先需要站在用户实际的业务角度出发,完成个性化的运维场景定制。 通过 DeepFlow 丰富的监控指标,可以全面覆盖网络和应用层的R(吞吐)E(异常)D(时延)的场景况,结合目前较为先进的 SRE 方法论,优化故障发现到故障解决的时间,使得整体业务水平在一个良好的 slo(服务等级目标);并针对重要业务中发现过的故障进行重点监控和故障场景复现进行针对性优化,改变过去发现业务问题再做问题定位的被动情景,转变为主动检测、主动监控、主动告警的监控闭环。 接下来为了解用户实际的业务场景和容忍度,和运维部门针对运维指标开设了讨论会,建立丰富、贴合用户使用要求和习惯的 SLI 指标和基线,通过主动监测和建立健康度管理模型的方式,帮助用户发现潜在故障。并且当发现了某些指标不合格,快速进行告警推送到指定责任人手里,再联合 DeepFlow […]

Read More