银行大数据平台一旦发生故障，影响范围可能覆盖数十个下游系统和数百个业务应用。明早8点监管报表还没出数，是因为ETL超时还是HDFS集群异常？如果没有完善的可观测性体系，排查过程可能耗费几小时甚至全天。
可观测性的三大支柱
- 指标（Metrics）：资源使用率、任务执行时间、数据延迟等时序数据
- 链路（Traces）：一笔数据从源系统到最终报表的流转路径和每跳耗时
- 日志（Logs）：ETL 作业执行的详细日志，用于根因定位
银行大数据平台的监控层次
第一层：基础设施监控
覆盖 HDFS、YARN、Hive、Spark、Flink、Kafka、ZooKeeper 核心组件健康状态。使用 Prometheus + Grafana 时序监控。
# Prometheus 告警规则
groups:
- name: bigdata_infra
rules:
- alert: HDFSDataNodeDown
expr: up{job="hdfs-datanode"} < 3
for: 1m
labels: severity: critical
- alert: KafkaConsumerLagHigh
expr: kafka_consumer_lag > 100000
for: 2m
labels: severity: critical
第二层：数据质量监控
监控数据管道的 SLA，检查ODS层分区是否按时就绪。
第三层：业务指标监控
监控下游报表指标是否在正常范围内。环比波动超过10%自动告警。
数据链路追踪
银行需要的是一笔数据从核心系统交易发生到最终出现在报表中的完整链路追踪。通过为每个数据管道作业注入统一的 Trace ID，实现：
[交易发生] --CDC--> [Kafka] --Flink--> [Hudi] --SparkETL--> [ClickHouse] --API--> [BI看板]
某银行通过 OpenTelemetry + Jaeger 实现了 Spark/Flink 作业的自动链路追踪，平均故障定位时间从 45 分钟降至 8 分钟。
智能告警体系
1. 动态基线告警
利用历史 30 天的时序数据，通过机器学习模型自动生成动态基线。当月度日均交易量增长30%导致ETL延迟从2小时变成2.5小时，传统固定阈值不会告警，但动态基线会识别出异常。
2. 多维钻取告警
当监控发现某个指标异常时，自动按维度下钻定位根因：按机构、产品、渠道等维度分析异常贡献度。
3. 告警降噪
分组聚合：同一故障根因触发的相关告警自动聚合为一条。某银行通过告警降噪，日均告警量从800条降至60条，有效识别率从30%提升到85%。
运维看板设计
| 视角 | 看板内容 | 目标用户 |
|---|---|---|
| 业务视角 | 核心报表出数时间、数据延迟 | 业务分析师 |
| 应用视角 | ETL任务成功率、执行时长 | 数据工程师 |
| 平台视角 | 集群节点健康、存储使用率 | 平台运维 |
| 安全视角 | 敏感数据访问记录、权限变更 | 安全合规 |
总结
金融大数据平台的可观测性建设，本质上是将数据管道的黑盒变为白盒：Metrics 监控基础设施和数据质量；Traces 全链路追踪让流转路径透明；Logs 集中式日志支持快速根因分析；降噪告警让每一条告警都有 actionable 价值。