运维监控体系建设-三大监控体系以及监控数据采集

最新推荐文章于 2024-09-09 08:07:24 发布

txzq

最新推荐文章于 2024-09-09 08:07:24 发布

阅读量2.3k

点赞数 30

分类专栏： IT运维管理文章标签：运维架构

本文链接：https://blog.csdn.net/u011278722/article/details/137799768

版权

IT运维管理专栏收录该内容

5 篇文章 1 订阅

订阅专栏

在《Linux系统监控之监控信息采集》一文中有提到系统稳定性的基石是监控。通过监控，我们可以提前发现和感知故障。而一套完整的运维监控体系，具体又包含哪些核心能力呢？我们又怎样衡量我们的监控体系建设是否达到预期？

监控三大体系

监控通常可以分为三大体系，或者说是三个层次。
一、系统监控
二、应用监控
三、业务监控

系统监控

指的是对系统资源的监控，如服务器的CPU，内存，磁盘，网络，I/O资源的状态。系统监控可以反映当前服务器的负载情况，是我们判断应用或组件是否处于健康状态的重要依据。针对不同的应用形态，不同的组件类型，其系统资源使用率的合理区间也各不相同。此外，系统监控数据也是我们进行容量评估，性能优化，成本优化的一项重要输入。我们通常会采集CPU，内存，磁盘等资源的监控数据，并计算出资源使用率的P95以及P99值，作为评估依据。

而系统监控数据的采集的底层原理在《Linux系统监控之监控信息采集》一文中也有提到。具体的采集方案后面再进一步探讨。

应用监控

指的是监控服务本身的使用状态，是对应用程序或服务的性能、可用性和健康状态进行实时监测和管理的过程。

比如用户注册服务的调用响应时间，错误率（5xx，4xx等错误），吞吐量等。
比如数据库的查询响应时间、吞吐量、连接数、缓存命中率等
比如如死锁、超时、慢查询、连接问题
消息队列的积压情况
集群的健康状况

应用监控是我们了解业务系统真实负载的一个重要途径，从API的请求量数据我们就能知道哪些服务是核心服务，哪些服务是边缘服务，也为应用系统的架构改造提供了依据。

通常这一部分的监控数据通常可以通过以下几个途径获得：

API 网关
应用日志分析
组件对应的监控
数据对应的监控

Prometheus 提供了丰富的Exporter，供大家使用，大家可以根据实际的业务需求使用相应的Exporter来进行监控数据的导出。
想查看完整的Exporter 清单，请点击此链接：Prometheus Exporter List

常用的Redis Exporter, Kafka Exporter, RocketMQ Exporter, MySQL Exporter, MongoDB Exproter, ElasticSearch Exporter等等

业务监控

而业务监控的对象则是业务数据。什么是业务数据？顾名思义，就是业务正常运转所产生的数据，具有业务属性。比如：

这一个小时的寄件订单量
当前营业网点的剩余派件量
当前网点收派人员排班情况
从双11活动开始到目前为止的交易订单量
交易总金额
各个SKU目前的销售情况等。

一般来说，随着业务量的增长，系统对服务器资源的需求量也会随之增长。我们需要根据当前的业务量，以及当前系统服务器资源的使用情况来决定是否需要对服务器资源进行扩或缩容。特别是在电商场大促场景下，一般在大促前会根据业务量预估，对系统进行多轮的压力测试，根据压测的结果，一方面对系统架构进行针对性的优化，一方面准备好足够的资源应对即将到来的流量洪峰。

监控如何落地

监控的目标

监控的最终目标就是帮助相关人员及时发现问题，快速定位问题，迅速解决问题。监控应该是端到端的，全链路的监控。

我们先思考几个问题：

我们都有哪些监控对象
监控对象有哪些监控指标
监控指标的告警阈值怎么设置
告警等级怎么确定
告警信息发送给谁
告警信息具备业务可读性吗

通过监控平台，我们需要知道哪些系统现在有问题，哪一个模块出了问题，哪一个组件出了问题，有没有人在处理问题，这个总是该由谁来处理等等。

而想要达成上面的目标，就需要我们完成一系列的事情，基本上包括了信息的采集，存储，加工和最终应用。从工具的角度来看，还没有哪一个监控工具能够提供一个完整的一揽子监控解决方案，往往每一个监控工具都是有针对性的，我们需要将这些工具进行整合，以及和其它基础平台进行集成，再加上持续不断的监控运营才能实现我们的监控目标。

系统监控实施

一般来讲，系统级的监控需要在服务器资源交付阶段完成。不管我们申请的是虚拟主机，还是物理主机，或是容器主机，在资源初始化的时候系统级监控就需要配置完成，可以固化到服务器初始化环节中，就好像初始化Ansible远程管理支持一样。

ZabbixAgent/Node Exporter安装
配置初始化
CMDB注册

如果是对存量服务器，则可通过Ansible这样的自动化运维工具来完成上面的这些操作和配置，当然前提是目标服务器已经支持了Ansible远程管理功能。
CMDB在这里扮演着非常重要的角色，CMDB数据就是基线数据，是统计任何其它数据的分母。

应用监控实施

以APISix这款开源API网关为例，我们可以开启Prometheus插件，可以全局开启，也可以针对指定的路由开启，不过通过都是全局开启。通过开启Prometheus插件，可以采集APISix的Metrics数据。比如以下几种数据：

Status codes: 上游服务返回的 HTTP 状态码，可以统计到每个服务或所有服务的响应状态码的次数总和。
Bandwidth: 经过 APISIX 的总带宽（出口带宽和入口带宽），可以统计到每个服务的带宽总和
Connections: 各种的 NGINX 连接指标，如 active（正处理的活动连接数），reading（NGINX 读取到客户端的 Header 信息数），writing（NGINX 返回给客户端的 Header 信息数），已建立的连接数。
Latency: 每个服务的请求用时和 APISIX 处理耗时的直方图

开启的Prometheus 的方法是：编辑 /usr/local/apisix/conf/config.yaml文件

配置启用plugin

   plugins:                          # plugin list
     - ...
     - prometheus
     - ...

配置Prometheus属性

plugin_attr:
  prometheus:
    export_addr:
      ip: 172.16.110.1
      port: 9092

在Prometheus服务器上配置APISIX的Prometheus 抓取任务

scrape_configs:
  - job_name: "apisix"
    scrape_interval: 15s # 该值会跟 Prometheus QL 中 rate 函数的时间范围有关系，rate 函数中的时间范围应该至少两倍于该值。
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["172.16.110.10:9091"]

这里只是提供了API的监测数据采集，其它的组件，也可以通过Prometheus Exporter来进行采集，具体方式就不在这展开了。

业务监控实施

在上一小节中提到的业务的数据，需要结合业务形态，自行在各自的业务系统中实现。通常可以将业务监控视为业务系统的一种报表，是对业务数据按需要统计后的结果，可以将统计结果存储于数据库中，提供接口进行查询即可。

业务系统的报表功能是属于辅助功能，数据量不大的系统，可直接使用关系型数据库来输出报表，通常将报表功能与其它业务功能进行剥离，独立部署，且连接数据库集群的从库来进行相应的查询。数据量较大的，则可借助企业大数据平台的能力来输出相应的报表数据。

监控数据的整合处理

当我们采集到了系统监控数据、应用监控数据以及业务监控数据后，还需要对这些数据进行汇聚处理，另外，还需要结合CMDB的系统数据，部署单元，部署实例数据，才能最终形成一个具有业务可读性的信息。

以apisix的这个http_status监控信息为例，只有IP地址，和URI的数据，我们还无法第一眼就识别出这是哪一个业务系统，哪一个模块的请求数据，这个数据还比较的原始，我们只有根据IP地址，在CMDB中进行查找，才能定位到相应的系统和模块。与系统关联上后，才能获取到该系统的相关干系人，比如说产品负责人，研发人员，运维人员，DBA等等。

apisix_http_status{code="200",route="1",matched_uri="/hello",matched_host="",service="",consumer="",node="127.0.0.1"} 4
apisix_http_status{code="200",route="2",matched_uri="/world",matched_host="",service="",consumer="",node="127.0.0.1"} 4