主要内容：

监控系统

随着企业经营规模的扩大，以及对内快速诊断效率和对外服务品质的追求，对于业务系统的掌控度的要求越来越高，主要体现在：

对于第三方依赖的监控，实时/准实时了解第三方的健康状况/服务品质，降低第三方依赖对于自身系统的扰动(服务降级、故障转移)。

对于容器的监控，实时/准实时的了解应用部署环境(CPU、内存、进程、线程、网络、带宽)情况，以便快速扩容/缩容、流量控制、业务迁移。

业务方对于自己的调用情况，方便作容量规划，同时对于突发的请求也能进行异常告警和应急准备。

自己业务的健康、性能监控，实时/准实时的了解自身的业务运行情况，排查业务瓶颈，快速诊断和定位异常，增加对自己业务的掌控力。

在这种情况下，一般都会引入APM(Application Performance Management & Monitoring)系统，通过各种探针采集数据，收集关键指标，同时搭配数据呈现和监控告警，能够解决上述的大部分问题。

然而随着RPC框架、微服务、云计算、大数据的发展，同时业务的规模和深度相比过往也都增加了很多，一次业务可能横跨多个模块/服务/容器，依赖的中间件也越来越多，其中任何一个节点出现异常，都可能导致业务出现波动或者异常，这就导致服务质量监控和异常诊断/定位变得异常复杂，于是催生了新的业务监控模式：调用链跟踪。能够分布式的抓取多个节点的业务记录，并且通过统一的业务id(traceId，messageId，requestId等)将一次业务在各个节点的记录串联起来，方便排查业务的瓶颈或者异常点。

7.1监控目标

维度详情

系统监控CPU,内存，磁盘，硬盘IO，系统负载等

服务监控apache,nginx,tomcat,redis,TCP连接数等

性能监控网站性能，服务器性能，数据库性能等

日志监控访问日志，错误日志等

安全监控用户登录数，本地文件改动，passwd文件变化等

网络监控端口，SMTP,网络使用率，网络入流量，网络出流量等

搞清楚要监控对象之后，需要监控具体哪些指标呢？通常有以下几个业务指标需要重点监控：

请求量

请求量监控分为两个维度，一个是实时请求量，一个是统计请求量。实时请求量用 QPS(Queries Per Second)即每秒查询次数来衡量，它反映了服务调用的实时变化情况。统计请求量一般用 PV(Page View)即一段时间内用户的访问量来衡量，比如一天的 PV 代表了服务一天的请求量，通常用来统计报表。

响应时间

大多数情况下，可以用一段时间内所有调用的平均耗时来反映请求的响应时间。但它只代表了请求的平均快慢情况，有时候我们更关心慢请求的数量。为此需要把响应时间划分为多个区间，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上这五个区间，其中 500ms 以上这个区间内的请求数就代表了慢请求量，正常情况下，这个区间内的请求数应该接近于 0；在出现问题时，这个区间内的请求数会大幅增加，可能平均耗时并不能反映出这一变化。除此之外，还可以从 P90、P95、P99、P999 角度来监控请求的响应时间，比如 P99 = 500ms，意思是 99% 的请求响应时间在 500ms 以内，它代表了请求的服务质量，即 SLA。

错误率

错误率的监控通常用一段时间内调用失败的次数占调用总次数的比率来衡量，比如对于接口的错误率一般用接口返回错误码为 503 的比率来表示。

7.2 APM选型

目前主要的一些APM工具有: Cat、Zipkin、Pinpoint、SkyWalking等。这里主要介绍SkyWalking，它是一款优秀的国产APM系统，被用于追踪、监控和诊断分布式系统，特别是使用微服务架构、云原生或容积技术，可视化一体化解决方案。

它的主要特性为：

1)多种监控手段，语言探针和service mesh。

2)多语言自动探针，Java, .Net Core, PHP, NodeJS, Golang, LUA。

3)轻量高效，不需要大数据。

4)模块化，UI、存储、集群管理多种机制可选。

5)支持告警。

6)优秀的可视化方案。

7.3 SkyWalking

7.3.1 基础介绍

7.3.1.1 模块构成

SkyWalking进行了精准的领域模型划分，共分为3个部分：

Agent：采集tracing(调用链数据)和metric(指标)信息并上报。

OAP：收集tracing和metric信息通过analysis core模块将数据放入持久化容器中(ES，H2，mysql等)，并进行二次统计和监控告警。

WebApp：前后端分离，前端负责呈现，并将查询请求封装为graphQL提交给后端，后端通过ribbon做负载均衡转发给OAP集群，再将查询结果渲染展示。

7.3.1.2数据容器

由于SkyWalking并没有自己定制的数据容器或者使用多种数据容器增加复杂度，而是主要使用ElasticSearch，所以数据容器的特性以及自己数据结构基本上就限制了业务的上限，以ES为例：

ES查询功能异常强大，在数据筛选方面碾压其他所有容器，在数据筛选潜力巨大。

支持sharding分片和replicas数据备份，在高可用/高性能/大数据支持都非常好。

支持批量插入，高并发下的插入性能大大增强。

数据密度低，源于ES会提前构建大量的索引来优化搜索查询，这是查询功能强大和性能好的代价，但是链路跟踪往往有非常多的上下文需要记录，所以SkyWalking把这些上下文二进制化然后通过Base64编码放入data_binary字段并且将字段标记为not_analyzed来避免进行预处理建立查询索引。

总体来说，SkyWalking尽量使用ES在大数据和查询方面的优势，同时尽量减少ES数据密度低的劣势带来的影响，从目前来看，ES在调用链跟踪方面是不二的数据容器，而在数据指标方面，ES也能中规中矩的完成业务，虽然和时序数据库相比要弱一些，但在PB级以下的数据支持也不会有太大问题。

7.3.1.3数据结构

如果说数据容器决定了上限，那么数据结构则决定了实际到达的高度。SkyWalking的数据结构主要为：

1)数据维度(ES索引为skywalking*inventory)

service：服务

instance：实例

endpoint：接口

network_adress：外部依赖

2)数据内容

原始数据

调用链跟踪数据(调用链的trace信息，ES索引为skywalking_segment，Skywalking主要的数据消耗都在这里)

指标(主要是jvm或者envoy的运行时指标，例如ES索引skywalking_instance_jvm_cpu)

二次统计指标

指标(按维度/时间二次统计出来的例如pxx、sla等指标，例如ES索引skywalking_database_access_p75_month)

数据库慢查询记录(数据库索引：skywalking_top_n_database_statement)

关联关系(维度/指标之间的关联关系，ES索引为skywalking*relation_*)