AI 平台租户隔离日志：排障需要看见边界

一、多租户日志不能混成一锅

AI 平台服务多个租户时，日志如果只按服务名聚合，很快会难以排障。某个租户请求量异常、某个租户模型调用失败、某个租户权限配置错误，都需要能按租户定位。

但租户日志也不能随意暴露。排障需要看见边界，隐私也需要被保护。

二、日志字段要带租户语义

flowchart TD A[请求日志] --> B[租户 ID] A --> C[工作流 ID] A --> D[模型版本] A --> E[错误码] B --> F[租户维度排障]

租户 ID、工作流 ID、请求 ID、模型版本、错误码是排障基础。没有这些字段，平台只能从海量日志里搜索文本。

同时要避免记录用户原文、Prompt 全文和敏感业务数据。日志字段要服务排障，不是复制请求内容。

三、日志结构要规范

type TenantLog = { tenantId: string requestId: string workflowId?: string modelVersion?: string errorCode?: string durationMs: number }

租户日志应使用结构化格式。文本日志方便人看，但不方便聚合和告警。

tenant_log_policy: require_tenant_id: true mask_user_input: true keep_prompt_hash: true restrict_cross_tenant_query: true

使用 prompt hash 可以关联问题，又不直接暴露原文。

四、查询权限要隔离

平台管理员可以看全局指标，但客户侧只能看自己的日志摘要。内部研发也不应该随意查询所有租户原始日志。

还要有审计记录。谁查询了哪个租户的日志，为什么查询，都要可追踪。

日志保留周期也要按租户和风险分层。调试日志通常短期保留，审计摘要可以保留更久。高敏感租户可能要求更短保留或专属存储。

tenant_log_retention: debug_days: 7 audit_days: 90 allow_tenant_override: true encrypt_at_rest: true

多租户日志还要避免标签爆炸。把 user_id、prompt_id、任意业务字段都放进日志标签，会拖慢日志平台。高基数字段可以作为普通字段存储，查询时再过滤。

告警也要按租户路由。某个租户错误率升高，不一定需要全平台告警；多个租户同时异常，才可能是平台级问题。租户维度能帮助值班人员判断影响面。

最后，日志里的错误码要稳定。客户成功、平台工程和客户管理员看到同一个错误码，才能用同一种语言沟通问题。

日志脱敏最好在采集端完成，而不是等数据进入日志平台后再处理。采集端越早去除敏感字段，后续索引、缓存、告警和导出链路的风险越低。

log_redaction_rules: drop_fields: - prompt - raw_user_input hash_fields: - document_id keep_fields: - tenant_id - request_id - error_code

还要为调试留一条受控通道。某些复杂故障确实需要更详细的上下文，但应该通过临时开关、审批记录、最小范围和短保留周期完成，而不是长期把详细输入打进日志。

租户隔离日志的真正难点，是让工程师还能高效排障，同时不给任何人默认越权的机会。这个平衡点要靠字段设计、权限设计和审计设计一起完成。

五、总结

AI 平台租户隔离日志要统一租户、请求、模型和错误字段，同时避免记录敏感原文。

排障需要边界清楚，日志权限也要边界清楚。