From b00308df45ea546d605706f9388a510da9eecbef Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 2 Feb 2024 14:14:43 +0800 Subject: [PATCH] =?UTF-8?q?=E5=AE=8C=E5=96=84=20core=20dump=20=E5=92=8C=20?= =?UTF-8?q?profile=20=E6=95=B0=E6=8D=AE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Observability/dumps.md | 6 +++--- Observability/logging.md | 2 +- Observability/profiles.md | 21 ++++++--------------- 3 files changed, 10 insertions(+), 19 deletions(-) diff --git a/Observability/dumps.md b/Observability/dumps.md index 6a5c8b2c..6f30cd8c 100644 --- a/Observability/dumps.md +++ b/Observability/dumps.md @@ -1,6 +1,6 @@ # core dump -CNCF 可观测性白皮书中，可观测的数据（Signals）只提到了 core dump。只提 core dump 有局限，dump 还应该包含更多，例如 Heap dump（某时刻 Java 堆栈的快照）、Thread dump（某一时刻 Java 线程快照）等。 +CNCF 可观测性白皮书中只提到了 core dump。只提 core dump 有局限，dump 还应该包含更多，例如 Heap dump（某时刻 Java 堆栈的快照）、Thread dump（某一时刻 Java 线程快照）等。 这里小篇幅解释下 core dump。 core dump 历史悠久，很早就出现在 Unix-like 系统中，在一个任何安装有《Linux man 手册》的 Linux 发行版上，都可以通过 man core 来查阅相关信息。 @@ -14,11 +14,11 @@ A small number of signals which cause abnormal termination of a process ... ``` -根据上面的解释，只要程序异常终止或者崩溃系统就会有选择的将运行中的状态保存在一个文件中，这个文件就称为 core dump 文件。core 的意思是内存，dump 的意思是扔出来，除了内存信息外，关键的程序运行状态也会 dump 下来，例如寄存器信息（程序指针、栈指针）、内存管理信息、其他处理器和操作系统状态等信息。 +根据上面的解释，只要程序异常终止或者崩溃系统就会有选择的将运行中的状态保存在一个文件中，core 的意思是内存，dump 的意思是扔出来，这个文件就称为 core dump 文件。除了内存信息外，关键的程序运行状态也会 dump 下来，例如寄存器信息（程序指针、栈指针）、内存管理信息、其他处理器和操作系统状态等信息。 core dump 主要用来分析程序运行到底是哪出错了，最典型的使用是结合 gdb 分析引发程序崩溃的问题。由于 core dump 文件会占据大量的磁盘空间（处理密集型的应用程序可能会生成两位数 Gb 大小的文件），默认情况下，Linux 不允许生成 core dump 文件，得通过命令 ulimit -c unlimited（不限制 core 文件大小）开启。 -虽然 CNCF 将 dumps 数据纳入了可观测体系，但众多的应用限制：应用和基础设施角色权限（容器应用与系统全局配置问题）、数据持久化的问题（例如 Pod 在重启之前得把 core dump 文件并写入持久卷）并没有像日志、Metrics 产生系统化处理的方案。毕竟分析 dumps 文件只是个极低概率的工作，所以早些年 Linux 社区[^1]以及 Docker 社区[^2]关于容器中支持 core_pattern 独立配置的讨论到目前也并没有进展，还是得依靠原始的手段去处理。 +虽然 CNCF 将 dumps 数据纳入了可观测体系，但众多的应用限制：应用和基础设施角色权限（容器应用与系统全局配置问题）、数据持久化的问题（Pod 在重启之前得把 core dump 文件写入持久卷）等原因并没有像日志、Metrics 产生系统化处理的方案。此外，毕竟分析 dumps 文件只是个极低概率的工作，虽然早些年 Linux 社区[^1]以及 Docker 社区[^2]也在讨论容器中支持 core_pattern 独立配置。但众多的原因（主要还是场景覆盖太少、动力不足），所以这些方案和讨论并没有进展，还是得依靠原始的手段去处理。 [^1]: 参见 https://lore.kernel.org/patchwork/patch/643798/ [^2]: 参见 https://github.com/moby/moby/issues/19289 \ No newline at end of file diff --git a/Observability/logging.md b/Observability/logging.md index d01e8fa3..beaac785 100644 --- a/Observability/logging.md +++ b/Observability/logging.md @@ -58,7 +58,7 @@ loki 一个明显的特点是非常经济，Loki 不再根据日志内容去建 ## 日志展示 -在仪表可视化领域，如果 Grafana 称第二，应该没有敢称第一。在 Grafana Labs 公司成立之前，Grafana Dashboard 就已经在各个开源社区有不小的名气和用户积累。依靠社区的用户基础，Grafana Labs 也快速地将产品渗透至各个企业，如果你观察仔细，还能在各大新闻联播节目时不时会见到 Grafana 的身影：2016年，在猎鹰9号火箭首次发射期间，Grafana 出现在 SpaceX 控制中心的屏幕上；几周后，微软发布一段宣传视频，展示了他们的水下数据中心，同样出现了 Grafana 的身影[^3]。 +在仪表可视化领域，如果 Grafana 称第二，应该没有敢称第一。在 Grafana Labs 公司成立之前，Grafana Dashboard 就已经在各个开源社区有不小的名气和用户积累。依靠社区的用户基础，Grafana Labs 也快速地将产品渗透至各个企业，如果你观察仔细，还能在各类大场面时不时会见到 Grafana 的身影：2016年，在猎鹰9号火箭首次发射期间，Grafana 出现在 SpaceX 控制中心的屏幕上；几周后，微软发布一段宣传视频，展示了他们的水下数据中心，同样出现了 Grafana 的身影[^3]。 Grafana slogan 中的 “Dashboard anything. Observe everything.” 这个anything 和 everything 可不是说说，使用 Grafana 可以非常轻松的将任何数据[^1]转成任何你想要的图表[^2]的展现形式来做到数据监控以及数据统计。 diff --git a/Observability/profiles.md b/Observability/profiles.md index 4a04edd5..c4a86974 100644 --- a/Observability/profiles.md +++ b/Observability/profiles.md @@ -1,32 +1,23 @@ # Profiles -了解 Profiles ，你可能需要先了解一下 Profiling。先看看 wiki 百科的解释： +熟悉 Go 语言的朋友一定了解 pprof，进行性能分析时，通过 pprof 的 CPU profiling 或者 Memory profiling 功能分析函数耗时以及内存占用情况。Profiles 就是进行 profiling 时程序运行的动态画像，当于动态的内部数据，说明各类资源分配的情况，能精确到进程、代码。 -:::tip Profiling - -在软件工程中，性能分析（performance analysis也称为profiling），是以收集程序运行时信息为手段研究程序行为的分析方法，是一种动态程序分析的方法。 - -::: - -可以看出，Profiling 是一个关于动态程序分析的术语，很多编程语言或框架也提供了丰富的 Profiling Tools，熟悉 Go 语言的朋友一定了解 pprof，当运行异常时，通过 pprof CPU profiling 或者 Memory profiling 分析函数耗时以及内存占用情况，展示形式以 Flame Graph（火焰图）表达。2021年国内某站崩溃[^1]，工程师们使用火焰图观察到到某一处 Lua 代码存在异常时，才找到问题的源头。 +Profiles 数据一般表示成火焰图、堆栈图，内存分析图等形式，可以让我们足够细地了解到程序使用各类资源的全貌，是回答从“是什么”到“为什么”的依据，例如通过 trace 了解到延迟在什么地方产生，再通过 Profiles 定位到是哪行代码影响。2021年国内某站崩溃，工程师们就是使用火焰图观察到到一处 Lua 代码存在异常，才找到问题的源头[^1]。

Lua 级别的 CPU 火焰图

-可观测中的 Profiles 聚焦在理解资源是如何在系统中被分配的，一般包括： +可观测中的 Profiles 数据由多种不同的 Profiler 组成，常见的有： - CPU Profilers （CPU 分析器） - Heap Profilers（堆分析器） - GPU Profilers （GPU 分析器） - Mutex Profilers （互斥锁分析器） - IO Profilers （IO 分析器） -- Language-specific Profilers（特定于语言的分析器 JVM Profiler） - -传统上，这些分析器并不适合在产生环境中运行（开销很大），不过由于采样分析变得越来越可行（只增加了百分之几的开销），这使得临时在生产环境中添加分析器，尽可能地观察到一段时间内的全局 Profiles 数据成为可能。 - -Traces 让我们了解延迟问题是分布式系统的的哪个部分导致的，而 Profiles 则使我们进一步定位到具体的函数具体的代码，更加深入挖掘并理解那些导致延迟问题存在的原因，是回答从“是什么”到“为什么”的重要数据。 +- Language-specific Profilers（特定于语言的分析器，例如 JVM Profiler） +传统上，这些 Profiler 并不适合在产生环境中运行（开销很大），不过由于采样分析变得越来越可行（只增加了很少的开销），这使得生产环境中添加 Profiler，尽可能地观察到一段时间内的全局 Profiles 数据成为可能。 -[^1]:参见《2021.07.13 我们是这样崩的》https://www.bilibili.com/read/cv17521097/ \ No newline at end of file +[^1]: 参见《2021.07.13 我们是这样崩的》https://www.bilibili.com/read/cv17521097/ \ No newline at end of file