本文源码:GitHub·点这里 || GitEE·点这里git
分布式系统的架构,业务开发,这些在良好的思路和设计文档规范之下,是相对来讲好处理的,这里的相对是指比较分布式架构下生产环境的忽然故障。github
在实际的开发中,有这样一个很妖娆的状况:越是核心复杂的业务,越是担忧出问题,越容易出问题。数据库
因此当核心服务的链路出现故障时,如何快速定位问题就是一件很头疼的事情,尤为是一些特殊状况下,问题很模糊很难复现,外加客户或者领导催促,这种场景内心阴影是大部分开发都有的。更有甚者,可能问题发生的切入点的开发是某人负责的,实际问题是发生在请求链路的其余服务上,这种状况遇多了,甩锅水平会直线上升。缓存
越是复杂的系统,越是经验丰富的开发或者运维,对监控系统就越是有执念,尤为是全链路的监控,底层,网络,中间件,服务链路,日志观察预警等,用来快速定位问题,省时省心。网络
在分布式系统中,须要监控的体系和层次极其复杂,一般总体上划分为三个层次:应用服务,软件服务,硬件服务。架构
一般状况,运维管理硬件服务,开发管理应用和软件服务。并发
应用层为开发的业务逻辑服务,也是最容易突发问题的一个层面,当在一家公司待久了,由于开发过多个业务线,就会感受本身不是开发,是个打杂的,天天都要分出大量时间处理各类问题。应用层监控涉及下面几个核心模块:框架
请求流量运维
任何服务,高并发的流量都会暴露各类服务问题,尤为核心接口的流量更是监控的重点。异步
服务链路
一次请求发生问题,快速判断问题所在的服务,或者哪些服务之间,这对快速处理问题是相当重要的。
日志体系
核心接口日志记录也是必备的功能,一般状况下基于日志体系的分析结果,能够明确系统的异常点,重点优化。
为了解决分布式系统的各类复杂业务场景,一般会引入各类中间软件来作支撑,例如必备的数据库,缓存,消息MQ等,一般这些中间件都会有自带的监控管理端口。
数据库:较多使用Druid监控分析;
消息队列:经常使用RocketMQ和控制台;
Redis缓存:提供命令获取相关监控数据;
还有一些公司甚至直接在中间件层开发一套管理运维和监控的聚合平台,这样更容易从总体上分析问题。
硬件层面,运维最关注的三大核心内容:CPU、内存、网络。底层硬件资源爆发的故障,来自上层的应用服务或者中间件服务触发的可能性偏高。
硬件层面的监控有许多成熟的框架,例如zabbix,grafana等,固然这些组件功能很丰富,不只仅在硬件层应用。
有些故障致使大面积服务瘫痪,也称为雪崩效应,可能故障源没有快速处理,也没有熔断机制,致使整个服务链路所有垮掉,这是常见的问题,因此在处理故障时,要学会基于全栈监控信息,全局关联分析核心故障点,快速切断单点服务的故障,保证整个系统的可用性。
监控系统虽然做用很大,可是实际搭建的时候难度仍是很大,须要有较好的意识,不是业务开发那种感受,方方面面需求都须要处理,作监控系统的基本策略以下。
不是全部服务的全部环境,和全部接口都须要监控,一般都是监控核心链路,核心中间件,和服务所在环境。
例如:交易链路,交易库,和部署的环境;或者大客户高并发业务,一旦出问题须要及时响应,当即处理。说的直接点,带来收益的服务是须要重点关注的。
非关键服务即便出现问题,是有缓冲时间的,因此不须要花费精力添加监控,在作监控系统的时候存在这样一句话:简单的链路添加监控,复杂了容易出错;复杂链路添加监控,更复杂更容易出错,然而这样倒是为了更好的解决故障。
监控系统的自己发生故障,不能影响正常业务流程,即便在必定状况下没有监控信息,也不能由于监控服务影响正常业务服务。
聚合的监控系统能够观察监控链路的全局状态,这样能够快速定位故障坐标,能够关联性分析问题缘由。
例如CPU忽然升高,某个中间件服务忽然中止,内存占用太高,这些能够基于监控系统作预警通知,而后邮件或者消息通知到相关负责人,达到快速响应的目的,这个场景大部分开发都熟悉,且有心理阴影。
GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent
推荐阅读:架构设计系列