为了更好地帮助大家理解监控的维度，本文先从一个通用的网站架构开始谈起，然后讲一讲 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、网卡出入流量利用率）对集群负载进行剖析。后续可以加入更多的业务指标来对容量进行管理。
