监控 Pod 时,我们在监控什么

标签: 监控 pod 监控 | 发表时间:2020-04-22 23:38 | 作者:老马
出处:http://weekly.dockone.io

应用 Kubernetes 化已经开始推进了一段时间,监控系统也提供了 Kubernetes Pod 相关的监控指标和警报规则。

由于 Kubernetes 和传统的物理机/虚拟机是完全不同的运行环境,因此监控系统提供的监控指标也存在一定的区别。虽然我们已经尽量统一不同平台的差异,但是日常工作中仍会收到用户对 Kubernetes 监控指标的反馈。

本文旨在从 CPU/内存/磁盘/网络四个角度阐述物理机/虚拟机(后续统一为 KVM)与 Kubernetes 的区别,帮助大家在使用监控产品时也能理解背后的原理。本文会一定程度上深入技术细节,但是也提供了监控产品使用指导,希望大家理解。

需要提前说明的是,监控平台所有的数据都是采集自 Kubernetes 原生暴露的指标,因此难免受限于 Kubernetes 原生接口的特点。

总体而言,Kubernetes 和 KVM 的区别在不同组件存在区别:
  • CPU 区别最大,这是 Kubernetes 技术本质决定的
  • 内存有一定区别,但是基本可以和 KVM 技术栈统一
  • 网络、磁盘区别不大,基本没有额外的理解成本


CPU

长话短说,在 KVM 场景下,用户需要关注的指标是 CPU 使用率 和 CPU load:
  • CPU load 高,CPU 使用率低,一般表明性能瓶颈出现在磁盘 I/O 上
  • CPU 使用率高,CPU load 远高于 CPU 核数,表示当前 CPU 资源严重不足


在 Kubernetes 场景下,用户需要关注的指标是 CPU 使用率和 CPU 限流时间:
  • CPU 使用率高(接近甚至稍微超过 100%),CPU 限流时间大,表示当前 CPU 资源严重不足,需要增加 request 或者 limit


出现这种差异的原因:
  • Kubernetes 和 KVM 在 CPU 资源隔离机制上存在差别
  • Linux 指标暴露 和 Kubernetes 指标暴露存在差别


监控提供了两个监控项,以及对应的指标项:

下图展示了一个被限流的应用,可以看到 CPU 使用率显示超过了 100%。

CPU 使用率

对于一个独立的 CPU core,它的时间被分成了三份:
  • 执行用户代码时间
  • 执行内核代码时间
  • 空闲时间(对于 x86 体系而言,此时会执行 HLT 指令)


因此 KVM 环境下计算 CPU 使用率很直接:(执行用户代码时间 + 执行内核代码时间)/ 总时间。

因为对于 Kubernetes Pod 而言,它不再享有独立的 CPU core,因此这个公式不再成立。在 Kubernetes 语境下,CPU 的资源总量/使用量是通过时间表示的:
  • 配置一个 CPU limit 为 4 的 POD,含义是 一秒钟内可以使用 4s 的 CPU 资源,这个当然需要多核/多线程的支持
  • 一个 POD 每秒使用 0.5s 的 CPU 资源,可以理解为这个 POD 使用了一个 CPU core 的 50%


原生的 Kubernetes 并不关注”使用率“这个概念,但是为了降低用户的迁移成本,监控通过 使用量 / Limit 来衡量 POD 的 CPU 使用率。

由于 Kubernetes 对 CPU Limit 的实现粒度有限,同时考虑到统计的误差,因此在压测等极限场景中 CPU 使用率会出现高于 100% 的”毛刺“。

CPU Load

CPU load 用于衡量当前系统的负载情况, Linux 系统使用当前处于可运行状态的线程数来标识,包括:
  • 处于 running 状态的线程,这个是最正常的情况,获得 CPU 分片,执行用户态或者内核态代码的线程
  • 出入 uninterruptible sleep 状态的线程,这个是特殊的情况,表明这个线程在进行 I/O 操作


因此,当 CPU 使用率很低,但 load 很高时, 我们可以推断大量线程处于 I/O 操作状态,系统的性能瓶颈出现在磁盘或者网络 I/O。

Kubernetes 虽然也提供了 cpu_load 指标, 却只包含了处于 running 状态的线程,这个指标也失去了判断系统性能瓶颈是否出现在 I/O 的作用。

另一方面,虽然不知道具体原因, Kubernetes 默认关闭 CPU load 指标,我们决定尊重这一决定。

同时,由于 CPU 使用方式的不同,Kubernetes 提供了“CPU 限制时间”指标,通过这个指标覆盖了 “CPU 使用率和 load 都很高,CPU 资源严重不足” 的情况。

具体来说,Kubernetes 通过 Completely Fair Scheduler (CFS) Cgroup bandwidth control 限制 Pod 的 CPU 使用:
  • 首先,我们将 1s 分成多个 period,每个 period 持续时间为 0.1s
  • 在每个 peroid 中,Pod 需要向 CFS 申请时间片,CFS 通过 Limit 参数判断这个申请是否达到这个 Pod 的资源限制
  • 如果达到了 Pod 的资源限制,”限流时间“ 指标会记录限流的时间


因此,当一个 Pod 的”限流时间“非常高时,意味着这个 Pod CPU 资源严重不足,需要增加更多的资源了。

内存

KVM 和 Kubernetes 都通过 内存使用率 这个指标衡量内存使用情况,但是 "哪些内存是使用内存" 两者有一定区别:
  • 在KVM场景中,内存的具体使用量并没有一个非常清晰的标准,cache/buffer/slab 内存对于应用性能的影响和应用本身的特点有关,没有统一的计算方案,综合各种因素,监控使用 total - available 作为内存使用
  • Kubernetes 没有提供 available 指标,我们主要使用 RSS 内存作为已用内存


监控针对内存提供的的监控项/指标项比较多:

目前报警/主机详情页/应用诊断报告都使用 RSS 内存使用占比作为内存使用衡量指标。

Linux free 命令一般包含这几列:
  • used:系统使用的内存,包括进程分配使用的内存,也包括系统为了优化性能而针对磁盘缓存分配的部分(即 cache/buffer)
  • cache/buffer:上述的缓存
  • available:估算的系统可用内存,考虑的 cache/buffer 以及不可回收的 slab 等


我们不能简单地将实际使用内存等价位used - cache/buffer,对于不同的应用,cache/buffer内存很可能是影响性能的重要部分(特别是依赖大量磁盘写操作的应用,如 Kafka、ElasticSearch 等)。

监控系统当前使用 total - available 作为已用内存,并基于此计算内存使用率。

Kubernetes 对于内存使用暴露了不同的值:
  • MemUsed:和 Linux 的 used 一样,包含了 cache 值
  • WorkingSet:比 memUsed 小一些,移除了一些“冷数据”,即长期没有访问的 cache 内存
  • RSS:移除了 cache 的内存


一般情况下,我们认为 WorkingSet 是比较合理的内存使用量指标,但是实践中发现,WorkingSet的值一般比较高,常规应用内存使用率基本在 90%,和 KVM 下相同应用差别较大。

考虑到常规 Web 应用一般不依赖磁盘 I/O,cache 内存基本用于日志系统,对系统性能影响不大,因此最终在监控系统中选择使用 RSS 衡量内存使用。 但是,我们依然建议当用户发现系统出现性能瓶颈时,使用不同的内存指标辅助判断,更好地理解当前系统的状态。

磁盘/网络

基于 LInux Cgroup 隔离机制,磁盘/网络相关指标 Kubernetes 和 KVM 区别不大。唯一需要注意的是, Web 应用一般只关注磁盘用量,但是 Kubernetes 环境默认是无盘系统(除非使用持久卷),因此并没有分配磁盘空间这一概念,用户也不需要再关心磁盘可用空间。

对于磁盘,我们主要关心磁盘写入性能相关指标:

对于网络,和KVM场景类似,主要关注流量、丢包率等指标:

作者:逸恒,酷家乐监控组成员,关注云原生时代监控系统的发展与挑战。

原文链接: https://tech.kujiale.com/jian- ... -yao/

相关 [监控 pod 监控] 推荐:

监控 Pod 时,我们在监控什么

- - DockOne.io
应用 Kubernetes 化已经开始推进了一段时间,监控系统也提供了 Kubernetes Pod 相关的监控指标和警报规则. 由于 Kubernetes 和传统的物理机/虚拟机是完全不同的运行环境,因此监控系统提供的监控指标也存在一定的区别. 虽然我们已经尽量统一不同平台的差异,但是日常工作中仍会收到用户对 Kubernetes 监控指标的反馈.

ZooKeeper监控

- - 淘宝网通用产品团队博客
        在公司内部,有不少应用已经强依赖zookeeper,比如meta和精卫系统,zookeeper的工作状态直接影响它们的正常工作. 目前开源世界中暂没有一个比较成熟的zk-monitor,公司内部的各个zookeeper运行也都是无监控,无报表状态. 目前zookeeper-monitor能做哪些事情,讲到这个,首先来看看哪些因素对zookeeper正常工作比较大的影响:.

性能监控

- - 互联网 - ITeye博客
一旦你的服务器是在控制台模式下运行,你就可以开始我们接下来的内容. iostat  iostat 命令用来显示存储子系统的详细信息,通常用它来监控磁盘 I/O 的情况. 要特别注意 iostat 统计结果中的 %iowait 值,太大了表明你的系统存储子系统性能低下. meminfo 和 free  Meminfo 可让你获取内存的详细信息,你可以使用 cat 和 grep 命令来显示 meminfo 信息: 1 cat /proc/meminfo  另外你可以使用 free 命令来显示动态的内存使用信息,free 只是给你大概的内存信息,而 meminfo 提供的信息更加详细.

DB2监控

- - CSDN博客数据库推荐文章
     收集的一些DB2监控方法.. -- 是到数据库快照,并存入文件.  -- 查找并重新绑定无效包 .  -- 查出 myuser 模式下的所有无效包.  -- 利用查出的 pkgname ,使用 Rebind 重新绑定. -- 查看所有用户定义(tabschema not like 'SYS%' )表的状态.

nagios 监控redis

- - C1G军火库
下载check_redis.pl. OK: REDIS 2.6.12 on 192.168.0.130:6379 has 1 databases (db0) with 49801 keys, up 3 days 14 hours - connected_clients is 1, blocked_clients is 0 | connected_clients=1 blocked_clients=0.

监控进程

- - 火丁笔记
有时候,进程突然终止服务,可能是没有资源了,也可能是意外,比如说:因为 OOM 被杀;或者由于 BUG 导致崩溃;亦或者误操作等等,此时,我们需要重新启动进程. 实际上,Linux 本身的初始化系统能实现简单的功能,无论是老牌的 SysVinit,还是新潮的  Upstart 或者  Systemd 均可,但它们并不适合处理一些复杂的情况,比如说:CPU 占用超过多少就重启;或者同时管理 100 个 PHP 实现的 Worker 进程等等,如果你有类似的需求,那么可以考虑试试 Monit 和 Supervisor,相信会有不一样的感受.

业务监控

- - 人月神话的BLOG
前面写了一些文章,包括移动BI,企业信息可视化,微信企业号,基于SNS移动应用协同等,这些都是个人认为企业后续信息化可能存在的机会点或发展趋势. 其中核心词汇将仍然集中在移动化,SNS化,可视化,无边界这些核心词汇和能力实现上. 当前我们看到不论是网管系统还是IT应用监控平台,其核心重点仍然围绕在IT基础设施和资源,数据库和应用中间件的监控和实时预警上,其更多面对的是IT运维和管控人员,而非业务人员.

SpringBoot-Metrics监控

- -
Metrics基本上是成熟公司里面必须做的一件事情,简单点来说就是对应用的监控,之前在一些技术不成熟的公司其实是不了解这种概念,因为业务跟技术是相关的. 当业务庞大起来,技术也会相对复杂起来,对这些复杂的系统进行监控就存在必要性了,特别是在soa化的系统中,完整一个软件的功能分布在各个系统中,针对这些功能进行监控就更必要了.

Linux系统监控

- - CSDN博客系统运维推荐文章
查看所有的进程和端口使用情况:. 查看nginx并发(连接数)进程数:. 查看当网络连接状态中,已建立连接的数量:. 查看系统tcp连接中各个状态的连接数. 输出每个ip的连接数,以及总的各个状态的连接数. df -hl 查看磁盘使用情况 . df -hl 查看磁盘剩余空间. df -h 查看每个根路径的分区大小.

Redis监控技巧

- - NoSQLFan
本文来自 Bugsnag的联合创始人 Simon Maynard的系列文章,作者根据几年来对 Redis的使用经历,对Redis 监控方法进行了系统性的总结,干货很多,值得一看. 原文链接: Redis Masterclass – Part 2, Monitoring. Redis 监控最直接的方法当然就是使用系统提供的 info 命令来做了,你只需要执行下面一条命令,就能获得 Redis 系统的状态报告.