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 平台租户隔离日志要统一租户、请求、模型和错误字段同时避免记录敏感原文。排障需要边界清楚日志权限也要边界清楚。