哪吒探针 - 跨平台agent部署实战指南（Windows/Linux双环境）
1. 环境准备与核心概念扫盲
如果你手头既有Windows服务器跑着业务，又有几台Linux机器在吭哧吭哧干活，想把它们的状态都集中在一个漂亮的仪表盘上看得一清二楚，那哪吒探针绝对是你的菜。我自己管理着十几台混合环境的服务器，从Windows Server到各种Linux发行版都有，之前东一个监控西一个日志，看得人头大。自从用上哪吒探针，所有机器的CPU、内存、磁盘、网络流量，甚至上面跑的服务状态，都能在一个Web页面上实时看到，那种掌控感别提多爽了。
简单来说，哪吒探针就是一个开源、轻量级的服务器监控工具。它分为两部分：服务端（Dashboard）和客户端（Agent）。服务端就是你搭建的那个监控面板，用来展示数据；客户端就是需要安装在你每台待监控服务器上的小程序，负责采集数据并上报。我们今天要折腾的，就是怎么在Windows和Linux这两种截然不同的系统上，把这个Agent给稳稳当当地装好、跑起来。
在开始动手之前，你得先准备好几样东西。首先，你需要一个已经搭建好的哪吒探针服务端。如果你还没有，可以去项目主页看看一键安装脚本，通常一条命令就能在Linux VPS上装好。这里假设你已经有了服务端的IP地址和端口，以及添加主机时生成的唯一Agent密钥。其次，根据操作系统下载对应的Agent程序。对于Windows，你需要两个文件：哪吒的Windows版Agent（通常是一个nezha-agent.exe）和一个叫NSSM的工具。对于Linux，就简单多了，直接下载对应架构（比如x86_64、arm64）的二进制文件就行。
注意：Agent密钥是每台服务器和服务端之间的“接头暗号”，千万不能泄露，也一定要填对，否则数据无法上报。
为什么Windows需要NSSM？这是因为Windows的服务管理不像Linux的systemd那么原生和方便。NSSM（the Non-Sucking Service Manager）是一个第三方工具，它可以把任何普通的命令行程序包装成Windows系统服务，这样Agent就能开机自启、后台稳定运行，不会因为你退出命令行窗口而关闭。这是Windows部署里非常关键的一步。
2. Windows环境详细部署与避坑指南
给Windows服务器装Agent，感觉像是在跟一个脾气有点倔但讲道理的朋友打交道。步骤不算复杂，但细节决定成败，一步错了可能就卡半天。下面我就把完整的流程和踩过的坑都给你捋清楚。
2.1 软件下载与环境变量配置
首先，去哪吒探针的GitHub Release页面，找到名字里带windows字样的压缩包，比如nezha-agent_windows_amd64.zip，把它下载到你的Windows服务器上。同时，去NSSM的官网下载它的Windows版本，建议下载最新的稳定版。下载完成后，分别解压。我个人的习惯是在C:盘根目录下新建一个Programs文件夹，然后把nezha-agent.exe和NSSM的整个文件夹（比如nssm-2.24）都放进去。这样路径清晰，不容易乱。
接下来是配置环境变量，这一步是为了让系统在任何位置都能识别nssm这个命令。按下Win + R，输入sysdm.cpl，回车打开“系统属性”。点击“高级”选项卡，再点击“环境变量”。在下面的“系统变量”框里，找到并选中Path变量，点击“编辑”。然后点击“新建”，把NSSM可执行文件所在的完整路径添加进去，比如C:\Programs\nssm-2.24\win64（根据你实际解压的路径和系统位数选择32位或64位目录）。最后一路点击“确定”关闭所有窗口。
这里有个小坑：在Win10及更新版本的系统里，添加Path变量时是纵向列表的形式，直接新建一行填入即可。而在一些老版本如Windows Server 2008 R2上，Path变量值是在一个文本框里，用英文分号
;隔开的多个路径。你需要把NSSM的路径追加到最后，确保前面有一个分号分隔，比如;C:\Programs\nssm-2.24\win64。
2.2 使用NSSM安装并配置Agent服务
环境变量配好后，我们需要用管理员权限来操作。在开始菜单搜索“cmd”，找到“命令提示符”，右键选择“以管理员身份运行”。这是必须的，否则安装系统服务时会权限不足。
在打开的管理员命令行中，首先可以输入nssm并回车，如果出现NSSM的帮助信息，说明环境变量配置成功了。接下来，我们安装服务。输入以下命令：
nssm install nezha-agent这里的nezha-agent是服务的名称，你可以自定义，比如改成MyServer-Monitor也行，方便识别。
命令执行后，会弹出一个NSSM的图形化设置窗口。这个窗口虽然简单，但每个标签页都很重要：
- Application标签页：
Path：点击Browse，找到你之前放置的nezha-agent.exe文件。Startup directory：通常会自动填充为nezha-agent.exe所在的目录，保持默认即可。Arguments：这是最核心的部分，需要填入连接服务端的参数。格式如下：
例如：-s 你的服务端IP:端口 -p 你的Agent密钥-s 192.168.1.100:5555 -p k1jH8fG23dL9pQwE。切记，参数里没有花括号{}，直接替换成你自己的真实IP和密钥。
- Details标签页：可以修改服务的显示名称（Display name）和描述（Description），方便在Windows服务管理器中识别，比如改成“哪吒探针监控代理”。
- Log on标签页：非常重要！为了确保服务有足够的权限访问系统性能计数器等资源，建议将运行身份设置为“本地系统账户”。如果Agent需要访问特定用户目录下的资源，则可以指定一个具有相应权限的用户账户。
所有设置检查无误后，点击窗口下方的Install service按钮。如果成功，命令行窗口会提示服务安装成功。
2.3 服务管理、测试与常见故障排查
服务安装好后，它并不会自动启动。我们回到管理员命令行，输入命令启动它：
nssm start nezha-agent如果想停止或重启服务，对应的命令是nssm stop nezha-agent和nssm restart nezha-agent。
如何验证是否成功呢？首先，你可以打开“任务管理器”，切换到“服务”标签页，找到你命名的服务（如nezha-agent），查看其状态是否为“正在运行”。更直接的方法是，回到你的哪吒探针服务端Web面板，刷新页面，看看对应的主机是否已经“上线”，并且开始有数据（CPU、内存等）刷新。
如果面板上没有显示上线，或者服务启动后立刻停止，别慌，这是排查问题的开始。我们可以查看服务的输出来定位问题。在管理员命令行中运行：
nssm status nezha-agent或者更详细地，使用NSSM的日志功能。在刚才的NSSM设置窗口的Log on标签页，可以配置标准输出和错误输出的日志文件路径。配置好后重启服务，然后去查看日志文件，里面通常会有连接失败的具体原因。
我遇到最多的几个坑是：
- 参数错误：
-s或-p写错了，多一个空格、少一个字母，或者IP地址、端口不对。一定要仔细核对。 - 防火墙阻拦：Windows防火墙或者云服务商的安全组规则，没有放行Agent到服务端指定端口（如5555）的出站连接。需要在防火墙高级设置中添加入站规则，或者在云控制台安全组里添加一条出站规则，允许目标端口。
- 路径或权限问题：
nezha-agent.exe所在的路径含有中文或特殊字符，或者运行服务的账户没有该目录的读取执行权限。尽量使用英文路径，并用系统账户运行。 - NSSM版本与系统不兼容：尝试下载不同版本的NSSM，或者确保下载的是对应你系统位数（32位或64位）的版本。
3. Linux环境部署与守护进程配置
相比Windows，在Linux上部署哪吒Agent可以说是行云流水，非常符合运维人员的操作习惯。整个过程基本上就是在和终端打交道，效率很高。不过，不同的Linux发行版在服务管理上略有差异，我们主要以最常见的Systemd为例，也会提及其他方法。
3.1 二进制文件部署与基础运行
首先，通过SSH连接到你的Linux服务器。确定你的系统架构，通常是x86_64（也叫amd64）或aarch64（arm64）。使用uname -m命令可以查看。然后去GitHub Release页面下载对应的Linux版本，例如nezha-agent_linux_amd64.zip。
我习惯将这类自管理的软件放在/opt目录下。执行以下命令来完成部署：
# 创建哪吒Agent的专属目录 sudo mkdir -p /opt/nezha/agent # 进入该目录（假设你已经把下载的压缩包上传到了服务器，比如在用户家目录） cd /opt/nezha/agent # 解压下载的文件（以amd64的tar.gz为例） sudo tar -zxvf ~/nezha-agent_linux_amd64.tar.gz # 授予可执行权限 sudo chmod +x nezha-agent现在，你可以直接运行Agent来测试连接了：
sudo ./nezha-agent -s 你的服务端IP:端口 -p 你的Agent密钥如果一切正常，终端会显示一些连接日志，并且你的服务端面板上应该能看到这台主机上线。但是，这样是前台运行，一旦你关闭SSH会话，进程就终止了。所以我们必须让它后台运行。
3.2 使用Systemd配置开机自启与守护
在Linux世界，Systemd是现代化发行版的标准服务管理器。用它来管理Agent服务是最规范、最可靠的方式。
我们需要创建一个Systemd的服务单元文件。使用vim或nano编辑器：
sudo vi /etc/systemd/system/nezha-agent.service将以下配置内容粘贴进去，并务必修改-s和-p参数为你自己的值：
[Unit] Description=Nezha Agent After=network.target # 如果服务端是域名，可能需要等待网络和DNS解析完全就绪，可以改为 After=network-online.target # 并运行：sudo systemctl enable systemd-networkd-wait-online.service [Service] Type=simple User=root Group=root WorkingDirectory=/opt/nezha/agent ExecStart=/opt/nezha/agent/nezha-agent -s 192.168.1.100:5555 -p k1jH8fG23dL9pQwE Restart=on-failure RestartSec=10 # 可选：设置环境变量，例如调试模式 # Environment=DEBUG=true # 可选：资源限制 # LimitNOFILE=65535 [Install] WantedBy=multi-user.target这个配置文件做了几件事：定义了服务描述；指定在网络就绪后启动；以root用户运行（根据安全需要，可以创建专用用户）；设置工作目录和启动命令；最重要的是Restart=on-failure，它会在Agent进程异常退出时自动重启，保障监控不间断；RestartSec=10表示重启前等待10秒。
保存退出后，依次执行以下命令：
# 重新加载Systemd配置，使其识别新服务 sudo systemctl daemon-reload # 设置开机自启 sudo systemctl enable nezha-agent.service # 立即启动服务 sudo systemctl start nezha-agent.service # 查看服务状态和日志，这是最重要的排查命令 sudo systemctl status nezha-agent.service # 持续查看日志输出 sudo journalctl -u nezha-agent.service -f执行status命令后，如果看到绿色的active (running)字样，就大功告成了。journalctl命令可以实时滚动显示服务的日志，对于调试连接问题非常有用。
3.3 针对不同Linux环境的备选方案
虽然Systemd是主流，但也会遇到一些特殊情况。比如，你管理的是一台旧版的CentOS 6或者Debian 7，它们使用SysVinit。或者你只是想快速测试，不想配置服务。这里有几个备选方案。
方案一：使用nohup &（临时后台运行）这是一个快速测试的权宜之计，不适合生产环境。
cd /opt/nezha/agent nohup sudo ./nezha-agent -s 你的服务端IP:端口 -p 你的Agent密钥 > nezha.log 2>&1 &命令解释：nohup让进程忽略挂断信号；> nezha.log将标准输出重定向到日志文件；2>&1将标准错误也重定向到标准输出（即同一个日志文件）；最后的&放入后台。你可以用tail -f nezha.log查看日志。
方案二：使用Supervisor进程管理如果你不喜欢Systemd，或者环境里没有，Supervisor是一个强大的替代品。首先安装它（以Ubuntu为例）：
sudo apt-get install supervisor然后创建一个配置文件：
sudo vi /etc/supervisor/conf.d/nezha-agent.conf内容如下：
[program:nezha-agent] directory=/opt/nezha/agent command=/opt/nezha/agent/nezha-agent -s 你的服务端IP:端口 -p 你的Agent密钥 autostart=true autorestart=true user=root redirect_stderr=true stdout_logfile=/var/log/nezha-agent.log保存后，更新Supervisor并启动：
sudo supervisorctl reread sudo supervisorctl update sudo supervisorctl start nezha-agent4. 双平台统一管理与高级技巧
当你的Windows和Linux服务器都成功接入哪吒探针后，真正的乐趣就开始了——在一个统一的平台上管理它们。但这不仅仅是看着数据，如何高效地利用这些信息，以及处理一些棘手的跨平台问题，才是提升运维效率的关键。
4.1 面板功能详解与告警配置
哪吒的面板非常直观。主面板以卡片形式展示所有服务器，绿色代表在线，红色代表离线。点击任意卡片可以进入详情页，看到更丰富的实时数据图表，包括CPU、内存、磁盘IO、网络流量（区分上传下载）的实时曲线和历史趋势。这对于排查性能瓶颈特别有用，比如你可以快速定位到某天下午3点CPU飙升的机器。
另一个核心功能是服务监控。你可以在服务端面板上，为每台服务器添加需要监控的服务进程或端口。例如，监控Nginx的80端口、MySQL的3306端口，或者一个具体的进程名java。一旦端口无法连接或进程消失，面板上该服务的状态就会变红，并可以触发告警。
告警配置是让监控系统从“被动查看”变为“主动通知”的灵魂。哪吒支持通过多种方式发送告警，我最常用的是Telegram Bot和微信（通过Server酱等通道）。配置路径通常在面板的“设置”或“报警”页面。你需要设置告警规则，比如：当服务器离线超过1分钟时告警；当CPU使用率连续5分钟超过90%时告警；当磁盘使用率超过85%时告警。合理设置阈值可以避免告警泛滥，又能及时抓住真正的问题。
4.2 跨平台运维的痛点与解决方案
管理异构环境时，总会遇到一些平台差异带来的小麻烦。这里分享几个我总结的经验。
问题一：监控数据差异的理解Windows和Linux在系统指标统计上有些许不同。例如，Linux的top命令和Windows任务管理器计算内存使用率的算法可能不同，哪吒Agent会适配各自系统的原生API来获取数据。所以，当你看到一台Windows服务器和一台配置相似的Linux服务器内存使用率百分比有差异时，不必过于惊讶，可以点开详情看具体的已用内存和总内存数值进行对比。
问题二：Agent更新与维护当哪吒发布新版本Agent时，你需要批量更新。对于Linux，可以写一个简单的Shell脚本，通过SSH批量登录服务器，执行下载、替换、重启服务的操作。对于Windows，如果没有统一的配置管理工具（如Ansible、SaltStack），手动更新会比较麻烦。一个取巧的办法是，在最初安装时，可以将Agent文件放在一个网络共享路径或内部Web服务器上，然后在NSSM的启动参数里直接指向这个网络路径的可执行文件。这样更新时只需替换中心位置的文件，并远程重启各服务器的服务即可。但这要求网络稳定，且服务器能访问该路径。
问题三：防火墙与网络策略的统一管理这是导致Agent离线最常见的原因。你必须确保所有服务器上的出站规则允许连接到服务端的端口（默认5555）。在云环境下，安全组规则同样需要配置。建议在运维手册中，将“开放对监控服务器IP:5555端口的出站连接”作为服务器初始化的一项标准步骤。
问题四：Agent资源占用监控监控程序本身也会消耗资源。哪吒Agent非常轻量，通常只占用几十MB内存和极少的CPU。但你仍然可以在面板上监控它自己。一个有趣的做法是，在Linux上，你可以添加一个监控项，检查nezha-agent这个进程是否存在；在Windows上，可以监控nezha-agent.exe进程。这样，万一Agent自己挂了，你也能收到告警——虽然这有点“我监控我自己”的递归意味，但对于核心监控系统来说，很有必要。
4.3 安全加固与最佳实践建议
把Agent部署到所有服务器上，意味着它拥有一定的系统访问权限。安全不容忽视。
- 最小权限原则：在Linux上，可以考虑创建一个专用的系统用户（如
nezha-agent）来运行Agent服务，而不是直接使用root。修改Systemd服务文件中的User和Group字段。确保这个用户只有读取系统统计信息（如/proc、/sys下文件）的必要权限。在Windows上，使用“本地系统账户”已经相对安全，如果环境允许，也可以创建一个权限受限的域用户或本地用户。 - 密钥管理：Agent密钥相当于密码。不要在命令行历史、脚本文件或版本控制系统中明文留存。在Linux中，可以考虑将密钥放在一个权限为600的配置文件中，让Agent通过环境变量或配置文件读取。虽然哪吒Agent目前主要支持命令行参数，但你可以通过编写一个简单的包装脚本来实现。
- 服务端安全：你的哪吒面板服务端本身也需要保护。务必使用强密码，启用HTTPS（可以通过Nginx反向代理配置SSL证书），并考虑设置IP白名单或基础的身份验证，防止面板被公网随意访问。
- 日志审计：定期查看Agent和服务端的日志。Linux的日志在
journalctl里，Windows的日志可以通过NSSM配置输出到文件。分析日志可以帮助你发现异常的连接尝试或自身运行问题。 - 备份配置：对于Linux的Systemd服务文件、Windows的NSSM服务配置，以及哪吒面板上的服务器列表、告警规则，建议定期备份。在重建面板或批量部署新服务器时，这些备份能节省大量时间。
最后，技术工具是死的，运维思路是活的。哪吒探针给了我们清晰的视野，但更重要的是根据告警和数据趋势去主动优化系统。比如，看到某台服务器磁盘使用率每周增长5%，就应该提前规划清理或扩容，而不是等到收到磁盘爆满的告警才手忙脚乱。把监控当成一个活的系统健康仪表盘，而不仅仅是故障报警器，这才是运维监控的价值所在。