找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 115354|回复: 0

程序员架构修炼:架构的保障,监控与告警、应急处置 ...

[复制链接]

该用户从未签到

发表于 2020-12-31 20:26:20 | 显示全部楼层 |阅读模式

您需要 登录 才可以下载或查看,没有账号?立即注册

×
前面的章节介绍了很多关于线上故障的案例,在这些案例中,我们发现很多问题最初都是由一些监控及告警系统通知的。接下来就简单介绍监控与告警相关的知识。
监控的重要性
监控是每个公司都必不可少的重要风险防控手段。有效的监控可以帮助开发人员和运维人员快速发现线上的问题,从而保证应用服务的安全、可靠,以及业务的稳定运行。如果没有对线上系统进行监控,开发人员和运维人员便无法在第一时间主动发现系统发生的问题,只能被动等待用户的反馈,这在无形中延长了故障发生的时间。
有了系统监控,就可以化被动为主动,在用户反馈前发现并解决问题,提升用户体验,减少用户投诉。
监控哪些内容
前面讲了监控的重要性,那么,一个完善的监控系统应该监控哪些内容呢?开发人员和运维人员需要重点关注其中的哪些监控指标呢?以一个分布式网站为例,对该网站的监控一般包含系统监控、应用监控、进程监控、服务监控、业务监控、调用链监控等。下面列举在各项监控内容中需要我们重点关注的指标。
1.系统监控
目前有很多应用都部署在Linux系统上,对于线上服务器的系统监控是一个比较重要的指标。我们通常关心的服务器相关指标有load、cpu、mem、traffic等。大多数情况下,在线上出现问题时,往往伴随着某些指标的异常。而且,在问题发生之前,某些指标会提前显示异常。
对于 Linux 机器,我们可以直接使用 Zabbix 进行系统指标监控。Zabbix 提供了系统监控模板Zabbix Agent,如图6.21所示。

                               
登录/注册后可看大图
图6.21
Zabbix是由Alexei Vladishev开发的一种网络监控管理系统,基于Server-Client架构,可用于监控各种网络服务、服务器和网络机器等状态。在客户端如UNIX、Windows中安装Zabbix Agent之后,可以监控CPU负荷、网络使用状况、硬盘容量等状态。
2.应用监控
除了系统级别的监控指标,最重要的就是在服务器上部署的应用的监控指标了,例如JVM、Nginx、MySQL等相关监控。
在采用Java开发的系统中,对JVM的监控是至关重要的,其中比较重要的几个指标有JVM的内存使用情况、GC次数、GC耗时、JVM线程数等。Java平台为应用程序、设备和系统等植入了有管理功能的JMX框架,JMX框架提供了关于JVM的大部分核心信息,应用系统可以通过接入 JMX 框架来实时读取 JVM 的 CPU、内存等信息。前面介绍过的Zabbix也提供了Zabbix JMX框架,支持通过该框架实现对JVM的监控。
除了 JVM,应用的正常运行还依赖 Nginx、MySQL 等基础设施,对这些基础设施的监控同样重要。对于Nginx,我们一般关注其接收请求数、处理请求数等;对于MySQL,我们一般关注SQL语句的执行时间、每秒请求数和慢SQL等。
3.进程监控进程监控,其实可以归类为系统监控或者应用监控,其监控指标也较为简单,就是进程有没有活着。但是,进程监控比较重要,值得在这里单独介绍。例如,对于 Java 这种单进程应用来说,进程挂了,就意味着整个系统都挂了,特别是对于某些定时任务应用,我们要对其进行活检监控,保证进程正常执行且没有挂掉。
4.服务监控
随着近几年微服务等技术的不断流行,很多应用都是分布式部署的,各个应用之间是通过RPC或者HTTP服务来通信的。所以,对于服务的监控也越来越重要。
服务监控的指标一般包括请求数、Q P S、RT、错误数等,可以通过 We b 服务器的access log或者应用的日志获取这些指标。
5.业务监控
无论我们对线上应用做多少监控,最终目的都是保证业务的正常运行。所以,对业务指标自身的监控也是十分重要的。
业务监控一般没有统一的方法,对于不同的业务,需要监控的指标不尽相同,监控方法也千差万别。比如,对于一个电商网站来说,其业务指标可能有下单人数、下单成功数等。
6.调用链监控
现在的互联网服务通常是由复杂的大规模分布式集群实现的,互联网应用构建在不同的软件模块集上,这些软件模块可能是由不同的团队使用不同的编程语言实现的,也可能部署在几千台服务器上且横跨多个不同的数据中心。因此,我们需要一些工具来帮助理解系统的行为和分析性能问题。
调用链监控在微服务系统中比较常见,一般用于跟踪一个请求从发起到返回的全过程,方便查看一个请求在各个相关系统中的调用情况。调用链监控是跨系统的监控,需要在请求发起时分配一个可以唯一识别本次调用请求的 traceId,这个 traceId 在整个调用链中一路透传下去,之后在每个系统的调用日志中都输出该traceId。在所有日志都汇总起来后,便可以根据日志分析本次调用的流程。
目前,业内的调用链监控大多是参考 Google 论文 Dapper,aLarge-Scale Distributed Systems Tracing Infrastructure 实 现的。
告警
监控与告警是一对分不开的兄弟,其实,我们做监控的目的是发现问题,然后通过告警方式将问题通知给开发人员及运维人员,让其快速定位并解决问题。告警信息一般通过邮件、短信、电话、钉钉等方式发送。
告警信息需要包含时间、机器IP、告警原因、告警描述和错误日志等重要信息,以便于开发人员快速排查问题,如图6.22所示。

                               
登录/注册后可看大图
图6.22
监控的架构
要想构建一个智能监控告警系统,就需要重点关注监控和告警,其中涉及的指标就是系统监控、应用监控、进程监控、服务监控、业务监控和调用链监控等。一个智能运维监控系统,在架构设计上从低到高可以分为3大模块,总计6层,如图6.23所示。

                               
登录/注册后可看大图
图6.23
下面对如图6.23所示的各层进行详细讲解。一个完整的监控告警系统的整体架构一般分为三个重要模块:数据收集模块、数据提取模块及监控告警模块。
数据收集模块主要负责数据的收集及展示,主要包含数据收集层和数据展示层。
◎ 数据收集层位于整个监控架构的底层,主要收集应用、业务及数据库相关的元数据。
◎ 数据展示层位于第 2 层,主要将数据收集层采集到的数据进行可视化展示,一般将其绘制成折线图、柱状图等,方便运维及开发人员查看数据的趋势及进行对比。
数据提取模块主要负责数据的提取,衔接数据收集模块和监控告警模块,主要包含数据提取层。数据提取层位于第3层,主要负责对数据收集层采集到的数据进行二次加工,以及规范化和过滤处理,并将需要的数据向上传递到告警模块。
监控告警模块主要负责监控告警的配置及送达,包含告警规则配置层、告警事件生成层及用户展示管理层。
◎ 告警规则配置层位于第 4 层,主要承接来自数据提取层的数据,并根据这些数据进行告警规则、阈值、告警联系人及告警方式的配置。
◎ 告警事件生成层位于第5层,根据告警规则配置及监控数据生成需要告警的事件,并且负责将告警事件通知给相关联系人。
◎ 用户展示管理层位于顶层,是一个We b展示界面,负责将监控统计报表、告警详情等信息统一展示给用户。
在日常工作中,线上环境出现意外情况是无法避免的,应急处理就是在故障发生时快速恢复服务,避免或减少故障带来的损失,以及对用户的影响。
应急处理原则如下。
◎ 应该第一时间恢复系统,而不是等彻底解决问题后恢复系统,要快速止损。
◎ 在明显造成资金损失时,要第一时间升级、快速止损。
◎ 在快速上线时一定要慎重,防止造成新的故障。
◎ 定位故障,快速启动应急流程与止损方案。
◎ 当运维负责人不能在短时间内解决问题时,必须进行升级处理。
◎ 尽量在不影响用户体验的前提下处理问题,保留现场。
线上应急处理一般为6个阶段,如图6.24所示。要记住应急只有一个目标:尽快恢复系统、消除影响。不管处于哪个阶段,首先都要想到恢复系统,恢复系统不一定能定位问题,也不一定有完美的解决方案,但有利于保留现场、定位问题、处理故障和回顾故障。

                               
登录/注册后可看大图
图6.24
下面对应急流程进行详细讲解。
1.定位故障
在定位故障时,我们可以通过系统最近发生的变化,以及系统层、应用层和中间件层监控来定位故障,例如:
◎ 系统最近是否上过线?
◎ 依赖的基础平台是否升过级?
◎ 依赖的系统是否上过线?
◎ 是否有线上营销活动?
◎ 网络是否稳定?◎ 业务量是否有变化?
对系统层一般监控如下指标。
◎ 系统的CPU使用率。
◎ 平均负载(Load Average)。
◎ 内存(Memory)。
◎ 网络与磁盘I/O。
◎ SWAP使用情况。
◎ 线程数。
◎ 文件描述符(File Description)等。
对应用层一般监控如下指标。
◎ 接口的响应时间。
◎ 每秒查询率(QPS)。
◎ 调用频次。
◎ 接口成功率。
对中间件层一般监控如下指标。
◎ 数据库的负载、慢查询、连接数等。
◎ 缓存的连接数、占用内存、吞吐量、响应时间等。◎ 消息队列的响应时间、吞吐量、负载、堆积情况等。
2.处理故障
处理故障要以定位故障为基础,必须清晰定位故障产生的根本原因,在提出解决故障的有效方案之前,不要用不确定的方法来尝试修复故障,这样可能导致引入新的故障。
3.回顾故障
在处理故障后,应急团队与相关方需要回顾事故产生的原因及应急过程的合理性,并提出整改措施,主要聚焦于如下几个问题。
◎ 类似的问题还有哪些没有发生?
◎ 做了哪些事情,故障就不会再发生?
◎ 做了哪些事情,即使发生故障,也不会有负面影响?
回复

使用道具 举报

网站地图|页面地图|文字地图|Archiver|手机版|小黑屋|找资源 |网站地图

GMT+8, 2024-12-23 05:15

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表