今天来看一个专门用于 Erlang/OTP 系统的命令行观测工具 observer_cli。对于正在开发或运维 Erlang/Elixir 应用的工程师来说这个工具能让你在终端里直接查看 BEAM 虚拟机的运行时状态包括监督树结构、进程详情、内存分配等关键指标。observer_cli 由 zhongwencool 开发维护目前 GitHub 上有 1.5k star支持 Erlang/OTP 26-29 版本。它提供了两种使用方式命令行接口CLI适合自动化脚本和运维场景文本用户界面TUI适合交互式探索。两种方式都基于 Erlang 分布式连接可以远程诊断生产环境节点。最核心的价值是你不需要图形界面直接在 SSH 会话中就能完成全面的运行时诊断。对于服务器运维、CI/CD 流水线集成、AI 代理工作流等场景特别实用。本文将带你完成从安装部署到实际使用的完整流程重点演示如何查看监督树和进程状态。1. 核心能力速览能力项说明项目类型Erlang/Elixir 运行时诊断工具开源地址github.com/zhongwencool/observer_cli主要功能进程监控、内存分析、调度器状态、监督树可视化、网络活动追踪支持平台Linux, macOS, Windows (需要 Erlang 环境)运行要求Erlang/OTP 26-29无需图形界面连接方式Erlang 分布式节点连接输出格式文本、Erlang 术语、JSONOTP 27适合场景生产环境诊断、自动化运维、性能调优、教学演示2. 适用场景与使用边界observer_cli 主要面向以下几类用户Erlang/Elixir 开发者在开发过程中实时查看应用状态调试监督树结构分析进程间通信。DevOps 工程师在生产环境通过 SSH 连接诊断问题无需图形界面访问权限。SRE 团队集成到监控告警系统中定期采集运行时指标。教学培训演示 OTP 应用架构和 BEAM 虚拟机工作原理。使用边界需要注意仅支持 Erlang/Elixir 的 BEAM 虚拟机环境需要节点间的网络连通性和正确的 cookie 配置不适合非 Erlang 生态的技术栈生产环境使用需确保网络安全性3. 环境准备与前置条件在开始安装 observer_cli 之前需要确认基础环境Erlang/OTP 版本要求最低支持 OTP 26.x推荐使用 OTP 27 以获得 JSON 输出支持最高支持 OTP 29.x检查当前 Erlang 版本erl -version # 或者 erl V系统路径配置 确保erl、escript等 Erlang 工具在 PATH 中which erl which escript网络和权限如果连接远程节点需要网络连通性知道目标节点的名称和分布式 cookie有权限在目标节点安装 observer_cli 依赖磁盘空间 工具本身很小但需要足够的空间编译 Erlang 依赖。4. 安装部署与启动方式observer_cli 提供多种安装方式根据你的使用场景选择。4.1 快速安装推荐对于大多数用户使用官方安装脚本是最简单的方式# 安装最新稳定版 curl -fsSL https://raw.githubusercontent.com/zhongwencool/observer_cli/v2.0.0/install.sh | sh安装完成后根据提示将$HOME/.local/bin加入 PATHecho export PATH$HOME/.local/bin:$PATH ~/.bashrc source ~/.bashrc验证安装observer_cli --version4.2 作为依赖集成到项目中如果你需要在目标节点永久安装可以将其加入项目依赖。Erlang 项目rebar.config{deps, [ {observer_cli, 2.0.0} ]}.然后编译rebar3 compileElixir 项目mix.exsdefp deps do [ {:observer_cli, 2.0.0} ] end编译mix deps.get mix compile4.3 从源码构建如果需要特定版本或自定义修改可以从源码构建VERSION2.0.0 git clone --branch v${VERSION} --depth 1 \ https://github.com/zhongwencool/observer_cli.git cd observer_cli # 使用 rebar3 构建 rebar3 escriptize cp _build/default/bin/observer_cli ~/.local/bin/ # 或使用 mix 构建Elixir 环境 mix deps.get mix escript.build cp observer_cli ~/.local/bin/5. 连接目标节点配置在使用 observer_cli 之前需要配置与目标节点的连接。5.1 设置连接信息安全起见建议使用环境变量存储 cookieexport OBSERVER_CLI_COOKIEyour_node_cookie_here建立连接配置observer_cli connect \ --node myappserver-host \ --cookie-env OBSERVER_CLI_COOKIE这个命令会保存连接配置后续命令无需重复指定节点信息。5.2 验证连接状态# 检查连接状态 observer_cli status # 运行基础诊断 observer_cli diagnose # 断开连接清理配置 observer_cli disconnect重要安全提醒分布式的 cookie 具有完整节点访问权限不是只读凭证。仅连接可信节点并在可信网络中使用。6. 监督树可视化实战监督树是 OTP 应用的核心架构observer_cli 可以清晰展示其层次结构。6.1 启动 TUI 界面observer_cli tui myappserver-host启动后会进入交互式界面使用方向键导航。6.2 查看应用监督树在 TUI 中按a键进入 Applications 页面选择你要查看的应用按Enter进入详情页选择 Supervision Tree 视图你会看到类似这样的结构my_app_sup ├── worker_1 ├── worker_2 └── dynamic_sup ├── dyn_worker_1 └── dyn_worker_26.3 理解监督树信息监督树视图显示的关键信息进程ID每个监督者和工作进程的唯一标识重启策略one_for_one、one_for_all、rest_for_one子进程规格worker 或 supervisor状态运行中、已终止、重启中6.4 命令行方式获取监督树对于自动化场景可以使用 CLI 命令observer_cli inspect --type supervision myappserver-host输出会以结构化文本或 JSON 格式展示监督树。7. 进程状态监控与分析除了监督树observer_cli 提供详细的进程级监控。7.1 进程排名视图在 TUI 中按p进入进程页面可以看到按各种指标排序的进程列表内存占用找出内存泄漏的进程消息队列长度发现消息积压问题Reductions识别 CPU 密集型进程堆大小监控内存使用模式7.2 单个进程详情选择特定进程后可以查看详细信息进程状态running、waiting、garbage collecting当前函数进程正在执行的代码位置堆栈跟踪最近的函数调用历史消息队列内容等待处理的消息数量内存分配详情二进制数据、ETS 表引用等7.3 进程跟踪功能对于问题诊断可以启用有界函数跟踪observer_cli trace --pid 0.123.0 --function my_module:my_fun --duration 5000这个功能需要节点全局同意适合调试生产环境问题。8. 系统级性能指标observer_cli 不仅关注进程级指标还提供系统级视角。8.1 内存分配器分析在 TUI 中按m进入内存页面查看总内存使用包括进程、ETS、原子表等分配器统计每个分配器的区块大小和数量二进制数据引用和堆二进制分布系统内存与操作系统内存的关联8.2 调度器监控按s查看调度器状态调度器利用率每个调度器的忙碌程度负载均衡检查工作是否均匀分布端口调度I/O 端口的活动情况8.3 网络和分布式监控对于分布式系统网络活动很关键节点连接当前连接的远程节点消息流量节点间消息传输统计端口活动网络端口的读写操作9. 自动化与集成应用observer_cli 的 CLI 模式非常适合自动化场景。9.1 定期健康检查创建监控脚本#!/bin/bash # health_check.sh output$(observer_cli diagnose --node myappserver-host --format json) # 解析 JSON 输出检查关键指标 error_count$(echo $output | jq .findings | map(select(.severity error)) | length) if [ $error_count -gt 0 ]; then echo CRITICAL: Found $error_count issues exit 1 else echo OK: System healthy exit 0 fi9.2 CI/CD 集成在部署流程中加入诊断# 部署后验证 observer_cli diagnose --node new_deployserver-host # 检查特定指标 observer_cli inspect --metric memory_usage --threshold 809.3 API 集成示例虽然 observer_cli 本身是命令行工具但可以包装成 HTTP APIimport subprocess import json def get_system_health(node_name): try: result subprocess.run([ observer_cli, diagnose, --node, node_name, --format, json ], capture_outputTrue, textTrue, timeout30) if result.returncode 0: return json.loads(result.stdout) else: return {error: result.stderr} except Exception as e: return {error: str(e)}10. 高级功能与插件系统observer_cli 支持插件扩展可以自定义监控页面。10.1 内置插件使用当前版本包含多个有用的插件ETS 表监控查看所有 ETS 表的状态和内存使用Mnesia 表分析监控分布式数据库表端口监控跟踪外部端口通信套接字统计网络连接详情10.2 自定义插件开发创建自定义监控页面-module(my_plugin). -behaviour(observer_cli_plugin). -export([hierarchy/0, sheet/2]). hierarchy() - [#{id my_metrics, title My Metrics}]. sheet(my_metrics, _Node) - Data get_my_custom_metrics(), observer_cli_plugin:sheet([ #{title Custom Metrics, columns [ #{title Metric, width 20}, #{title Value, width 10} ], rows Data} ]).11. 性能优化与最佳实践在生产环境使用 observer_cli 时遵循这些最佳实践。11.1 资源使用优化observer_cli 本身很轻量但连接诊断时要注意诊断频率避免过高频率的自动诊断影响性能数据量控制使用--limit参数限制返回数据量超时设置为自动化脚本设置合理的超时时间11.2 安全配置建议网络隔离仅在可信网络中使用分布式连接Cookie 管理使用环境变量而非硬编码访问控制限制可连接节点的 IP 范围日志安全注意日志可能包含敏感信息11.3 监控策略设计建立有效的监控策略分层监控系统级、应用级、进程级分层采集基线建立记录正常状态下的指标基线告警阈值基于基线设置合理的告警阈值趋势分析关注指标的变化趋势而非绝对值12. 常见问题与排查方法问题现象可能原因排查方式解决方案连接被拒绝Cookie 不匹配或网络不通检查节点状态和 cookie验证 cookie 配置检查防火墙命令执行超时节点负载过高或网络延迟检查节点资源使用情况增加超时时间优化节点性能TUI 显示乱码终端编码不支持检查 TERM 环境变量设置export TERMxterm-256color内存信息不准确节点版本不兼容验证 OTP 版本兼容性升级到支持的 OTP 版本插件加载失败插件编译错误或版本不匹配检查插件依赖和编译日志重新编译插件检查版本兼容性12.1 连接问题深度排查# 1. 验证节点是否可访问 ping server-host # 2. 检查 Erlang 分布式连接 erl -sname test -setcookie MyCookie # 在 Erlang shell 中尝试连接 net_adm:ping(myappserver-host). # 3. 验证 observer_cli 配置 observer_cli status12.2 性能数据异常分析当发现性能指标异常时确认数据真实性多次采样验证趋势关联分析结合系统监控数据交叉验证根因分析从系统级到进程级逐层下钻影响评估确定问题对业务的影响程度13. 与传统图形界面对比observer_cli 与 Erlang 自带的 observer GUI 工具相比各有优势observer_cli 优势无需图形界面纯命令行操作适合远程服务器和自动化场景资源消耗更小输出格式标准化易于解析图形界面 observer 优势可视化更直观适合初学者实时刷新交互体验更好图表展示趋势更明显选择建议生产环境运维优先选择 observer_cli开发调试根据习惯选择两者都可自动化集成必须使用 observer_cli14. 实际案例诊断内存泄漏问题通过一个真实场景展示 observer_cli 的实际价值。14.1 问题现象应用运行一段时间后内存持续增长最终被 OOM Killer 终止。14.2 诊断步骤# 1. 连接问题节点 observer_cli connect --node problematicserver-host # 2. 运行全面诊断 observer_cli diagnose --format json diagnosis.json # 3. 分析内存排名 observer_cli inspect --type processes --sort memory --limit 1014.3 发现根本原因通过进程内存排名发现某个进程的消息队列堆积了大量消息进一步分析发现是消息处理逻辑存在缺陷导致消息无法被及时消费。14.4 解决方案修复消息处理逻辑增加流控机制问题得到解决。observer_cli 为 Erlang/Elixir 开发者提供了强大的命令行诊断能力特别适合生产环境运维和自动化场景。通过本文的实践指南你可以快速掌握其核心功能并将其应用到实际工作中。建议从连接本地开发环境开始练习逐步扩展到测试和生产环境的使用。
Erlang/OTP 命令行诊断工具 observer_cli 实战指南
今天来看一个专门用于 Erlang/OTP 系统的命令行观测工具 observer_cli。对于正在开发或运维 Erlang/Elixir 应用的工程师来说这个工具能让你在终端里直接查看 BEAM 虚拟机的运行时状态包括监督树结构、进程详情、内存分配等关键指标。observer_cli 由 zhongwencool 开发维护目前 GitHub 上有 1.5k star支持 Erlang/OTP 26-29 版本。它提供了两种使用方式命令行接口CLI适合自动化脚本和运维场景文本用户界面TUI适合交互式探索。两种方式都基于 Erlang 分布式连接可以远程诊断生产环境节点。最核心的价值是你不需要图形界面直接在 SSH 会话中就能完成全面的运行时诊断。对于服务器运维、CI/CD 流水线集成、AI 代理工作流等场景特别实用。本文将带你完成从安装部署到实际使用的完整流程重点演示如何查看监督树和进程状态。1. 核心能力速览能力项说明项目类型Erlang/Elixir 运行时诊断工具开源地址github.com/zhongwencool/observer_cli主要功能进程监控、内存分析、调度器状态、监督树可视化、网络活动追踪支持平台Linux, macOS, Windows (需要 Erlang 环境)运行要求Erlang/OTP 26-29无需图形界面连接方式Erlang 分布式节点连接输出格式文本、Erlang 术语、JSONOTP 27适合场景生产环境诊断、自动化运维、性能调优、教学演示2. 适用场景与使用边界observer_cli 主要面向以下几类用户Erlang/Elixir 开发者在开发过程中实时查看应用状态调试监督树结构分析进程间通信。DevOps 工程师在生产环境通过 SSH 连接诊断问题无需图形界面访问权限。SRE 团队集成到监控告警系统中定期采集运行时指标。教学培训演示 OTP 应用架构和 BEAM 虚拟机工作原理。使用边界需要注意仅支持 Erlang/Elixir 的 BEAM 虚拟机环境需要节点间的网络连通性和正确的 cookie 配置不适合非 Erlang 生态的技术栈生产环境使用需确保网络安全性3. 环境准备与前置条件在开始安装 observer_cli 之前需要确认基础环境Erlang/OTP 版本要求最低支持 OTP 26.x推荐使用 OTP 27 以获得 JSON 输出支持最高支持 OTP 29.x检查当前 Erlang 版本erl -version # 或者 erl V系统路径配置 确保erl、escript等 Erlang 工具在 PATH 中which erl which escript网络和权限如果连接远程节点需要网络连通性知道目标节点的名称和分布式 cookie有权限在目标节点安装 observer_cli 依赖磁盘空间 工具本身很小但需要足够的空间编译 Erlang 依赖。4. 安装部署与启动方式observer_cli 提供多种安装方式根据你的使用场景选择。4.1 快速安装推荐对于大多数用户使用官方安装脚本是最简单的方式# 安装最新稳定版 curl -fsSL https://raw.githubusercontent.com/zhongwencool/observer_cli/v2.0.0/install.sh | sh安装完成后根据提示将$HOME/.local/bin加入 PATHecho export PATH$HOME/.local/bin:$PATH ~/.bashrc source ~/.bashrc验证安装observer_cli --version4.2 作为依赖集成到项目中如果你需要在目标节点永久安装可以将其加入项目依赖。Erlang 项目rebar.config{deps, [ {observer_cli, 2.0.0} ]}.然后编译rebar3 compileElixir 项目mix.exsdefp deps do [ {:observer_cli, 2.0.0} ] end编译mix deps.get mix compile4.3 从源码构建如果需要特定版本或自定义修改可以从源码构建VERSION2.0.0 git clone --branch v${VERSION} --depth 1 \ https://github.com/zhongwencool/observer_cli.git cd observer_cli # 使用 rebar3 构建 rebar3 escriptize cp _build/default/bin/observer_cli ~/.local/bin/ # 或使用 mix 构建Elixir 环境 mix deps.get mix escript.build cp observer_cli ~/.local/bin/5. 连接目标节点配置在使用 observer_cli 之前需要配置与目标节点的连接。5.1 设置连接信息安全起见建议使用环境变量存储 cookieexport OBSERVER_CLI_COOKIEyour_node_cookie_here建立连接配置observer_cli connect \ --node myappserver-host \ --cookie-env OBSERVER_CLI_COOKIE这个命令会保存连接配置后续命令无需重复指定节点信息。5.2 验证连接状态# 检查连接状态 observer_cli status # 运行基础诊断 observer_cli diagnose # 断开连接清理配置 observer_cli disconnect重要安全提醒分布式的 cookie 具有完整节点访问权限不是只读凭证。仅连接可信节点并在可信网络中使用。6. 监督树可视化实战监督树是 OTP 应用的核心架构observer_cli 可以清晰展示其层次结构。6.1 启动 TUI 界面observer_cli tui myappserver-host启动后会进入交互式界面使用方向键导航。6.2 查看应用监督树在 TUI 中按a键进入 Applications 页面选择你要查看的应用按Enter进入详情页选择 Supervision Tree 视图你会看到类似这样的结构my_app_sup ├── worker_1 ├── worker_2 └── dynamic_sup ├── dyn_worker_1 └── dyn_worker_26.3 理解监督树信息监督树视图显示的关键信息进程ID每个监督者和工作进程的唯一标识重启策略one_for_one、one_for_all、rest_for_one子进程规格worker 或 supervisor状态运行中、已终止、重启中6.4 命令行方式获取监督树对于自动化场景可以使用 CLI 命令observer_cli inspect --type supervision myappserver-host输出会以结构化文本或 JSON 格式展示监督树。7. 进程状态监控与分析除了监督树observer_cli 提供详细的进程级监控。7.1 进程排名视图在 TUI 中按p进入进程页面可以看到按各种指标排序的进程列表内存占用找出内存泄漏的进程消息队列长度发现消息积压问题Reductions识别 CPU 密集型进程堆大小监控内存使用模式7.2 单个进程详情选择特定进程后可以查看详细信息进程状态running、waiting、garbage collecting当前函数进程正在执行的代码位置堆栈跟踪最近的函数调用历史消息队列内容等待处理的消息数量内存分配详情二进制数据、ETS 表引用等7.3 进程跟踪功能对于问题诊断可以启用有界函数跟踪observer_cli trace --pid 0.123.0 --function my_module:my_fun --duration 5000这个功能需要节点全局同意适合调试生产环境问题。8. 系统级性能指标observer_cli 不仅关注进程级指标还提供系统级视角。8.1 内存分配器分析在 TUI 中按m进入内存页面查看总内存使用包括进程、ETS、原子表等分配器统计每个分配器的区块大小和数量二进制数据引用和堆二进制分布系统内存与操作系统内存的关联8.2 调度器监控按s查看调度器状态调度器利用率每个调度器的忙碌程度负载均衡检查工作是否均匀分布端口调度I/O 端口的活动情况8.3 网络和分布式监控对于分布式系统网络活动很关键节点连接当前连接的远程节点消息流量节点间消息传输统计端口活动网络端口的读写操作9. 自动化与集成应用observer_cli 的 CLI 模式非常适合自动化场景。9.1 定期健康检查创建监控脚本#!/bin/bash # health_check.sh output$(observer_cli diagnose --node myappserver-host --format json) # 解析 JSON 输出检查关键指标 error_count$(echo $output | jq .findings | map(select(.severity error)) | length) if [ $error_count -gt 0 ]; then echo CRITICAL: Found $error_count issues exit 1 else echo OK: System healthy exit 0 fi9.2 CI/CD 集成在部署流程中加入诊断# 部署后验证 observer_cli diagnose --node new_deployserver-host # 检查特定指标 observer_cli inspect --metric memory_usage --threshold 809.3 API 集成示例虽然 observer_cli 本身是命令行工具但可以包装成 HTTP APIimport subprocess import json def get_system_health(node_name): try: result subprocess.run([ observer_cli, diagnose, --node, node_name, --format, json ], capture_outputTrue, textTrue, timeout30) if result.returncode 0: return json.loads(result.stdout) else: return {error: result.stderr} except Exception as e: return {error: str(e)}10. 高级功能与插件系统observer_cli 支持插件扩展可以自定义监控页面。10.1 内置插件使用当前版本包含多个有用的插件ETS 表监控查看所有 ETS 表的状态和内存使用Mnesia 表分析监控分布式数据库表端口监控跟踪外部端口通信套接字统计网络连接详情10.2 自定义插件开发创建自定义监控页面-module(my_plugin). -behaviour(observer_cli_plugin). -export([hierarchy/0, sheet/2]). hierarchy() - [#{id my_metrics, title My Metrics}]. sheet(my_metrics, _Node) - Data get_my_custom_metrics(), observer_cli_plugin:sheet([ #{title Custom Metrics, columns [ #{title Metric, width 20}, #{title Value, width 10} ], rows Data} ]).11. 性能优化与最佳实践在生产环境使用 observer_cli 时遵循这些最佳实践。11.1 资源使用优化observer_cli 本身很轻量但连接诊断时要注意诊断频率避免过高频率的自动诊断影响性能数据量控制使用--limit参数限制返回数据量超时设置为自动化脚本设置合理的超时时间11.2 安全配置建议网络隔离仅在可信网络中使用分布式连接Cookie 管理使用环境变量而非硬编码访问控制限制可连接节点的 IP 范围日志安全注意日志可能包含敏感信息11.3 监控策略设计建立有效的监控策略分层监控系统级、应用级、进程级分层采集基线建立记录正常状态下的指标基线告警阈值基于基线设置合理的告警阈值趋势分析关注指标的变化趋势而非绝对值12. 常见问题与排查方法问题现象可能原因排查方式解决方案连接被拒绝Cookie 不匹配或网络不通检查节点状态和 cookie验证 cookie 配置检查防火墙命令执行超时节点负载过高或网络延迟检查节点资源使用情况增加超时时间优化节点性能TUI 显示乱码终端编码不支持检查 TERM 环境变量设置export TERMxterm-256color内存信息不准确节点版本不兼容验证 OTP 版本兼容性升级到支持的 OTP 版本插件加载失败插件编译错误或版本不匹配检查插件依赖和编译日志重新编译插件检查版本兼容性12.1 连接问题深度排查# 1. 验证节点是否可访问 ping server-host # 2. 检查 Erlang 分布式连接 erl -sname test -setcookie MyCookie # 在 Erlang shell 中尝试连接 net_adm:ping(myappserver-host). # 3. 验证 observer_cli 配置 observer_cli status12.2 性能数据异常分析当发现性能指标异常时确认数据真实性多次采样验证趋势关联分析结合系统监控数据交叉验证根因分析从系统级到进程级逐层下钻影响评估确定问题对业务的影响程度13. 与传统图形界面对比observer_cli 与 Erlang 自带的 observer GUI 工具相比各有优势observer_cli 优势无需图形界面纯命令行操作适合远程服务器和自动化场景资源消耗更小输出格式标准化易于解析图形界面 observer 优势可视化更直观适合初学者实时刷新交互体验更好图表展示趋势更明显选择建议生产环境运维优先选择 observer_cli开发调试根据习惯选择两者都可自动化集成必须使用 observer_cli14. 实际案例诊断内存泄漏问题通过一个真实场景展示 observer_cli 的实际价值。14.1 问题现象应用运行一段时间后内存持续增长最终被 OOM Killer 终止。14.2 诊断步骤# 1. 连接问题节点 observer_cli connect --node problematicserver-host # 2. 运行全面诊断 observer_cli diagnose --format json diagnosis.json # 3. 分析内存排名 observer_cli inspect --type processes --sort memory --limit 1014.3 发现根本原因通过进程内存排名发现某个进程的消息队列堆积了大量消息进一步分析发现是消息处理逻辑存在缺陷导致消息无法被及时消费。14.4 解决方案修复消息处理逻辑增加流控机制问题得到解决。observer_cli 为 Erlang/Elixir 开发者提供了强大的命令行诊断能力特别适合生产环境运维和自动化场景。通过本文的实践指南你可以快速掌握其核心功能并将其应用到实际工作中。建议从连接本地开发环境开始练习逐步扩展到测试和生产环境的使用。
