腾讯mini项目-【指标监控服务重构】2023-07-28

今日已办

项目对齐和问题

  1. 选择使用 otelzap 自主上报 而不是采集 docker 的 container 的日志
    • 后者会产生很多冗余不必要的日志(包括其他容器),会消耗大量 clickhouse 的存储空间,这与我们一开始追求的性能资源指标违背
    • 后者的配置(排除其他容器、解析器 - 解析 trace_id 关联 trace)比较复杂,前置的使用更加简单,并且可以自主添加附属属性来辅组过滤、筛选的功能,结合 signoz log 的 query 快速的定位日志,同样方便与 trace 相关联
  2. 优化了otelclient的初始化逻辑
  3. 同一个 Trace 的 不同 Span(有顺序的)存在时间重叠,没有完全衔接的问题
    • 官方示例也存在,Traefik 也存在
    • 组员反馈在本地运行 profile (不用 docker)就不会出现该问题
  4. Signoz Web 的 Service Map 无法观察到已存在的服务【待解决】

Showcase

使用 SigNoz Web 展示了 上报 Trace、Metric、Log 的效果

会议记录:

  1. 使用 backend_id 而不是 id 作为 trace 的关联
  2. 整个链路都要带上 backend_id,调研是否有让 trace 带 attribute 的方法,而不是每个 span 都手动加上
  3. 导师评论完代码

明日待办

  • 根据导师的建议和代码 comment 来修改代码

你可能感兴趣的:(重构,go,clickhouse)