本文是《性能之巅》Systems Performance第 2 版第 4 章的导读。本书是系统性能领域的经典本系列逐章导读把书的核心概念讲清楚。城市监控系统上一章画好了城市地图——我们知道内核是市政府、进程是市民、文件系统是图书馆、I/O 栈是物流系统。但地图是静态的。城市每时每刻都在运转——工厂在开工、快递在派送、图书馆在借还书。你怎么知道现在发生了什么你需要一套城市监控系统。监控系统不是一种工具而是一整套体系有装在工厂门口的计数器数进出人数有定时巡逻的保安定期看一眼有全程跟拍的摄像头记录每个事件还有后台的报表系统把数据汇总成图表。这一章讲的就是这套监控系统有哪些类型的监控、数据从哪里来、以及一个最基础也最容易被忽略的报表工具——sar。一、监控系统有哪些类型监控系统按怎么看来分有四种类型。类型一计数器——预埋的传感器城市里到处都装着传感器工厂门口有人流计数器仓库门口有货物计数器快递网点有包裹计数器。这些传感器一直在工作一直在计数不需要你额外做什么。你只需要读取它们。技术上的计数器就是内核里预先埋好的整数变量# 看系统调用了多少次cat/proc/stat# 看网络收了多少包cat/proc/net/dev# 看磁盘 I/O 统计cat/proc/diskstats计数器的特点开销几乎为零——内核一直在维护读的时候只是读一个数字永远在运行——不需要你启用或配置只能看预设的——内核埋了什么你才能看什么计数器是最基础的监控。任何监控系统、任何性能工具底层都依赖计数器。类型二剖析——抽样调查计数器告诉你发生了多少次但不告诉你时间花在哪了。剖析Profiling就像抽样调查——不追查每一个市民而是定时随机抽查看他们正在干什么。# 每 99 毫秒采样一次看 CPU 在执行哪个函数perf record-F99-a-g--sleep30剖析的原理时间轴 │ │ │ │ │ │ ↓ ↓ ↓ ↓ ↓ ↓ 采样 采样 采样 采样 采样 采样 │ │ │ │ │ │ 函数A 函数A 函数B 函数A 函数C 函数A从采样结果推断函数 A 出现了 3 次函数 B 出现 1 次函数 C 出现 1 次——函数 A 最耗 CPU。剖析的特点开销可控——采样率可以调99 Hz 通常开销很小能看到为什么——不只是数字而是具体的函数和调用栈不精确——是抽样可能漏掉短时间的事件剖析是 CPU 分析的主力。火焰图就是剖析结果的可视化。类型三追踪——全程跟拍剖析是抽样追踪Tracing是全程跟拍——每一个事件都记录不漏掉任何一个。# 追踪每一个系统调用strace-p1234# 追踪每一个磁盘 I/Obiosnoop# 追踪每一个网络连接tcplife追踪的特点完整——不漏任何事件能看到完整因果开销大——事件多的时候会拖慢系统适合低频事件——比如磁盘 I/O每秒几千次不适合 CPU 指令每秒几十亿次追踪分两种静态追踪内核预先埋好的追踪点tracepoint动态追踪运行时插入的追踪点kprobe、uprobe动态追踪是手电筒——你想照哪里就照哪里。这是 Linux 性能分析最强大的能力。类型四监控——长期报表监控Monitoring是长期记录指标看趋势和异常。# sar 定期记录系统统计sar-u110# 监控系统如 Prometheus、Grafana长期记录监控的特点长期——记录几天、几个月甚至几年的数据趋势——看指标是上升还是下降告警——指标异常时通知你监控和前面三种的关系计数器、剖析、追踪是手段监控是目的——把手段收集的数据长期保存用于趋势分析和告警监控的关键是选对指标不要只监控平均值要监控 P99不要只监控资源要监控用户体验不要只监控当前值要监控变化率二、监控数据从哪来监控系统需要数据。数据从哪里来有五个主要来源。来源一/proc——内核的公告板/proc 是内核的公告板——内核把各种统计信息写在这里谁都可以看。# 看系统整体统计cat/proc/stat# 看内存信息cat/proc/meminfo# 看进程信息cat/proc/PID/status# 看磁盘统计cat/proc/diskstats# 看网络统计cat/proc/net/dev/proc 的特点文本格式——可以直接cat也可以用脚本处理动态生成——读的时候内核才生成内容不占磁盘覆盖全面——CPU、内存、磁盘、网络、进程应有尽有/proc 的缺点格式不统一——每个文件格式不一样解析麻烦有开销——文本编码和解析都有成本不够实时——有些统计是累计值需要自己算差值来源二/sys——设备的公告板/sys 是设备的公告板——主要展示设备、驱动、内核子系统的信息。# 看 CPU 缓存大小cat/sys/devices/system/cpu/cpu0/cache/index0/size# 看内核参数cat/sys/kernel/mm/transparent_hugepage/enabled# 看块设备队列cat/sys/block/sda/queue/scheduler/sys 的特点结构化——按设备、子系统组织比 /proc 更有条理可写——很多文件可以写入用于调优设备相关——主要展示硬件和驱动信息来源三Tracepoint——预埋的摄像头Tracepoint 是内核开发者预埋的摄像头——在内核代码的关键位置已经放好了追踪点。# 列出所有 tracepointperf list# 追踪块设备 I/O 事件perf trace-eblock:block_rq_issue# 追踪调度事件perf trace-esched:sched_switchTracepoint 的特点稳定——接口固定不会随内核版本变化低开销——没启用时是空操作有格式——每个 tracepoint 都有明确的参数定义常见的 tracepoint 类别类别内容sched:调度事件block:块设备 I/Osyscalls:系统调用net:网络事件ext4:ext4 文件系统kvm:KVM 虚拟化来源四kprobe/uprobe——临时摄像头kprobe 和 uprobe 是临时安装的摄像头——你想在哪装就在哪装。# 在内核函数上装摄像头bpftrace-ekprobe:vfs_read { [comm] count(); }# 在用户函数上装摄像头bpftrace-euprobe:/bin/bash:readline { [comm] count(); }kprobe 的特点灵活——任意内核函数都能追踪不稳定——函数名可能随内核版本变化需要知道函数名——得先查源码或符号表uprobe 的特点灵活——任意用户函数都能追踪需要知道偏移——得先解析二进制kprobe/uprobe 是最后的手段——当 tracepoint 不够用时用它们深入代码。来源五PMC——CPU 的仪表盘PMC性能监控计数器是 CPU 的仪表盘——它们能告诉你 CPU 内部发生了什么。# 看 IPC每周期指令数perfstat-ecycles,instructions-asleep5# 看缓存命中率perfstat-ecache-references,cache-misses-asleep5PMC 的特点硬件级——直接读取 CPU 内部的计数器需要处理器支持——不是所有 CPU 都有云上可能不可用——很多云厂商禁用 PMCPMC 能回答的问题CPU 效率高不高IPC缓存命中率怎么样内存带宽够不够分支预测失败多不多五个来源的关系观测数据来源/proc系统级计数器/sys设备级计数器Tracepoint静态事件kprobe/uprobe动态事件PMC硬件计数器计数器追踪计数器/proc、/sys、PMC看发生了多少次追踪Tracepoint、kprobe/uprobe看具体发生了什么三、一个被低估的工具sar监控数据来源有了但怎么用有一个工具几乎被所有人低估但它能解决很多问题。它就是sarSystem Activity Reporter。sar 是什么sar 是城市的综合报表系统——它定期收集系统统计保存下来随时可以回看。# 看今天的 CPU 统计sar-u# 看今天的磁盘统计sar-d# 看今天的网络统计sar-nDEVsar 的特点历史数据——它有一个后台守护进程定期默认每 10 分钟记录系统统计覆盖全面——CPU、内存、磁盘、网络、中断什么都有命令行友好——文本输出容易解析为什么 sar 被低估因为它太低调了。它不像top那样实时刷新看起来很静态它不像perf那样能生成火焰图看起来很朴素它不像bpftrace那样能写自定义脚本看起来很古老但 sar 有一个别人没有的能力看历史。当你遇到性能问题时你经常需要回答这个问题是什么时候开始的昨天这个时候系统是什么状态上周的峰值是多少top、perf、bpftrace都只能看现在。只有sar能看过去。sar 怎么用启用 sar# Ubuntu/Debianvim/etc/default/sysstat# 把 ENABLEDfalse 改成 ENABLEDtrue# 重启服务servicesysstat restart看历史数据# 看今天的 CPU 统计sar-u# 看指定日期的 CPU 统计sar-u-f/var/log/sysstat/sa15# 看指定时间范围sar-u-s10:00:00-e12:00:00看当前数据# 每秒一次看 CPUsar-u1# 每秒一次看磁盘sar-d1# 每秒一次看网络sar-nDEV1sar 的常用选项选项内容-uCPU 统计-r内存统计-d磁盘统计-n DEV网络接口-n TCPTCP 统计-n ETCPTCP 错误-q负载和队列-B换页统计-W交换统计sar 的输出格式$ sar-u13Linux5.3.0-1010-aws(ip-10-1-239-218)02/27/20 _x86_64_(2CPU)07:32:45 CPU %user %nice %system %iowait %steal %idle 07:32:46 all32.160.0061.810.000.006.0307:32:47 all33.830.0061.190.000.004.9807:32:48 all31.500.0060.500.000.008.00Average: all32.500.0061.170.000.006.33sar 的输出可以导出# JSON 格式sadf-j---u# CSV 格式sadf-d---u# SVG 图表sadf-g---ucpu.svgSVG 格式特别有用——可以直接在浏览器里看图表。sar 的实战价值场景一问题是什么时候开始的用户说系统从昨天开始变慢。你sar -u -f /var/log/sysstat/sa14一看昨天下午 3 点 CPU 利用率突然从 30% 升到 80%。再查一下3 点有个定时任务在跑。场景二昨天这个时候正常吗今天系统卡你sar -u一看CPU 90%。但你不知道是不是正常的。sar -u -f /var/log/sysstat/sa15看一下昨天同一时间——也是 90%。原来是正常的。场景三峰值是多少要做容量规划需要知道历史峰值。sar -u -f /var/log/sysstat/sa*全部看一遍找出最高值。sar 是性能分析的考古学家——它让你能看到过去发生了什么。四、怎么选监控工具监控工具这么多怎么选按场景选场景推荐工具快速看当前状态top、vmstat、iostat看历史趋势sarCPU 剖析perf record、profile磁盘 I/O 追踪biosnoop、biolatency网络连接追踪tcplife、tcpretrans系统调用追踪strace、perf trace自定义追踪bpftrace长期监控Prometheus、Grafana按问题类型选是否是否是否系统慢是 CPU 问题perf record火焰图是磁盘问题biolatencybiosnoop是网络问题tcplifetcpretransUSE 方法逐个排查监控工具的三个层次第一层快速检查——top、vmstat、iostat、sar用途快速看整体发现问题方向特点简单、快、覆盖广第二层深入分析——perf、Ftrace、BCC用途定位到具体函数、具体代码路径特点功能强、开销可控第三层自定义追踪——bpftrace、BCC Python用途解决特殊问题写自定义逻辑特点灵活、强大、需要写代码原则先用第一层不够用第二层再不够用第三层。不要一上来就用最复杂的工具。五、总结监控系统有四种类型——计数器预埋传感器、剖析抽样调查、追踪全程跟拍、监控长期报表。各有各的用途。数据来源有五个——/proc系统计数器、/sys设备计数器、Tracepoint静态事件、kprobe/uprobe动态事件、PMC硬件计数器。计数器是基础——开销几乎为零永远在运行但只能看预设的。剖析是 CPU 分析的主力——定时采样看时间花在哪。火焰图是最有效的可视化。追踪是手电筒——想看哪里照哪里。动态追踪kprobe/uprobe是 Linux 最强大的能力。sar 是最被低估的工具——它是唯一的考古学家能看历史。遇到问题时先问过去正常吗用 sar 回答。监控工具分三层——快速检查top/vmstat/iostat、深入分析perf/Ftrace/BCC、自定义追踪bpftrace。先用简单的不够再升级。选工具看场景——CPU 问题用 perf磁盘问题用 biolatency网络问题用 tcplife历史问题用 sar。下一章讲应用程序——也就是企业。观测工具讲完了接下来看城市里最重要的那些企业它们怎么运转、怎么分析它们的性能、怎么从操作系统角度看它们。
性能之巅 导读（四）：观测工具
本文是《性能之巅》Systems Performance第 2 版第 4 章的导读。本书是系统性能领域的经典本系列逐章导读把书的核心概念讲清楚。城市监控系统上一章画好了城市地图——我们知道内核是市政府、进程是市民、文件系统是图书馆、I/O 栈是物流系统。但地图是静态的。城市每时每刻都在运转——工厂在开工、快递在派送、图书馆在借还书。你怎么知道现在发生了什么你需要一套城市监控系统。监控系统不是一种工具而是一整套体系有装在工厂门口的计数器数进出人数有定时巡逻的保安定期看一眼有全程跟拍的摄像头记录每个事件还有后台的报表系统把数据汇总成图表。这一章讲的就是这套监控系统有哪些类型的监控、数据从哪里来、以及一个最基础也最容易被忽略的报表工具——sar。一、监控系统有哪些类型监控系统按怎么看来分有四种类型。类型一计数器——预埋的传感器城市里到处都装着传感器工厂门口有人流计数器仓库门口有货物计数器快递网点有包裹计数器。这些传感器一直在工作一直在计数不需要你额外做什么。你只需要读取它们。技术上的计数器就是内核里预先埋好的整数变量# 看系统调用了多少次cat/proc/stat# 看网络收了多少包cat/proc/net/dev# 看磁盘 I/O 统计cat/proc/diskstats计数器的特点开销几乎为零——内核一直在维护读的时候只是读一个数字永远在运行——不需要你启用或配置只能看预设的——内核埋了什么你才能看什么计数器是最基础的监控。任何监控系统、任何性能工具底层都依赖计数器。类型二剖析——抽样调查计数器告诉你发生了多少次但不告诉你时间花在哪了。剖析Profiling就像抽样调查——不追查每一个市民而是定时随机抽查看他们正在干什么。# 每 99 毫秒采样一次看 CPU 在执行哪个函数perf record-F99-a-g--sleep30剖析的原理时间轴 │ │ │ │ │ │ ↓ ↓ ↓ ↓ ↓ ↓ 采样 采样 采样 采样 采样 采样 │ │ │ │ │ │ 函数A 函数A 函数B 函数A 函数C 函数A从采样结果推断函数 A 出现了 3 次函数 B 出现 1 次函数 C 出现 1 次——函数 A 最耗 CPU。剖析的特点开销可控——采样率可以调99 Hz 通常开销很小能看到为什么——不只是数字而是具体的函数和调用栈不精确——是抽样可能漏掉短时间的事件剖析是 CPU 分析的主力。火焰图就是剖析结果的可视化。类型三追踪——全程跟拍剖析是抽样追踪Tracing是全程跟拍——每一个事件都记录不漏掉任何一个。# 追踪每一个系统调用strace-p1234# 追踪每一个磁盘 I/Obiosnoop# 追踪每一个网络连接tcplife追踪的特点完整——不漏任何事件能看到完整因果开销大——事件多的时候会拖慢系统适合低频事件——比如磁盘 I/O每秒几千次不适合 CPU 指令每秒几十亿次追踪分两种静态追踪内核预先埋好的追踪点tracepoint动态追踪运行时插入的追踪点kprobe、uprobe动态追踪是手电筒——你想照哪里就照哪里。这是 Linux 性能分析最强大的能力。类型四监控——长期报表监控Monitoring是长期记录指标看趋势和异常。# sar 定期记录系统统计sar-u110# 监控系统如 Prometheus、Grafana长期记录监控的特点长期——记录几天、几个月甚至几年的数据趋势——看指标是上升还是下降告警——指标异常时通知你监控和前面三种的关系计数器、剖析、追踪是手段监控是目的——把手段收集的数据长期保存用于趋势分析和告警监控的关键是选对指标不要只监控平均值要监控 P99不要只监控资源要监控用户体验不要只监控当前值要监控变化率二、监控数据从哪来监控系统需要数据。数据从哪里来有五个主要来源。来源一/proc——内核的公告板/proc 是内核的公告板——内核把各种统计信息写在这里谁都可以看。# 看系统整体统计cat/proc/stat# 看内存信息cat/proc/meminfo# 看进程信息cat/proc/PID/status# 看磁盘统计cat/proc/diskstats# 看网络统计cat/proc/net/dev/proc 的特点文本格式——可以直接cat也可以用脚本处理动态生成——读的时候内核才生成内容不占磁盘覆盖全面——CPU、内存、磁盘、网络、进程应有尽有/proc 的缺点格式不统一——每个文件格式不一样解析麻烦有开销——文本编码和解析都有成本不够实时——有些统计是累计值需要自己算差值来源二/sys——设备的公告板/sys 是设备的公告板——主要展示设备、驱动、内核子系统的信息。# 看 CPU 缓存大小cat/sys/devices/system/cpu/cpu0/cache/index0/size# 看内核参数cat/sys/kernel/mm/transparent_hugepage/enabled# 看块设备队列cat/sys/block/sda/queue/scheduler/sys 的特点结构化——按设备、子系统组织比 /proc 更有条理可写——很多文件可以写入用于调优设备相关——主要展示硬件和驱动信息来源三Tracepoint——预埋的摄像头Tracepoint 是内核开发者预埋的摄像头——在内核代码的关键位置已经放好了追踪点。# 列出所有 tracepointperf list# 追踪块设备 I/O 事件perf trace-eblock:block_rq_issue# 追踪调度事件perf trace-esched:sched_switchTracepoint 的特点稳定——接口固定不会随内核版本变化低开销——没启用时是空操作有格式——每个 tracepoint 都有明确的参数定义常见的 tracepoint 类别类别内容sched:调度事件block:块设备 I/Osyscalls:系统调用net:网络事件ext4:ext4 文件系统kvm:KVM 虚拟化来源四kprobe/uprobe——临时摄像头kprobe 和 uprobe 是临时安装的摄像头——你想在哪装就在哪装。# 在内核函数上装摄像头bpftrace-ekprobe:vfs_read { [comm] count(); }# 在用户函数上装摄像头bpftrace-euprobe:/bin/bash:readline { [comm] count(); }kprobe 的特点灵活——任意内核函数都能追踪不稳定——函数名可能随内核版本变化需要知道函数名——得先查源码或符号表uprobe 的特点灵活——任意用户函数都能追踪需要知道偏移——得先解析二进制kprobe/uprobe 是最后的手段——当 tracepoint 不够用时用它们深入代码。来源五PMC——CPU 的仪表盘PMC性能监控计数器是 CPU 的仪表盘——它们能告诉你 CPU 内部发生了什么。# 看 IPC每周期指令数perfstat-ecycles,instructions-asleep5# 看缓存命中率perfstat-ecache-references,cache-misses-asleep5PMC 的特点硬件级——直接读取 CPU 内部的计数器需要处理器支持——不是所有 CPU 都有云上可能不可用——很多云厂商禁用 PMCPMC 能回答的问题CPU 效率高不高IPC缓存命中率怎么样内存带宽够不够分支预测失败多不多五个来源的关系观测数据来源/proc系统级计数器/sys设备级计数器Tracepoint静态事件kprobe/uprobe动态事件PMC硬件计数器计数器追踪计数器/proc、/sys、PMC看发生了多少次追踪Tracepoint、kprobe/uprobe看具体发生了什么三、一个被低估的工具sar监控数据来源有了但怎么用有一个工具几乎被所有人低估但它能解决很多问题。它就是sarSystem Activity Reporter。sar 是什么sar 是城市的综合报表系统——它定期收集系统统计保存下来随时可以回看。# 看今天的 CPU 统计sar-u# 看今天的磁盘统计sar-d# 看今天的网络统计sar-nDEVsar 的特点历史数据——它有一个后台守护进程定期默认每 10 分钟记录系统统计覆盖全面——CPU、内存、磁盘、网络、中断什么都有命令行友好——文本输出容易解析为什么 sar 被低估因为它太低调了。它不像top那样实时刷新看起来很静态它不像perf那样能生成火焰图看起来很朴素它不像bpftrace那样能写自定义脚本看起来很古老但 sar 有一个别人没有的能力看历史。当你遇到性能问题时你经常需要回答这个问题是什么时候开始的昨天这个时候系统是什么状态上周的峰值是多少top、perf、bpftrace都只能看现在。只有sar能看过去。sar 怎么用启用 sar# Ubuntu/Debianvim/etc/default/sysstat# 把 ENABLEDfalse 改成 ENABLEDtrue# 重启服务servicesysstat restart看历史数据# 看今天的 CPU 统计sar-u# 看指定日期的 CPU 统计sar-u-f/var/log/sysstat/sa15# 看指定时间范围sar-u-s10:00:00-e12:00:00看当前数据# 每秒一次看 CPUsar-u1# 每秒一次看磁盘sar-d1# 每秒一次看网络sar-nDEV1sar 的常用选项选项内容-uCPU 统计-r内存统计-d磁盘统计-n DEV网络接口-n TCPTCP 统计-n ETCPTCP 错误-q负载和队列-B换页统计-W交换统计sar 的输出格式$ sar-u13Linux5.3.0-1010-aws(ip-10-1-239-218)02/27/20 _x86_64_(2CPU)07:32:45 CPU %user %nice %system %iowait %steal %idle 07:32:46 all32.160.0061.810.000.006.0307:32:47 all33.830.0061.190.000.004.9807:32:48 all31.500.0060.500.000.008.00Average: all32.500.0061.170.000.006.33sar 的输出可以导出# JSON 格式sadf-j---u# CSV 格式sadf-d---u# SVG 图表sadf-g---ucpu.svgSVG 格式特别有用——可以直接在浏览器里看图表。sar 的实战价值场景一问题是什么时候开始的用户说系统从昨天开始变慢。你sar -u -f /var/log/sysstat/sa14一看昨天下午 3 点 CPU 利用率突然从 30% 升到 80%。再查一下3 点有个定时任务在跑。场景二昨天这个时候正常吗今天系统卡你sar -u一看CPU 90%。但你不知道是不是正常的。sar -u -f /var/log/sysstat/sa15看一下昨天同一时间——也是 90%。原来是正常的。场景三峰值是多少要做容量规划需要知道历史峰值。sar -u -f /var/log/sysstat/sa*全部看一遍找出最高值。sar 是性能分析的考古学家——它让你能看到过去发生了什么。四、怎么选监控工具监控工具这么多怎么选按场景选场景推荐工具快速看当前状态top、vmstat、iostat看历史趋势sarCPU 剖析perf record、profile磁盘 I/O 追踪biosnoop、biolatency网络连接追踪tcplife、tcpretrans系统调用追踪strace、perf trace自定义追踪bpftrace长期监控Prometheus、Grafana按问题类型选是否是否是否系统慢是 CPU 问题perf record火焰图是磁盘问题biolatencybiosnoop是网络问题tcplifetcpretransUSE 方法逐个排查监控工具的三个层次第一层快速检查——top、vmstat、iostat、sar用途快速看整体发现问题方向特点简单、快、覆盖广第二层深入分析——perf、Ftrace、BCC用途定位到具体函数、具体代码路径特点功能强、开销可控第三层自定义追踪——bpftrace、BCC Python用途解决特殊问题写自定义逻辑特点灵活、强大、需要写代码原则先用第一层不够用第二层再不够用第三层。不要一上来就用最复杂的工具。五、总结监控系统有四种类型——计数器预埋传感器、剖析抽样调查、追踪全程跟拍、监控长期报表。各有各的用途。数据来源有五个——/proc系统计数器、/sys设备计数器、Tracepoint静态事件、kprobe/uprobe动态事件、PMC硬件计数器。计数器是基础——开销几乎为零永远在运行但只能看预设的。剖析是 CPU 分析的主力——定时采样看时间花在哪。火焰图是最有效的可视化。追踪是手电筒——想看哪里照哪里。动态追踪kprobe/uprobe是 Linux 最强大的能力。sar 是最被低估的工具——它是唯一的考古学家能看历史。遇到问题时先问过去正常吗用 sar 回答。监控工具分三层——快速检查top/vmstat/iostat、深入分析perf/Ftrace/BCC、自定义追踪bpftrace。先用简单的不够再升级。选工具看场景——CPU 问题用 perf磁盘问题用 biolatency网络问题用 tcplife历史问题用 sar。下一章讲应用程序——也就是企业。观测工具讲完了接下来看城市里最重要的那些企业它们怎么运转、怎么分析它们的性能、怎么从操作系统角度看它们。
