监控基础

1. 为什么需要监控

监控如同切脉诊断，是技术人员先于用户发现问题的最佳手段。完善的监控系统能够引导技术人员快速定位问题并解决,可以将系统的问题扼杀于萌芽状态。完善的监控系统，是技术人员运筹帷幄的强有力保障。我们应建立完善的监控体系.监控系统可以贯穿于移动端、前端、业务服务端、中间件、应用层、操作系统等，***到IT系统的各个环节。

2. 监控要达到的效果
   • 趋势分析：长期收集并统计监控样本数据，对监控指标进行趋势分析。例如，通过分析磁盘的使用空间增长率，可以预测何时需要对磁盘进行扩容。
   • 对照分析：随时掌握系统的不同版本在运行时资源使用情况的差异，或在不同容量的环境下系统并发和负载的区别。
   • 告警：当系统即将出现故障或已经出现故障时，监控可以迅速反应并发出告警。这样，管理员就可以提前预防问题发生或快速处理已产生的问题，从而保证业务服务的正常运行。
   • 故障分析与定位：故障发生时，技术人员需要对故障进行调查和处理。通过分析监控系统记录的各种历史数据，可以迅速找到问题的根源并解决问题。
   • 数据可视化：通过监控系统获取的数据，可以生成可视化仪表盘，使运维人员能够直观地了解系统运行状态、资源使用情况、服务运行状态等.
3. 五层轻量监控体系

监控系统分为端监控、业务层监控、应用层监控、中间件监控、系统层监控这5层。

• 端监控：针对用户在体验上可以感知的对象进行监控，如网站、App、小程序等。在移动客户端的系统中，端监控的对象主要有H5、小程序、Android系统、iOS系统等，完善的端监控可以反馈地域、渠道、链接等多维度的用户体验信息；用户终端为传统的Web页面时，端监控仍会围绕用户体验采集数据，比如页面打开速度（测速）、页面稳定性（JS）和外部服务调用成功率（API），这3个方面的数据反映了Web页面的健康度.
• 业务层监控：对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大盘。比如用户访问QPS、DAU日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象.
• 应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对Spring Boot、JVM信息、服务链路、Dubbo等应用在进行诸如RPC调用、Trace链路追踪动作时产生的数据进行监控。
• 中间件监控：监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件（RabbitMQ、Kafka、RocketMQ等）、数据库中间件（MySQL、Oracle、PostgreSQL、TIDB、PolarDB等）、数据库连接池中间件（HikariCP、Druid、BoneCP等）、缓存中间件（Redis、Memcached等）和Web服务中间件（Tomcat、Jetty等）。
• 系统层监控：如何对系统层进行监控. 主要包含CPU、Load、内存、磁盘I/O、网络相关参数、内核参数、ss统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset采集、DNS解析采集等指标。这些都可以作为对系统层监控的关键指标。另外，网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、***进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。

Zabbix是针对系统层的监控系统.

ELK（Elasticsearch+Logstash+Kibana）主要是做日志监控的

Prometheus和Grafana可以实现对端、业务层、应用层、中间件、系统层进行监控，因此Prometheus是打造一站式通用监控架构的最佳方案之一.

• 监控功能
• 可观察性
• 数据分析

监控是为技术人员和业务人员提供服务的

目的是通过监控系统了解技术应用或运行的环境状况，并检测、洞察、诊断、解决因环境引发的故障或潜在风险.

概念解析

• SPM（Super Position Model）全称超级位置模型，是Web端Aplus日志体系和App端UserTrack日志体系共同使用的重要规范。SPM的作用类似于IP地址，可以直接定位前端控件区块。阿里的SPM位置编码由A.B.C.D四段构成，其中A代表站点/业务，B代表页面，C代表页面区块，D代表区块内的点位。
• SCM（Super Content Model）全称超级内容模型，是一种与业务内容一起下发的埋点数据，用来唯一标识一块内容。在客户端埋点时，将SCM编码作为埋点的参数上传给UT服务器，SCM编码也采用含义与SPM相同的A.B.C.D格式。
• 黄金令箭，即用户在页面上进行交互行为触发的一个异步请求，用户按照约定的格式向日志服务器发送请求，展现、点击、等待、报错等都可以作为交互行为。规则为/goldenkey_xxx，其中x为一串数字，用于标识某个具体的交互事件。

  监控架构分类

1. 监控三要素

• Metrics的特点是可聚合（Aggregatable），它是根据时间发生的可以聚合的数据点。通俗地讲，Metrics是随着时间的推移产生的一些与监控相关的可聚合的重要指标（如与Counter计数器、Historgram等相关的指标）。
• Logging是一种离散日志（或称事件），分为有结构的日志和无结构的日志两种。
• Tracing是一种为请求域内的调用链提供的监控理念。

其中CapEx代表搭建的投入成本，OpEx代表运维成本，Reaction代表监控手段的响应能力，Investigation代表查问题的有效程度。一般来说，Metrics和HealthCheck对于监控告警非常有帮助，Metrics、Tracing和Logging对于调试、发现问题非常有帮助。

Prometheus是基于Metrics的监控系统，具有投入成本（CapEx）中等、运维成本（OpEx）低、响应能力（Reaction）高等特点

在业务开发中，通过查日志的方式就能定位到系统存在问题，通过Tracing模式可以查到链路上出现问题的环节.

进行监控告警时，HealthCheck是运维团队监测应用系统是否存活、是否健康的最后一道防线，这是必须引起重视的一道防线。HealthCheck在微服务中通过对一个特定的HTTP请求进行轮询实现监控。通过对这个请求进行轮询，不但可以得到微服务的监控状态，还可以得到相关中间件如MQ、Redis、MySQL、配置中心等的健康状态。监控告警的优先级依然是Metrics监控最高，HealthCheck最低。

MDD思想:从指标到洞察力

1.MDD思想综述

MDD（Metrics-Driven Development）主张整个应用开发过程由指标驱动，通过实时指标来驱动快速、精确和细粒度的软件迭代。指标驱动开发的理念，不但可以让程序员实时感知生产状态，及时定位并终结问题，而且可以帮助产品经理和运维人员一起关注相关的业务指标.

MDD的关键原则

* 将指标分配给指标所有者（业务、应用、基础架构等）。
* 创建分层指标并关联趋势。
* 制定决策时使用的指标。

MDD则主张将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到实施后才补充。相对于通过制定各种复杂、严格的研发规定，以及开无数的评审、研讨会议来确保软件的安全发布、稳定运行，MDD理念的特别之处在于应用程序本身。在MDD理念下，采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。在软件的设计初期就包括Metrics设计，设计一套规则来评价系统的稳定性、健康状态，并监控其他考核目标，将这些作为服务本身的KPI。因此，通过应用MDD理念，可将Dev与Ops之间或多个Dev团队之间出现的责任博弈降至最低，甚至使矛盾完全消失，这也有利于团队稳定发展。因此，MDD可以用于决策支持、预测趋势、测试系统的补充、关联性分析等。依照MDD的理念，在需求阶段就可以考虑设置关键指标监控项，随着应用的上线，通过指标了解系统状态，通过对现状的可视化和具体化，帮助用户对未来进行规划和预测，进而实现业务改善。传统模式中，Dev和Ops是割裂的，而MDD是DevOps文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升DevOps意识有很大的帮助。

MDD理念的监控分层主要有3种

* Infrastructure/System Metrics：如服务器状态、网络状态、流量等。
* Service/Application Metrics：如每个API耗时、错误次数等，可以分为中间件监控、容器监控（Nginx、Tomcat）等
* Business Metrics：运营数据或者业务数据，比如单位时间订单数、支付成功率、A/B测试、报表分析等.

2. 指导实践的3大监控方法论
   • Google的四大黄金指标
   • 延迟（Latency）：服务请求所需耗时，例如HTTP请求平均延迟。需要区分成功请求和失败请求，因为失败请求可能会以非常低的延迟返回错误结果。
   • 流量（Traffic）：衡量服务容量需求（针对系统而言），例如每秒处理的HTTP请求数或者数据库系统的事务数量。
   • 错误（Errors）：请求失败的速率，用于衡量错误发生的情况，例如HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，以及由策略原因导致的失败（比如强制要求响应时间超过30ms的请求为错误）。
   • 饱和度（Saturation）：衡量资源的使用情况，例如内存、CPU、I/O、磁盘使用量（即将饱和的部分，比如正在快速填充的磁盘）。
   • Netflix的USE方法

USE是Utilization（使用率）、Saturation（饱和度）、Error（错误）的首字母组合.

主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈及错误

* **使用率**：关注系统资源的使用情况。这里的资源主要包括但不限于CPU、内存、网络、磁盘等。100%的使用率通常是系统性能瓶颈的标志。
* **饱和度**：例如CPU的平均运行排队长度，这里主要是针对资源的饱和度（注意，不同于四大黄金指标）。任何资源在某种程度上的饱和都可能导致系统性能的下降。
* **错误**：错误数。例如，网卡在数据包传输过程中检测到以太网络冲突了14次

• Weave Cloud的RED方法

RED方法是Weave Cloud基于Google的4个黄金指标再结合Prometheus及Kubernetes容器实践得出的方法论，特别适用于对云原生应用以及微服务架构应用进行监控和度量。在四大黄金指标的原则下，RED方法可以有效地帮助用户衡量云原生以及微服务应用下的用户体验问题。RED方法主要关注以下3种关键指标。

* **(Request）Rate**：每秒接收的请求数。
* **(Request）Errors**：每秒失败的请求数。
* **(Request）Duration：**每个请求所花费的时间，用时间间隔表示。

上述三大监控理论的最佳实践是：在遵循Google四大黄金指标的前提下，对于在线系统，结合RED方法和缓存命中率方式进行监测；对于离线系统或者主机监控，以USE方法为主进行监测；对于批处理系统，可以采用类似Pushgateway的形式进行监控。

监控系统选型分析

1. 黑盒监控和白盒监控

监控系统必须支持探针（Probing）和内省（Introspection）。

• 黑盒监控，对应探针的概念，常见的有HTTP探针、TCP探针等，可以在系统或者服务发生故障时快速通知相关人员进行处理。探针位于应用程序的外部，通过监听端口是否有响应且返回正确的数据或状态码等外部特征来监控应用程序。Nagios就是一个主要基于黑盒/探针的监控系统。
• 白盒监控，对应内省的概念，通过白盒能够了解监控对象内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。白盒监控可以直接将事件、日志和指标发送到监控工具，它具有比黑盒监控更丰富的应用程序上下文信息。MDD理念主要对应的就是基于白盒的监控系统。
  2. 监控检查的两种模式-拉取和推送

监控系统执行监控检查的模式主要有拉取（Pull）和推送（Push）两种.

• 拉取模式（简称拉模式）
  • 概念:是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值，由于有拉取间隔，因此并不能准确获取数值状态的变化，只能看到拉取间隔内的变化，因此可能会产生一些毛刺现象，需要进一步进行数据处理。监控和性能测试更关注p95/p99位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的.
  • 优点:告警可以按照策略分片，告警模块只需要拉取自己需要的数据，且可以完美支持聚合场景；拉模式的缺点在于监控数据体量非常庞大，对存储有较高的要求，实战中可能还需要考虑数据的冷热分离.
• 推送模式（简称推模式)
  • 概念:是应用程序基于事件主动将数据推向监控系统的方式
  • 优点:实时性好，一旦触发一个事件就可以立刻收集发送信息.
  • 缺点:由于事件的不可预知性，大量的数据推送到监控系统，解析和暂存会消耗大量的内存，这可能对监控的进程产生影响。由于消息是推送过来的，所以主动权在推送方。在这种模式下，由于网络等迟迟没有得到确认，所以在ack等情况下很容易造成数据重复。这是因为推模式在进行推送中，如果发送失败，为了防止内存撑爆，系统会将数据持久化到文件或者队列。因此采用推模式时，若产生了重复数据，就需要进行去重等操作.
• Prometheus和zabbix分别采用的模式
  • Prometheus在收集数据时，主要采用拉模式（服务端主动去客户端拉取数据），当然它也支持接收推送到Pushgateway的事件；
  • 以Zabbix为代表的传统监控系统采用推模式（客户端发送数据给服务端）。拉模式在云原生环境中有比较大的优势，原因是在分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成对所有要监控节点的服务发现，此时直接去拉取需要的数据就好了；推模式虽然可以省去服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这无形中加大了部署的难度
    3. 监控系统选型分析
    4. 功能维度: 直接决定了能否实现开箱即用，从而缩短项目周期、降低成本等

2. 性能维度: 性能是根据当前业务量做技术评估的一个重要因素.
   • Zabbix:
     • MySQL写入瓶颈: Zabbix使用MySQL来存放监控历史数据
     • Zabbix有些数据采集会通过服务器端主动探测(拉取)的方式，当目标机器量大了之后，拉任务也经常出现积压.
   • Prometheus
     • 面对海量的监控数据和性能压力，阿里使用了联邦（Federation）的架构将监控压力分担到多个层次的Prometheus并实现全局聚合。在联邦集群中，每个数据中心部署单独的Prometheus，用于采集当前数据中心监控数据，并由一个中心的Prometheus负责聚合多个数据中心的监控数据
     • 针对每个集群的OS指标（如节点资源CPU、内存、磁盘等水位以及网络吞吐）、元集群以及用户集群K8S master指标（如kube-apiserver、kube-controller-manager、kube-scheduler等）、K8S组件（如kubernetes-state-metrics、cadvisor）、etcd指标（如etcd写磁盘时间、DB size、Peer之间吞吐量）等，架构被分层为监控体系、告警体系和展示体系3部分。监控体系按照从元集群监控向中心监控汇聚的角度，呈现为树形结构，其可以细分为3层：
       • 边缘Prometheus：为了有效监控元集群K8S和用户集群K8S的指标，避免网络配置的复杂性，将Prometheus下沉到每个元集群内。
       • 级联Prometheus：级联Prometheus的作用在于汇聚多个区域的监控数据。级联Prometheus存在于每个大区域，例如中国区，欧洲美洲区、亚洲区。每个大区域内包含若干个具体的区域，例如北京、上海、东京等。随着每个大区域内集群规模的增长，大区域可以拆分成多个新的大区域，并始终维持每个大区域内有一个级联Prometheus，通过这种策略可以实现灵活的架构扩展和演进。
       • 中心Prometheus：中心Prometheus用于连接所有的级联Prometheus，实现最终的数据聚合、全局视图和告警。为提高可靠性，中心Prometheus使用双活架构，也就是在不同可用区布置两个Prometheus中心节点，都连接相同的下一级Prometheus。
3. 数据存储:
   • Zabbix采用关系数据库保存
   • Open-Falcon采用RDD数据存储,也加入了一致性Hash算法分片数据，并且可以对接到OpenTSDB.
   • Prometheus自研了一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。
4. 服务发现
   • Prometheus的动态发现机制
5. 运维管理
   • Zabbix:
     • Zabbix管理成本高昂
     • Zabbix易用性问题: Zabbix的模板是不支持继承的，机器分组也是扁平化的，监控策略不容易复用。Zabbix要采集哪些数据，是需要在服务器端做手工配置的
   • 运维管理还需要考虑到Web功能、画图展示、默认监控等
   • 微服务监控有四大难点
     • 配置难。监控对象动态可变，无法进行预先配置
     • 融合难。监控范围非常繁杂，各类监控难以互相融合
     • 排查难。微服务实例间的调用关系非常复杂，故障排查会很困难
     • 建模难。微服务架构仍在快速发展，难以抽象出稳定的通用监控模型
6. 开发语言
   • Go语言凭借简单的语法和优雅的并发, 在云原生场景使用广泛.
   • Go语言的应用方向:
     • 服务器编程
     • 脚本编程
     • 网络编程
     • 云平台
7. 社区力度和生态发展
8. 误区探讨
   • 监控选型时切忌一味地追求性能或者功能，性能可以优化，功能可以二次开发。如果要在功能和性能方面做一个抉择的话，那么首选性能，因为总体上来说，性能优化的空间没有功能扩展的空间大。然而对于长期发展而言，生态又比性能以及功能都重要。
   • 监控系统选型还有一个标准，就是尽量贴合团队的自身技术体系栈.没有最好的，只有最合适的
   • 盲目追新并不是监控选型的态度，专业的监控架构是综合实际使用情况去做设计、做规划的，可以根据实际情况结合使用多种监控.

     参考链接和书籍

• Prometheus云原生监控:运维和开发实战:https://weread.qq.com/web/reader/23d328c072106cb723d1641k16732dc0161679091c5aeb1