58项目经理教你如何构建万台服务器下的立体化监控体系

为了更好地帮助你们理解监控的维度，本文先从一个通用的网站架构开始谈起，而后讲一讲 58 集团是怎么在横向和纵向两个维度覆盖各类类型监控的。

为了更好地帮助你们理解监控的维度，本文先从一个通用的网站架构开始谈起，而后讲一讲 58 集团是怎么在横向和纵向两个维度覆盖各类类型监控的。

主要分为两个部分进行分享：

网站的整体架构

构创建体化的监控体系

网站的整体架构

业务集群

对于大多数的技术人员来讲，最熟悉的就是业务集群，咱们在业务集群上实现业务逻辑，由 Nginx 将流量分发到这些业务集群上。

如上图所示，是相关的架构，这部分你们都比较熟悉，咱们就不展开了。下面详细说一下大型网站在机房外部和机房内部的流量接入端的架构。

机房外部

用户访问一个页面，从浏览器的地址栏输入网址，按下回车键，到页面加载出来，通过哪些步骤呢。

拿一个典型页面举例，经过浏览器中的开发者工具，咱们能够看到加载和渲染这个页面须要加载不少页面资源。

不但加载了不少文档类型的资源，例如 HTML；也加载了不少静态资源，例如 CSS、JS 和图片文件。

咱们将前一种划分为动态内容，将后一种划分为静态资源。若是咱们在全国只有一个机房，那么全国各地的用户都须要跨越多个区域、多个运营商的网络才能访问到网站，以下图所示，这样访问速度必定不是很快。

怎么解决这个问题呢？最简单的方法就是让用户就近访问页面资源，在全国各区域、各运营商用户数量比较多的网络内创建节点，让用户就近访问。

以下图所示，不一样颜色的圆圈表明不一样的运营商，节点覆盖了页面数量大的区域。

页面上加载的绝大多数资源都是静态资源，经过这种方式能够很是显著地提高页面的加载速度。

这种技术就是 CDN 技术（Content Delivery Network，即内容分发网络）。

对于动态请求的优化思路也是相似，前面提到的是只有一个机房提供动态请求响应的状况，南方用户的动态请求响应速度是较慢的。

以下图所示，若是在华东、华南等区域部署机房，能够更好地对华东、华南的用户进行覆盖，提高动态内容的访问速度。

那 CDN 是如何实现静态资源的就近访问的呢？使用的就是 DNS 调度的方法。

咱们都知道经过 HTTP 协议发起请求的几个步骤以下：

域名解析

创建链接

发送请求

接收响应

以下图所示，用户在向域名解析服务器发起域名解析请求的时候，DNS 服务器返回了离该用户最近的 CDN 节点的 IP，从而实现了用户的就近访问。

机房内部

如上图，在通过域名解析阶段后，动态的请求会直接访问机房（也能够作动态内容的加速），静态资源在无缓存时也会回源（去机房获取资源文件），这两种状况都会访问机房的 VIP。

分别通过四层负载均衡和七层负载均衡集群后，流量被分发到业务集群。业务集群之间也会存在互相调用的状况。

对每个关键集群来讲都存在主备，主集群出现问题则切换到备集群；也能够主备集群同时提供服务，每一个集群都预留承担所有流量的资源。

每一个集群内部都包含多台服务器，少许服务器出现异常不影响集群提供服务。机房网络出口提供备份链路，主链路出现问题能够自动切换到备链路。

当遇到极端状况，两条链路都中断的状况，能够切换域名的解析结果和 CDN 的回源 IP 到备份机房的 VIP，而后经过机房之间的专线将流量导入。若是有多个机房，那么直接将流量切到其余正常的机房便可。

构创建体化的监控体系

监控的定位和目标

监控的定位和目标以下：

线上服务的守护神，服务稳定性的重要保障

运维和研发、测试人员的眼睛，快速发现和排查故障

将运维数据进行量化和可视化，便于对网站进行优化

监控系统架构

监控系统的底层模块基于 Open-Falcon，上层作了不少深度的二次开发，总体系统架构图以下：

监控的应用规模

监控体系在 58 集团的应用规模以下：

覆盖了近万台服务器，包括 58 集团下属的各网站，如 58 同城、赶集网、中华英才网、安居客、转转。

监控的业务指标，监控系统中配置了超过 3000 个集群、近 3000 个监控模板、近 300 万个监控指标、天天实时处理的数据量超过 2T。

立体化监控体系概述

参考网站的架构图，立体化的监控体系包括纵向和横向两个方向。

纵向实现了自底向上各层级的监控，包括网络、服务器、系统层、应用层、业务层，以下图所示：

横向实现了从外到内各层级的监控，包括用户端、机房网络出口端、流量接入端、业务端等，以下图所示：

纵向各层级的监控指标

网络监控

最基本的网络监控包括：

机房出口 VIP 是否存活，从机房外对 VIP 进行 ping，若是连续屡次发现 VIP 不通则发出告警。

流量是否正常，在四层网络设备上监测出入流量和包量等关键指标。

机房间专线流量和质量是否正常，以及网络设备及流量是否正常等。在机房之间的网络设备上监控专线的流量和质量，例如：带宽使用量，丢包率、ping 延时等。针对上面的技术我特地整理了一下，有不少技术不是靠几句话能讲清楚，因此干脆找朋友录制了一些视频，不少问题其实答案很简单，可是背后的思考和逻辑不简单，要作到知其然还要知其因此然。若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java进阶群：591240817，群里有大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

服务器监控

服务器的监控包括服务器是否宕机，服务器硬件是否有异常等。

宕机监控，在每一个机房都部署监控机，经过 ping 的方式对同机房的服务器进行宕机监控。

为了不网络抖动的影响，当连续屡次发现 ping 不通则发出宕机告警。

在同机房进行部署是为了不因为机房间网络链路出现问题致使大量的误报宕机。

在监控管理层面经过配置不一样的模板，给不一样集群、不一样角色的用户发送不一样的告警，例如：对于数据库主库宕机发送语音告警，其它架构层面支持自动剔除故障机器的宕机发送短信告警便可。

服务器硬件监控，经过在监控 Agent 上部署插件，能够很好地支持多种多样的硬件监控，也很是便于对硬件进行适配。对硬件监控的覆盖程度视业务需求而定。

系统监控

服务器资源使用率，包括 CPU、内存、磁盘、网卡等各项指标。

对于一个中大型互联网公司，业务比较复杂，服务器根据用途被划分为不一样的集群，由不一样的运维和开发人员负责管理。

那么添加这些监控对于技术人员来讲是较大的工做量，且只依靠人去添加监控很难保证监控的覆盖率。咱们的思路是尽量自动化地添加基础的监控。

咱们对各个业务在系统监控层面的需求进行概括，肯定了一些核心的监控指标、异常判断条件、告警方式等，生成一个默认的监控模板。

咱们的 CMDB 系统包含最基础的服务器资产数据，包括集群的名称、集群中的服务器列表、集群的运维和研发负责人等信息。

这样就能够从 CMDB 中同步这些信息，在监控系统中自动添加每一个集群的基础系统监控，也就是自动添加集群、自动建立监控模板（继承了基础监控模板），告警按需求发给运维和研发负责人。

经过这种方式在短期内作到了全部集群基础监控的 100% 覆盖，起码能作到服务器宕机和系统资源使用率问题致使的异常都可以有效的发出告警，迅速解决了监控初始建设阶段的核心痛点。

对于某些集群，因为业务的特殊性，基础的监控模板不能知足他的需求，能够继承父模板的监控指标，而后进行告警条件、告警方式的修改。

应用监控

应用监控用来监控部署的应用程序是否正常，包括：端口，进程，功能（页面或接口），QPS，链接数等指标。

通常来讲，让运维和开发人员去建立监控模板、关联到集群、配置告警接收人等工做有必定的工做量，并且也有必定的难度。一些状况下，因为配置的问题会致使监控和告警不能生效。

为了解决这个问题，咱们基于自动添加的系统监控：

一方面从部署上线系统同步应用程序的端口等信息，自动添加端口监控。

另外一方面基于系统监控的模板，容许用户方便的添加应用监控，例如：只须要填写端口、进程名等就能够方便的添加端口监控和进程监控。

对于功能（页面或接口）、QPS、链接数等指标，咱们也提供了部署监控插件进行监控的方式。

用户能够经过帮助文档页面下载多种语言（Java、PHP、Python，Shell等）的监控插件模板，而后进行简单修改，采集到被监控指标后能够方便的接入监控系统。

经过这种方式咱们快速提高了应用监控的覆盖率。

业务监控

业务的监控对象包括业务关心的各项指标，例如订单量、成交额等。

因为业务监控和具体的业务相关，不能采用通用的方式进行监控，因此采用自定义监控插件的方式监控。

全部能够采集到的指标均可以添加监控和告警；将数据以 Json 格式发给监控 Agent 即完成数据上报。

横向各层级的监控指标

用户端

有以下几种采集数据的方式：

使用在用户端网络内合做用户电脑或手机上部署的探针进行探测。

在页面中嵌入 JS 代码，从真实用户的浏览器端对性能数据进行采集。

在 APP 端嵌入 SDK，从真实用户的 APP 对访问错误和性能数据进行采集。

采集的数据包括用户端可用性、首屏时间、所有资源下载时间、所有资源字节数、基础 HTML 页面下载时间等数据，以下图所示：

另外，还能够对 DNS 劫持、链路劫持、访问出错、访问速度较慢的问题进行告警，以 DNS 劫持数据的展现举例：

点击图例后，跳转到详情数据：

机房网络出口端

既能够在网络设备上采集流量，也能够在四层负载均衡上采集流量。并可分别对网络的连通性、进出流量、进出包数等关键指标进行监控。

页面和接口监控

对重点页面、接口的可用性、响应时间进行监控。

这些监控都是对机房出口的 VIP 发起请求，流量通过负载均衡服务分发到后端业务集群，业务集群内有少许服务器出现异常，负载均衡服务会自动到另外一台服务器重试，异常不会暴露给外部用户。

当探测此处的页面和接口监控发现了异常，那么用户已经可见了，是比较严重的故障。

经过这种监控方式也能够比较客观的评价业务集群的运行情况，重点关注的指标的稳定性和响应时间。

页面监控：对页面的基础页面（即 HTML）进行探测，连续一段时间发现状态码与预期不一致、响应时间过长、找不到匹配的关键词、页面长度较短等状况，会发出告警。

接口监控：对接口进行探测，连续一段时间发现状态码与预期不一致、响应时间过长，接口返回的消息体中业务状态码不符合预期或数据长度较短等状况，会发出告警。

流量接入端

大型网站的流量接入端包括四层和七层的负载均衡集群。

通常的网站可使用 LVS 提供四层负载均衡服务，技术实力雄厚的公司可使用本身定制开发的四层负载均衡服务。

七层负载均衡端是流量接入端的重要服务，处于用户流量接入的咽喉要道，重要性不言而喻，因此要有完善的监控。

另外因为全部流量都通过该服务，能够收集到不少用户端访问和后端业务集群运行情况的数据。

通常七层的负载均衡服务使用 Nginx，除了基础的服务器、系统、应用层的监控，还能够实现更多的监控。

有如下几种方式实现：

将日志实时传输，集中计算，再将结果给监控服务端。

将日志在 Nginx 上实时计算，传送结果给监控服务端。

用 Lua 实现 Nginx 扩展，实时计算，传送结果给监控服务端。

咱们采用了第一种方式，复杂的计算不占用 Nginx 集群的计算资源。

采集的指标包括（以下图）：

各域名的各类状态码的数量和比率、响应时间。

各后端集群的各类状态码的数量和比率、响应时间。

业务集群端

在流量接入端已经可以对业务集群的可用性、响应时间等关键指标进行监控和告警，对业务集群还能够按照纵向各层级添加监控指标。

其余核心功能

监控数据展现

用户可以按照服务器和集群查看监控指标，为了便于用户使用，能够直接查询最经常使用的监控指标。

能够在一个视图中展现全部机器的某项监控指标：

监控异常查看

为了方便用户查看当前有哪些异常，咱们提供了监控异常查看页面，且能够对信息进行搜索：

另外还能够在时间维度上查看全部近期的告警：

监控墙

为了便于值班和巡检，咱们提供了监控墙功能，能够展现在监控大屏上：

容量管理

为了便于提高服务器的资源利用率，及时发现系统性能瓶颈，为服务器申请提供数据支持，基于监控系统的数据，咱们开发了容量管理系统。

第一步先实现集群的基本容量评估，经过几项主要的系统负载参数（CPU、内存、磁盘空间、磁盘 IO、网卡出入流量使用率）对集群负载进行分析。后续能够加入更多的业务指标来对容量进行管理。