如果你正在开发或运维 Erlang/Elixir 应用，observer_cli 绝对是一个值得立刻加入工具箱的命令行诊断利器。这个由 zhongwencool 开源的项目专门为 BEAM 虚拟机（Erlang/Elixir 运行时）设计，让你无需图形界面就能实时监控生产环境节点的运行状态。

observer_cli 最核心的价值在于：它提供了两种明确的诊断接口。CLI 命令行工具适合自动化场景和 AI 工作流，能够输出稳定的文本、Erlang 项式或 JSON 格式数据；TUI 终端界面则提供交互式探索能力，让你像使用图形化 observer 一样在终端里查看进程、内存、调度器等详细信息。

本文会带你完成 observer_cli 的完整部署和使用流程，重点演示如何通过命令行监控 OTP 监督树和进程状态，以及如何将诊断能力集成到自动化运维流程中。

1. 核心能力速览

2. 适用场景与使用边界

observer_cli 主要面向以下几类用户：

Erlang/Elixir 开发人员：在开发过程中实时查看应用进程状态，调试监督树结构，分析内存泄漏问题。

DevOps 运维工程师：在生产环境监控 BEAM 节点健康状态，快速诊断性能瓶颈，收集故障时的系统快照。

自动化脚本和 AI Agent：通过 JSON 输出接口集成到监控系统，实现定时诊断和告警触发。

不适合的场景包括：

• 需要图形化界面的深度性能分析（此时应使用原生 observer）
• 非 BEAM 虚拟机的监控需求
• 需要长期持续连接监控（observer_cli 采用短连接设计）

安全边界：observer_cli 通过 Erlang 分布式协议连接节点，需要节点间的 cookie 认证。务必只在可信网络环境下使用，distribution cookie 不是只读凭证，具有完整的节点访问权限。

3. 环境准备与前置条件

在开始安装 observer_cli 之前，需要确保环境满足以下要求：

操作系统要求：

• Linux (Ubuntu/CentOS 等主流发行版)
• macOS
• 理论上支持 Windows，但建议在 WSL2 环境下运行

Erlang/OTP 版本：

• 最低要求：OTP 26.0+
• 推荐版本：OTP 29.x（最新稳定版）
• JSON 输出功能需要 OTP 27.0+

依赖工具：

• curl（用于安装脚本）
• git（源码安装时需要）
• rebar3 或 mix（根据项目构建工具选择）

网络要求：

• 能够访问 GitHub 下载发布包
• 节点间网络互通（用于连接远程 BEAM 节点）

权限要求：

• 对目标监控节点具有 distribution cookie
• 本地安装目录的写入权限

4. 安装部署与启动方式

observer_cli 提供多种安装方式，推荐使用 GitHub Release 的自动安装脚本。

4.1 一键安装（推荐）

对于 macOS 或 Linux 系统，最简单的安装方式是使用官方安装脚本：

# 安装最新稳定版（2.0.0） curl -fsSL https://raw.githubusercontent.com/zhongwencool/observer_cli/v2.0.0/install.sh | sh

安装脚本会自动检测本地 OTP 主版本，下载对应的预构建 escript，并安装到$HOME/.local/bin目录。如果该目录不在 PATH 中，安装脚本会提示你添加：

# 将以下内容添加到 ~/.bashrc 或 ~/.zshrc export PATH="$HOME/.local/bin:$PATH" source ~/.bashrc # 或 source ~/.zshrc

验证安装是否成功：

observer_cli --version

4.2 源码编译安装

如果需要自定义构建或使用特定版本，可以从源码编译：

# 克隆指定版本源码 VERSION=2.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/

4.3 项目依赖集成

如果需要在 Erlang 项目中直接使用 observer_cli，可以将其添加为依赖：

Erlang 项目（rebar.config）：

{deps, [ {observer_cli, "2.0.0"} ]}.

然后编译：

rebar3 compile

Elixir 项目（mix.exs）：

defp deps do [ {:observer_cli, "2.0.0"} ] end

然后编译：

mix deps.get mix compile

5. 功能测试与效果验证

安装完成后，我们通过实际示例验证 observer_cli 的核心功能。

5.1 连接目标节点

首先需要设置目标节点的 cookie 并建立连接：

# 设置环境变量（避免在命令行中暴露 cookie） export OBSERVER_CLI_COOKIE='your_node_cookie_here' # 连接目标节点 observer_cli connect \ --node myapp@server-host \ --cookie-env OBSERVER_CLI_COOKIE

连接成功后，可以测试基本状态检查：

# 检查节点状态 observer_cli status # 运行完整诊断 observer_cli diagnose

5.2 TUI 交互式监控

对于交互式探索，启动 TUI 模式：

observer_cli tui myapp@server-host

TUI 启动后，你会看到类似下面的终端界面：

Observer CLI v2.0.0 - Connected to myapp@server-host Press 'h' for help, 'q' to quit System Overview: Memory: 128MB used, 512MB total Processes: 245 active, 1000 max CPU: 15% usage, 4 schedulers

TUI 主要功能页面：

• 系统概览：内存、进程数、CPU 使用率等整体指标
• 进程列表：按内存、消息队列大小等排序的进程列表
• 应用监控：各 OTP 应用的状态和资源使用
• ETS 表：ETS 表的详细信息和内存占用
• 监督树：图形化展示监督树结构（重点功能）
• 端口监控：外部端口和 NIF 的状态

5.3 监督树可视化验证

监督树查看是 observer_cli 的核心功能之一。在 TUI 界面中：

1. 按s键进入监督树页面
2. 使用方向键导航树形结构
3. 按Enter键展开/折叠子树
4. 观察进程状态（running、waiting、suspended 等）

典型的监督树显示效果：

sup_root ├── worker_1 (running, pid=<0.123.0>) ├── supervisor_1 │ ├── worker_2 (running, pid=<0.124.0>) │ └── worker_3 (waiting, pid=<0.125.0>) └── gen_server_1 (running, pid=<0.126.0>)

5.4 进程详细监控

在进程列表页面（按p键），可以查看：

• 进程 PID 和注册名
• 当前函数和执行状态
• 内存占用（堆大小、二进制数据等）
• 消息队列长度
• 减少次数（reductions）

这对于识别有问题的进程特别有用，比如消息队列积压或内存异常增长的进程。

6. 接口 API 与批量任务

observer_cli 的 CLI 模式非常适合自动化集成，特别是 JSON 输出功能。

6.1 JSON 输出示例

在 OTP 27+ 环境中，可以获取机器可读的诊断数据：

# 获取 JSON 格式的系统状态 observer_cli status --format json # 完整诊断输出 observer_cli diagnose --format json > diagnostic_report.json

JSON 输出示例：

{ "version": "2.0.0", "node": "myapp@server-host", "timestamp": "2024-01-15T10:30:00Z", "system": { "memory_total": 536870912, "memory_used": 134217728, "process_count": 245, "run_queue": 2 }, "status": "healthy" }

6.2 自动化监控脚本

可以编写 shell 脚本实现定时监控：

#!/bin/bash # monitor_beam_node.sh NODE="myapp@server-host" COOKIE="your_cookie" LOG_FILE="/var/log/beam_monitor.log" # 运行诊断并记录结果 observer_cli connect --node $NODE --cookie $COOKIE observer_cli diagnose --format json >> $LOG_FILE observer_cli disconnect # 检查关键指标 if grep -q "\"run_queue\": [5-9]" $LOG_FILE; then echo "警告: 运行队列过高" | mail -s "BEAM 节点告警" admin@company.com fi

6.3 批量节点监控

对于多节点环境，可以编写批量检查脚本：

#!/bin/bash # batch_monitor.sh NODES=("app1@host1" "app2@host2" "app3@host3") COOKIE="shared_cookie" for node in "${NODES[@]}"; do echo "检查节点: $node" observer_cli connect --node $node --cookie $COOKIE observer_cli status observer_cli disconnect echo "----------------------------------------" done

7. 资源占用与性能观察

observer_cli 本身设计为轻量级工具，对目标节点影响极小。

7.1 资源占用特点

内存占用：observer_cli 进程本身占用约 10-30MB 内存，诊断过程中会在目标节点创建临时进程执行数据收集，完成后立即清理。

CPU 影响：数据收集操作是短时间的，通常持续几秒到几十秒，取决于系统规模。TUI 模式的持续监控会有定期轮询，但间隔可配置。

网络流量：通过 Erlang 分布协议通信，数据经过压缩，流量较小。一次完整的诊断通常在几百KB到几MB之间。

7.2 性能优化建议

调整轮询间隔：在 TUI 模式中，默认刷新间隔为 1 秒。对于大型系统可以适当延长：

# 每 5 秒刷新一次 observer_cli tui myapp@server-host --interval 5000

选择性监控：如果只关心特定指标，使用 CLI 模式执行针对性检查，而不是完整的诊断：

# 只检查内存使用 observer_cli connect --node myapp@server-host observer_cli eval "erlang:memory()." observer_cli disconnect

避免高频监控：在生产环境中，避免设置过短的监控间隔，通常 30 秒到 5 分钟的间隔是合理的。

8. 常见问题与排查方法

8.1 典型错误处理

节点连接问题：

# 错误信息：Connection failed to myapp@server-host # 排查步骤： 1. 确认节点正在运行：ping 目标主机，检查 Erlang 节点进程 2. 验证 cookie：确保本地和目标节点使用相同的 cookie 3. 检查防火墙：确认 EPMD 端口（4369）和节点间端口通畅

权限不足问题：

# 错误信息：Permission denied when reading system info # 解决方案： # 确保目标节点以允许监控的模式启动 erl -name myapp@server-host -setcookie mycookie +Mea max

版本兼容性问题：

# 错误信息：Function clause error # 排查：检查 observer_cli 版本与目标节点 Erlang 版本兼容性 # observer_cli 2.0.0 需要 OTP 26-29，确保版本匹配

9. 最佳实践与使用建议

9.1 生产环境部署建议

安全配置：

• 使用专用的监控 cookie，与业务 cookie 分离
• 通过防火墙限制监控网络的访问
• 定期轮换监控凭证

监控策略：

• 关键指标基线化：记录正常状态下的指标范围
• 设置合理的告警阈值（如消息队列长度 > 1000）
• 保留历史诊断数据用于趋势分析

集成方案：

• 将 JSON 输出集成到 Prometheus + Grafana 监控栈
• 通过 Webhook 将告警发送到 Slack/Teams 等协作工具
• 定期生成健康报告发送给运维团队

9.2 开发环境使用技巧

调试监督树：

# 重点关注监督树的结构变化 observer_cli tui dev@localhost # 按 's' 进入监督树页面，观察应用启动过程中的树形结构变化

内存泄漏排查：

# 定期检查进程内存增长 observer_cli connect --node dev@localhost observer_cli eval "observer_cli_probe:process_count()." # 对比多次检查结果，识别异常增长模式

性能瓶颈分析：

# 检查调度器负载和运行队列 observer_cli connect --node dev@localhost observer_cli eval "erlang:statistics(run_queue)."

9.3 自动化运维集成

CI/CD 集成：在部署后自动运行健康检查

#!/bin/bash # post_deploy_check.sh observer_cli connect --node $DEPLOYED_NODE if observer_cli diagnose | grep -q "status.*healthy"; then echo "部署后检查通过" exit 0 else echo "部署后检查失败" exit 1 fi

定时监控任务：通过 crontab 设置定期检查

# 每 5 分钟检查一次 */5 * * * * /home/user/scripts/beam_health_check.sh

10. 总结与下一步

observer_cli 作为 BEAM 生态中的命令行诊断工具，填补了生产环境无图形界面监控的空白。其最大的优势在于既能满足交互式探索需求（TUI 模式），又能很好地支持自动化运维（CLI + JSON 输出）。

在实际使用中，建议首先掌握监督树查看和进程监控这两个核心功能，这是诊断 Erlang/Elixir 应用问题最常用的手段。然后根据实际需求逐步深入内存分析、调度器监控等高级功能。

对于运维团队，将 observer_cli 集成到现有的监控体系中，可以显著提升 BEAM 应用的可观测性。特别是 JSON 输出功能，为构建自定义的监控面板和告警系统提供了便利。

下一步可以探索的方向包括：

• 与 Prometheus 监控栈的深度集成
• 基于历史数据的异常检测算法
• 多节点集群的统一监控视图
• 与 APM 工具（如 AppSignal、DataDog）的协同使用

observer_cli 的文档和社区资源相当丰富，遇到问题时可以查阅 GitHub 项目的 Issue 和 Discussion 区域，或者参考 Erlang/Elixir 相关的技术论坛。