如果你正在开发或维护 Erlang/OTP 应用却苦于无法直观地监控运行时状态那么 observer_cli 可能是你一直在寻找的工具。在 Erlang 生态中虽然官方提供了 observer 图形化工具但在服务器环境或终端开发场景下一个轻量级、命令行友好的运行时观测工具显得尤为重要。observer_cli 并不是另一个简单的进程列表工具它真正解决的是 Erlang/OTP 应用在生产环境下的可观测性痛点。通过实时展示监督树结构、进程状态、内存使用和系统负载等信息它让开发者能够快速定位性能瓶颈、内存泄漏和进程异常问题。与传统的日志调试相比observer_cli 提供了更直观的运行时洞察能力。本文将深入解析 observer_cli 的核心功能并通过实际示例演示如何利用它来监控和理解 Erlang/OTP 应用的运行时行为。无论你是 Erlang 新手还是经验丰富的开发者掌握这个工具都将显著提升你的调试和性能优化效率。1. 为什么需要 observer_cliErlang 应用监控的真实痛点在深入技术细节之前我们先明确 observer_cli 解决的核心问题。Erlang/OTP 应用以其高并发和容错能力著称但这种架构优势也带来了监控复杂性传统监控方式的局限性依赖日志输出只能看到应用层面的信息无法了解运行时系统状态图形化 observer 工具在服务器环境下安装和使用的复杂性较高手动调用 Erlang Shell 命令信息分散缺乏整体视图observer_cli 的独特价值终端友好纯命令行界面适合服务器环境和远程调试实时更新动态刷新显示便于监控系统变化趋势信息聚合将监督树、进程状态、内存使用等关键指标集中展示轻量级资源消耗小适合生产环境长期运行特别是在微服务架构和容器化部署场景下observer_cli 的终端友好特性使其成为 Erlang 应用监控的首选工具。2. observer_cli 的核心功能解析observer_cli 提供了多个功能模块每个模块针对不同的监控需求2.1 监督树可视化监督树是 OTP 应用的核心架构observer_cli 以树状结构清晰展示所有监督者与工作进程的层级关系Application ├── Supervisor: my_app_sup │ ├── Worker: gen_server_1 │ ├── Worker: gen_server_2 │ └── Supervisor: child_sup │ └── Worker: gen_server_3这种可视化帮助开发者快速理解应用架构定位问题进程所在的监督分支。2.2 进程详细信息监控每个 Erlang 进程的关键指标都被实时监控进程 ID 和注册名当前状态running、waiting、suspended内存使用情况堆大小、消息队列长度缩减次数reductions用于衡量 CPU 负载2.3 系统负载概览系统级监控指标包括CPU 使用率按调度器细分内存分配进程内存、二进制数据、ETS 表等I/O 统计信息调度器负载均衡情况3. 环境准备与安装部署3.1 环境要求在开始使用 observer_cli 前确保你的环境满足以下要求Erlang/OTP 21.0 或更高版本推荐 OTP 24rebar3 或 mix 构建工具根据项目类型选择3.2 安装方式方式一作为项目依赖安装推荐在rebar.config中添加依赖{deps, [ {observer_cli, 1.7.0} ]}.然后编译项目rebar3 compile方式二全局安装如果你希望在任何 Erlang shell 中都能使用 observer_cligit clone https://github.com/zhongwencool/observer_cli.git cd observer_cli rebar3 compile3.3 验证安装启动 Erlang shell 并验证安装$ erl Erlang/OTP 25 [erts-13.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] Eshell V13.0 (abort with ^G) 1 observer_cli:start().如果看到类似下面的输出说明安装成功observer_cli started, press Enter to stop.4. 基础使用与界面导航4.1 启动 observer_cli在 Erlang shell 中直接启动%% 基本启动 observer_cli:start(). %% 指定刷新间隔毫秒 observer_cli:start(1000). % 每秒刷新一次 %% 在远程节点启动 observer_cli:start(nodehostname).4.2 界面布局解析启动后observer_cli 界面通常分为几个主要区域----------------------------------------- | 顶部系统概览CPU、内存、进程数等 | ----------------------------------------- | 左侧导航菜单 | | • Overview | | • Processes | | • Applications | | • ETS Tables | | • Ports | ---------------------------------------- | 右侧详细信息显示区域 | | 根据左侧选择显示相应内容 | -----------------------------------------4.3 键盘导航observer_cli 支持键盘操作↑/↓上下移动选择Enter进入选中项或刷新q或CtrlC退出Tab在不同面板间切换5. 实战示例监控一个真实的 OTP 应用让我们通过一个具体的例子来演示 observer_cli 的强大功能。假设我们有一个简单的 OTP 应用5.1 示例应用代码创建监督者模块my_sup.erl-module(my_sup). -behaviour(supervisor). -export([start_link/0]). -export([init/1]). start_link() - supervisor:start_link({local, ?MODULE}, ?MODULE, []). init([]) - SupFlags #{strategy one_for_one, intensity 1, period 5}, ChildSpecs [ #{id worker1, start {my_worker, start_link, [worker1]}, restart permanent, shutdown 5000, type worker, modules [my_worker]}, #{id worker2, start {my_worker, start_link, [worker2]}, restart permanent, shutdown 5000, type worker, modules [my_worker]} ], {ok, {SupFlags, ChildSpecs}}.创建工作进程模块my_worker.erl-module(my_worker). -behaviour(gen_server). -export([start_link/1]). -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2]). start_link(Name) - gen_server:start_link({local, Name}, ?MODULE, [], []). init([]) - {ok, #{count 0}}. handle_call(get_count, _From, State #{count : Count}) - {reply, Count, State}; handle_call(_Request, _From, State) - {reply, ok, State}. handle_cast(increment, State #{count : Count}) - {noreply, State#{count Count 1}}; handle_cast(_Msg, State) - {noreply, State}. handle_info(_Info, State) - {noreply, State}. terminate(_Reason, _State) - ok.5.2 启动应用并监控编译并启动应用1 c(my_sup), c(my_worker). {ok,my_worker} 2 my_sup:start_link(). {ok,0.118.0}现在启动 observer_cli 来监控这个应用3 observer_cli:start().5.3 分析监督树结构在 observer_cli 界面中导航到 Applications 或 Processes 视图你应该能看到类似这样的监督树my_sup (supervisor) ├── worker1 (gen_server) └── worker2 (gen_server)这直观地展示了应用的进程架构对于理解复杂应用的运行时结构非常有帮助。6. 高级功能与性能分析6.1 进程详细信息分析选择特定的进程可以查看详细信息%% 在 observer_cli 中选择 worker1 进程后显示的信息示例 Process: 0.120.0 Registered Name: worker1 Status: running Memory: 2.5 KB Message Queue Length: 0 Reductions: 1,2456.2 内存使用监控observer_cli 提供详细的内存分析进程内存每个进程的堆内存使用情况二进制数据大型二进制数据的存储情况ETS 表内存ETS 表占用的内存空间系统总内存Erlang 虚拟机的整体内存使用6.3 性能瓶颈识别通过观察以下指标识别性能问题高消息队列长度表示进程处理能力不足异常的内存增长可能的内存泄漏迹象不均衡的调度器负载CPU 资源利用问题7. 常见问题与排查指南7.1 启动问题排查问题现象可能原因解决方案undefined function observer_cli:start/0依赖未正确安装或编译检查rebar.config配置重新编译依赖连接远程节点失败节点名称错误或网络问题验证节点名称格式nodehostname界面显示乱码终端编码设置问题设置终端为 UTF-8 编码7.2 性能问题诊断案例消息队列积压在 observer_cli 中发现某个进程的消息队列长度持续增长定位问题进程在 Processes 视图中按消息队列排序分析进程状态检查进程是否处于阻塞状态查看堆栈跟踪使用process_info(Pid, current_stacktrace)获取更多信息案例内存泄漏排查监控内存增长趋势在 Overview 面板观察内存使用变化识别问题进程按内存使用排序进程列表分析进程状态检查是否存在异常的大内存进程7.3 生产环境使用建议在生产环境使用 observer_cli 时需要注意%% 安全的使用方式限制访问权限 %% 在 vm.args 中添加 %% -kernel inet_dist_listen_min 9100 inet_dist_listen_max 9105 %% 使用安全的刷新间隔避免性能影响 observer_cli:start(5000). % 5秒刷新一次减少系统负载8. 最佳实践与工程建议8.1 监控策略设计分层监控体系应用层业务逻辑相关的监控指标OTP 层监督树和进程状态监控系统层CPU、内存等资源监控关键监控指标%% 重要的监控阈值 -define(MAX_MESSAGE_QUEUE_LEN, 1000). % 消息队列最大长度 -define(MAX_PROCESS_MEMORY_MB, 100). % 单个进程内存上限 -define(MAX_SYSTEM_MEMORY_PERCENT, 80). % 系统内存使用率上限8.2 自动化监控集成将 observer_cli 的功能集成到自动化监控系统中%% 定期收集监控数据的示例 collect_metrics() - Processes observer_cli_lib:get_processes(), SystemInfo observer_cli_lib:get_system_info(), % 发送到监控系统 send_to_monitoring_system(Processes, SystemInfo).8.3 安全注意事项在生产环境使用 observer_cli 时确保访问控制限制对 observer_cli 的访问权限网络安全使用安全的节点间通信资源限制设置适当的刷新频率避免性能影响日志记录记录所有监控访问行为9. 与其他监控工具的对比9.1 observer_cli vs 官方 observer特性observer_cli官方 observer界面类型命令行终端图形化界面资源消耗低中等服务器兼容性优秀需要图形环境远程监控简单复杂自动化集成容易困难9.2 observer_cli vs 自定义监控脚本observer_cli 相比自定义脚本的优势功能完整覆盖监督树、进程、内存等全方位监控实时性动态刷新实时反映系统状态易用性统一的界面和操作方式社区支持持续更新和维护observer_cli 作为 Erlang/OTP 生态中的终端监控利器填补了命令行环境下运行时可视化的空白。它不仅仅是一个工具更是理解复杂 OTP 应用运行时行为的重要窗口。通过本文的详细介绍和实战示例你应该已经掌握了 observer_cli 的核心功能和使用方法。在实际项目中建议将 observer_cli 作为日常开发和问题排查的标准工具结合本文提到的最佳实践构建完善的 Erlang 应用监控体系。对于希望深入学习的开发者建议进一步探索 observer_cli 的源码实现理解其数据采集和展示机制这将有助于你定制更适合特定项目需求的监控解决方案。