Hasura项目中实现请求追踪与审计日志的技术方案

在GraphQL服务开发中，请求追踪和审计日志是保障系统可观测性和安全性的重要组成部分。本文将以Hasura项目为例，探讨如何在数据库层面获取请求上下文信息，实现完善的审计日志功能。

请求上下文信息的获取挑战

Hasura作为一款流行的GraphQL引擎，已经提供了通过current_setting('hasura.user', 't')获取会话变量的能力。但在实际生产环境中，仅凭用户ID等基础信息往往无法满足完整的审计需求。

开发者通常还需要获取以下关键信息：

• 请求唯一标识符(request_id)
• 客户端IP地址
• 用户代理(User-Agent)
• 其他自定义请求头

技术实现方案对比

传统方案：前置拦截器

在Hasura v2版本中，官方并未直接提供获取完整请求头信息的内置方法。常见的变通方案是在Hasura前部署一个拦截器服务，该方案的工作流程如下：

1. 拦截器捕获所有入站请求
2. 提取请求头信息并持久化到数据库
3. 将请求转发给Hasura服务
4. 审计日志触发器通过会话变量关联原始请求信息

这种方案虽然可行，但引入了额外的组件，增加了系统复杂度和维护成本。

现代方案：OpenTelemetry集成

在Hasura的新版本(DDN/v3)中，官方强化了可观测性支持，通过OpenTelemetry(OTEL)自动捕获丰富的请求上下文信息：

• 客户端IP地址
• 用户代理
• 请求处理时间
• 调用链路追踪

这些信息通过OTEL的trace和span机制收集，开发者可以通过配置的观测平台直接查看完整的请求上下文，无需额外开发拦截逻辑。

技术选型建议

对于新项目，建议直接采用Hasura DDN版本，利用其内置的可观测性功能。这不仅能满足审计需求，还能获得完整的性能监控和错误追踪能力。

对于必须使用v2版本的现有系统，可以考虑以下优化方案：

1. 在数据库层面创建扩展函数，通过Hasura的元数据接口获取请求信息
2. 利用Hasura的事件触发器机制，在请求处理前后记录审计信息
3. 开发自定义中间件，统一处理请求上下文信息的收集和传递

最佳实践

无论采用哪种方案，实现审计日志时应注意：

1. 确保敏感信息的适当脱敏处理
2. 考虑日志存储的性能影响，必要时采用异步写入
3. 设计合理的日志索引，便于后续查询分析
4. 保持日志格式的一致性，方便自动化处理

通过合理利用Hasura提供的各种机制，开发者可以在不引入过多复杂性的前提下，构建出满足业务需求的审计日志系统。