监控系统必备基础知识第一篇

监控基础

1. 为何须要监控

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

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

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

• 端监控：针对用户在体验上能够感知的对象进行监控，如网站、App、小程序等。在移动客户端的系统中，端监控的对象主要有H五、小程序、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