服务器监控的真相是：出事了你才知道。

凌晨三点网站挂了，你在睡觉。第二天打开手机，用户已经在骂了。然后你才开始排查：日志、负载、磁盘……一切都晚了。

传统方案是上监控系统：Prometheus + Grafana + Alertmanager，一套下来光配置就要折腾一晚上，还要养一个进程常驻。你只是个 1.5GB 内存的小 VPS，为个监控再吃掉几百兆，不值。

如果你已经在用 Hermes Agent，其实有个零成本的现成方案——它的 cron 任务支持一种 watchdog 模式：纯脚本执行，正常时完全静默，出问题才把报警消息推给你。

本文讲清楚这个机制，并给出磁盘、服务探活、SSL 证书、内存四个可以直接用的监控脚本。

一、先分清 cron 的两种模式

Hermes Agent 的定时任务（cronjob）有两种玩法：

LLM 模式（默认）：每个 tick 跑一次完整的 AI Agent。你可以让它每天九点总结昨天的日志、分析磁盘增长趋势、给你写一份简报。能干复杂的事，但每次执行都要花 token。

watchdog 模式（no_agent=true）：任务退化成纯脚本，LLM 完全不参与。脚本的 stdout 就是全部语义：

  • stdout 为空 → 一切正常，静默，什么都不发
  • stdout 非空 → 把输出原样投递给你
  • 脚本非零退出或超时 → 发错误警报

这套语义天生就是监控的：脚本只在异常时打印，正常时闭嘴。零 token 消耗，零噪音，相当于一个带消息推送的自定义 crontab。

二、watchdog 模式的正确用法

规则只有一条：正常不说话，异常才报警。

所以脚本的逻辑不是"报告状态"，而是"发现异常就 echo 一行"。写反了就会变成每天轰炸你几百条消息。

脚本放哪：Hermes home 下的 scripts/ 目录（Windows 是 %LOCALAPPDATA%\hermes\scripts\，Linux 是 ~/.hermes/scripts/）。脚本用 .sh/.bash 后缀走 bash 执行，其他后缀走 Python。

三、四个可以直接用的监控脚本

1. 磁盘空间

#!/usr/bin/env bash
# disk-watch.sh — 根分区使用率超阈值报警
THRESHOLD=80
usage=$(df -h / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
if [ "$usage" -ge "$THRESHOLD" ]; then
  echo "WARNING: 根分区已用 ${usage}% (阈值 ${THRESHOLD}%)"
fi

跑法：df -h / 取根分区，NR==2 跳过表头，去掉百分号后和阈值比。超了就 echo 一行，没超就什么都不输出——完美符合 watchdog 语义。

2. 服务探活

#!/usr/bin/env bash
# health-check.sh — HTTP 探活，挂了才报警
URL="https://your-site.example.com/"
if ! curl -fsS -o /dev/null --max-time 10 "$URL"; then
  echo "ALERT: $URL 不可达"
fi

-f 让 HTTP 4xx/5xx 也算失败，--max-time 10 防止 curl 卡死。把 URL 换成你自己的站点、API 或博客，每分钟或每五分钟跑一次，比任何监控系统都直接。

3. SSL 证书剩余天数

#!/usr/bin/env bash
# ssl-check.sh — 证书剩余不足 14 天报警
HOST="your-site.example.com"
PORT=443
enddate=$(echo | openssl s_client -servername "$HOST" -connect "$HOST:$PORT" 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -z "$enddate" ]; then
  echo "ALERT: $HOST 证书信息读取失败"
  exit 0
fi
expire=$(date -d "$enddate" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$enddate" +%s 2>/dev/null)
now=$(date +%s)
days=$(( (expire - now) / 86400 ))
if [ "$days" -lt 14 ]; then
  echo "ALERT: $HOST SSL 证书还剩 ${days} 天"
fi

证书过期是静默杀手——网站还开着，浏览器开始报大红叉，用户全跑了。这个脚本每天跑一次就行，date -d 兼容 GNU（Linux），date -j -f 兜底 BSD（macOS）。

4. 内存使用率

#!/usr/bin/env bash
# mem-watch.sh — 内存使用率超 90% 报警
mem=$(free -m | awk 'NR==2 {print int($3/$2*100)}')
if [ "$mem" -ge 90 ]; then
  echo "WARNING: 内存使用率 ${mem}%"
fi

低配 VPS 上 OOM 是家常便饭。这个脚本能在内存被打满之前给你留出抢救时间。

四、注册任务

脚本写好、chmod +x 之后，在 Hermes 会话里直接对 agent 说：

创建一个 watchdog 任务：每 30 分钟运行一次，脚本路径 ~/.hermes/scripts/disk-watch.sh，任务名叫「磁盘监控」。

agent 会通过 cronjob 工具创建。也可以用 CLI 命令管理：

hermes cron list          # 查看所有任务
hermes cron run <ID>      # 立即触发一次（测试用）
hermes cron pause <ID>    # 暂停
hermes cron resume <ID>   # 恢复
hermes cron remove <ID>   # 删除

调度格式很灵活：30m（每 30 分钟）、every 2h（每两小时）、0 9 * * *（每天九点）、every monday 9am（每周一）都可以。

五、进阶：LLM 模式的智能简报

watchdog 管"出事"，LLM 模式管"省心"。

同一个 cron 任务，不用脚本，直接用 prompt：

每天上午 9 点，检查 ~/logs/ 下昨天的 nginx 访问日志，汇总出：请求量变化、5xx 错误、值得注意的爬虫或攻击 IP，输出一份 10 行以内的中文简报。

每次 tick 都会跑一个完整的 agent，自动分析、总结、投递。代价是 token，但换来的是"打开手机就知道服务器昨晚发生了什么"。

还能串起来用：context_from 可以把任务 A 的脚本输出注入任务 B 的 prompt，让 watchdog 先收集数据、LLM 再分析，各干各擅长的。

六、注意事项

  • 先手动跑一遍脚本再注册任务：bash ~/.hermes/scripts/disk-watch.sh，确认输出符合预期。watchdog 不会给你调试的机会。
  • 单个任务有 3 分钟硬超时：脚本里避免长阻塞操作（比如 curl 必须带 --max-time）。
  • 任务调度有锁：同一时刻同一个任务不会重复执行，不用担心 tick 重叠。
  • 脚本退出码：非零退出会被当作错误处理并告警，所以脚本里"正常退出"一定 exit 0。
  • 别用 watch_patterns 干这活：那是给后台进程的，watchdog 模式才是定时监控的正确姿势。

监控这件事，90% 的服务器只需要"磁盘、探活、证书、内存"这四样。一套 Prometheus 是给几十台机器的，一台小鸡，四个脚本，够了。

我在自己的香港小 VPS 上就是这么干的：Zola 博客 + Kavita + nginx 全家桶挤在 1.5GB 内存里，没跑任何监控守护进程，全靠 Hermes 的 watchdog 盯着。它安静得你几乎忘了它存在——直到某天早上收到一条 ALERT。

The truth about server monitoring: you find out when things break.

Your site dies at 3 a.m. You're asleep. By morning, users are already complaining. Then the post-mortem begins: logs, load, disk… all too late.

The traditional answer is a full monitoring stack: Prometheus + Grafana + Alertmanager. A whole evening of configuration, a permanent resident process, and hundreds of megabytes eaten by the monitor itself. On a 1.5GB VPS, that's a bad trade.

If you already run Hermes Agent, there's a zero-cost option built in — its cron jobs support a watchdog mode: pure script execution, completely silent when healthy, and it only pushes you a message when something's wrong.

Here's how it works, plus four ready-to-use scripts for disk, service health, SSL expiry, and memory.

I: Two modes, get them straight

Hermes Agent's scheduled jobs (cronjob) come in two flavors:

LLM mode (default): a full AI Agent runs on every tick. It can summarize yesterday's logs at 9 a.m., analyze disk growth trends, and write you a briefing. Powerful, but every run costs tokens.

Watchdog mode (no_agent=true): the job degrades to a pure script. The LLM is not involved at all. The script's stdout is the entire protocol:

  • empty stdout → all good, silent, nothing delivered
  • non-empty stdout → the output is delivered verbatim
  • non-zero exit or timeout → error alert

That semantic is monitoring in a nutshell: print only on anomaly, shut up otherwise. Zero token cost, zero noise — a custom crontab with push notifications attached.

II: How to write a watchdog script

One rule: stay silent when healthy, shout when broken.

The script's job is not to report status — it's to echo a line when something's wrong. Write it backwards and you'll be paged hundreds of times a day.

Where scripts live: the scripts/ directory under your Hermes home (%LOCALAPPDATA%\hermes\scripts\ on Windows, ~/.hermes/scripts/ on Linux). .sh/.bash files run via bash; anything else runs via Python.

III: Four scripts you can use today

1. Disk space

#!/usr/bin/env bash
# disk-watch.sh — alert when root partition exceeds threshold
THRESHOLD=80
usage=$(df -h / | awk 'NR==2 {gsub(/%/,"",$5); print $5}')
if [ "$usage" -ge "$THRESHOLD" ]; then
  echo "WARNING: root partition at ${usage}% (threshold ${THRESHOLD}%)"
fi

df -h / grabs the root partition, NR==2 skips the header, the percent sign is stripped before the numeric comparison. Over the threshold it echoes one line; under it, nothing — exactly the watchdog contract.

2. Service health

#!/usr/bin/env bash
# health-check.sh — alert when HTTP probe fails
URL="https://your-site.example.com/"
if ! curl -fsS -o /dev/null --max-time 10 "$URL"; then
  echo "ALERT: $URL unreachable"
fi

-f makes 4xx/5xx count as failures, --max-time 10 keeps curl from hanging forever. Swap in your site, API, or blog and run it every minute or five — more direct than any monitoring platform.

3. SSL certificate days left

#!/usr/bin/env bash
# ssl-check.sh — alert when cert has fewer than 14 days left
HOST="your-site.example.com"
PORT=443
enddate=$(echo | openssl s_client -servername "$HOST" -connect "$HOST:$PORT" 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -z "$enddate" ]; then
  echo "ALERT: $HOST cert info read failed"
  exit 0
fi
expire=$(date -d "$enddate" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$enddate" +%s 2>/dev/null)
now=$(date +%s)
days=$(( (expire - now) / 86400 ))
if [ "$days" -lt 14 ]; then
  echo "ALERT: $HOST SSL cert expires in ${days} days"
fi

Cert expiry is a silent killer — the site stays up, browsers start showing the red screen, users leave. Run this daily. date -d handles GNU (Linux), date -j -f is the BSD (macOS) fallback.

4. Memory usage

#!/usr/bin/env bash
# mem-watch.sh — alert when memory exceeds 90%
mem=$(free -m | awk 'NR==2 {print int($3/$2*100)}')
if [ "$mem" -ge 90 ]; then
  echo "WARNING: memory at ${mem}%"
fi

OOM is routine on low-end VPSs. This one buys you time before the box starts swapping itself to death.

IV: Registering the job

After writing the script and chmod +x it, just tell the agent in a Hermes session:

Create a watchdog job: run every 30 minutes, script path ~/.hermes/scripts/disk-watch.sh, name it "disk watch".

The agent creates it via the cronjob tool. Or manage everything from the CLI:

hermes cron list          # list all jobs
hermes cron run <ID>      # trigger once immediately (testing)
hermes cron pause <ID>    # pause
hermes cron resume <ID>   # resume
hermes cron remove <ID>   # delete

Schedule formats are flexible: 30m, every 2h, 0 9 * * *, every monday 9am.

V: Advanced — LLM-mode briefings

Watchdog covers "it broke." LLM mode covers "I don't want to look."

Same cron mechanism, no script, just a prompt:

Every day at 9 a.m., check yesterday's nginx access logs in ~/logs/, summarize request volume changes, 5xx errors, and notable crawlers or attack IPs. Output a Chinese briefing under 10 lines.

Each tick runs a full agent that analyzes, summarizes, and delivers. The cost is tokens; the payoff is "I know what happened on the server last night just by glancing at my phone."

You can even chain jobs: context_from injects job A's script output into job B's prompt — watchdog collects, LLM interprets, each doing what it's good at.

VI: Notes

  • Run the script manually first (bash ~/.hermes/scripts/disk-watch.sh) and confirm the output. Watchdog mode gives you no debugging window.
  • Each job has a 3-minute hard timeout: avoid long blocking operations in scripts (curl must always carry --max-time).
  • Ticks are locked: the same job never runs twice concurrently.
  • Exit codes matter: non-zero exit is treated as an error and alerts. Normal runs must exit 0.
  • Don't use watch_patterns for this: that's for long-lived background processes. Watchdog mode is the right tool for scheduled monitoring.

90% of servers need only four checks: disk, health, cert, memory. A Prometheus stack is for fifty machines. One small VPS? Four scripts are enough.

That's exactly how my Hong Kong VPS runs: a Zola blog, Kavita, and nginx squeezed into 1.5GB of RAM, no monitoring daemon at all — just Hermes watchdogs. They're so quiet you forget they exist. Until one morning an ALERT arrives.