广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
Posted 魏小言
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”相关的知识，希望对你有一定的参考价值。
文章目录
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
日志中心
日志中心，是广告链路中数据的中转站。实时监控全链路服务健壮性、及支撑 结算、曝光、互动 等监测上报。在后链路中发挥着举足轻重的作用。
日志中心是囊括了多个功能模块，依据其功能特征可分为：实时服务监控、监测[曝光/互动/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 的日志分析 —— Prometheus & Graphite
Metrics 是 服务可观测方向的三要素之一，其他的分别是 Log\\Trace。[可观测方向详情可见 云原生热门话题｜什么是可观测性]
先说一下技术选型问题，为什么在那么多组件中选了 Prometheus & Graphite ? 主要涉及到下述流程：
- 市场调研
- 需要完备的调研手段及方案，可以是开源产品或竞品、甚至是行业中牛耳公司的设计
- 结合自身条件
- 充分内视，了解自身长短板。结合调研结果，找出最适合自己的一种
- 二次开发/定制
- 落地的同时，要结合情景考量当前方案的痛点，并给予补充开发或定向开发
- …
欢迎关注文末公众号
在原本方案中只有 Prometheus 组件，但其存在两个痛点。[Prometheus 组件详情参看 普罗米修斯？古希腊泰坦之神？异形？不，新一代企业级监控组件—Prometheus]
- Prometheus 指标数据准确度 非 100%
- 这里应对，是采用 Graphite + Prometheus 双监控链路的形式，提供数据支撑。当然涉及到数据的冗余度问题，这里核心指标是双采形式，常规指标为 Prometheus 独有。
- Prometheus 重启/中断指标将从 0 初始计算
- 这里采用热备方式进行规避。
监控服务是怎么监控自身 & 比常规服务更坚强
作为监控服务，核心职责是监控其他服务。
在此前提下，隐含了对监控服务的硬性要求，就是你要比常规服务更健壮。总不能对象服务还没挂，监控服务就先歇了。
所以，为保障坚挺的高可用性，监控服务具备一套高扩展、高性能的架构设计、灵活自主的扩缩容机制、外加两套降级方案 和 一套自身服务监控。
高扩展、高性能的架构设计
服务单实例中，采取多协程并发的方式进行编排。将数据注入 内存 chan 中，动态调起多个协程并发进行业务聚合产出数据指标。在极致利用机器的同时，满足动态扩展的特性。
可靠的两套降级方案
为保障服务在流量超高峰，能够持续输出业务数据，设计了两种降级方案。
- 流量抽样
- 在顶着最高承载能力下，一次进行 80%、40%、20%、10% 梯度比例抽样，若 数据量超载，则进入第二方案。
- 保大不保小
- 对流量进行漏斗模型过滤，只保障部分核心数据正常产出，其他数据任务将全部放弃。
监控服务自身
在服务进行监控的同时，我们设计了自身服务数据 Check 逻辑，确保服务数据无污染，且是正确无误的。
在 上文中 涉及到过 双链路模式，通过对 Graphtie 和 Prometheus 两个不同链路数据的拟合，可以对服务自身的数据情况做出判定。
灵活自主的扩缩容机制
服务采用 分布式方式部署，以服务流量入口阈值、服务出口失败率、服务出口 P90 阈值，三个指标联动模式，为扩缩容时机提供数据依据。
- 冗余度：常备节点与扩容节点之间，机器规模冗余度在 1.05 左右。
欢迎关注文末公众号
成型监控效果
数据指标在聚合之后，以数据源模式内嵌至 Grafana 组件中，提供实时、多样化、多维度的可视化效果。[Grafana 详细可参看 五分钟搭建基于 Prometheus + Grafana 实时监控系统]
可支持业务维度：曝光量/占比、物料填充量/占比、各投放引擎候选类型量/占比…；服务维度：QPS/失败率/SLA/HttpCode分布 …
曝光数据流转结算
曝光数据，是 ADX 额外关注的部分。而曝光数据的流转 是沟通结算，涉及营收的重要桥梁…
见后续文章！
欢迎关注文末公众号
推荐阅读：
三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…
以上是关于广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”的主要内容，如果未能解决你的问题，请参考以下文章