日本VPS监控怎么配

一、日本VPS监控到底要监控哪些指标

监控不是装个工具就完事，监控什么、为什么监控这个指标，决定了它能不能在出事那天真的救你。

第一层：机器还活着吗。这是最基础的存活探针，包括机器能否 ping 通、SSH 端口是否响应、系统是否还在运行。外部探针做这个，因为机器内部的监控在机器挂掉时也会一起死。

# 本机看系统运行时间与负载
uptime
# 三个负载值分别是 1 分钟、5 分钟、15 分钟的平均任务数

第二层：资源用了多少。CPU、内存、磁盘、磁盘 inode、负载。这四项是判断「要不要被扩容或被杀」的核心。内存看的不只是 used，要看 available；磁盘看的不只是容量，要看 inode——一个装了几十万小文件的目录，容量还有一半但 inode 用完了，一样写不进去。

free -m          # 看 available 那一列
df -h           # 容量
df -i           # inode，这个最常被忽略

第三层：服务还正常吗。这是最贴近业务的一层：网站返回 200 还是 500、接口的响应时间、证书还有多少天过期。这一层不能只看端口通不通——端口通但应用返回 500，端口监控完全看不出问题。

第四层：外部世界怎么看得到你。从外部网络测你的站点首字节时间和完整加载时间。这一层能发现一类内部监控发现不了的问题：回程线路劣化、DNS 解析到了错误的节点、CDN 缓存配置错误。

zenlayer 官网机型与实时报价

优先级排序很清楚：先做第三层（业务可用性）和第四层（外部可用性），再做第一层和第二层。因为业务挂了而 CPU 正常，和 CPU 100% 但业务正常，处理的紧急程度完全不同。资源类指标是「预防性」的，业务可用性是「即时」的。

二、监控装在机器内部还是外部，这是第一个分岔

两种方式不是二选一，是必须都有，但职责不同。

内部监控装在机器上，负责细粒度。它能看到进程级别、容器级别、数据库连接数级别的东西。缺点是机器宕机时它自己也停了，机器网络不通时它也发不出告警——它只能告诉你「机器内部的某件事不对」。

外部监控装在别处，负责存活和外部视角。它在你的机器完全死掉、IP 被封、线路不通的时候还能告诉你「这个站访问不了了」。这是内部监控永远做不到的。

推荐的组合结构：

监控层	部署位置	监控内容	故障时的作用
外部可用性	第三方或另一台机器	HTTP 状态码、响应时间、证书到期	唯一能在机器全死时告警的一层
外部基础设施	第三方	ping、端口、DNS 解析	区分是机器死了还是服务挂了
主机资源	机器内部	CPU、内存、磁盘、inode、负载	提前发现资源耗尽
应用指标	机器内部	队列长度、连接数、错误率	定位到具体是哪个组件

查 justg 在售套餐与库存

为什么不建议只装内部监控？最典型的场景是机器被 DDoS 打到网络栈堵死，此时内部 agent 可能还在跑、指标也还在采，但告警消息发不出去，或者发出去了但你收到的是「一切正常」。外部探针是唯一不受这种情况影响的视角。

也不建议只装外部监控？外部探针只能告诉你「访问不了」，不能告诉你「为什么」。当站点返回 500 时，你需要的是内部的应用日志和错误率曲线，而不是反复刷新页面。

免费方案能覆盖的场景：外部可用性用各种在线的 HTTP 监控服务；主机资源用 Node Exporter 加 Prometheus 加 Grafana 这套开源组合，或者更轻的 Netdata；日志告警用 journald 加自定义规则。

自建 Prometheus 栈的资源账要算清楚：Prometheus 本身约占 200 到 400 MB 内存，Grafana 约 100 到 200 MB，Node Exporter 每台约 20 到 30 MB。所以你至少需要一台 1 GB 内存的机器专门跑监控，如果还要跑 Alertmanager 和长期存储，建议 2 GB 起。

三、主机资源监控的具体配置

这一节给出可直接执行的部分。

先装采集端。以 Debian 系为例：

# 安装 Node Exporter（采集 CPU、内存、磁盘等）
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xzf node_exporter-1.8.2.linux-amd64.tar.gz
sudo mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
sudo useradd -r -s /bin/false node_exporter

# 建立 systemd 服务
sudo tee /etc/systemd/system/node_exporter.service > /dev/null << 'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter

验证采集端正常：访问 http://127.0.0.1:9100/metrics，应该能看到大量以 node_ 开头的指标行。

关键：采集端的 9100 端口绝对不要暴露到公网。它会泄露你的 CPU 型号、内存大小、磁盘序列号等硬件信息。要么只监听本地，要么在防火墙上限制来源。

# 只监听本地回环，不对外
sudo sed -i 's|--web.listen-address=.*|--web.listen-address=127.0.0.1:9100|' /etc/default/node_exporter
sudo systemctl restart node_exporter

Prometheus 端的抓取配置：

scrape_configs:
  - job_name: 'node'
    scrape_interval: 15s
    static_configs:
      - targets: ['10.0.0.11:9100', '10.0.0.12:9100']

抓取间隔定 15 秒是个平衡点：太密（比如 5 秒）对小机器是持续的负担，Prometheus 自身的存储写入量会明显上升；太疏（比如 60 秒）会漏掉持续 30 秒的尖峰，而尖峰往往是问题的关键线索。

采集端本身的资源占用要算进机器账里。Node Exporter 空载约占 20 到 30 MB 内存、CPU 占用在 1% 到 3% 之间，这个开销在任何一档配置上都算轻。但 Prometheus 端不一样：它自身约 200 到 400 MB 内存，且存储量随采集间隔成反比增长。如果你的机器只有 2 GB 内存，还要跑网站和数据库，那监控端就不要放在这台机器上——放到另一台机器或者用外部托管服务。这个判断比任何优化技巧都重要。

还有一项常被忽略的采集端安全设置。Node Exporter 默认暴露的指标里包含主机名、内核版本、CPU 型号、内存条信息、网卡名和文件系统 UUID。这些信息本身不致命，但拼在一起是一份相当完整的硬件指纹。采集端要么只监听 127.0.0.1，要么通过 SSH 隧道或者 WireGuard 拉取，绝不要把 9100 端口直接暴露到公网。

另外，采集和告警要分离部署。采集端（Node Exporter）应该和被监控的机器放在一起，因为要读本机的指标；告警端（Prometheus + Alertmanager）应该放在别处，因为它的职责是「在被监控机器全死的时候还能发出声音」。这两者放在一起是最常见的架构错误。

告警规则怎么写。下面这套阈值是通用起点，按你的实际基线调整：

groups:
  - name: node_alerts
    rules:
      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{mountpoint="/rootfs"} / node_filesystem_size_bytes{mountpoint="/rootfs"}) < 0.15
        for: 10m
        annotations:
          summary: "磁盘剩余低于 15%"

      - alert: DiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/rootfs"}[6h], 86400) < 0
        for: 30m
        annotations:
          summary: "按当前增长速率，24 小时内磁盘将写满"

      - alert: HostOutOfMemory
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
        for: 5m
        annotations:
          summary: "可用内存低于 10%"

      - alert: HighLoad
        expr: node_load1 / count(node_cpu_seconds_total) > 1.5
        for: 15m
        annotations:
          summary: "负载持续高于 CPU 核数 1.5 倍"

      - alert: InstanceDown
        expr: up == 0
        for: 3m
        annotations:
          summary: "实例失联超过 3 分钟"

这五条里最值得单独讲的是第二条 predict_linear。它用过去 6 小时的线性趋势预测 24 小时后的剩余空间。这种告警的价值在于——磁盘写满是可预测的，绝大多数情况下你能在写满之前几天就收到提醒，而不是等服务因为写日志失败而挂掉。这个告警往往比「剩余低于 15%」更早触发。

查看 zgovps 当前月价与库存

内存告警为什么用 MemAvailable 而不是 free？MemAvailable 是内核估算的「在不做 swap 的情况下还能分配多少」，它已经把可回收的 page cache 算进去了。用 free 减去 buffers 和 cached 的旧算法会产生大量误报。

四、业务层监控：让告警对应到用户能感知的问题

资源指标正常但业务已经挂了，是监控体系最典型的失效。这个问题要靠业务层探针解决。

最简单有效的做法是一个定时执行的检查脚本，每分钟跑一次：

#!/bin/bash
# /usr/local/bin/check_site.sh
URL="https://你的域名"
CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
TTFB=$(curl -s -o /dev/null -w "%{time_starttransfer}" --max-time 10 "$URL")

if [ "$CODE" != "200" ]; then
  echo "ALERT: HTTP $CODE from $URL"
  exit 1
fi

# 首字节超过 3 秒判为异常
awk "BEGIN {exit !($TTFB > 3.0)}" && echo "ALERT: TTFB ${TTFB}s from $URL" && exit 1
exit 0

把这三个值都采集起来，而不只是「通」或「不通」。状态码告诉你哪一类问题，响应时间告诉你问题有多严重。只采状态码的监控，在「返回 200 但耗时 8 秒」时是瞎的。

数据库和应用层要单独探。数据库连接不上时，网站可能仍然返回 200（如果代码里吞了异常），或者返回一个自定义的错误页。只探首页会漏掉这种情况。

# 数据库连通性
mysqladmin ping -h 127.0.0.1 -u monitor -p'密码' 2>&1

# 应用队列深度（RabbitMQ）
rabbitmqctl list_queues name messages 2>/dev/null

# 进程是否存活
pgrep -f "gunicorn|php-fpm|node" | wc -l

再往上一层是业务指标：下单成功率、支付回调到达率、注册转化数。这些是最贴近「用户是否受影响」的信号，但实现成本高。建议先把前四层做扎实，再考虑第五层。一个没人看的仪表盘不如一套能触发动作的告警。

业务探针的设计有三个容易踩的坑：

第一个坑是探针请求本身制造负载。每分钟一次首页请求对静态站无所谓，但如果探针指向的是一个需要查数据库的动态页面，等于凭空多了一个持续的全表查询。高流量站点上这类探针会把监控变成负载源。做法是专门建一个只返回状态码的 /healthz 接口，让它跳过所有业务逻辑。

# 一个独立 server 块，不带任何业务处理
server {
    listen 8080;
    location = /healthz {
        access_log off;
        return 200 "ok\n";
    }
}

第二个坑是探针从本机发起。本机探针能验证应用是否活着，但验证不了用户从外部访问是否正常——回程线路问题、DNS 问题、防火墙误配，在本机探针下全都看不见。应用探针可以在本机，可用性探针必须在外部，两者的分工是固定的。

第三个坑是探针只看「通不通」。HTTP 探针返回 200 才算通过的做法，会把「返回了一个错误页但状态码是 200」的情况判为正常。所以探针要检查响应体里的关键字，而不只是状态码。

# 状态码 + 响应内容双重校验
BODY=$(curl -s --max-time 10 https://你的域名/healthz)
CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://你的域名/healthz)
if [ "$CODE" != "200" ] || ! echo "$BODY" | grep -q "ok"; then
  echo "ALERT: healthz failed code=$CODE body=$BODY"
fi

关于数据库探针的一个技术选择：用 mysqladmin ping 而不是 mysql -e "SELECT 1"。前者的返回值直接反映服务进程是否存活，后者会因为权限问题、连接数满、认证插件不匹配等多种原因失败，误报率高得多。

业务探针的采样频率也要定。一分钟一次是常规选择，适合大多数站点。但有一种情况要加密：如果你的站点在特定时段有流量高峰（比如电商的整点秒杀），就要在这几个时段加密采样，否则你恰恰在出问题时只有稀疏数据。加密采样的实现很简单，在脚本里判断当前小时是否在关注区间，是则每 10 秒跑一次。

还要给探针留一个「最近成功时间」的记录。这是判断监控系统本身是否失效的关键指标——如果最后一次成功是 10 分钟前，而你的采样间隔是 1 分钟，说明探针挂了。很多监控系统坏掉的标志不是「不告警」，而是「静默地不再告警」。

查看 景文互联 当前月价与库存

# 每次成功就把时间戳写入文件，监控系统检查这个文件的新鲜度
date +%s > /var/lib/monitor/last_success
# 检查逻辑：文件里的时间戳距今超过 3 个采样周期就要报警

五、外部监控怎么搭才能在机器全死时还活着

外部监控的价值在于它是独立视角。下面是可以直接落地的几层。

第一层：用别处的机器做 HTTP 探针。在你自己的另一台 VPS 上跑一个定时任务，用 cron 每分钟请求一次你的站点，失败就发通知。这是最可靠的一层，因为它完全在你控制之下。

# 加到监控机（不是被监控机）的 crontab
*/1 * * * * /usr/local/bin/check_site.sh | mail -s "[ALERT] site down" [email protected]

第二层：DNS 解析监控。很多故障不是服务器挂了，而是 DNS 指到了错误的 IP 或者解析记录过期。这一层专门盯解析。

# 检查解析到的 IP 是否与预期一致
dig +short yourdomain.com @8.8.8.8
# 检查多个公共解析器的结果是否一致
for ns in 8.8.8.8 1.1.1.1 223.5.5.5; do dig +short yourdomain.com @$ns; done

三个解析器返回不同的 IP，就是 DNS 侧的问题，此时去查域名商而不是去查服务器。

第三层：用外部的公开监控服务。这类服务有分布式的探针节点，能给你一个「不同地区看到的样子」。这对判断是不是地域性问题特别有用——比如日本节点的用户在大陆访问慢，探针从欧美访问却正常，说明是回程线路问题而不是你的配置问题。

第四层：TLS 证书到期监控。这一项必须单独说，因为它的失效方式是「某天突然全站打不开」，而在此之前没有任何征兆。

第五层：端口与服务的可达性。用外部工具检查特定端口是否开放，能区分「网站服务挂了」和「整台机器的网络挂了」。

# 从外部机器检查端口是否可达
nc -zv 你的域名 443
# 检查 HTTP 是否返回正常状态码
curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 http://你的域名

这五层各自的盲区：

监控层	能发现	发现不了
外部 HTTP 探针	应用返回错误、响应慢	只在特定地域慢的问题
外部 DNS 监控	解析错误、记录过期	服务器本身的问题
外部端口探针	网络中断、防火墙误配	应用层错误
证书到期监控	证书过期	证书链不完整等中间问题
公开多地探针	地域性差异	短时抖动（采样间隔内）

查看 backwaves 当前月价与库存

六、告警噪音怎么压，这是监控系统能否用起来的关键

一个每十分钟响一次、且大部分时候不需要处理的监控系统，最终一定会被关掉。压噪音的原则有四条。

第一条：每条告警必须对应一个明确的动作。写不出「收到这条告警我要做什么」的告警，就不要加。如果确实不知道，说明这条告警本身没有价值。

第二条：用 for 参数设置持续时间，过滤瞬时抖动。for: 5m 表示这个条件连续成立 5 分钟才告警。CPU 瞬间冲到 90% 然后立刻回落，这是正常的负载波动，不该半夜叫人。

第三条：分级。把告警分成三类：

级别	含义	通知方式	例子
P1 紧急	服务不可用	电话/立即推送	站点返回 502、实例失联
P2 重要	功能受损但还能用	推送	磁盘 24 小时内将写满、证书 7 天后过期
P3 提示	需要留意	汇总邮件	内存使用率 70%、inode 使用率 60%

查 digitalvirt 在售套餐与库存

只有 P1 值得半夜叫你。其余的进汇总。这条规则执行下去，你的夜间打扰会减少八成以上。

第四条：抑制与去重。同一条告警不要重复发。Alertmanager 里的 group_by 和 repeat_interval 就是干这个的。

route:
  receiver: default
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [ 'severity="critical"' ]
      receiver: pager
      repeat_interval: 30m

repeat_interval: 4h 表示同一条持续中的告警每 4 小时才重发一次，而不是每分钟重发一次。

噪音的三个具体来源和对应处理：

- 抖动型噪音（CPU、内存瞬时超标）：加 for 参数。

- 阈值型噪音（阈值定得太低）：把阈值调到实测基线的 1.5 倍。定阈值的方法是：先采集两周数据，看 P95 是多少，阈值设在这个值之上。

- 依赖型噪音（数据库挂了，一堆应用告警跟着响）：用 inhibit_rules，让上游故障时抑制下游告警。

再给一条实操建议：告警消息里必须带上「怎么办」。

- alert: DiskSpaceLow
  expr: (node_filesystem_avail_bytes{mountpoint="/rootfs"} / node_filesystem_size_bytes{mountpoint="/rootfs"}) < 0.15
  for: 10m
  annotations:
    summary: "磁盘剩余低于 15%"
    description: "根分区 {{ $value | humanizePercentage }} 已用。当前目录: {{ $labels.instance }}"
    runbook: "1) df -h / 定位占用 2) du -sh /*/* | sort -rh | head 3) 清理 /var/log 与 apt 缓存 4) 检查是否有失控的日志文件"

runbook 字段里的那段文字，就是你在凌晨三点接到告警时最需要的东西。

七、证书到期和 DNS 到期怎么盯

这两项的共同点是：失效之前没有任何异常，失效当天直接全站不可用。所以必须单独监控。

证书监控的命令：

# 查看证书有效期
echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null | openssl x509 -noout -dates

# 只看剩余天数
EXPIRY=$(echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))
echo "剩余 $DAYS 天"

告警阈值设成三档：30 天提醒一次、14 天提醒一次、7 天提醒一次。不要只在 7 天才告警——如果自动续期脚本挂了，你要留出人工介入的时间。

证书自动续期用 certbot，但必须配好续期后的重载。这是最常见的翻车点：证书续上了，但服务还在用内存里的旧证书。

# 测试续期流程是否正常
certbot renew --dry-run

# 续期后自动重载 Nginx
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh > /dev/null << 'EOF'
#!/bin/bash
systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

certbot 的定时任务默认每天跑两次，但它是随机时间的，这是为了避开 Let\'s Encrypt 的速率限制。所以你不能指望它在固定时间续期，只能靠监控发现它没续上。这就是证书监控存在的意义。

DNS 到期监控查的是两件事：域名本身的注册到期时间，以及每条解析记录的 TTL 是否合理。

# 查域名到期时间
whois 你的域名.com | grep -i "expiry date"

# 查当前解析
dig yourdomain.com +short
dig yourdomain.com NS +short

查看 恒创科技 当前月价与库存

DNS 到期监控要特别小心误报。不同 whois 服务器返回的到期时间可能相差几个月，尤其是 .com 域名在不同注册商显示不一致的情况。监控脚本要取多个 whois 源里最早的那个日期，宁可早提醒。

八、值班流程怎么定，让告警真的有人处理

监控装完人不看，等于没装。值班流程要解决三个问题：谁来看、多久之内处理、怎么处理完。

分级响应表：

级别	首次响应时间	处置目标	处置人
P1	15 分钟内	2 小时内恢复	值班人 + 备份人
P2	2 小时内	当日处理	值班人
P3	次日	本周处理	负责人

查看 hostkvm 当前月价与库存

把值班流程写成可执行的文档，不要只存在脑子里。每个 P1 告警对应的处理步骤应该是这样的一串：

第一步：确认告警属实。远程 SSH 上去或者看外部探针，避免误报消耗值班精力。

# 快速看一眼系统状态
uptime
free -m
df -h
systemctl --failed

第二步：定位范围。是这台机器的问题还是全部的问题？打开站点看返回什么。

# 看最近的错误日志
sudo journalctl -p err --since "30 min ago" --no-pager | tail -50

第三步：判断是业务问题还是资源问题。资源问题按预案处理（清理、重启、扩容）；业务问题看应用日志。

第四步：处置并验证。处置完必须验证恢复，不能凭「看起来好了」结束。

# 验证
curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}s\n" https://你的域名

第五步：记录。写清告警内容、原因、处置动作、耗时、是否需要补改进。这一步不能省——没有复盘的告警处置等于每次都从零开始。

复盘可以很短，但要素要齐。一份够用的复盘包含五个字段：现象（告警内容与首次触发时间）、影响（哪些用户受影响、持续多久）、根因（为什么会出现这个状态）、处置（做了什么、耗时多少）、改进（下次怎么避免）。根因这一栏如果写不出来，说明处置只是把症状压下去了，下次还会犯。

关于「改完没验证」的复盘陷阱很常见。比如处理完内存告警，扩容了机器或者清理了日志，指标恢复正常就关闭工单——但如果没做「压力测试复现」，你无法确认问题真的解决了。处置完成的判据是：让触发条件重新成立一次，看告警是否按预期不再触发。

再讲一条值班里的经验：不要在告警刚触发时立刻做不可逆操作。凌晨三点收到磁盘满的告警，直接 rm -rf /var/log/* 是常见但危险的做法——如果误删的是数据库目录，你把一次故障变成了两次。正确顺序是：先看是什么在占空间（du -sh /*/* | sort -rh | head -20），确认目标之后再删具体文件，删之前先确认路径。

排班和轮值：如果只有一个人负责，就不需要排班，但要保证有替代联系方式（备用手机、备用账号、或者直接托管给服务商）。如果有多人，用简单的轮值表就行，不要上复杂的值班系统。

再补一条最容易被忽略的：告警通道本身要监控。**给告警通道加一个心跳检查——如果 5 分钟内没有收到「一切正常」的心跳，就说明告警通道挂了，主动报警。

九、常见的监控报错与排查方法

这一节是排查手册，按症状查。

症状一：Prometheus 抓不到 Node Exporter，Target 显示 down。

# 在 Prometheus 机器上测试连通性
curl -v http://目标IP:9100/metrics

常见原因：Node Exporter 没启动（systemctl status node_exporter）、防火墙拦了 9100（sudo ufw status）、或者 Node Exporter 只监听了 127.0.0.1 而 Prometheus 在另一台机器。

症状二：告警一直不触发。

# 在 Prometheus 的 UI 里直接查表达式，看返回什么
node_filesystem_avail_bytes / node_filesystem_size_bytes

常见原因：表达式写错了（少了花括号、标签名不对）、指标名写错（现在 Node Exporter 的指标名不是 node_load1 而是 node_load1 但需要带 {}）、或者 for 时间设得太长还没到。

症状三：告警疯狂重复触发。

查 repeat_interval 和 group_interval 的配置。同一个 alertname 出现在多个实例上时，没有 group_by: ['instance'] 就会各自报一遍。

症状四：Grafana 图表显示 No data。

先在 Prometheus 里查同一个表达式确认有数据，再看 Grafana 的数据源配置和查询的时间范围。最常见的原因是时间范围选在了没有采集数据的时段。

症状五：监控本身把机器拖慢了。

# 看监控进程的 CPU 和内存占用
ps aux --sort=-%cpu | head -15
ps aux --sort=-%mem | head -15

Node Exporter 本身很轻，通常在 1% 到 3% CPU。真正吃资源的是 Prometheus 本身（几百 MB 内存）和高频抓取。如果抓取间隔是 5 秒且监控了几十台机器，Prometheus 的存储写入量会非常大。

症状六：证书监控报「连接失败」但网站明明正常。

# 确认是不是 IPv6 解析优先的问题
dig AAAA 你的域名 +short
curl -4 -s -o /dev/null -w "%{http_code}\n" https://你的域名
curl -6 -s -o /dev/null -w "%{http_code}\n" https://你的域名

如果 AAAA 记录指向了不可达的 IPv6 地址，监控机解析到它就会失败，但用户用 IPv4 访问完全正常。这种情况要么删掉错误的 AAAA 记录，要么在监控命令里显式加 -4。

症状七：告警发不出去，通知渠道报错。

# 测试通知渠道
# Webhook 类检查返回码和证书
curl -v -X POST -H "Content-Type: application/json" -d '{"text":"test"}' 你的webhook地址

查 vollcloud 在售套餐与库存

常见原因：Webhook 用了自签名证书、网络代理拦截、或者消息格式不符合渠道要求。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 zenlayer 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 justg 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zgovps 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

日本VPS监控最少要装哪些东西？

最少三样：外部的 HTTP 可用性探针（能放在别的机器上或者用公开服务）、主机资源采集（Node Exporter 之类）、以及一个告警接收渠道（邮件或 IM 机器人）。这三样能覆盖「站点打不开」「机器资源耗尽」「告警没人知道」三个最常见的问题。

监控应该装在网站所在的日本机器上吗？

主机资源监控应该装在本机，但可用性探针必须装在别处。理由是本机探针在机器宕机时会跟着死，它发不出告警。可用性探针放在另一台机器或第三方服务上，才能在原机全挂时告诉你。

告警阈值应该怎么定？

先采集至少一周的数据，看各指标的 P95 值，阈值设在 P95 的 1.5 倍左右。不要照抄别人的阈值——不同业务的高峰形态差别很大，用别人的阈值必然产生噪音。

内存监控应该看 used 还是 available？

看 available。free -m 里的 used 不含可回收的 page cache，看 used 会得出「内存快满了」的错误结论。内核估算的 MemAvailable 才是真实可分配量。

Prometheus 自建好还是用托管服务好？

看机器数量。少于十台且有富余资源，自建足够；几十台以上或者要求高可用，托管服务省心。注意自建的资源账：Prometheus 约 200 到 400 MB 内存，Grafana 约 100 到 200 MB，Node Exporter 每台约 20 到 30 MB，所以监控节点建议至少 2 GB 内存。

告警发到微信或者 QQ 怎么接？

用第三方机器人网关接收 Webhook 告警再转发，或者直接用支持 IM 机器人的监控服务（Prometheus Alertmanager 本身不支持 IM，需要加一层 relay）。关键不是接哪个平台，而是确认你真的会看那个平台——接到一个你不看的渠道等于没接。

日本节点服务器监控告警延迟会不会比别的地方大？

会，而且这是真实影响。跨境链路的抖动会让告警消息的送达时间变长，所以关键告警必须有至少两条独立通道——比如邮件加 IM 机器人，或者再加一个短信通道。P1 级别的告警不要只依赖一条链路。

监控发现的告警，要怎么沉淀成避免下次犯错的措施？

每次处置完写一行复盘：现象、根因、处置、耗时、改进项。改进项要落成具体的动作（改配置、加监控项、调整阈值），否则下次同样的问题会用同样的方式再发生一次。没有改进项的复盘是无效复盘。