正文
通过以上数据说明，作业帮服务观测体系的建设在互联网企业有一定的代表性的。
作业帮所有服务节点都会部署自研的 log-agent 组件来采集服务、中间件和节点的日志。
在日志采集后，通过 Kafka 做日志数据传输，后端同时对接着大数据、日志检索、业务监控等多个消费服务。
最后，所有日志数据最终都会上传到对象存储中，以 zstd 的格式压缩保存。
作业帮的监控系统围绕 Prometheus 进行构建，Prometheus 当前已经是云原生监控的事实标准。它在作业帮的监控体系里承担着数据采集的角色, 并将监控数据实时写入到 VictoriaMetrics 时序数据库中。
Prometheus 模块本身不做数据持久化, 从而保证了整个 Prometheus 服务是无状态的, 如果发生机器宕机可以快速自愈。
为了应对庞大的监控数据量, 我们通过 hashmod 的方式对 Prometheus 进行了分片, 按数据量的大小在集群内部署一个或多个 Prometheus 实例。
我们使用 VictoriaMetrics 做为监控数据的持久化存储。选择它主要有 3 个原因:
-
兼容 Prometheus 的查询语句: 可以像 Pormetheus 一样使用它, 从而做到对外无感透明
-
高性能: 相比其他主流的时序数据库, 有着更高的性能和更少的内存使用
-
高压缩率: 能更有效地使用存储空间, 这个能减少存储监控数据使用的机器成本
追踪体系在作业帮内部落地时, 采用了 jaeger 作为底层来采集服务请求, 用 Kafka 来传递追踪数据, 最后将追踪数据写入到 clickhouse 中保存,。
同时还有拓扑分析服务对接着流式追踪数据，提供实时的服务拓扑分析聚合数据，以时序数据的方式保存在 prometheus 中。
成本在服务观测体系落地上至关重要，一般来说服务观测成本不能超过业务总体成本的 15%。但是对于大部分企业来说实际应该位于 10% 以下才能说服决策者进行大规模应用。比如全量而非采样进行分布式追踪采集，日志保存时效长短。这些数据对后期高级观测能力的效果至关重要。
作业帮在成本优化上几个探索：
ELK 是大部分公司日构建志体系的基础方案，但现在随着服务和流量的增长，在海量日志数据场景下显得越来越力不从心。最主要的问题在于 ES 上，ES 是一个搜索引擎，会付出大量的资源用于索引的构建和维护，以提升检索速率，最终形成数据膨胀。
日志检索是一个明显的写多读少的场景，绝大部分日志在写入后可能就没有任何访问。为此构建大量索引带来的问题就是写入性能劣化，同时也会导致日志数据的膨胀，这些都会带来额外的成本开销。另外日志检索是一个时延不敏感的场景，查询多花一秒少花一秒对用户体验不会有大的影响。
作业帮的日志检索系统就是基于 indexless 的方向设计实现的。在日志写入阶段，不会对日志做解析格式化，而是直接批量写入到文件中，以实现最大的写入性能。日志文件则会按块切分并压缩，每个压缩日志块大小保证在 8M 左右，同时会按时间、所属服务、实例名、日志类型等数据为日志块编制索引。通过这种设计，单核可以支持 50MB/S 的日志写入。
在用户查询时，日志检索系统会基于检索条件圈定符合条件的日志块，然后并发对这些日志块数据做全文检索。如果检索的并发量足够，即是全文检索也能保证一个相对短的查询时间。作业帮的检索系统可以支持 1TB 的日志在 10s 内完成查询。
