运维监控建设参考方案一例
2021-05-21 10:56:32 
阿炯
监控是整个运维以及产品整个生命周期最重要的一环，它旨在事前能够及时预警发现故障，事中能够结合监控数据定位问题，事后能够提供数据用于分析问题。
一、监控的目的
监控贯穿应用的整个生命周期，即从程序设计、开发、部署、下线，其主要的服务对象有：技术、业务
技术通过监控系统可以了解技术的环境状态，可以帮助检测、诊断、解决技术环境中的故障和问题。然而监控系统的最终目标是业务，是为了更好的支持业务运行，确保业务的持续开展。所以监控的目的可以简单归纳如下：
能够对系统进行7*24小时的实时监控；
能够及时反馈系统状态；
保证平台的稳定运行；
保证服务的安全可靠；
保证业务的持续运行。
二、监控的模式
监控由上至下可以分为：
业务监控、应用监控、操作系统
其中业务监控主要是研发提供一些业务指标、业务数据，对其增长率、错误率等进行告警或者展示，需要提前定义规范甚至埋点。应用程序的监控主要有探针和内省。其中探针主要是从外部探测应用程序的特征，比如监听端口是否有响应。内省主要是查看应用程序内部的内容，应用程序通过检测并返回其内部的状态，内部的组件，事务和性能等度量，它可以直接将事件、日志和指标直接发送给监控工具。操作系统主要是监控主要组件的使用率、饱和度以及错误，比如CPU的使用率、CPU的负载等。
三、监控的方式
监控的主要方式有:
健康检查。健康检查是对应用本身健康状况的监控，检查服务是否还正常存活。
日志。日志是排查问题的主要方式，日志可以提供丰富的信息用于定位和解决问题。
调用链监控。调用链监控可以完整的呈现出一次请求的全部信息，包括服务调用链路、所耗时间等。
指标监控。指标是一些基于时间序列的离散数据点，通过聚合和计算后能反映出一些重要指标的趋势。
在上述4种监控方式中，健康检查是云平台等基础设施提供的能力，日志则一般有单独的日志中心进行日志的采集、存储、计算和查询，调用链监控一般也有独立的解决方案进行服务调用的埋点、采集、计算和查询，指标监控则是通过一些exporter抓取目标暴露的指标，然后对这些指标数据进行清理、聚合，我们通过聚合出来的数据进行展示、告警等。
说明：该方案主要是针对指标监控
四、监控选型
4.1 健康检查
云平台提供健康检查能力，直接在云平台中配置。
4.2 日志
成熟的开源日志解决方案是ELK。
4.3 调用链监控
调用链健康使用第三方的健康软件，常用的有skywalking、zikpin、pinpoint、elastic APM、Cat。其中zikpin和cat对代码有一定的侵入性，而skywalking、pinpoint、elastic APM是基于字节码注入技术，对代码没有侵入性，而且改动最小。
pinpoint的agent仅支持java和php，而skywalking和elastic APM都支持多种语言，比如java/nodejs/go等。在云原生环境下，skywalking和elastic APM更适合。
elastic APM直接使用es作为存储，可以在kibana上直接看应用信息，但是其关系图是需要产生一定的费用。skywalking是国人开源的一款产品，已经毕业于Apache基金会，社区非常活跃，版本迭代很快，专为微服务、云原生架构和基于容器(docker、K8s、Mesos)架构而设计。
4.4 指标监控
在云原生环境、传统的监控方式并不适合，在传统环境，zabbix无疑是首选，但是在云原生环境，Prometheus却成为了热门，其主要原因有：
成熟的社区支撑。Prometheus是CNCF的毕业项目，有许多大厂做背书，社区庞大，是首推的云原生监控解决方案。
易于部署和运维。Prometheus核心只有一个二进制文件，没有其他的第三方依赖，部署运维均十分方便。
采用Pull模型，通过HTTP的Pull方式从各个监控目标拉取监控数据。Push模型一般通过Agent方式去采集信息并推送到收集器中，每个服务的Agent都需要配置监控数据项与监控服务端的信息，在大量服务时会加大运维难度；另外，采用Push模型，在流量高峰期间监控服务端会同时接收到大量请求和数据，会给监控服务端造成很大压力，严重时甚至服务不可用。
强大的数据模型。Prometheus采集到的监控数据均以指标的形式存在于内置的时序数据库中，除了基本的指标名称外，还支持自定义的标签。通过标签可以定义出丰富的维度，方便进行监控数据的聚合和计算。
强大的查询语言PromQL。通过PromQL可以实现对监控数据的查询、聚合、可视化、告警。
完善的生态。常见的操作系统、数据库、中间件、类库、编程语言，Prometheus都提供了接入方案，并且提供了Java/Golang/Ruby/Python等语言的客户端SDK，能够快速实现自定义的监控逻辑。
高性能。Prometheus单一实例即可处理数以百计的监控指标，每秒处理数十万的数据，在数据采集和查询方面有着优异的性能表现。
注意：由于采集的数据有可能丢失，Prometheus并不适合对采集数据要求100%准确的场景。
五、Prometheus监控系统概述
监控系统的整体框架如下：
Prometheus Server：用于抓取指标、存储时间序列数据
exporter：暴露指标让任务来抓
pushgateway：push 的方式将指标数据推送到该网关
alertmanager：处理报警的报警组件
adhoc：用于数据查询
其流程很简单，Prometheus server端可以直接接收或者通过pushgateway获取到数据，存储到TSDB中，然后对数据进行规则整理，通过Altermanager进行报警或者通过Grafana等工具进行展示。
六、指标监控的对象
监控系统一般采用分层的方式划分监控对象。在我们的监控系统中，主要关注以下几种类型的监控对象：
主机监控，主要指主机节点软、硬件资源的一些监控数据。
容器环境监控，主要指服务所处运行环境的一些监控数据。
应用服务监控，主要指服务本身的基础数据指标，提现服务自身的运行状况。
第三方接口监控，主要指调用其他外部服务接口的情况。
对于应用服务和第三方接口监控，我们常用的指标包括：响应时间、请求量QPS、成功率。
6.1 主机监控
1)为什么需要主机监控
主机是系统的载体，一切系统应用都运行在主机之上，如果某台或者几台主机宕机，会导致上面运行的所以应用都没办法正常提供服务，严重者导致生产事故。所以对主机的监控与预警是非常有必要的，我们可以在其出故障之前对其进行处理，避免严重的事故发生。
2)如何判断资源情况
主机的监控主要从一下三个方面来综合考虑其状态：
使用率：资源忙于工作的平均时间，通常是随时间变化的百分比
饱和度：资源队列的长度
错误：资源错误事件的计数
3)哪些资源需要监控
主机的主要资源对象有：CPU、内存、磁盘、可用性、服务状态、网络
4)如何进行监控
在Prometheus监控方案中，主机的资源指标是通过node-exporter来进行采集，然后存储在Prometheus时序数据库里，然后可以通过PromQL来查询各个指标的具体情况。
①CPU
CPU主要从使用率和饱和度来进行监控。
(1)使用率，指标node_cpu_seconds_total通常会根据CPU使用率超过多少来进行告警，比如当CPU使用率大于80%，则进行告警，当然CPU是一个Gauge类型的，它的数据是会上下增减的，所以我们在判断CPU使用率的时候通常是一段时间内CPU持续高达多少的时候才进行告警，比如下面的表达式就是统计5分钟内CPU使用率大于60%的主机：
100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)* 100) > 60
CPU指标还有用户态、内核态的指标数据，这个根据情况来进行监控。
(2)饱和度，指标node_loadCPU的饱和度通常指的是CPU的负载情况。正常情况下CPU的整体负载不超过CPU的总数，比如2颗CPU，则负载不超过2。我们收集到的指标有1分钟、5分钟、15分钟的负载数据，在配置监控的时候选择好统计时间，一般情况下会选择5分钟的负载作为统计，如下表示5分钟的负载大于CPU的总数的2倍：
node_load5 > on (instance) 2 * count by(instance)(node_cpu_seconds_total{mode="idle"})
②内存
内存主要从使用率和饱和度来进行监控。
(1)使用率 内存的使用率可以直观的看到整体CPU的使用情况，其计算方式使用(free + buffer + cache)/ total。指标主要有：
node_memory_MemTotal_bytes：主机上的总内存
node_memory_MemFree_bytes：主机上的可用内存
node_memory_Buffers_bytes：缓冲缓存中的内存
node_memory_Cached_bytes：页面缓存中的内存
比如下面的表达式是用于统计内存使用率大于80%：
100 - sum(node_memory_MemFree_bytes{job="node-exporter"} + node_memory_Buffers_bytes{job="node-exporter"} + node_memory_Cached_bytes{job="node-exporter"})by (instance) / sum(node_memory_MemTotal_bytes{job="node-exporter"})by(instance)*100 > 80
(2)饱和度 内存的饱和度是指内存和磁盘的读写情况来监控。指标有：
node_vmstat_pswpin：系统每秒从磁盘读到内存的字节数，单位KB
node_vmstat_pswpout：系统每秒从内存写到磁盘的字节数，单位KB
③ 磁盘
磁盘的监控有点特殊，我们不按着USE的方法去测量。如果单考虑其使用率并没有多大的效果，因为10G剩余20%和1T剩余20%对我们的影响是不一样的，所以我们可以监控其增长趋势以及方向。比如：根据前面1h的磁盘增长情况来预测在4h内是否会把磁盘用完
predict_linear(node_filesystem_free_bytes{job="node-exporter",mountpoint!=""}[1h], 4*3600)
当然，如果仅仅这样预测也会产生很多垃圾告警，因为在某一小时的增长速度可能很快，这样算下来预测会在接下来的4小时内使用完，但是我们登上主机一看，才用了40%，这时候就算有告警我们也不会处理。所以我们还可以再加一个条件，比如磁盘使用率大于80%并且在接下来的4小时内会使用完。如下：
(100 - (node_filesystem_avail_bytes{fstype!="",job="node-exporter"} / node_filesystem_size_bytes{fstype!="",job="node-exporter"} * 100)>80) and (predict_linear(node_filesystem_free_bytes{job="node-exporter",mountpoint!="",device!="rootfs"}[1h],4 * 3600) < 0)
除此之外，我们还需要监控磁盘的io，不论是云主机磁盘还是物理磁盘，每块盘都有其对应的IOPS，如果某个主机的IO很高，也会导致其他的问题，比如系统繁忙、负载很高等情况。node-exporter中定义了其指标，仅需要对其进行聚合，然后对聚合后的数据进行页面展示或者告警处理。其聚合公式如下：
100-(avg(irate(node_disk_io_time_seconds_total[1m])) by(instance)*100)
④ 可用性
可用性是指的主机可用性，我们可以通过up指标来判断主机是否可用，如果其值等于0表示宕机，等于1表示存活。比如下面即可表示主机不可用：
up{job="node-exporter"}==0
⑤ 服务状态
服务状态旨在监控关键服务，比如docker.service,ssh.service,kubelet.service等。指标为：
node_systemd_unit_state
比如监听docker.service的服务状态为存活：
node_systemd_unit_state{name="docker.service",state="active"} == 1
监控主要服务，以便于我们能在服务出问题的第一时间收到消息进行处理。
⑥ 网络
网络主要是监控其在每台主机上的出入流量，还有tcp连接状态。prometheus的node-exporter会抓取每台主机的网卡以及其出入网卡的流量，还有每台主机的TCP状态，我们可以将需要的指标进行聚合，根据聚合后的指标数据再进行页面展示或者告警处理。比如统计流入的流量：
((sum(rate (node_network_receive_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100)
统计流出的流量:
((sum(rate (node_network_transmit_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100)
以及统计TCP状态为ESTABLISHED的数量：
node_netstat_Tcp_CurrEstab
我们可以根据每个指标做对应的监控以及告警。
6.2 容器监控
1)为什么需要容器监控
在云原生时代，容器是我们应用的载体，它相当于应用的基础设施，所以对其的监控是很有必要的。我们在创建一个容器的时候往往会给其cpu和内存一个限制值，特别是内存，如果其使用达到了限制值，就会导致OOM，这时候我们就会做升级配置或查找原因处理。
2)监控的指标对象主要有哪些
监控对象主要有以下：cpu、memory、event
3)如何进行监控
我们使用cAdvisor来获取容器指标(kubelet已经集成了这个服务)。
① CPU
在容器中，就简单通过其使用率来监控其状态，我们通过其(使用量/limit)来得到其使用率。如下：
sum(
node_namespace_Pod_container:container_cpu_usage_seconds_total:sum_rate* on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (workload, workload_type,namespace,pod)
/sum(
kube_pod_container_resource_limits_cpu_cores* on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (workload, workload_type,namespace,pod) * 100 > 80
如果CPU的使用率持续大于我们设定的阈值，则考虑增加CPU的Limit值。
② memory
和CPU一样，通过其使用率来观察容器的内存是否充足。如下：
sum(
container_memory_working_set_bytes * on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (namespace,pod) / sum(
kube_pod_container_resource_limits_memory_bytes * on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (namespace,pod) * 100 / 2 > 80
如果内存的使用率大于我们设定的阈值，则考虑是否需要增加Pod的内存了。
③ 事件
这里的事件针对的是kubernetes的pod事件。在kubernetes中，事件分为两种，一种是Warning事件，表示产生这个事件的状态转换是在非预期的状态之间产生的；另外一种是Normal事件，表示期望到达的状态，和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例，当创建一个Pod的时候，首先Pod会进入Pending的状态，等待镜像的拉取，当镜像录取完毕并通过健康检查的时候，Pod的状态就变为Running。此时会生成Normal的事件。而如果在运行中，由于OOM或者其他原因造成Pod宕掉，进入Failed的状态，而这种状态是非预期的，那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言，如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。
在kubernetes中通过kube-eventer来进行事件监控，然后针对不同的事件来进行告警通知。
6.3 应用服务监控
1)为什么需要应用服务监控
应用是业务的载体，也是用户最直观的体验，应用的状态与否直接关系到业务的优良以及用户的体验。如果没有对其做好一定的监控措施，可能会出现以下问题：
无法识别或诊断故障
无法衡量应用程序的运行性能
无法衡量应用程序或组件的业务指标以及成功与否，例如跟踪销售数据或交易价值
2)有哪些监控指标
①应用程序监控
HTTP接口：URL存活、请求量、耗时、异常量
JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数连接池：总连接数、活跃连接数
业务指标：视业务来定，比如PV、订单量等
3)如何进行监控
① 应用程序监控
应用程序指标可以衡量应用程序的性能和状态，包括应用程序最终用户的体验，如延迟和响应时间。在这背后，我们测量了应用程序的吞吐量：请求、请求量、事务和事务时间。
(1)、HTTP接口监控可以使用prometheus的blackbox_exporter来进行接口存活的监控，可以用于对http,https,tcp,dns以及ICMP协议进行探测，从而抓取数据进行监控。
(2)、JVM监控通过在应用中埋点来暴露JVM数据，使用Prometheus监控采集JVM数据，借助Prometheus Grafana大盘来展示JVM数据，并创建报警，即可实现利用Prometheus监控JVM的目的。
② 业务指标监控
业务指标是应用程序指标的更进一层，它们通常与应用程序指标同义。如果你考虑将对特定服务的请求数量作为应用程序指标进行测量，那么业务指标通常会对请求的内容执行某些操作。一个应用程序指标的示例可能是测量支付交易的延迟，相应的业务指标可能是每个支付交易的价值。业务指标可能包括新用户/客户的数量、销售数量、按价值或位置划分的销售额，或者其他任何有助于衡量业务状况的指标。
6.4 第三方接口监控
1)为什么需要第三方接口监控
第三方接口的优良直接影响自身业务，所以对第三方接口的异常情况监控是非常重要的。主要是其的响应时间、存活性以及成功率。
2)有哪些监控指标
响应时间、存活性、成功率
3)如何进行监控
可以使用prometheus的blackbox_exporter来进行接口的监控。通过第三方接口监控的维度，我们可以方便地将自身服务与所使用到的第三方服务关联起来，以统一的视图展示服务用到了哪些第三方服务接口、这些第三方服务接口的响应时间和成功率是多少。当服务出现异常时，对于定位问题有很大帮助；同时一些内部的服务可能监控报警并不全面，第三方监控也能帮助他们提升服务质量。
七、告警通知
达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。Prometheus允许基于PromQL定义报警的触发条件，Prometheus周期性的对PromQL进行计算，当满足条件时就会向Alertmanager发送报警信息。
在配置告警规则的时候，我们将按组进行分类，这样就可以对相同组下的告警进行聚合，方便配置以及查看。Alertmanager在接收到报警后，可以对报警进行分组、抑制、静默等额外处理，然后路由到不同的接收器。Alertmanager支持多种报警通知方式，除常用的邮件通知外，还支持钉钉、企业微信等方式，也支持通过webhook自定义通知方式。我们可以按轻重缓急定义不同的通知方式，这样就可以根据不同通知方式采取不同的措施。
八、故障处理流程
收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。
8.1 故障等级划分
在处理故障之前，需要先清晰的认识是什么样的故障，然后再采取什么样的措施。所以我们就需要对故障等级做一个划分。例如将系统故障等级按照《信息系统安全等级保护基本要求》具体划分为四个等级，一级和二级故障为重大故障；三级和四级故障为一般性故障。
1)一级故障
系统发生故障，预计将已经严重影响公司生产业务系统，导致相关生产业务系统中断1小时以上，并预计24小时以内无法恢复的，具备以下一个或几个特征，既定义为一级故障。
公司机房网络与阿里云VPC网络出现故障，导致工作人员和用户无法访问相关业务系统；
WEB网站和APP系统等关键服务器宕机或有其他原因导致拒绝提供服务的；
利用技术手段造成业务数据被修改、假冒、泄漏、窃取的信息系统安全事件；
由病毒造成关键业务系统不能正常提供服务。
2)二级故障
信息系统发生故障，预计将或已经严重影响公司生产业务系统，导致相关生产业务系统中断1小时以上，并预计24小时以内可以恢复的，具备以下一个或几个特征，即定义为二级故障。
公司机房网络与阿里云VPC出现线路和设备故障；
WEB网站和APP系统等关键服务器宕机或有其他原因导致拒绝提供服务的；
12小时以内无法解决的三级故障。
3)三级故障
满足以下条件之一，即定义为三级故障。
故障发生后，影响到信息系统的运行效率，速度变慢，但不影响业务系统访问；
故障发生后预计在12小时以内恢复；
24小时以内无法解决的四级故障
4)四级故障
满足以下条件之一，即定义为四级故障。
故障发生后，可随时应急处理，不会影响系统的全面运行；
生产业务系统设备因病毒攻击等原因，造成网络数据出现偶尔掉包，但不影响系统的正常访问和运行。
8.2 故障处理程序
1)故障发现
工作人员在发现故障或接收到故障报告后，首先要记录故障发生时间和发现时间，及发现部门，发现人及联系电话，对故障的等级进行初步判定，并报告相关人员进行处理。
2)故障处理
发生故障的系统通知到运维人员，运维人员应先询问了解设备和配置近期的变更情况，查清故障的影响范围，从而确定故障的等级和发生故障的可能位置；
对于一般性故障按照规定的故障升级上报要求进行上报，并在处理过程中及时向主管领导通报故障处理情况；
对于重大故障按照规定的故障升级上报要求进行上报，并在处理过程中及时向主管领导通报故障处理情况。
3)故障上报
根据故障等级和发生的时限，要对故障的情况进行及时的上报，并对报告人，告知人际时间内容进行记录。重大故障由故障处理组领导负责上报，一般性故障由故障处理人员负责上报。故障升级上报时限如下表所示：
8.3 故障处理流程图
作者丨乔克
来源丨公众号：运维开发故事(ID：mygsdcsf)
企业应用运维管理指标体系
为了提升运维的投入产出比并提升运维侧对业务侧的价值创造属性，企业的运维部门需要构建一套运维管理指标体系，这将帮助企业运维部门形成高效的工作流体系，提升日常运维工作的效率，减轻运维工作对人工和经验的依赖，并为基于大数据的智能运维应用的部署提供支持和引导。本节转自：互联互通社区-IT智库
上图以博睿数据的企业应用运维指标体系为例，展示了一种的全新的企IT运维指标体系，这一体系从业务视角切入，以业务场景为主题，以业务连续性为宗旨，通过直面业务场景、正向梳理IT调用链、逆向接入数据源等实施步骤，最终构建起具备概览所有业务场景健康度、俯瞰多维立体化IT指标等能力的资源指标管理体系。
一、业务监测
业务端是企业应用运维指标体系的首要关注点。对于企业来说，业务状况是企业管理者最关心的部分，也是企业所有决策的基础，而随着大数据和人工智能技术的发展，大量企业借助信息技术实现转型升级。
业务分析常见指标说明
转化率：转化率指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率。计算公式为：转化率=(转化次数/点击量)×100%。例如10名用户看到某个搜索推广的结果，其中5名用户点击了某一推广结果并被跳转到目标URL上，之后其中的2名用户有了后续转化的行为。
点击率：“点击率”来自于英文“Click-throughRate”(点进率)以及“ClicksRatio”(点击率)，是指网站页面上某一内容被点击的次数与被显示次数之比，即clicks/views，能够反映网页上某一内容的受关注程度，经常用来衡量广告的吸引程度。
UV(UniqueVisitor)独立访客：统计1天内访问某站点的用户数(以cookie为依据)，通常将访问网站的一台电脑客户端计为一个访客，可以理解为访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。若更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数不变。若用户不保存cookies访问、清除cookies或者更换设备访问，计数会加1。
PV(PageView)访问量：页面浏览量或点击量，衡量网站用户访问的网页数量，在一定统计周期内用户每打开或刷新一个页面就记录1次，多次打开或刷新同一页面则浏览量累计。
启动用户数：通对启动用户数跨天去重，从而反应真实的UV。
留存率：互联网行业通过拉新或推广的活动把用户引过来，用户开始访问网站/应用，但是经过一段时间可能就会有一部分客户逐渐流失。留存率定义为用户在某段时间内开始使用网站/应用(一般定义是注册)，经过一段时间后，仍然继续使用的人被认作是留存用户。留存率体现了网站/应用的质量和保留用户的能力。
七日留存：指发生初始行为的用户经过七天，发生了回访行为的用户。例如，选择条件：初始行为=点击购买，回访行为=点击购买，4月1日发生购买的用户200人，这200人中4月7日再次购买的用户有50人，则第7日留存用户为50。
活跃用户数：传统意义上是一段时间内有访问行为的用户数，对于网站来说是访问，而对于APP来说是启动；时间窗口往往是天或月，例如：按天统计时就是DAU，按月统计时则是MAU。
ROI:投资回报率，对企业来说用于推广效果评估，可以助力企业实现一定程度的精准投放。
活跃用户ID数：每一个用户都会对应一个ID。
活跃天数：通常指人均活跃天数。
老用户数：通常指在特定分析时间段内，之前已经访问过的用户数量。
每日流失用户：当天没有访问网站的老用户。平均停留时间：平均每位访问者在网站上停留的时间。
人均使用时长：常见于对APP数据统计，人均使用时长=总使用时长/使用人数。
触发次数：触发一个事件的次数，比如点击登录、加购等按钮次数。
周活跃率：去重后的周活跃用户数量/历史累计去重后的用户数量。
日活跃率：去重后的日活跃用户数量/历史累计去重后的用户数量。
达成人数：完成特定流程或事件的人数。
页面访问次数：特定页面的打开次数。
新增用户占比：特定时间段内，新用户与总人数的比值。
二、用户端体验监测
用户端(APP、小程序、网站等)是企业与用户的数字触点，同时也是企业获客、留客的重要途径。在互联网/数字化服务的整个链条上，客户需首要关注的是用户端体验及表现，从而使得用户端体验成为数字化经营中企业产品力和市场竞争力的重要组成部分。
用户端监测常见指标说明
可优化延时：衡量会话受可优化问题的影响的时间量，如果解决了相应的可优化问题，用户就可以在更短的时间内完成会话。使用投影法可以计算会话可优化延时。
体验评分：以百分制计算会话的综合体验评分。体验评分=[(执行通过率/100%)舍尾取整]×(1-可用性)×100×[(1-可优化延时/会话整体耗时×权重A+(1-请求错误率)×权重B+(1-请求警示率)×权重C]，不可用或非100%通过的会话，会话体验评分为0。权重使用主客观综合赋权法确定，权重=0.8×主观权重+(1-0.8)×客观权重，0.8为初始权重参数。
首屏时间：用户访问网站时，页面第一屏的打开展现时间。
可用性：网站打开成功率，是反映网站是否稳定的重要指标。
ANR1：指在Android上，应用程序响应不够灵敏时，系统会向用户显示的一个对话框，通常关注指标有ANR次数、ANR率等。
整体性能：页面全部加载完成的时间，即页面打开的耗时。
崩溃：APP崩溃是导致用户流失的重要因素之一。由于大多数公司在APP上线之前无法做到在各种环境下的全面适配测试，出现崩溃在所难免。快速定位问题点及问题复现是崩溃分析的意义所在，公司常需要关注崩溃次数及崩溃率，通过崩溃堆栈进行问题分析与定位。
白屏时间：即用户点击一个链接或打开浏览器输入URL地址后，从屏幕空白到显示第一个画面的时间。白屏时间的长短将直接影响用户对该网站的第一印象。
首次渲染时间：从开始浏览到实际渲染出第一个像素之间的时间间隔。
卡顿：如果出现出现jank(FPS突降)、帧渲染缓慢、FPS长期过低三者之一，则会出现屏幕卡顿问题，可以通过查看受此问题影响的时间区域的FPS、帧渲染时间，确定具体的卡顿原因。
可交互时间：网页第一次完全达到可交互状态的时间点，可交互的状态下浏览器可以持续性地响应用户的输入。
通过率：以百分率表示在规定的时间内，会话未出现致命问题的情况下的动作执行通过性，通过率=会话预设交互已执行次数/总预设交互次数×100%。
用户端访问过程中的错误情况也需要关注，常见的错误包括JS错误、请求错误率、400错误率、500错误率、600错误率等。
DNS时间：指页面或元素访问过程中DNS解析所用的时间。
劫持比率：浏览过程中发生DNS劫持或页面劫持的总监测次数占总访问次数的比率。
首包时间：从页面浏览开始到接收到第一包数据(通常为基础文档数据)返回之间的时间差。
应用安装耗时：应用在安装过程中消耗的时间。
信息量：页面上显示的信息量，以图像判断所传递的信息量。
响应时间：指客户端发送调度请求之后到接收到调度服务器返回第一包数据之间的时间差。
TCP链接时间：下载该元素过程中建立TCP连接所用的时间。
SSL建连时间：下载元素所需的SSL握手用时。
CDN：构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。是目前常用的网站加速技术。国内CDN厂商众多，企业每年在CDN服务方面投入从千万级到十万级不等，因此CDN服务质量也是各类网站的关注重点，了解其服务质量主要通过CDN请求性能、CDN运营商匹配率、CDN城市匹配率来评估。
三、应用端监测
了解应用访问情况是企业 IT 运维的基础。用户端指标所反映的访问情况只是一个表象，用户端真正所访问到的其实是网站的后台应用，当前企业面临着日益激增的 IT 复杂性和业务需求的快速变化，IT 应用在运行过程中发生性能下降或者服务不可用等故障的可能性大大增加，从而影响业务服务的正常运行。
健康度：应用健康度的标示，展示应用当前是否有性能问题。常分为四个等级：正常、较慢、很慢、停滞。
Apdex：全称是ApplicationPerformanceIndex，是由Apdex联盟开发的用于评估应用性能的工业标准。Apdex标准从用户的角度出发，将对应用响应时间的表现，转为用户对于应用性能的可量化范围为0-1的满意度评价。
响应时间：应用的平均响应时间。错误率：发生错误的请求占比，即所选时间范围内，业务过程错误数量之和／总请求数×100%。
吞吐率：包含自身调用、数据库调用、NoSQL调用、第三方服务调用过程中所传输的数据量。
慢请求次数：发生慢请求的次数，需要进一步定位慢请求所对应的业务、容器、容器集和集群。
慢请求占比：发生慢请求次数占所有请求次数的比例。
此外，企业还需要关注数据库的调用数据库错误率、调用数据库次数及调用数据库响应时间；除了企业的自身调用需要关注外，其外部调用同样也需要，常见指标包括：调用外部服务次数、调用外部服务响应时间、调用外部服务错误率等。
四、网络监测
各个应用之间的调用通过网络来实现，各个企业 IT 建设的规模与复杂度与日俱增，需要通过网络监测对现有运维流程进行优化，不断提升管理和运维水平。
网络监测常见指标说明
流量：传输数据的总量(单位Byte)。
吞吐量：传输数据的速率(单位bps)。
建连成功率：建连成功次数占总请求次数的比率。
客户端传输时延：服务侧丢包时，客户端传输停顿到重传包的平均时间。
丢包率：数据交互过程中丢包数与总包数的比率。
客户数：访问源客户端总个数。
流入包数：流入传输数据总包数。
流出字节：流出数据的字节数。
包大小：数据包大小。
服务器延时：数据包从服务端传送到客户端的平均耗时。
其它常关注指标有：流出吞吐量、重传时延、大包占比、0窗口(TCP报头结构中有16位的窗口大小，由接收方填充用来告知发送方当前本端还能接收的数据长度。如果接收方不断从网络中接收并缓存数据，但是应用程序并没有处理缓存的数据，直到最后接收方就会向发送方发送一个0窗口的报文段)、流入字节、流入吞吐量、中包占比及带宽等。
五、资源层监测
网站所有服务均体现在基础资源层面，因此基础资源监控是所有监控中最底层的部分，也是实现AIOps不可或缺的一环。
资源层监测常用指标
CPU使用率：服务器运行的程序占用的CPU资源，表示服务器在某个时间点的运行程序的情况。
内存使用率：体现进程在服务器中所开销的内存使用率。除此之外还有磁盘使用率及CPU使用率、当前进程打开文件数、过去5分钟系统平均负载、当前内核空间占用CPU百分比、GPU显存空闲量、磁盘每秒写入字节数等。
在微服务环境下，企业使用K8s对容器进行编排管理，对K8s的管理监控也是基础资源监控的一部分。K8s监测通常需要覆盖以下8方面：Cluster(集群)，Node8(节点)，Workspace(企业空间)，Namespace(项目)，Workload(工作负载)，Pod7(容器组)，Container(容器)，Component(KubeSphere核心组件)。其常见监控指标为：集群节点总数、集群中调度完成Pod数。
六、中间件监测
中间件是介于应用系统和系统软件之间的一类软件，位于客户机服务器的操作系统之上，管理计算资源和网络通信，衔接网络上应用系统的各个部分或不同的应用，从而实现资源共享、功能共享的目的。中间件是一类独立的系统软件服务程序，分布式应用软件借助中间件在不同的技术之间共享资源，根据链接的资源和功能的不同，中间件分为消息中间件、交易中间件和服务器中间件等种类。
1、消息中间件
常见指标消息中间件利用高效可靠的消息传递机制进行数据交流，并基于数据通信来实现分布式系统的集成。只要有网络就会有数据传递，消息中间件的应用牵涉到数据传输的安全可靠，在任何网络环境下都具备较强的刚需属性。消息中间件包含老牌的ActiveMQ5、RabbitMQ以及炙手可热的Kafka，RocketMQ等。
消息中间件常见指标包括：消息订阅错误数、消息订阅数量、消息推送平均耗时、消息推送错误数、消息推送数量、消息订阅平拒绝耗时。
2、交易中间件常见指标
交易中间件是协助开发在线交易系统(OLTP)的C/S/S应用框架，其主要功能包括：1、支持大量客户端的链接和高并发交易的处理；2、便捷定制应用服务功能，实现服务器端的业务逻辑；3、对企业各个层次的IT资源均衡使用；4、提供一定程度的交易安全保证。交易中间件在金融、财税、运输、电力、电信等行业中具有广泛应用和推广。
交易中间件通常使用java来开发，所以在运维监测过程中需要关注JVM的使用情况，常见指标包括：
新生代内存的垃圾收集事件称为YoungGC(又称MinorGC)，当JVM无法为新对象分配新生代内存空间时会触发YoungGC，需要关注其产生的平均数量和平均时间。
FullGC：清理整个堆的GC事件，包括新生代、老年代、元空间等，需要关注指标的平均数量及平均时间。
一般情况下，新创建的对象都会被分配到Eden区，为大多数对象分配内存的池，所以需要实时了解Eden区使用率及平均使用情况。在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到老年代。需要关注老年代使用率指标，用于对老年代区域中数据进行整理及分析。
七、数据库监测
数据库是按照数据结构来组织、存储和管理数据的仓库，是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。
数据库监测常用指标说明
查询响应时间：即从提交查询到结果返回所需的时间。
QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
查询错误率：数据库查询过程中出错概率。
健康度：对数据库监控各项指标进行加权统计，并通过专家模型得到健康度打分。
连接数：数据库当前连接数，可以显示包括IP的连接方、连接个数、连接状态及接时长等信息。
链接利用率：数据库链接的可利用占比。
除此之外还需关注数据库请求平均耗时、数据库请求详情、SQL查询耗时排名等指标。
八、小结监控和可观察性对提升系统管理的作用
在不断发展的 DevOps 世界中，深入了解系统行为、诊断问题和提高整体性能的能力是首要任务之一。监控和可观察性是促进这一过程的两个关键概念，为系统的健康和性能提供了宝贵的可见性。虽然这些术语经常可以互换使用，但它们代表着理解和管理复杂系统的不同方法。在本文中，将探讨监视和可观察性之间的差异，提供示例来说明它们的应用，并强调各自的又是。同时还将深入研究用于有效监测和可观测性的技术和工具。
监控：了解系统状态
监控的重点是收集和分析有关系统或应用程序状态的数据。它通常包括设置特定的指标、阈值和警报机制，以跟踪各种组件的性能和可用性。常见的监测技术和工具包括：
指标监控：使用 Nagios、Zabbix、Prometheus 和 Datadog 等工具监控预定义的指标，如 CPU 使用情况、内存消耗、磁盘空间、网络流量和特定于应用程序的指标。
日志监控：使用 ELK Stack（Elasticsearch、Logstash 和 Kibana）、Splunk 或 Graylog 等工具分析系统不同组件生成的日志，以识别错误、安全漏洞或异常行为。
综合监控：使用 Selenium、Pingdom 或 New Relic Synthetics 等工具模拟用户交互并监控系统响应，以确保可用性和性能。
可观察性：理解系统行为
可观察性采用更全面的方法，通过分析相互关联的组件及其关系来理解和解释复杂系统的行为。它强调回答问题和调查超出预定义度量的系统行为的能力。其使用的技术和工具包括:
分布式跟踪：使用 Jaeger、Zipkin 或 AWS X-Ray 等工具捕获和分析通过分布式系统的请求流。它支持识别瓶颈、延迟问题和依赖关系。
应用程序日志记录：使用 Fluentd、Logback 或 Log4j 等工具收集具有上下文信息的结构化日志，以跟踪执行路径、解决问题并全面了解系统行为。
实时分析：利用流数据平台 (如 Apache Kafka 或 Apache Flink) 和可视化工具 (如 Grafana 或 Kibana) 来处理和分析大容量、实时数据流，以获得系统性能洞察。
监控和可观察性用例
以下是监控和可观察性在 DevOps 中发挥重要作用的几个常见用例：
应用程序性能监控 (APM)
监控：跟踪响应时间、错误率和资源利用率等指标，以确保最佳性能。例如，设置 CPU 使用率高或响应时间慢的警报。
可观察性：分析分布式跟踪和日志，以识别性能瓶颈，了解依赖关系，并排除问题。例如，使用分布式跟踪来查明跨微服务的延迟问题。
基础设施监控
监控：跟踪服务器指标（CPU、内存、磁盘空间）和网络指标（带宽、延迟），以确保基础设施运行状况。例如，监视磁盘空间以避免由于磁盘已满而导致的潜在停机。
可观察性：分析日志和事件，以识别异常行为或安全威胁。例如，使用日志分析来检测未经授权的访问尝试或系统日志中的异常模式。
云资源监控
监控：跟踪云服务（如 AWS CloudWatch、Azure Monitor）的资源利用率和性能指标，以优化成本并确保服务可用性。例如，监视自动扩展组中已配置实例的数量。
可观察性：分析云提供商日志、跟踪和指标，以深入了解云资源的行为并诊断问题。例如，使用可观察性工具来识别无服务器架构中的性能瓶颈。
持续集成/持续部署（CI/CD）管道
监控：跟踪构建和部署指标（例如，构建持续时间、成功 / 失败率），以确保 CI/CD 管道的效率和可靠性。例如，监视生成队列长度以防止出现瓶颈。
可观察性：分析来自 CI/CD 工具 (例如 Jenkins, CircleCI) 的日志和事件，以排除构建或部署失败的故障。例如，使用可观察性来调查部署失败的原因。
网络监控
监控：跟踪网络流量、延迟和数据包丢失，以确保网络性能并识别潜在问题。例如，监控网络带宽利用率以防止拥塞。
可观察性：分析网络日志、数据包捕获和流数据，以诊断网络问题、检测安全漏洞或识别异常行为。例如，使用可观察性工具来调查网络错误的突然增加。
这些只是监控和可观察性如何应用于各种 DevOps 用例的几个例子。具体的用例和需求可能因系统、基础设施和团队需求的性质而异。
小结
监控通过捕获预定义的指标和基于阈值的警报来提供系统运行状况和性能的快照。它可用于检测特定问题或事件，并提供有关系统或应用程序状态的即时反馈。可观察性提供了对复杂系统更全面的了解，支持主动故障排除和根本原因分析。它侧重于获取上下文信息，揭示预定义指标之外的见解，培养持续改进的文化。实现可观察性通常需要额外的工具和架构考虑，这可能会增加复杂性和资源需求。然而，深度系统理解的好处以及解决未知或未预料到的问题的能力使其值得投资。
监控和可观察性都是现代 DevOps 实践的重要组成部分，但它们涉及系统可见性的不同方面。监控提供了系统运行状况的集中和即时视图，跟踪预定义的度量和阈值，而可观察性提供了对系统行为的整体理解，捕获上下文信息并支持深入分析。通过结合监控和可观察性技术并利用适当的工具，团队可以获得对系统性能的全面了解，及早发现问题，并不断优化其系统。在监视预定义的度量和通过可观察性探索不可预见的场景之间保持平衡，使团队能够在 DevOps 的动态世界中有效地管理和改进其软件系统的可靠性、性能和恢复能力。
一、监控的目的
监控贯穿应用的整个生命周期，即从程序设计、开发、部署、下线，其主要的服务对象有：技术、业务
技术通过监控系统可以了解技术的环境状态，可以帮助检测、诊断、解决技术环境中的故障和问题。然而监控系统的最终目标是业务，是为了更好的支持业务运行，确保业务的持续开展。所以监控的目的可以简单归纳如下：
能够对系统进行7*24小时的实时监控；
能够及时反馈系统状态；
保证平台的稳定运行；
保证服务的安全可靠；
保证业务的持续运行。
二、监控的模式
监控由上至下可以分为：
业务监控、应用监控、操作系统
其中业务监控主要是研发提供一些业务指标、业务数据，对其增长率、错误率等进行告警或者展示，需要提前定义规范甚至埋点。应用程序的监控主要有探针和内省。其中探针主要是从外部探测应用程序的特征，比如监听端口是否有响应。内省主要是查看应用程序内部的内容，应用程序通过检测并返回其内部的状态，内部的组件，事务和性能等度量，它可以直接将事件、日志和指标直接发送给监控工具。操作系统主要是监控主要组件的使用率、饱和度以及错误，比如CPU的使用率、CPU的负载等。
三、监控的方式
监控的主要方式有:
健康检查。健康检查是对应用本身健康状况的监控，检查服务是否还正常存活。
日志。日志是排查问题的主要方式，日志可以提供丰富的信息用于定位和解决问题。
调用链监控。调用链监控可以完整的呈现出一次请求的全部信息，包括服务调用链路、所耗时间等。
指标监控。指标是一些基于时间序列的离散数据点，通过聚合和计算后能反映出一些重要指标的趋势。
在上述4种监控方式中，健康检查是云平台等基础设施提供的能力，日志则一般有单独的日志中心进行日志的采集、存储、计算和查询，调用链监控一般也有独立的解决方案进行服务调用的埋点、采集、计算和查询，指标监控则是通过一些exporter抓取目标暴露的指标，然后对这些指标数据进行清理、聚合，我们通过聚合出来的数据进行展示、告警等。
说明：该方案主要是针对指标监控
四、监控选型
4.1 健康检查
云平台提供健康检查能力，直接在云平台中配置。
4.2 日志
成熟的开源日志解决方案是ELK。
4.3 调用链监控
调用链健康使用第三方的健康软件，常用的有skywalking、zikpin、pinpoint、elastic APM、Cat。其中zikpin和cat对代码有一定的侵入性，而skywalking、pinpoint、elastic APM是基于字节码注入技术，对代码没有侵入性，而且改动最小。
pinpoint的agent仅支持java和php，而skywalking和elastic APM都支持多种语言，比如java/nodejs/go等。在云原生环境下，skywalking和elastic APM更适合。
elastic APM直接使用es作为存储，可以在kibana上直接看应用信息，但是其关系图是需要产生一定的费用。skywalking是国人开源的一款产品，已经毕业于Apache基金会，社区非常活跃，版本迭代很快，专为微服务、云原生架构和基于容器(docker、K8s、Mesos)架构而设计。
4.4 指标监控
在云原生环境、传统的监控方式并不适合，在传统环境，zabbix无疑是首选，但是在云原生环境，Prometheus却成为了热门，其主要原因有：
成熟的社区支撑。Prometheus是CNCF的毕业项目，有许多大厂做背书，社区庞大，是首推的云原生监控解决方案。
易于部署和运维。Prometheus核心只有一个二进制文件，没有其他的第三方依赖，部署运维均十分方便。
采用Pull模型，通过HTTP的Pull方式从各个监控目标拉取监控数据。Push模型一般通过Agent方式去采集信息并推送到收集器中，每个服务的Agent都需要配置监控数据项与监控服务端的信息，在大量服务时会加大运维难度；另外，采用Push模型，在流量高峰期间监控服务端会同时接收到大量请求和数据，会给监控服务端造成很大压力，严重时甚至服务不可用。
强大的数据模型。Prometheus采集到的监控数据均以指标的形式存在于内置的时序数据库中，除了基本的指标名称外，还支持自定义的标签。通过标签可以定义出丰富的维度，方便进行监控数据的聚合和计算。
强大的查询语言PromQL。通过PromQL可以实现对监控数据的查询、聚合、可视化、告警。
完善的生态。常见的操作系统、数据库、中间件、类库、编程语言，Prometheus都提供了接入方案，并且提供了Java/Golang/Ruby/Python等语言的客户端SDK，能够快速实现自定义的监控逻辑。
高性能。Prometheus单一实例即可处理数以百计的监控指标，每秒处理数十万的数据，在数据采集和查询方面有着优异的性能表现。
注意：由于采集的数据有可能丢失，Prometheus并不适合对采集数据要求100%准确的场景。
五、Prometheus监控系统概述
监控系统的整体框架如下：
Prometheus Server：用于抓取指标、存储时间序列数据
exporter：暴露指标让任务来抓
pushgateway：push 的方式将指标数据推送到该网关
alertmanager：处理报警的报警组件
adhoc：用于数据查询
其流程很简单，Prometheus server端可以直接接收或者通过pushgateway获取到数据，存储到TSDB中，然后对数据进行规则整理，通过Altermanager进行报警或者通过Grafana等工具进行展示。
六、指标监控的对象
监控系统一般采用分层的方式划分监控对象。在我们的监控系统中，主要关注以下几种类型的监控对象：
主机监控，主要指主机节点软、硬件资源的一些监控数据。
容器环境监控，主要指服务所处运行环境的一些监控数据。
应用服务监控，主要指服务本身的基础数据指标，提现服务自身的运行状况。
第三方接口监控，主要指调用其他外部服务接口的情况。
对于应用服务和第三方接口监控，我们常用的指标包括：响应时间、请求量QPS、成功率。
6.1 主机监控
1)为什么需要主机监控
主机是系统的载体，一切系统应用都运行在主机之上，如果某台或者几台主机宕机，会导致上面运行的所以应用都没办法正常提供服务，严重者导致生产事故。所以对主机的监控与预警是非常有必要的，我们可以在其出故障之前对其进行处理，避免严重的事故发生。
2)如何判断资源情况
主机的监控主要从一下三个方面来综合考虑其状态：
使用率：资源忙于工作的平均时间，通常是随时间变化的百分比
饱和度：资源队列的长度
错误：资源错误事件的计数
3)哪些资源需要监控
主机的主要资源对象有：CPU、内存、磁盘、可用性、服务状态、网络
4)如何进行监控
在Prometheus监控方案中，主机的资源指标是通过node-exporter来进行采集，然后存储在Prometheus时序数据库里，然后可以通过PromQL来查询各个指标的具体情况。
①CPU
CPU主要从使用率和饱和度来进行监控。
(1)使用率，指标node_cpu_seconds_total通常会根据CPU使用率超过多少来进行告警，比如当CPU使用率大于80%，则进行告警，当然CPU是一个Gauge类型的，它的数据是会上下增减的，所以我们在判断CPU使用率的时候通常是一段时间内CPU持续高达多少的时候才进行告警，比如下面的表达式就是统计5分钟内CPU使用率大于60%的主机：
100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)* 100) > 60
CPU指标还有用户态、内核态的指标数据，这个根据情况来进行监控。
(2)饱和度，指标node_loadCPU的饱和度通常指的是CPU的负载情况。正常情况下CPU的整体负载不超过CPU的总数，比如2颗CPU，则负载不超过2。我们收集到的指标有1分钟、5分钟、15分钟的负载数据，在配置监控的时候选择好统计时间，一般情况下会选择5分钟的负载作为统计，如下表示5分钟的负载大于CPU的总数的2倍：
node_load5 > on (instance) 2 * count by(instance)(node_cpu_seconds_total{mode="idle"})
②内存
内存主要从使用率和饱和度来进行监控。
(1)使用率 内存的使用率可以直观的看到整体CPU的使用情况，其计算方式使用(free + buffer + cache)/ total。指标主要有：
node_memory_MemTotal_bytes：主机上的总内存
node_memory_MemFree_bytes：主机上的可用内存
node_memory_Buffers_bytes：缓冲缓存中的内存
node_memory_Cached_bytes：页面缓存中的内存
比如下面的表达式是用于统计内存使用率大于80%：
100 - sum(node_memory_MemFree_bytes{job="node-exporter"} + node_memory_Buffers_bytes{job="node-exporter"} + node_memory_Cached_bytes{job="node-exporter"})by (instance) / sum(node_memory_MemTotal_bytes{job="node-exporter"})by(instance)*100 > 80
(2)饱和度 内存的饱和度是指内存和磁盘的读写情况来监控。指标有：
node_vmstat_pswpin：系统每秒从磁盘读到内存的字节数，单位KB
node_vmstat_pswpout：系统每秒从内存写到磁盘的字节数，单位KB
③ 磁盘
磁盘的监控有点特殊，我们不按着USE的方法去测量。如果单考虑其使用率并没有多大的效果，因为10G剩余20%和1T剩余20%对我们的影响是不一样的，所以我们可以监控其增长趋势以及方向。比如：根据前面1h的磁盘增长情况来预测在4h内是否会把磁盘用完
predict_linear(node_filesystem_free_bytes{job="node-exporter",mountpoint!=""}[1h], 4*3600)
当然，如果仅仅这样预测也会产生很多垃圾告警，因为在某一小时的增长速度可能很快，这样算下来预测会在接下来的4小时内使用完，但是我们登上主机一看，才用了40%，这时候就算有告警我们也不会处理。所以我们还可以再加一个条件，比如磁盘使用率大于80%并且在接下来的4小时内会使用完。如下：
(100 - (node_filesystem_avail_bytes{fstype!="",job="node-exporter"} / node_filesystem_size_bytes{fstype!="",job="node-exporter"} * 100)>80) and (predict_linear(node_filesystem_free_bytes{job="node-exporter",mountpoint!="",device!="rootfs"}[1h],4 * 3600) < 0)
除此之外，我们还需要监控磁盘的io，不论是云主机磁盘还是物理磁盘，每块盘都有其对应的IOPS，如果某个主机的IO很高，也会导致其他的问题，比如系统繁忙、负载很高等情况。node-exporter中定义了其指标，仅需要对其进行聚合，然后对聚合后的数据进行页面展示或者告警处理。其聚合公式如下：
100-(avg(irate(node_disk_io_time_seconds_total[1m])) by(instance)*100)
④ 可用性
可用性是指的主机可用性，我们可以通过up指标来判断主机是否可用，如果其值等于0表示宕机，等于1表示存活。比如下面即可表示主机不可用：
up{job="node-exporter"}==0
⑤ 服务状态
服务状态旨在监控关键服务，比如docker.service,ssh.service,kubelet.service等。指标为：
node_systemd_unit_state
比如监听docker.service的服务状态为存活：
node_systemd_unit_state{name="docker.service",state="active"} == 1
监控主要服务，以便于我们能在服务出问题的第一时间收到消息进行处理。
⑥ 网络
网络主要是监控其在每台主机上的出入流量，还有tcp连接状态。prometheus的node-exporter会抓取每台主机的网卡以及其出入网卡的流量，还有每台主机的TCP状态，我们可以将需要的指标进行聚合，根据聚合后的指标数据再进行页面展示或者告警处理。比如统计流入的流量：
((sum(rate (node_network_receive_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100)
统计流出的流量:
((sum(rate (node_network_transmit_bytes_total{device!~'tap.*|veth.*|br.*|docker.*|virbr*|lo*'}[5m])) by (instance)) / 100)
以及统计TCP状态为ESTABLISHED的数量：
node_netstat_Tcp_CurrEstab
我们可以根据每个指标做对应的监控以及告警。
6.2 容器监控
1)为什么需要容器监控
在云原生时代，容器是我们应用的载体，它相当于应用的基础设施，所以对其的监控是很有必要的。我们在创建一个容器的时候往往会给其cpu和内存一个限制值，特别是内存，如果其使用达到了限制值，就会导致OOM，这时候我们就会做升级配置或查找原因处理。
2)监控的指标对象主要有哪些
监控对象主要有以下：cpu、memory、event
3)如何进行监控
我们使用cAdvisor来获取容器指标(kubelet已经集成了这个服务)。
① CPU
在容器中，就简单通过其使用率来监控其状态，我们通过其(使用量/limit)来得到其使用率。如下：
sum(
node_namespace_Pod_container:container_cpu_usage_seconds_total:sum_rate* on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (workload, workload_type,namespace,pod)
/sum(
kube_pod_container_resource_limits_cpu_cores* on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (workload, workload_type,namespace,pod) * 100 > 80
如果CPU的使用率持续大于我们设定的阈值，则考虑增加CPU的Limit值。
② memory
和CPU一样，通过其使用率来观察容器的内存是否充足。如下：
sum(
container_memory_working_set_bytes * on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (namespace,pod) / sum(
kube_pod_container_resource_limits_memory_bytes * on(namespace,pod)
group_left(workload, workload_type) mixin_pod_workload
) by (namespace,pod) * 100 / 2 > 80
如果内存的使用率大于我们设定的阈值，则考虑是否需要增加Pod的内存了。
③ 事件
这里的事件针对的是kubernetes的pod事件。在kubernetes中，事件分为两种，一种是Warning事件，表示产生这个事件的状态转换是在非预期的状态之间产生的；另外一种是Normal事件，表示期望到达的状态，和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例，当创建一个Pod的时候，首先Pod会进入Pending的状态，等待镜像的拉取，当镜像录取完毕并通过健康检查的时候，Pod的状态就变为Running。此时会生成Normal的事件。而如果在运行中，由于OOM或者其他原因造成Pod宕掉，进入Failed的状态，而这种状态是非预期的，那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言，如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。
在kubernetes中通过kube-eventer来进行事件监控，然后针对不同的事件来进行告警通知。
6.3 应用服务监控
1)为什么需要应用服务监控
应用是业务的载体，也是用户最直观的体验，应用的状态与否直接关系到业务的优良以及用户的体验。如果没有对其做好一定的监控措施，可能会出现以下问题：
无法识别或诊断故障
无法衡量应用程序的运行性能
无法衡量应用程序或组件的业务指标以及成功与否，例如跟踪销售数据或交易价值
2)有哪些监控指标
①应用程序监控
HTTP接口：URL存活、请求量、耗时、异常量
JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数连接池：总连接数、活跃连接数
业务指标：视业务来定，比如PV、订单量等
3)如何进行监控
① 应用程序监控
应用程序指标可以衡量应用程序的性能和状态，包括应用程序最终用户的体验，如延迟和响应时间。在这背后，我们测量了应用程序的吞吐量：请求、请求量、事务和事务时间。
(1)、HTTP接口监控可以使用prometheus的blackbox_exporter来进行接口存活的监控，可以用于对http,https,tcp,dns以及ICMP协议进行探测，从而抓取数据进行监控。
(2)、JVM监控通过在应用中埋点来暴露JVM数据，使用Prometheus监控采集JVM数据，借助Prometheus Grafana大盘来展示JVM数据，并创建报警，即可实现利用Prometheus监控JVM的目的。
② 业务指标监控
业务指标是应用程序指标的更进一层，它们通常与应用程序指标同义。如果你考虑将对特定服务的请求数量作为应用程序指标进行测量，那么业务指标通常会对请求的内容执行某些操作。一个应用程序指标的示例可能是测量支付交易的延迟，相应的业务指标可能是每个支付交易的价值。业务指标可能包括新用户/客户的数量、销售数量、按价值或位置划分的销售额，或者其他任何有助于衡量业务状况的指标。
6.4 第三方接口监控
1)为什么需要第三方接口监控
第三方接口的优良直接影响自身业务，所以对第三方接口的异常情况监控是非常重要的。主要是其的响应时间、存活性以及成功率。
2)有哪些监控指标
响应时间、存活性、成功率
3)如何进行监控
可以使用prometheus的blackbox_exporter来进行接口的监控。通过第三方接口监控的维度，我们可以方便地将自身服务与所使用到的第三方服务关联起来，以统一的视图展示服务用到了哪些第三方服务接口、这些第三方服务接口的响应时间和成功率是多少。当服务出现异常时，对于定位问题有很大帮助；同时一些内部的服务可能监控报警并不全面，第三方监控也能帮助他们提升服务质量。
七、告警通知
达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。Prometheus允许基于PromQL定义报警的触发条件，Prometheus周期性的对PromQL进行计算，当满足条件时就会向Alertmanager发送报警信息。
在配置告警规则的时候，我们将按组进行分类，这样就可以对相同组下的告警进行聚合，方便配置以及查看。Alertmanager在接收到报警后，可以对报警进行分组、抑制、静默等额外处理，然后路由到不同的接收器。Alertmanager支持多种报警通知方式，除常用的邮件通知外，还支持钉钉、企业微信等方式，也支持通过webhook自定义通知方式。我们可以按轻重缓急定义不同的通知方式，这样就可以根据不同通知方式采取不同的措施。
八、故障处理流程
收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。
8.1 故障等级划分
在处理故障之前，需要先清晰的认识是什么样的故障，然后再采取什么样的措施。所以我们就需要对故障等级做一个划分。例如将系统故障等级按照《信息系统安全等级保护基本要求》具体划分为四个等级，一级和二级故障为重大故障；三级和四级故障为一般性故障。
1)一级故障
系统发生故障，预计将已经严重影响公司生产业务系统，导致相关生产业务系统中断1小时以上，并预计24小时以内无法恢复的，具备以下一个或几个特征，既定义为一级故障。
公司机房网络与阿里云VPC网络出现故障，导致工作人员和用户无法访问相关业务系统；
WEB网站和APP系统等关键服务器宕机或有其他原因导致拒绝提供服务的；
利用技术手段造成业务数据被修改、假冒、泄漏、窃取的信息系统安全事件；
由病毒造成关键业务系统不能正常提供服务。
2)二级故障
信息系统发生故障，预计将或已经严重影响公司生产业务系统，导致相关生产业务系统中断1小时以上，并预计24小时以内可以恢复的，具备以下一个或几个特征，即定义为二级故障。
公司机房网络与阿里云VPC出现线路和设备故障；
WEB网站和APP系统等关键服务器宕机或有其他原因导致拒绝提供服务的；
12小时以内无法解决的三级故障。
3)三级故障
满足以下条件之一，即定义为三级故障。
故障发生后，影响到信息系统的运行效率，速度变慢，但不影响业务系统访问；
故障发生后预计在12小时以内恢复；
24小时以内无法解决的四级故障
4)四级故障
满足以下条件之一，即定义为四级故障。
故障发生后，可随时应急处理，不会影响系统的全面运行；
生产业务系统设备因病毒攻击等原因，造成网络数据出现偶尔掉包，但不影响系统的正常访问和运行。
8.2 故障处理程序
1)故障发现
工作人员在发现故障或接收到故障报告后，首先要记录故障发生时间和发现时间，及发现部门，发现人及联系电话，对故障的等级进行初步判定，并报告相关人员进行处理。
2)故障处理
发生故障的系统通知到运维人员，运维人员应先询问了解设备和配置近期的变更情况，查清故障的影响范围，从而确定故障的等级和发生故障的可能位置；
对于一般性故障按照规定的故障升级上报要求进行上报，并在处理过程中及时向主管领导通报故障处理情况；
对于重大故障按照规定的故障升级上报要求进行上报，并在处理过程中及时向主管领导通报故障处理情况。
3)故障上报
根据故障等级和发生的时限，要对故障的情况进行及时的上报，并对报告人，告知人际时间内容进行记录。重大故障由故障处理组领导负责上报，一般性故障由故障处理人员负责上报。故障升级上报时限如下表所示：
8.3 故障处理流程图
作者丨乔克
来源丨公众号：运维开发故事(ID：mygsdcsf)
企业应用运维管理指标体系
为了提升运维的投入产出比并提升运维侧对业务侧的价值创造属性，企业的运维部门需要构建一套运维管理指标体系，这将帮助企业运维部门形成高效的工作流体系，提升日常运维工作的效率，减轻运维工作对人工和经验的依赖，并为基于大数据的智能运维应用的部署提供支持和引导。本节转自：互联互通社区-IT智库
上图以博睿数据的企业应用运维指标体系为例，展示了一种的全新的企IT运维指标体系，这一体系从业务视角切入，以业务场景为主题，以业务连续性为宗旨，通过直面业务场景、正向梳理IT调用链、逆向接入数据源等实施步骤，最终构建起具备概览所有业务场景健康度、俯瞰多维立体化IT指标等能力的资源指标管理体系。
一、业务监测
业务端是企业应用运维指标体系的首要关注点。对于企业来说，业务状况是企业管理者最关心的部分，也是企业所有决策的基础，而随着大数据和人工智能技术的发展，大量企业借助信息技术实现转型升级。
业务分析常见指标说明
转化率：转化率指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率。计算公式为：转化率=(转化次数/点击量)×100%。例如10名用户看到某个搜索推广的结果，其中5名用户点击了某一推广结果并被跳转到目标URL上，之后其中的2名用户有了后续转化的行为。
点击率：“点击率”来自于英文“Click-throughRate”(点进率)以及“ClicksRatio”(点击率)，是指网站页面上某一内容被点击的次数与被显示次数之比，即clicks/views，能够反映网页上某一内容的受关注程度，经常用来衡量广告的吸引程度。
UV(UniqueVisitor)独立访客：统计1天内访问某站点的用户数(以cookie为依据)，通常将访问网站的一台电脑客户端计为一个访客，可以理解为访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。若更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数不变。若用户不保存cookies访问、清除cookies或者更换设备访问，计数会加1。
PV(PageView)访问量：页面浏览量或点击量，衡量网站用户访问的网页数量，在一定统计周期内用户每打开或刷新一个页面就记录1次，多次打开或刷新同一页面则浏览量累计。
启动用户数：通对启动用户数跨天去重，从而反应真实的UV。
留存率：互联网行业通过拉新或推广的活动把用户引过来，用户开始访问网站/应用，但是经过一段时间可能就会有一部分客户逐渐流失。留存率定义为用户在某段时间内开始使用网站/应用(一般定义是注册)，经过一段时间后，仍然继续使用的人被认作是留存用户。留存率体现了网站/应用的质量和保留用户的能力。
七日留存：指发生初始行为的用户经过七天，发生了回访行为的用户。例如，选择条件：初始行为=点击购买，回访行为=点击购买，4月1日发生购买的用户200人，这200人中4月7日再次购买的用户有50人，则第7日留存用户为50。
活跃用户数：传统意义上是一段时间内有访问行为的用户数，对于网站来说是访问，而对于APP来说是启动；时间窗口往往是天或月，例如：按天统计时就是DAU，按月统计时则是MAU。
ROI:投资回报率，对企业来说用于推广效果评估，可以助力企业实现一定程度的精准投放。
活跃用户ID数：每一个用户都会对应一个ID。
活跃天数：通常指人均活跃天数。
老用户数：通常指在特定分析时间段内，之前已经访问过的用户数量。
每日流失用户：当天没有访问网站的老用户。平均停留时间：平均每位访问者在网站上停留的时间。
人均使用时长：常见于对APP数据统计，人均使用时长=总使用时长/使用人数。
触发次数：触发一个事件的次数，比如点击登录、加购等按钮次数。
周活跃率：去重后的周活跃用户数量/历史累计去重后的用户数量。
日活跃率：去重后的日活跃用户数量/历史累计去重后的用户数量。
达成人数：完成特定流程或事件的人数。
页面访问次数：特定页面的打开次数。
新增用户占比：特定时间段内，新用户与总人数的比值。
二、用户端体验监测
用户端(APP、小程序、网站等)是企业与用户的数字触点，同时也是企业获客、留客的重要途径。在互联网/数字化服务的整个链条上，客户需首要关注的是用户端体验及表现，从而使得用户端体验成为数字化经营中企业产品力和市场竞争力的重要组成部分。
用户端监测常见指标说明
可优化延时：衡量会话受可优化问题的影响的时间量，如果解决了相应的可优化问题，用户就可以在更短的时间内完成会话。使用投影法可以计算会话可优化延时。
体验评分：以百分制计算会话的综合体验评分。体验评分=[(执行通过率/100%)舍尾取整]×(1-可用性)×100×[(1-可优化延时/会话整体耗时×权重A+(1-请求错误率)×权重B+(1-请求警示率)×权重C]，不可用或非100%通过的会话，会话体验评分为0。权重使用主客观综合赋权法确定，权重=0.8×主观权重+(1-0.8)×客观权重，0.8为初始权重参数。
首屏时间：用户访问网站时，页面第一屏的打开展现时间。
可用性：网站打开成功率，是反映网站是否稳定的重要指标。
ANR1：指在Android上，应用程序响应不够灵敏时，系统会向用户显示的一个对话框，通常关注指标有ANR次数、ANR率等。
整体性能：页面全部加载完成的时间，即页面打开的耗时。
崩溃：APP崩溃是导致用户流失的重要因素之一。由于大多数公司在APP上线之前无法做到在各种环境下的全面适配测试，出现崩溃在所难免。快速定位问题点及问题复现是崩溃分析的意义所在，公司常需要关注崩溃次数及崩溃率，通过崩溃堆栈进行问题分析与定位。
白屏时间：即用户点击一个链接或打开浏览器输入URL地址后，从屏幕空白到显示第一个画面的时间。白屏时间的长短将直接影响用户对该网站的第一印象。
首次渲染时间：从开始浏览到实际渲染出第一个像素之间的时间间隔。
卡顿：如果出现出现jank(FPS突降)、帧渲染缓慢、FPS长期过低三者之一，则会出现屏幕卡顿问题，可以通过查看受此问题影响的时间区域的FPS、帧渲染时间，确定具体的卡顿原因。
可交互时间：网页第一次完全达到可交互状态的时间点，可交互的状态下浏览器可以持续性地响应用户的输入。
通过率：以百分率表示在规定的时间内，会话未出现致命问题的情况下的动作执行通过性，通过率=会话预设交互已执行次数/总预设交互次数×100%。
用户端访问过程中的错误情况也需要关注，常见的错误包括JS错误、请求错误率、400错误率、500错误率、600错误率等。
DNS时间：指页面或元素访问过程中DNS解析所用的时间。
劫持比率：浏览过程中发生DNS劫持或页面劫持的总监测次数占总访问次数的比率。
首包时间：从页面浏览开始到接收到第一包数据(通常为基础文档数据)返回之间的时间差。
应用安装耗时：应用在安装过程中消耗的时间。
信息量：页面上显示的信息量，以图像判断所传递的信息量。
响应时间：指客户端发送调度请求之后到接收到调度服务器返回第一包数据之间的时间差。
TCP链接时间：下载该元素过程中建立TCP连接所用的时间。
SSL建连时间：下载元素所需的SSL握手用时。
CDN：构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。是目前常用的网站加速技术。国内CDN厂商众多，企业每年在CDN服务方面投入从千万级到十万级不等，因此CDN服务质量也是各类网站的关注重点，了解其服务质量主要通过CDN请求性能、CDN运营商匹配率、CDN城市匹配率来评估。
三、应用端监测
了解应用访问情况是企业 IT 运维的基础。用户端指标所反映的访问情况只是一个表象，用户端真正所访问到的其实是网站的后台应用，当前企业面临着日益激增的 IT 复杂性和业务需求的快速变化，IT 应用在运行过程中发生性能下降或者服务不可用等故障的可能性大大增加，从而影响业务服务的正常运行。
健康度：应用健康度的标示，展示应用当前是否有性能问题。常分为四个等级：正常、较慢、很慢、停滞。
Apdex：全称是ApplicationPerformanceIndex，是由Apdex联盟开发的用于评估应用性能的工业标准。Apdex标准从用户的角度出发，将对应用响应时间的表现，转为用户对于应用性能的可量化范围为0-1的满意度评价。
响应时间：应用的平均响应时间。错误率：发生错误的请求占比，即所选时间范围内，业务过程错误数量之和／总请求数×100%。
吞吐率：包含自身调用、数据库调用、NoSQL调用、第三方服务调用过程中所传输的数据量。
慢请求次数：发生慢请求的次数，需要进一步定位慢请求所对应的业务、容器、容器集和集群。
慢请求占比：发生慢请求次数占所有请求次数的比例。
此外，企业还需要关注数据库的调用数据库错误率、调用数据库次数及调用数据库响应时间；除了企业的自身调用需要关注外，其外部调用同样也需要，常见指标包括：调用外部服务次数、调用外部服务响应时间、调用外部服务错误率等。
四、网络监测
各个应用之间的调用通过网络来实现，各个企业 IT 建设的规模与复杂度与日俱增，需要通过网络监测对现有运维流程进行优化，不断提升管理和运维水平。
网络监测常见指标说明
流量：传输数据的总量(单位Byte)。
吞吐量：传输数据的速率(单位bps)。
建连成功率：建连成功次数占总请求次数的比率。
客户端传输时延：服务侧丢包时，客户端传输停顿到重传包的平均时间。
丢包率：数据交互过程中丢包数与总包数的比率。
客户数：访问源客户端总个数。
流入包数：流入传输数据总包数。
流出字节：流出数据的字节数。
包大小：数据包大小。
服务器延时：数据包从服务端传送到客户端的平均耗时。
其它常关注指标有：流出吞吐量、重传时延、大包占比、0窗口(TCP报头结构中有16位的窗口大小，由接收方填充用来告知发送方当前本端还能接收的数据长度。如果接收方不断从网络中接收并缓存数据，但是应用程序并没有处理缓存的数据，直到最后接收方就会向发送方发送一个0窗口的报文段)、流入字节、流入吞吐量、中包占比及带宽等。
五、资源层监测
网站所有服务均体现在基础资源层面，因此基础资源监控是所有监控中最底层的部分，也是实现AIOps不可或缺的一环。
资源层监测常用指标
CPU使用率：服务器运行的程序占用的CPU资源，表示服务器在某个时间点的运行程序的情况。
内存使用率：体现进程在服务器中所开销的内存使用率。除此之外还有磁盘使用率及CPU使用率、当前进程打开文件数、过去5分钟系统平均负载、当前内核空间占用CPU百分比、GPU显存空闲量、磁盘每秒写入字节数等。
在微服务环境下，企业使用K8s对容器进行编排管理，对K8s的管理监控也是基础资源监控的一部分。K8s监测通常需要覆盖以下8方面：Cluster(集群)，Node8(节点)，Workspace(企业空间)，Namespace(项目)，Workload(工作负载)，Pod7(容器组)，Container(容器)，Component(KubeSphere核心组件)。其常见监控指标为：集群节点总数、集群中调度完成Pod数。
六、中间件监测
中间件是介于应用系统和系统软件之间的一类软件，位于客户机服务器的操作系统之上，管理计算资源和网络通信，衔接网络上应用系统的各个部分或不同的应用，从而实现资源共享、功能共享的目的。中间件是一类独立的系统软件服务程序，分布式应用软件借助中间件在不同的技术之间共享资源，根据链接的资源和功能的不同，中间件分为消息中间件、交易中间件和服务器中间件等种类。
1、消息中间件
常见指标消息中间件利用高效可靠的消息传递机制进行数据交流，并基于数据通信来实现分布式系统的集成。只要有网络就会有数据传递，消息中间件的应用牵涉到数据传输的安全可靠，在任何网络环境下都具备较强的刚需属性。消息中间件包含老牌的ActiveMQ5、RabbitMQ以及炙手可热的Kafka，RocketMQ等。
消息中间件常见指标包括：消息订阅错误数、消息订阅数量、消息推送平均耗时、消息推送错误数、消息推送数量、消息订阅平拒绝耗时。
2、交易中间件常见指标
交易中间件是协助开发在线交易系统(OLTP)的C/S/S应用框架，其主要功能包括：1、支持大量客户端的链接和高并发交易的处理；2、便捷定制应用服务功能，实现服务器端的业务逻辑；3、对企业各个层次的IT资源均衡使用；4、提供一定程度的交易安全保证。交易中间件在金融、财税、运输、电力、电信等行业中具有广泛应用和推广。
交易中间件通常使用java来开发，所以在运维监测过程中需要关注JVM的使用情况，常见指标包括：
新生代内存的垃圾收集事件称为YoungGC(又称MinorGC)，当JVM无法为新对象分配新生代内存空间时会触发YoungGC，需要关注其产生的平均数量和平均时间。
FullGC：清理整个堆的GC事件，包括新生代、老年代、元空间等，需要关注指标的平均数量及平均时间。
一般情况下，新创建的对象都会被分配到Eden区，为大多数对象分配内存的池，所以需要实时了解Eden区使用率及平均使用情况。在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到老年代。需要关注老年代使用率指标，用于对老年代区域中数据进行整理及分析。
七、数据库监测
数据库是按照数据结构来组织、存储和管理数据的仓库，是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。
数据库监测常用指标说明
查询响应时间：即从提交查询到结果返回所需的时间。
QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
查询错误率：数据库查询过程中出错概率。
健康度：对数据库监控各项指标进行加权统计，并通过专家模型得到健康度打分。
连接数：数据库当前连接数，可以显示包括IP的连接方、连接个数、连接状态及接时长等信息。
链接利用率：数据库链接的可利用占比。
除此之外还需关注数据库请求平均耗时、数据库请求详情、SQL查询耗时排名等指标。
八、小结监控和可观察性对提升系统管理的作用
在不断发展的 DevOps 世界中，深入了解系统行为、诊断问题和提高整体性能的能力是首要任务之一。监控和可观察性是促进这一过程的两个关键概念，为系统的健康和性能提供了宝贵的可见性。虽然这些术语经常可以互换使用，但它们代表着理解和管理复杂系统的不同方法。在本文中，将探讨监视和可观察性之间的差异，提供示例来说明它们的应用，并强调各自的又是。同时还将深入研究用于有效监测和可观测性的技术和工具。
监控：了解系统状态
监控的重点是收集和分析有关系统或应用程序状态的数据。它通常包括设置特定的指标、阈值和警报机制，以跟踪各种组件的性能和可用性。常见的监测技术和工具包括：
指标监控：使用 Nagios、Zabbix、Prometheus 和 Datadog 等工具监控预定义的指标，如 CPU 使用情况、内存消耗、磁盘空间、网络流量和特定于应用程序的指标。
日志监控：使用 ELK Stack（Elasticsearch、Logstash 和 Kibana）、Splunk 或 Graylog 等工具分析系统不同组件生成的日志，以识别错误、安全漏洞或异常行为。
综合监控：使用 Selenium、Pingdom 或 New Relic Synthetics 等工具模拟用户交互并监控系统响应，以确保可用性和性能。
可观察性：理解系统行为
可观察性采用更全面的方法，通过分析相互关联的组件及其关系来理解和解释复杂系统的行为。它强调回答问题和调查超出预定义度量的系统行为的能力。其使用的技术和工具包括:
分布式跟踪：使用 Jaeger、Zipkin 或 AWS X-Ray 等工具捕获和分析通过分布式系统的请求流。它支持识别瓶颈、延迟问题和依赖关系。
应用程序日志记录：使用 Fluentd、Logback 或 Log4j 等工具收集具有上下文信息的结构化日志，以跟踪执行路径、解决问题并全面了解系统行为。
实时分析：利用流数据平台 (如 Apache Kafka 或 Apache Flink) 和可视化工具 (如 Grafana 或 Kibana) 来处理和分析大容量、实时数据流，以获得系统性能洞察。
监控和可观察性用例
以下是监控和可观察性在 DevOps 中发挥重要作用的几个常见用例：
应用程序性能监控 (APM)
监控：跟踪响应时间、错误率和资源利用率等指标，以确保最佳性能。例如，设置 CPU 使用率高或响应时间慢的警报。
可观察性：分析分布式跟踪和日志，以识别性能瓶颈，了解依赖关系，并排除问题。例如，使用分布式跟踪来查明跨微服务的延迟问题。
基础设施监控
监控：跟踪服务器指标（CPU、内存、磁盘空间）和网络指标（带宽、延迟），以确保基础设施运行状况。例如，监视磁盘空间以避免由于磁盘已满而导致的潜在停机。
可观察性：分析日志和事件，以识别异常行为或安全威胁。例如，使用日志分析来检测未经授权的访问尝试或系统日志中的异常模式。
云资源监控
监控：跟踪云服务（如 AWS CloudWatch、Azure Monitor）的资源利用率和性能指标，以优化成本并确保服务可用性。例如，监视自动扩展组中已配置实例的数量。
可观察性：分析云提供商日志、跟踪和指标，以深入了解云资源的行为并诊断问题。例如，使用可观察性工具来识别无服务器架构中的性能瓶颈。
持续集成/持续部署（CI/CD）管道
监控：跟踪构建和部署指标（例如，构建持续时间、成功 / 失败率），以确保 CI/CD 管道的效率和可靠性。例如，监视生成队列长度以防止出现瓶颈。
可观察性：分析来自 CI/CD 工具 (例如 Jenkins, CircleCI) 的日志和事件，以排除构建或部署失败的故障。例如，使用可观察性来调查部署失败的原因。
网络监控
监控：跟踪网络流量、延迟和数据包丢失，以确保网络性能并识别潜在问题。例如，监控网络带宽利用率以防止拥塞。
可观察性：分析网络日志、数据包捕获和流数据，以诊断网络问题、检测安全漏洞或识别异常行为。例如，使用可观察性工具来调查网络错误的突然增加。
这些只是监控和可观察性如何应用于各种 DevOps 用例的几个例子。具体的用例和需求可能因系统、基础设施和团队需求的性质而异。
小结
监控通过捕获预定义的指标和基于阈值的警报来提供系统运行状况和性能的快照。它可用于检测特定问题或事件，并提供有关系统或应用程序状态的即时反馈。可观察性提供了对复杂系统更全面的了解，支持主动故障排除和根本原因分析。它侧重于获取上下文信息，揭示预定义指标之外的见解，培养持续改进的文化。实现可观察性通常需要额外的工具和架构考虑，这可能会增加复杂性和资源需求。然而，深度系统理解的好处以及解决未知或未预料到的问题的能力使其值得投资。
监控和可观察性都是现代 DevOps 实践的重要组成部分，但它们涉及系统可见性的不同方面。监控提供了系统运行状况的集中和即时视图，跟踪预定义的度量和阈值，而可观察性提供了对系统行为的整体理解，捕获上下文信息并支持深入分析。通过结合监控和可观察性技术并利用适当的工具，团队可以获得对系统性能的全面了解，及早发现问题，并不断优化其系统。在监视预定义的度量和通过可观察性探索不可预见的场景之间保持平衡，使团队能够在 DevOps 的动态世界中有效地管理和改进其软件系统的可靠性、性能和恢复能力。