简单聊聊运维监控的其他用途 - charlieroro

简单聊聊运维监控的其他用途

说到监控，一般都会聊到这三个基本维度：metrics、log和tracing，以及这几种常用的工具：Prometheus+grafana+alertmanager、ELK、jaeger。

监控通常来展示应用或集群的运行状态，配合告警来达到维护系统稳定性的目的。但除此之外，还可以将监控数据用于其他用途。

下面以metrics为例，聊聊除了监控和告警外，还可以用于实现哪些功能。

扩缩容采用的其实也是监控方式。它会实时获取服务的相关指标，以此来达到扩容实例和缩容实例的目的。

最常见的方式是使用kubernetes提供的HPA资源来实现基于CPU利用率的扩缩容，也可以使用自定义指标，如基于QPS，来实现扩缩容。

开源产品可以参见：prometheus-adapter和KEDA。

相对高级的方式是集合机器学习来实现HPA，相比上述方式的好处是，结合机器学习可以提前预知可能存在的资源波峰，提前进行HPA，避免被动HPA带来的延迟影响。可以参考腾讯的Crane实现。

这也是一种比较高级的用法。

在实际场景中，大部分业务开发并不清楚自己的服务到底需要多少(CPU、内存等)资源，因此通常的做法是在允许的范围内尽可能多申请资源，但这样做会导致大量资源浪费。

典型的场景，如可能会给某个用于同步配置文件的服务申请4C8G这样的资源配置，但该服务实际使用的CPU可能仅为0.1Core，而内存可能仅为几十M。

这种配置处理方式除了会造成资源上的浪费外，还给运维带来了一定的复杂度。例如，很多公司的开发环境都会分为生产和非生产。非生产环境一般资源都比较有限(虽然开发规范要求生产和非生产要保证一致，但出于成本等因素很难实现统一)，因此经常会出现某些新的应用因为集群资源不足而无法发布的问题，此时运维人员不得不与其他业务开发者沟通来释放出一部分资源，但实际情况是，环境中的很多应用资源利用率极低，但又不能轻易修改其资源配置。

因此比较理想的做法是使用机器学习，根据历史资源使用率来为应用提供合理的资源配置。这种方式有一定的挑战性，因为应用的资源并不是一成不变的，其资源使用率会因白天/晚上、工作日/休息天、大促、甚至系统重启加载等因素而异，因此不能仅仅根据平均值来设置资源配置。可以参考uber的最佳实践.

提供业务数据

SLI、SLO和SLA

使用指标来保证SLA也是一种常见的方式。比如某个云厂商保证的VM的SLA为x%，那么我们可以通过node-exporter提供的节点指标来统计节点的在线率等信息，进而检查LB是否达到了SLA是的要求。当然也可以将SLA用于内部团队，用来评估团队提供的服务是否足够稳定。

提供运营数据

在工作中，有些场景可能会需要知道，如online环境有多少应用？配置了大规格CPU或内存的应用有哪些？某个应用的POD的应用ID是啥？

遇到这类问题，通常想法就是登录对应的环境，然后查看相应的配置。但很多时候会遇到环境授权的问题，大部分只要审批通过即可。但偶尔也会遇到到因为相关审批人请假等原因导致问题定位受阻的情况。这时候应该想到利用监控数据。以metrics为例，这类监控数据涵盖的信息相当广泛，可以包含Iaas层数据(如虚拟机，kafka、redis等组件信息，网关信息)和Paas层数据(容器数据、kubernetes组件信息)和Saas层数据(应用自定义指标)等，由于metrics不会像Log这样可能会因为包含隐私数据而被隔离，且由于实际监控告警可能会结合来自不同采集源的metrics，因此一般不会也很难对metrics进行隔离。因此metrics中其实包含了大量有用的信息。

除了解决某些情况下获取相关数据的问题，只要有足够的标签，metrics还可以提供更多层次的信息，可以给战略决策以及工作质量评价等方面提供更高维度的信息。

针对业务部门，除了通过服务重启、异常请求等指标反应服务的运行状态之外，还可以通过如下指标绘制的曲线，从一定时间维度上了解本部门的服务现状，由此可以摒弃其他因素来直接评价服务开发质量(如加班时长与服务质量并无直接关联)。

• 服务发布次数：从该指标可以判断某个服务是处于快速迭代开发阶段，还是处于稳定维护阶段
• 服务的重启次数和异常比率：可以将这些指标用在开发环境和生产环境中，从特定角度判断服务的运行状况(一般http服务不会返回非200的状态码，如果处理错误，可将自定义错误码放到body中)。

目前应该没有公司高层会通过这种方式了解公司的现状，但我认为这不失为一种精确了解公司现状的方式。

大多数公司高层了解到的关于公司现状的信息基本都是通过层层上报获得的，但层层上报很难避免信息注水以及部门偏袒等因素。可以通过metrics的相关指标的曲线图来直接反应公司运营现状，如：

• 部门所有服务的发布次数曲线：以此可以判断部门服务的迭代开发情况，甚至以此可以判断各部门的加班情况
• 部门服务的总异常比率：由此可以判断部门服务的开发质量
• 从网关上访问的TopN(以及倒数TopN)的Qps服务：由此可以判定当前最有价值以及最小价值的服务或部门
• 服务存在和消亡指标：结合服务发布指标，可以近似判定公司是不是存在无效扩招。如历史服务相关指标并未增加，但却扩招了大量人员。

上面仅给出了部分可能有用的场景(毕竟本人也不是高层。)，但metrics指标所包含的信息互不影响，又相互关联，彼此之间有着千丝万缕的关系。通过梳理相关的信息，甚至可以得出惊人的数据，例如整个公司最近半年甚至一年的发展现状，这些信息甚至直接反应了公司的运营情况。

上面介绍了metrics指标在监控告警之外的一些用途场景，特别是最后一点，这也是我在使用metrics的过程中越来越深刻体会到的一点。

基于上面的介绍，我总结了几点应该做的事：

• 业务的相关指标最好有部门维度、项目维度以及应用维度的标签
• 最好对指标进行租户隔离，避免信息泄露。单个或少量指标基本是没有隐患的，但大量指标可能会汇总出重要信息
• 可以为部门或高层提供一个能够访问相应权限的指标的方式，