机器人上线后，真正难排查的问题通常不是“程序有没有运行”，而是某一次操作为什么失败、是谁修改了配置、订单为什么重复处理，以及错误发生前后系统到底做了什么。日志系统的目标不是把所有内容全部保存，而是在需要排查问题时提供足够、可信且受控的信息。
一、先区分运行日志和业务日志
运行日志关注服务是否正常，例如启动、停止、连接数据库、队列积压和外部接口错误；业务日志关注用户动作和业务状态，例如创建订单、修改配置、审核操作和任务完成。两者混在一起，后期很难检索。
如果还没有监控体系，可以结合Telegram机器人监控与告警方案，把日志、健康检查和告警分开设计。
二、管理员操作必须有审计记录
涉及群组设置、权限、订单、费率、机器人配置等敏感操作时，应记录操作人、时间、对象、动作和结果。例如“管理员A修改群组配置B的日切时间，从X调整为Y”。这样出现争议时，可以追溯变化来源。
三、日志字段应该保持结构化
推荐使用固定字段，例如时间、级别、服务、事件类型、用户或群组标识、对象标识、请求或任务标识、结果和错误码。结构化日志比把所有信息拼成一行中文文本更容易搜索、统计和接入监控系统。
四、错误日志不要只记录“失败”
发生异常时至少记录错误类型、外部接口或模块、任务标识和可用于排查的上下文。对于重试机制，还应记录当前重试次数和最终结果。
例如 Telegram API 返回限流时，可以记录请求类型、相关任务和服务端给出的等待信息，但不应把 Bot Token 或完整授权凭证写进日志。
五、敏感信息一定要脱敏
日志中不要直接保存 Bot Token、数据库密码、API 密钥、私钥或完整支付凭证。手机号、身份证号、银行卡号等敏感数据也应根据业务需要进行遮罩或哈希处理。
如果机器人涉及 TRX、USDT、钱包或交易业务，更应该把“可追踪”和“可泄露”区分开来：保留必要的订单和链上交易标识，不要把私钥等高敏感凭证放入日志。
六、如何设计日志级别
可以使用 DEBUG、INFO、WARN、ERROR 等级别。开发测试环境允许更详细的信息，生产环境则应减少无意义的 DEBUG 日志。严重故障可以进入告警渠道，但不要因为普通用户操作就产生大量高优先级告警。
七、给每次请求或任务一个关联ID
一个用户操作可能经过机器人入口、业务服务、队列、数据库和第三方接口。如果每个模块使用不同的日志标识，排查会非常困难。可以为请求或任务生成关联 ID，并在各环节传递。
这样遇到“订单创建成功但通知没发送”时，可以用一个 ID 找到整个处理链路，而不需要逐个系统猜测。
八、日志保存多久比较合适
没有一个适用于所有业务的固定期限。普通运行日志可以采用滚动保留；审计日志则根据业务风险、合同要求和当地法律确定期限。重要的是避免无限保存，因为日志本身也可能包含个人数据和业务信息。
九、日志访问也需要权限控制
不是所有管理员都应该看到全部日志。普通运营人员可以查看业务结果，高权限人员才查看详细错误或审计信息。日志平台本身也应启用访问控制，并记录谁查看或导出了敏感日志。
十、如何把日志用于故障排查
建议建立几个固定排查路径：机器人无响应时看进程和健康检查；消息发送失败时看 Telegram API 与限流；订单异常时按订单号或关联 ID 搜索；配置被修改时看审计日志；数据库问题则结合慢查询和连接错误分析。
如果机器人部署在 Docker 环境，也可以结合Telegram机器人Docker部署教程建立日志收集和持久化策略。
十一、群发、批量操作与资金业务要特别注意
群发任务应记录任务创建人、授权范围、发送结果和失败原因，并设置限速与停止机制；批量操作应保留任务边界和对象数量，避免误操作扩大影响；涉及资金、代理或数字资产时，应增加人工审核、权限分离和异常告警。
十二、上线前的日志验收清单
至少验证：正常请求是否有记录、错误是否能定位、管理员操作是否可追溯、敏感字段是否脱敏、日志是否会无限增长、权限是否最小化、备份是否安全，以及发生异常时能否通过关联 ID 找到完整处理链路。
十三、SOSBOT可以协助日志与后台设计
如果你的机器人已经运行，但遇到“出了问题不知道从哪里查”的情况，可以从日志分层、审计字段和告警规则开始改造。SOSBOT提供 Telegram 机器人开发、定制、部署以及网站软件开发服务，可通过 Telegram 联系 @sosbot 沟通。
发表回复