前面的章节介绍了很多关于线上故障的案例，在这些案例中，我们发现很多问题最初都是由一些监控及告警系统通知的。接下来就简单介绍监控与告警相关的知识。
监控的重要性
监控是每个公司都必不可少的重要风险防控手段。有效的监控可以帮助开发人员和运维人员快速发现线上的问题，从而保证应用服务的安全、可靠，以及业务的稳定运行。如果没有对线上系统进行监控，开发人员和运维人员便无法在第一时间主动发现系统发生的问题，只能被动等待用户的反馈，这在无形中延长了故障发生的时间。
有了系统监控，就可以化被动为主动，在用户反馈前发现并解决问题，提升用户体验，减少用户投诉。
监控哪些内容
前面讲了监控的重要性，那么，一个完善的监控系统应该监控哪些内容呢？开发人员和运维人员需要重点关注其中的哪些监控指标呢？以一个分布式网站为例，对该网站的监控一般包含系统监控、应用监控、进程监控、服务监控、业务监控、调用链监控等。下面列举在各项监控内容中需要我们重点关注的指标。
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.回顾故障
在处理故障后，应急团队与相关方需要回顾事故产生的原因及应急过程的合理性，并提出整改措施，主要聚焦于如下几个问题。
◎ 类似的问题还有哪些没有发生？
◎ 做了哪些事情，故障就不会再发生？
◎ 做了哪些事情，即使发生故障，也不会有负面影响？
下篇文章给大家讲解的是程序员管理探秘：为成为技术主管做准备；
觉得文章不错的朋友可以转发此文关注小编；
感谢大家的支持
联系客服
