[转帖]简单聊聊运维监控的其他用途

简单,聊聊,监控,其他,用途 · 浏览次数 : 0

小编点评

**metrics指标的多种应用场景** **1. 监控告警** **2. 部署状态监控** **3. 扩容容纳监控** **4. 业务数据分析** **5. 战略决策** **6. 工作质量评估** **扩缩容监控** * HPA 资源监控 * 基于 CPU 利用率的扩缩容 * 基于 QPS 的扩缩容 **业务数据分析** * 服务发布次数 * 服务状态曲线 * 容器数据监控 **战略决策** * 公司服务状态分析 * 扩缩容预警 **工作质量评估** * 监控告警 * 服务发布次数 * 异常比率

正文

https://www.cnblogs.com/charlieroro/p/16434344.html

 

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

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

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

扩缩容

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

一般方式

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

开源产品可以参见:prometheus-adapterKEDA

高级方式

相对高级的方式是集合机器学习来实现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的过程中越来越深刻体会到的一点。

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

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

本文来自博客园,作者:charlieroro,转载请注明原文链接:https://www.cnblogs.com/charlieroro/p/16434344.html

与[转帖]简单聊聊运维监控的其他用途相似的内容:

[转帖]简单聊聊运维监控的其他用途

https://www.cnblogs.com/charlieroro/p/16434344.html 说到监控,一般都会聊到这三个基本维度:metrics、log和tracing,以及这几种常用的工具:Prometheus+grafana+alertmanager、ELK、jaeger。 监控通常

[转帖]带你重走 TiDB TPS 提升 1000 倍的性能优化之旅

https://tidb.net/blog/29074d86#TiDB%20%E6%80%A7%E8%83%BD%E5%92%8C%E7%A8%B3%E5%AE%9A%E6%80%A7%E7%9A%84%E6%8C%91%E6%88%98 今天我们来聊一下数据库的性能优化,第一部分简单介绍一下性能优

[转帖]简单介绍四种IO模型

https://cdn.modb.pro/db/525350 当一个网络IO发生(假设是read)时,它会涉及两个系统对象,一个是调用这个IO的进程,另一个是系统内核。当一个read操作发生时,它会经历两个阶段:①等待数据准备;②将数据从内核拷贝到进程中。为了解决网络IO中的问题,提出了4中网络IO

[转帖]简单理解Linux的Memory Overcommit

https://zhuanlan.zhihu.com/p/551677956 Memory Overcommit的意思是操作系统承诺给进程的内存大小超过了实际可用的内存。一个保守的操作系统不会允许memory overcommit,有多少就分配多少,再申请就没有了,这其实有些浪费内存,因为进程实际使

[转帖]IPMItool 简单介绍

IPMItool是一个用于管理和配置,支持智能平台管理接口(IPMI)1.5版和2.0版规范的设备的实用程序。 IPMI是一个开放的标准,监控,记录,回收,库存和硬件实现独立于主CPU,BIOS,以及操作系统的控制权。 服务处理器(或底板管理控制器,BMC)的背后是平台管理的大脑,其主要目的是处理自

[转帖]一个简单的内核参数优化

一个简单的内核参数优化 作者:孤风孤影 https://www.bilibili.com/read/cv15200947/ 出处:bilibili net.ipv4.tcp_keepalive_time=600 #此参数表示TCP发送keepalive探测消息的间隔时间(秒) net.ipv4.tc

[转帖]Ceph简单搭建

https://cloud.tencent.com/developer/article/1643322 Ceph基础介绍 ​ Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统,根据场景划分可以将Ceph分为三大块,分别是对象存储、块设备存储和文件系统服务。在虚拟化领域里,比较常用到的是Ce

[转帖]arcconf工具简单学习

https://blog.yelvlab.cn/archives/622/ 最近用到了一个MICROCHIP公司的阵列卡Microsemi Adaptec SmartRAID 3152-8i,但是常用的Raid Manager工具megacli,并不兼容这张卡,无法进行管理和监控,所以研究一下能管理

【转帖】PyCharm---Django简单例子--基础1

https://www.cnblogs.com/kllay/p/7286701.html 环境: python 2.7 Django 1.11.2 查看版本:python -m django --version 1.新建Django项目 django-admin startproject TestH

[转帖]企业nginx简单配置

https://www.jianshu.com/p/6a3e298b31be 第五章 企业简单应用 网站访问方式 1.基于域名访问www.baidu.com 基于IP地址访问172.16.1.7配置文件地址被改动一定要重启服务 基于端口访问10.0.0.51:80 修改扩展配置文件端口信息后访问时优