OLAP

让遥测从生产端到达查询端

平台在可信内网的一台 Linux 主机上运行 OpenTelemetry Collector 采集器与 OpenObserve 存储查询平台。Collector 接收应用信号并采集主机资源；OpenObserve 保存和查询记录，并提供调用链（Trace）的搜索、详情与时间线。

应用将日志、指标和追踪送入 Collector，宿主资源读数也进入同一指标通道。Collector 按有限队列、并发和重试预算导出记录，使用者再从 OpenObserve 查询已经保存的内容。业务项目决定请求分类、调查条件和分析面板，平台提供一致的接入与查询基础。

沿标准协议保留信号身份

应用使用标准遥测协议 OTLP，经 gRPC 接入，也可配置二进制 HTTP 接口。日志、指标和追踪经过有容量限制的处理流程，再分别进入后端。记录保留来源资源（Resource）和记录组件（Scope），平台不替应用改写这些身份。

接收端放在获准的私有网络，部署方建立网络路径，并运营可选的外部 HTTPS 入口。后端账号只在一处配置，Collector 从该来源取得发送所需的连接材料，减少同一目的地与凭据在多处独立维护。

接入一个应用，先建立可核对的信号路径

应用应使用实际声明的 OTLP 监听地址和所需协议，明确服务身份与记录组件。gRPC 与可选的二进制 HTTP 入口都有自己的地址与路径；不能从“Collector 已启动”猜测另一个端口也已开放。

接入检查可选择一条已知的非敏感日志、一个可区分的指标值和一段明确的 Trace。先记录预期来源与时间范围，再在后端查询对应记录。这样可以发现目的地错误、单位换算错误或来源丢失，而不必把真实用户内容当作测试材料。

1. 选择实际接收入口

   核对协议、监听地址和获准网络路径，使用同一权威配置派生后端连接材料。

2. 发送可区分的记录

   保留 Resource 与 Scope，用独立预期的内容和单位区分日志、指标与追踪。

3. 从保存端读回

   按已知来源与观察时段查询后端，对照实际记录，而不是只查看发送端的成功提示。

让运行预算成为显式配置

每种信号使用容量有限的内存队列、固定并发发送和有限重试时间，队列满时不等待无限缓存。主机指标共享指标发送通道。处理内存、批量大小和进程上限共同限制资源使用，接收失败与进程重启仍可能造成记录缺口。

OpenObserve 分别限制写入缓冲、查询执行内存与单个内存数据文件，并读取服务实际获得的内存上限。只提高进程限制不能替代这些内部预算。保留时长、查询范围和超时同样明确，已有数据流的专用设置仍由后端管理。

只绘制能够解释的资源读数

主机采集选择 CPU 空闲比例、可用与总内存，以及文件系统已用、空闲和保留空间。容量作为瞬时读数（Gauge）进入后端，避免被当成不断累加的计数器。应用指标不受这项主机指标适配影响。

概览使用三个纵向完整面板。CPU 展示非空闲比例，内存以 GiB（1024³ 字节）并列呈现可用与总量，文件系统图保留设备、挂载点和空间状态。不同设备的容量不相加；采集器未包含的文件系统保持不可用，由查询者选择相关挂载。

没有看到记录时，沿四个位置检查

先确认生产端是否生成了所需信号，再检查导出与 Collector 的有界处理过程，然后查看后端是否保存了相应数据流，最后核对查询的来源、单位和时间窗口。这一顺序保留了每个位置能证明的事实，不把一个界面的空结果归因于整个系统。

查询失败应显示不可用；成功但没有匹配记录应保持空结果；确实采到零的指标才显示零。旧样本可以用于历史分析，但不能因为查询刚完成就被称为最新采样。观察覆盖范围不足时，应保留缺口而不是补齐一条看似连续的曲线。

• 可以确认：后端找到独立预期的记录

  这能证明该记录在所选来源与时间范围内可查询，并支持相应单位和标签的核对。

• 不能推断：导出确认即后端完整可见

  生产端或接收端确认不等于所有记录已保存，也不能保证没有丢失或持续新鲜。

• 继续核对：服务内存预算

  观察服务实际取得的内存上限，并分别核对队列、写入缓冲与查询预算；宿主总内存不是这些预算的替代值。

把查询成功与观察充分分开

成功返回空结果、尚未出现的信号流和查询失败有不同含义。查询回看旧样本，也不代表发送端刚采集了新数据。主机趋势本身不提供新鲜度、当前健康或丢失记录统计，这些判断需要对应的额外证据。

设计要求用实际生成的服务配置启动 Collector 与 OpenObserve，核对有效内存限制，再发送已知的非敏感日志、指标和追踪并在后端读回。概览验证直接执行所维护的查询表达式，对照 CPU 换算、内存单位与文件系统标签。