new-api 系列（六）：监控、日志与告警

系列目录

1. （一）认识 new-api——新一代 AI API 管理网关
2. （二）安装部署——从零搭建 new-api
3. （三）渠道配置——接入各类模型提供商
4. （四）令牌与用户管理
5. （五）计价模型与成本控制
6. （六）监控、日志与告警（本文）
7. （七）生产环境部署与安全加固
8. （八）进阶——多实例、负载均衡与 SSO
9. （九）接入国内支付——支付宝、微信与自动充值
10. （十）接入国际支付——Stripe、PayPal 与海外收银

请求日志

new-api 的日志系统记录每一次 API 请求的完整信息，是排查问题、审计用量、计算成本的基础。

日志字段

日志面板

后台 →「日志」：

• 默认按时间倒序显示
• 可按令牌名、模型名、渠道名过滤
• 支持关键词搜索
• 支持导出 CSV

日志保留策略

new-api 日志存储在数据库中，默认不自动清理。随着请求量增长，日志表会越来越大。建议定期清理：

• SQLite：日志量大时建议定期导出 CSV 后手动清理，或切 MySQL
• MySQL：可以设置定时任务清理超过 N 天的日志

-- MySQL 清理 90 天前的日志（谨慎操作，建议先备份）
DELETE FROM logs WHERE created_at < DATE_SUB(NOW(), INTERVAL 90 DAY);

用量分析

导出的 CSV 可以用 Excel / Python / 命令行快速分析：

# 按令牌统计 Token 消耗
awk -F, '{tokens[$1]+=$4+$5} END {for (t in tokens) print t, tokens[t]}' logs.csv | sort -k2 -rn

# 按模型统计调用次数
awk -F, '{count[$2]++} END {for (m in count) print m, count[m]}' logs.csv | sort -k2 -rn

渠道健康检查

渠道健康检查是 new-api 最实用的自动化运维功能之一——它能自动检测上游渠道是否可用，故障时自动禁用，恢复后自动重新启用。

配置项

在渠道编辑页面开启「健康检查」：

工作流程

手动健康操作

在渠道列表页可以手动操作：

• 测试：立即发送一次测试请求
• 禁用：手动禁用渠道（维护时用）
• 启用：手动恢复已禁用的渠道

Webhook 告警

new-api 支持通过 Webhook 将关键事件推送到即时通讯工具，无需时刻盯面板。

支持的平台

配置入口

后台 →「设置」→「通知设置」：

Webhook URL: https://hooks.slack.com/services/xxx/yyy/zzz
通知事件:
  [x] 渠道禁用/恢复
  [x] 用户额度预警
  [ ] 新用户注册

事件类型与 Payload

渠道状态变更：

{
  "type": "channel_status_changed",
  "channel_name": "OpenAI-官方",
  "status": "disabled",
  "reason": "连续 3 次健康检查失败",
  "timestamp": 1749135600
}

用户额度预警：

{
  "type": "quota_warning",
  "token_name": "alice-dev",
  "user": "alice",
  "remaining_quota": 5000,
  "threshold": 10000,
  "timestamp": 1749135600
}

钉钉机器人配置示例

1. 钉钉群 → 群设置 → 智能群助手 → 添加机器人 → 自定义
2. 安全设置选「加签」或「自定义关键词」（建议用加签更安全）
3. 复制 Webhook URL，填入 new-api 设置

自定义 Webhook 处理

如果你的通知目标是 new-api 不内置支持的平台，可以写一个简单的中间服务：

# webhook-relay.py
from flask import Flask, request
import requests

app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def relay():
    data = request.json
    # 转发到你的 Telegram Bot / 短信服务 / 邮件等
    if data['type'] == 'channel_status_changed':
        msg = f"渠道 {data['channel_name']} 状态变更: {data['status']}"
        send_telegram(msg)
    return 'ok'

def send_telegram(msg):
    requests.post(f"https://api.telegram.org/bot{TOKEN}/sendMessage",
                  json={"chat_id": CHAT_ID, "text": msg})

监控面板内置统计

new-api 管理面板的「仪表盘」提供基础的用量概览：

• 今日总请求数
• 今日 Token 消耗
• 当前活跃渠道数
• 当前在线用户数

配合「日志」页面的筛选和导出功能，日常运维够用。

外部监控集成

Prometheus + Grafana（高级）

new-api 可选暴露 Prometheus metrics 端点。如果有 Grafana 环境，可以搭建专业的监控面板：

# docker-compose 中加入 Prometheus
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

Grafana 面板可以展示：

• 每分钟请求数（QPM）
• Token 消耗趋势
• 各渠道响应时间 P50/P95/P99
• 错误率

这是进阶运维需求，个人使用可以跳过。

系统资源监控

new-api 本身很轻量，但跑久了也需要关注服务器资源：

# 内存占用
ps aux | grep new-api

# 磁盘（SQLite 数据库会增长）
du -sh ~/new-api/

# CPU
top -p $(pgrep new-api)

建议配合 htop、prometheus-node-exporter 等工具监控服务器整体状态。

排查常见问题

请求突然全部报错

1. 先看「日志」页面最近的错误状态
2. 检查「渠道」列表，看是否有渠道被自动禁用
3. 手动「测试」被禁用渠道，确认是否恢复
4. 查看 Webhook 通知，定位第一次故障时间

某个用户用量异常暴增

1. 在「日志」页面按该用户令牌筛选
2. 导出 CSV 分析请求频率和模型
3. 临时禁用令牌，联系用户确认
4. 设置更严格的 QPM 限制

日志表过大导致面板卡顿

1. SQLite 用户：导出重要日志后，停服，备份，清理旧日志
2. MySQL 用户：执行定期清理 SQL
3. 考虑迁移到 MySQL（日志查询性能更好）

系列导航

系列导航

• （一）认识 new-api——新一代 AI API 管理网关
• （二）安装部署——从零搭建 new-api
• （三）渠道配置——接入各类模型提供商
• （四）令牌与用户管理
• （五）计价模型与成本控制
• （六）监控、日志与告警（本文）
• （七）生产环境部署与安全加固
• （八）进阶——多实例、负载均衡与 SSO
• （九）接入国内支付——支付宝、微信与自动充值
• （十）接入国际支付——Stripe、PayPal 与海外收银

实操清单

• 日志正常记录（/home/sdmike/new-api/logs/ 有持续产生的日志文件）
• 对每个渠道开启健康检查（自动禁用 + 自动恢复，当前未确认是否已开启）
• SMTP 邮件通知已配置：Resend SMTP（smtp.resend.com:465，TLS），发件人 noreply@k330.com
• 测试邮件告警：手动禁用一个渠道，确认收到故障邮件通知
• 配置 Webhook 通知（钉钉/飞书/企业微信，当前未配置）
• 导出一次日志 CSV，验证数据完整性
• 设置日志定期清理策略（系统设置 → 日志保留天数，当前未配置）
• 配置用户额度预警阈值（当前未配置）
• （可选）搭建 Grafana 监控面板