Discord 机器人：启动与监控

Discord 机器人会与 Discord 网关保持一条持久 WebSocket 连接，因此需要一台持续在线的机器。它对资源的需求不高，但与 Telegram 机器人不同，它应对重启的能力更差：每次重启都会强制与网关建立一条新连接。

安装

useradd -r -m -d /srv/dbot -s /usr/sbin/nologin dbot
cd /srv/dbot && sudo -u dbot git clone https://github.com/you/bot.git .
sudo -u dbot npm ci --omit=dev
install -o dbot -g dbot -m 600 /dev/null /srv/dbot/.env

将令牌和 ID 写入 .env。来自 Discord Developer Portal 的令牌拥有机器人的完全访问权限——请像对待密码一样对待它。

对于 Python 库，流程相同，只是需要使用虚拟环境；参见 Python 应用。

服务

/etc/systemd/system/dbot.service：

[Unit]
Description=Discord bot
After=network-online.target
Wants=network-online.target

[Service]
User=dbot
WorkingDirectory=/srv/dbot
EnvironmentFile=/srv/dbot/.env
ExecStart=/usr/bin/node index.js
Restart=always
RestartSec=15
MemoryMax=512M
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now dbot

RestartSec=15 而非默认的五秒：当与网关的连接断开时，频繁重启会导致 Discord 方面临时封禁来自您服务器的连接。

MemoryMax 可以防止存在内存泄漏的机器人拖垮整台机器——在只有 2 GB 内存的 VDS-1 上尤其重要。

监控

systemctl status dbot
journalctl -u dbot -f
journalctl -u dbot --since today -p err
systemctl show dbot -p NRestarts

NRestarts 是最有用的指标：如果这个计数器每小时都在增长，说明机器人正在崩溃，而 Restart=always 掩盖了这一点。

查看某个具体服务的内存占用：

systemctl status dbot | grep Memory

如需了解整台机器的整体情况，请查看面板 /hosting/vds/m/<id> 中“概览”里的 CPU、内存和流量图表。

速率限制

Discord 会对 API 调用进行速率限制。迹象是日志中出现 429 错误以及命令“卡住”。以下措施有帮助：

• 不要在循环中不间断地发送消息；
• 编辑同一条消息，而不是发送新消息；
• 缓存参考数据，而不是在每个事件中都重新请求；
• 使用 Redis 队列进行批量广播。

更新

cd /srv/dbot
sudo -u dbot git pull
sudo -u dbot npm ci --omit=dev
systemctl restart dbot
journalctl -u dbot -n 50

最后一行是必须的：请确认机器人已连接到网关，而不是因为新的依赖项而崩溃。

常见错误

不要在 screen 或 tmux 中运行机器人。会话能在 SSH 断开后存活，但无法在机器重启后存活——而且一个月后您就会忘记它到底在哪里运行。