OpenObserve RUM模块中会话邮件显示异常问题分析与解决方案

问题背景

在OpenObserve v0.14.0版本的RUM(真实用户监控)模块中，开发团队发现了一个关于会话数据显示的异常现象。当用户查看会话列表时，部分会话记录中的用户邮箱字段会显示为"unknown"，但进入同一会话的详细回放页面后，用户信息却能正确显示。这种不一致性影响了用户体验和数据分析的准确性。

技术分析

问题根源

经过深入排查，发现问题源于RUM会话页面的查询机制设计。系统在处理会话列表请求时，实际上会触发两个独立的查询请求：

1. 主查询：从_rumdata表中获取会话基础信息

SELECT min(_timestamp) as zo_sql_timestamp, 
       min(type) as type, 
       SUM(CASE WHEN type='error' THEN 1 ELSE 0 END) AS error_count,
       SUM(CASE WHEN type!='null' THEN 1 ELSE 0 END) AS events,  
       min(usr_email) as user_email,
       min(usr_id) as user_id, 
       session_id 
FROM "_rumdata" 
GROUP BY session_id 
ORDER BY zo_sql_timestamp DESC

2. 辅助查询：从_sessionreplay表中获取会话回放相关数据

SELECT min(_timestamp) as zo_sql_timestamp, 
       min(start) as start_time, 
       max(end) as end_time, 
       min(user_agent_user_agent_family) as browser, 
       min(user_agent_os_family) as os, 
       min(ip) as ip, 
       min(source) as source, 
       session_id 
FROM "_sessionreplay"  
WHERE application_id='XXXXXXXXXXX' 
GROUP BY session_id 
ORDER BY zo_sql_timestamp DESC

关键问题在于这两个查询之间存在条件不一致的情况。主查询没有应用任何过滤条件，而辅助查询则包含了application_id的条件限制。这种不对称导致两个查询返回的session_id集合不完全匹配，最终造成前端数据合并时出现用户信息丢失的情况。

解决方案

开发团队提出了两种解决思路：

方案一：API优化方案

1. 借鉴trace模块的设计思路，新增专用API端点
2. 将两个查询逻辑合并到单个API调用中
3. 确保查询条件的一致性，避免数据不匹配

这种方案需要前后端协同修改，但能提供更优雅的长期解决方案。

方案二：查询优化方案

1. 在辅助查询中增加session_id过滤条件
2. 使用主查询返回的session_id集合作为过滤依据
3. 确保两个查询基于相同的数据子集

这种方案改动较小，可以快速解决问题，但可能不是最理想的架构设计。

最终团队选择了方案二作为快速修复方案，通过为辅助查询添加session_id IN (主查询结果)的条件，确保了两组数据的一致性。

技术启示

这个问题给我们带来了几个重要的技术思考：

1. 分布式查询一致性：在需要合并多个数据源的系统中，确保查询条件的一致性至关重要
2. 前端数据合并策略：当需要合并来自不同API的数据时，需要有明确的匹配策略和错误处理机制
3. 监控数据完整性：对于RUM这类监控系统，数据完整性直接影响分析结果的准确性

总结

OpenObserve团队通过深入分析RUM模块中会话数据显示异常的问题，不仅快速定位并解决了当前问题，还优化了系统的查询机制。这个案例展示了在复杂系统中处理数据一致性的重要性，也为类似系统的设计提供了有价值的参考经验。