1. 从一次磁盘告警说起TaoToken API 调用日志为什么会把 /var/log 撑爆凌晨两点收到磁盘告警/分区使用率 96%du -sh /var/log/*一跑发现一个 18GB 的taotoken-api.log静静躺在那里。这不是段子是我上个月在一台跑了三个月定时任务的测试机上真实遇到的情况。应用侧用 Python 脚本每隔几分钟调用一次 TaoToken API 做模型对话和批量文本处理日志直接print到文件没有任何切割策略三个月下来单文件就长成了这个体量。TaoToken API 调用日志和普通 Web 访问日志不太一样。它的单条记录通常包含请求时间、模型 ID、输入输出 token 数、耗时、HTTP 状态码如果开了 debug 级别还会把完整的请求体和响应体写进去。一次 Claude 长文本对话的响应体动辄几 KB高频调用场景下一天写几百 MB 很正常。日志本身有价值——排查 401、限流、超时、模型返回异常都靠它但让它无限增长就是运维事故。logrotate 是 Linux 上解决这个问题的标准工具几乎所有发行版都预装配合 cron 每天自动跑。它的工作方式不是简单删日志而是切割、压缩、保留、删除四步组合把当前日志改名归档新建空文件继续写旧归档压缩成.gz超过保留数量的最旧文件自动删掉。这样既保住了最近几天的排查依据又不会让磁盘被历史日志吃光。这篇面向的是在 Linux 服务器上跑 TaoToken API 调用脚本、或者用 Coding Plan 做长期编码任务、日志写在/var/log或应用目录下的运维同学。我会给出可直接复制的 logrotate 配置片段覆盖 daily、rotate 7、compress、postrotate 重载服务这几个关键动作再带你用logrotate -d调试、检查归档文件生成和磁盘占用变化确保配置真的生效。适合谁手上有 Linux 机器、日志已经开始变大、但还没配轮转的人。2. TaoToken 前置准备拿到 API Key 并确认日志落盘位置在配 logrotate 之前得先确认两件事TaoToken API 的调用凭证拿到了以及你的调用日志到底写在哪个路径。很多人配轮转失败不是 logrotate 写错了而是规则里的路径和实际日志路径对不上。TaoToken 的 API Key 在控制台的 API Keys 页面创建地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建后复制那串sk-开头的密钥只显示一次丢了就得重建。Base URL 用 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为 OpenAI 兼容接口的base_url使用。模型 ID 按你实际调用的填比如claude-sonnet-4-5、gpt-4o这类具体以控制台模型列表为准。如果你是用 Claude Code 做长期编码任务接入时三件套要写全Base URL 填https://taotoken.net/apiAPI Key 填刚创建的sk-密钥Model ID 填你选的模型。Cline 配 MCP 或者 Codex 改auth.json也是同样三件套缺一个都会报鉴权失败。这部分配置文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到字段名不确定的时候对着看。日志路径这块分几种常见情况。系统级服务比如你用 systemd 跑一个 Python 调用脚本日志可能在/var/log/下用户级脚本可能写在~/app/logs/或项目目录的logs/里容器化部署则要看有没有挂载出来。先用命令定位# 找出最近修改过的大日志文件按大小排序 sudo find /var/log /home /opt -name *.log -size 100M -exec ls -lh {} \; 2/dev/null # 或者直接看 /var/log 下占用 sudo du -sh /var/log/* | sort -rh | head -20假设你的 TaoToken 调用日志落在/var/log/taotoken-api.log下面所有配置都按这个路径写。如果你的实际路径不同把配置里的路径整体替换即可logrotate 规则里的路径必须和真实文件路径完全一致支持通配符比如/var/log/taotoken/*.log。还有一点要提前想清楚日志是应用自己写的logrotate 切割后应用如果还持有旧文件的文件描述符会继续往被改名的文件里写导致新文件一直是空的、旧文件还在涨。这就是为什么配置里必须有postrotate段去通知应用重开日志文件或者用copytruncate模式。下面会具体讲两种方案的取舍。3. 可复制配置/etc/logrotate.d/taotoken-api 完整片段与参数取舍logrotate 的规则文件放在/etc/logrotate.d/目录下每个服务一个文件文件名随意但建议见名知意。新建/etc/logrotate.d/taotoken-api写入下面这段配置。这是针对 TaoToken API 调用日志的完整规则daily、rotate 7、compress、postrotate 重载服务都在里面/var/log/taotoken-api.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate if [ -f /var/run/taotoken-api.pid ]; then kill -USR1 $(cat /var/run/taotoken-api.pid) fi endscript }逐行说清楚每个参数在干什么方便你按自己场景改daily表示每天轮转一次。如果你的调用量特别大一天能写几个 GB可以换成size 200M达到 200MB 就触发比按天更及时。size和daily同时写时size优先。rotate 7保留 7 个归档第 8 个生成时最旧的被删。按天轮转就是保留一周排查问题够用如果按 size 轮转7 个归档可能只覆盖一两天要相应调大。compress把归档压成.gz文本日志压缩率通常 80% 以上18GB 能压到 3GB 左右。delaycompress是延迟一轮再压缩因为有些应用在轮转后短时间内还持有旧文件句柄立即压缩可能出问题延迟一轮更稳。missingok日志不存在时不报错notifempty日志为空时不轮转这两个是防呆配置建议都留着。create 0640 www-data adm在轮转后新建空日志文件并设权限。用户和组要改成你应用实际运行的身份比如你的脚本用ubuntu用户跑就写create 0640 ubuntu ubuntu。权限设错会导致应用写不进新日志这是新手最常踩的坑之一。postrotate ... endscript是轮转后执行的命令。这里发USR1信号给应用进程让它重开日志文件。很多服务nginx、rsyslog都支持用信号触发日志重开。如果你的应用不支持信号有两个替代方案一是用copytruncate替代create加postrotatelogrotate 会先复制日志再清空原文件应用无需感知二是自己在 postrotate 里重启应用服务比如systemctl reload taotoken-api。copytruncate的缺点是复制和清空之间有时间窗口可能丢几条日志但对不支持信号的应用最省事。sharedscripts表示多个日志文件匹配同一规则时postrotate 只执行一次避免重复发信号。如果你只轮转一个文件加不加都行加上更规范。如果你的日志是按目录组织的比如/var/log/taotoken/*.log把第一行路径改成通配符即可其余不变。注意通配符匹配到的文件会共用同一套 rotate 计数不是每个文件独立保留 7 个。配置写完后先别急着让它自动跑用调试模式验证一遍下一节讲具体命令。4. 验证请求与成功结果logrotate -d 调试、归档生成与磁盘占用对比配置写完直接等 cron 跑是危险的万一路径写错或者权限不对可能把不该动的文件轮转了。正确做法是先用-d调试模式空跑它只打印会做什么不实际改文件。sudo logrotate -d /etc/logrotate.d/taotoken-api输出里重点看几行reading config file确认读到了你的配置considering log /var/log/taotoken-api.log确认路径匹配log needs rotating或log does not need rotating告诉你当前是否会触发最后rotating pattern那段会列出它打算执行的 rename、compress、postrotate 动作。如果路径写错这里会显示skipping或者根本找不到文件一眼就能看出来。调试没问题后强制触发一次真实轮转sudo logrotate -f /etc/logrotate.d/taotoken-api-f是 force忽略 daily 的时间判断立即执行。执行完检查归档文件ls -lh /var/log/taotoken-api.log*正常结果应该看到类似这样的输出-rw-r----- 1 www-data adm 0 Jun 10 03:00 /var/log/taotoken-api.log -rw-r----- 1 www-data adm 2.1M Jun 10 03:00 /var/log/taotoken-api.log.1原来的taotoken-api.log被改名成.1同时新建了一个 0 字节的同名文件。因为配了delaycompress.1这一轮还没压缩下一轮轮转时它才会变成.1.gz。再强制跑一次就能看到压缩效果sudo logrotate -f /etc/logrotate.d/taotoken-api ls -lh /var/log/taotoken-api.log*这次会看到.1.gz出现.2是上一轮的.1。压缩后的体积对比很直观2.1M 的文本压成几百 KB。磁盘占用变化用du对比# 轮转前记录 sudo du -sh /var/log/taotoken-api.log # 轮转并压缩后 sudo du -sh /var/log/taotoken-api.log* | sort -rh如果日志原本是 18GB压缩后归档总量通常降到 3GB 以内加上 rotate 7 的限制长期占用会被钉死在一个上限附近不会再无限涨。最后确认 cron 会自动跑。logrotate 依赖/etc/cron.daily/logrotate这个每日任务检查它存在且有执行权限cat /etc/cron.daily/logrotate ls -l /etc/cron.daily/logrotate有内容且权限是-rwxr-xr-x就说明自动轮转链路是通的。你也可以手动执行一次sudo /etc/cron.daily/logrotate模拟 cron 的行为看它是否正常处理了/etc/logrotate.d/下所有规则。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 与轮转不生效配 logrotate 的过程中报错分两类一类是 logrotate 本身的一类是 TaoToken API 调用侧的。分开说。logrotate 侧最常见的现象是配置了但日志还在涨。先跑sudo logrotate -d /etc/logrotate.d/taotoken-api看它是否log does not need rotating。如果是因为daily还没到时间正常如果路径不匹配检查配置里的路径和ls出来的真实路径是否一字不差。另一个高频问题是轮转后应用写不进新日志报Permission denied这是create的用户组和实际运行身份不一致改成应用运行用户即可。还有应用继续往旧文件写、新文件一直 0 字节的情况说明 postrotate 的信号没生效应用不支持USR1改用copytruncate或者把 postrotate 换成重启服务。TaoToken API 调用侧如果你在日志里看到401 Unauthorized基本是 API Key 没填对或者过期了去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 重新确认密钥注意 Base URL 要用https://taotoken.net/api别多加斜杠或路径。看到local proxy failed这类连接错误检查服务器出网是否正常、DNS 能否解析以及有没有在代码里错误地配了本地代理地址。看到reading choices相关的解析报错通常是响应体不是预期的 JSON 结构可能是模型 ID 写错导致返回了错误页核对 Model ID 是否和控制台一致。OAuth 相关报错多出现在 Claude Code 或 Codex 这类工具的登录环节确认三件套Base URL、Key、Model ID都填了缺一个就会走到默认的 OAuth 流程然后失败。排查时把日志级别临时调到 debug能看到完整的请求 URL 和响应体定位快很多。但记得排查完调回 info否则 debug 日志量会暴涨反而给 logrotate 增加压力。6. 长期运行建议与接入入口日志轮转配好之后建议再补两个动作。一是给磁盘加个监控/分区超过 80% 就告警logrotate 是兜底不是万能应用突然疯狂打日志时监控能提前发现。二是定期抽查归档日志zgrep直接搜压缩文件确认轮转没有丢关键记录zgrep 401 /var/log/taotoken-api.log.*.gz如果你还在用 Coding Plan 跑长期编码任务日志量会比普通调用大不少建议把rotate调到 14 或者用size 100M配合rotate 10保留更长的排查窗口。模型对话调试可以在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 直接试确认模型 ID 和返回格式没问题再写进脚本。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 长期编码和 Agent 场景看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。把日志轮转和调用配置都落地服务器就不会再因为一个日志文件半夜告警了。
