广告业务系统之数据中转站 —— “日志中心-实时服务监控”

news2024/10/7 12:21:14

日志中心，是广告链路中数据的中转站。实时监控全链路服务健壮性、及支撑结算、曝光、互动等监测上报。在后链路中发挥着举足轻重的作用。

日志中心是囊括了多个功能模块，依据其功能特征可分为：实时服务监控、监测[曝光/互动/Win]上报、流转结算 三种类型。

目前来看，ADX 链路包含了多个微服务/模块。为解决各服务数据口径问题，及对系统整体健壮性、业务数据增长点分析、细节处的种种痛点隐患 等问题，将对前链路收敛、统一数据指标，形成基于 trace 日志的 metrics 实时监控。

当然这个模块的背后，也存在着压缩成本/资源等额外的多种因素。

依据暨广告、推荐、搜索三大顶级复杂业务之 “广告业务系统详叙” 中的 ADX 架构模块图，链路中包含了 前置、流量引擎、竞价、画像、投放引擎 …等五个主要服务模块。
欢迎关注文末公众号

那么如何收敛这些模块中的日志数据，并形成统一的日志 trace 呢？

熟悉监控系统搭建的同学，可能觉得不是问题，经典的 EFK\Prometheus\Graphite 等等，很多成熟的轮子。不错，不熟悉的同学，可以参看云原生社区中监控系列 “监控组件选型对比”做简单的了解。

由于桃李在前，这里就直接上方案了。

在这里插入图片描述
在上述数据流图中，五个模块/微服务都是基于 Docker 镜像方式进行独立部署[Docker 相关可参看 Docker 工程环境搭建及介绍]，其中的日志数据将以 resp 形式进行透传，同时以 pvId/uuid 进行耦合。

耦合形成 pv 粒度的 trace 日志。这时候，我们在数据流的必经之路 —— 前置部分，打开一个小口，将数据流出。

注意：resp 形式并非最佳，虽然成本极低，但且易形成带宽及 IO 压力。[ADX
系统可忽略，与其特定的部署方式有关：为极致压缩服务性能，各服务将以同机的方式部署(详细可关注后续文章)；agent\SDK\Filebeat
等等其他形式皆可成为替代方案]

就像是做临床手术一样，从咽喉处开口获取全链路的 trace 数据。由于 ADX 数据的规模随业务增长呈正相关，意味着我们需要考虑到流量翻番的特殊情况。
故，依托中间件具有 “削峰填谷” 的奇效，将数据灌入 Kafka ，流转至下游分析服务及 Hive 存储。

Hive 存储所属异步链路，通过 Flink\Spark 等数据挖掘手段的介入，进行 OLAP 分析，进一步辅助业务决策等。
分析服务所属则是同步链路，凭借 Graphite\Prometheus\Zabbix\Open-Falcon 等组件优秀的数据采集\聚合\可视化等多维能力，搭建涵盖业务、服务两方面的实时监控，共同助力业务前进。

Metrics 是服务可观测方向的三要素之一，其他的分别是 Log\Trace。[可观测方向详情可见云原生热门话题｜什么是可观测性]

先说一下技术选型问题，为什么在那么多组件中选了 Prometheus & Graphite ? 主要涉及到下述流程：

在原本方案中只有 Prometheus 组件，但其存在两个痛点。[Prometheus 组件详情参看普罗米修斯？古希腊泰坦之神？异形？不，新一代企业级监控组件—Prometheus]

Prometheus 指标数据准确度非 100%
- 这里应对，是采用 Graphite + Prometheus 双监控链路的形式，提供数据支撑。当然涉及到数据的冗余度问题，这里核心指标是双采形式，常规指标为 Prometheus 独有。
Prometheus 重启/中断指标将从 0 初始计算
- 这里采用热备方式进行规避。