今日已办
项目对齐和问题
- 选择使用 otelzap 自主上报 而不是采集 docker 的 container 的日志
- 后者会产生很多冗余不必要 的日志（包括其他容器），会消耗大量 clickhouse 的存储空间，这与我们一开始追求的性能资源指标违背
- 后者的配置（排除其他容器、解析器 - 解析 trace_id 关联 trace）比较复杂 ，前置的使用更加简单，并且可以自主添加附属属性来辅组过滤、筛选的功能，结合 signoz log 的 query 快速的定位日志，同样方便与 trace 相关联
- 优化了otelclient的初始化逻辑
- 同一个 Trace 的 不同 Span（有顺序的）存在时间重叠，没有完全衔接的问题
- 官方示例也存在，Traefik 也存在
- 组员反馈在本地运行 profile （不用 docker）就不会出现该问题
- Signoz Web 的 Service Map 无法观察到已存在的服务【待解决】
Showcase
使用 SigNoz Web 展示了 上报 Trace、Metric、Log 的效果
会议记录：
- 使用 backend_id 而不是 id 作为 trace 的关联
- 整个链路都要带上 backend_id，调研是否有让 trace 带 attribute 的方法，而不是每个 span 都手动加上
- 导师评论完代码
明日待办
- 根据导师的建议和代码 comment 来修改代码