DataOps 监测的问题与挑战
DataOps 监测所遇到的问题
随着数据量和数据 pipeline 流程的不断增加，数据质量问题日益凸显。数据源的多样性和复杂性是数据质量监测的一个主要问题。随着数据来源和类型的不断增加，数据质量监测需要处理的数据类型和数据质量问题也越来越复杂。数据源的多样性和复杂性意味着需要对不同的数据源进行针对性的质量监测，以确保数据的完整性、准确性、一致性、可靠性和及时性等各项指标符合要求。
其次，数据的质量监测需要应对数据量大、数据结构复杂的问题。在数据采集和处理过程中，数据量可能非常大，处理数据的速度和效率也成为关键问题。此外，数据结构的多样性和复杂性也会给数据质量监测带来一定挑战，需要使用适当的数据结构和算法来处理数据。
DataOps 监测的重要性
DataOps 监测的重要性在于确保数据流从源头到目的地的可靠性、准确性和高效性，我们可以从四个方面来阐述：
- 及时发现问题和异常：DataOps 监测能够实时检测数据处理过程中的异常情况和问题。通过监测关键指标和性能指标，例如数据流入和流出速率、处理延迟、错误率等，可以迅速发现潜在的数据质量、传输或处理问题。这有助于及早发现并解决数据流的中断、数据丢失或错误，避免对业务流程和数据分析的负面影响。
- 提高数据可靠性和一致性：DataOps 监测有助于确保数据在整个流程中的可靠性和一致性。通过监测数据传输的延迟、丢失情况和错误率，可以及时检测到潜在的数据传输错误或丢失。这样可以确保数据的完整性和准确性，保证数据在不同系统和组件之间的正确传递和处理，从而避免数据不一致或数据质量问题。
- 优化性能和效率：监测 DataOps 可以帮助识别性能瓶颈和优化机会，提高数据处理的速度和效率。通过分析处理延迟、资源利用率、数据处理速度等指标，可以确定瓶颈所在并采取相应的优化措施。优化 DataOps 的性能和效率可以提高数据处理速度、降低延迟，从而加快业务响应能力和提升用户体验。
- 及时警报和故障处理：DataOps 监测工具可配置警报规则，使得在出现异常情况时能够及时通知相关人员。通过警报通知，团队可以迅速采取行动，识别和解决潜在问题，最大程度地减少业务中断或数据丢失的风险。及时的故障处理和恢复措施可以确保 DataOps 的连续性和稳定性。
如何监控复杂使用场景下的数据质量问题
在复杂的使用场景下，数据质量监测变得更为复杂和困难。这是因为这些场景通常包括多个数据源、多个数据处理流程以及多个数据消费方，而且每个环节都可能会影响数据质量。我们会从常见的数据监测处理方式和具体的案例来介绍如何做好复杂使用场景下的数据质量监测。
DataOps 核心性能质量指标
- 数据流速率：表示数据在 DataOps 中的流动速度。它可以用来衡量数据处理的效率和性能，以及处理能力是否满足业务需求。
- 处理延迟：指数据从输入到输出之间的时间延迟。较低的处理延迟意味着数据能够及时处理并快速到达目标位置，从而满足实时性要求。
- 错误率：表示在数据处理过程中发生的错误或异常情况的比例。较高的错误率可能表示数据质量或处理过程存在问题，需要及时检测和纠正。
- 数据完整性：用于检查数据在流程中是否完整、准确且未丢失。通过监控数据完整性，可以确保数据在处理过程中没有丢失或损坏。
DataOps 常见的处理方式
我们在复杂使用场景下我们我们常常会对数据的完整性和及时性较为关注，那么首先在这里我们先引入三个监控思路，下面再通过具体的案例来逐一的对每种场景进行说明：
- 针对于数据采集、处理、存储组件的性能检测：我们可以针对数据采集、处理、存储的组件的性能状态指标的采集来监测多个数据处理流程的数据完整性和及时性
- 针对数据进行打标：我可以对每条数据(每个数据包)流经不同组件时添加相应的时间标记，在存储端以任务的方式对不同阶段的数据完整性和及时性进行验证，或者也可以每个数据处理的阶段对时间标记进行处理计算出相应阶段的延迟和数据完整性指标，并且通过 API 的方式对外提供相应的状态指标，运维同学可以通过 API 获取对应数据链路的状态来监测多个数据处理流程的数据完整性和及时性
- 针对数据采集、处理、存储组件的链路监控：我们可以采用对应数据采集、处理、存储的组件应用的 apm plug-in 将对应的数据状态转换为链路数据来进行多个数据处理流程的数据完整性和及时性的监控
大数据场景下的最佳实践
我们以常见大数据架构 Beats 作为数据采集日志数据投递到 Logstash 中进行 Pipeline 预处理后投递到 Kafka 消息队列中缓存等待处理，Flink 从 Kafka 中消费数据进行具体业务逻辑计算后投递到后端存储中如 ES、Clickhouse、Kudu 中。
针对大数据场景下的性能检测
从上图场景的分析场景的大数据架构我们可以看出，如果我们想达到对组件性能指标的获取就需要分别获取 Beats、Logstash、kafka、Flink、Elasticsearch、Kudu、Clickhouse 的性能指标
Beats 性能指标的获取
Filebeat 可以通过 HTTP 端口来公开内部指标，这些指标有助于监视Beat的内部状态，但是出于安全考虑，默认情况下该功能是不开启的。
我们可以通过修改我们 Beats 的采集配置 YML 文件中将该配置开启并进行指标的收集， 我们通过将 http.enabled(启用HTTP端口来公开内部指标) 选项置为 True ，并且指定 http.port(对外暴露的端口) 来开启对 Beats 指标的采集比如如下配置：
http.enabled: true
http.port: 5067
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/testlog/*.log
processors:
- timestamp:
field: start_time
timezone: Asia/Shanghai
layouts:
- '2006-01-02 15:04:05'
- '2006-01-02 15:04:05.999'
test:
- '2019-06-22 16:33:51'
- drop_fields:
fields: [start_time]
output.logstash:
hosts: ["127.0.0.1:5044"]
我们可以通过开启的端口获取到 Beats 的关键运行指标可以直接反应出 DataOps 的状态比如：
| 指标 | 单位 | 描述 |
|---|---|---|
| filebeat_output_read_errors | 条 | Filebeat 向后输出读取错误数 |
| filebeat_output_write_errors | 条 | Filebeat 向后输出写入错误数 |
| filebeat_pipeline_failed | 条 | Filebeat 中执行 Pipeline 计算失败条数 |
可以通过 Datakit 的 pythond 采集来对 Beats 性能指标进行采集，采集脚本如下：
import requests
from datakit_framework import DataKitFramework
class FilebeatsCollector(DataKitFramework):
name = "filebeats"
interval = 1 # 触发间隔，单位秒
port = 5067 # filebeats 端口 默认5067
def get_filebeats_metrics(self):
"""
获取 filebeats 采集器指标
"""
# 获取filebeats数据
filebeats_response = requests.get(f'http://localhost:{self.port}/stats?pretty')
if filebeats_response.status_code != 200:
raise Exception(f'获取 filebeats 数据失败, 请检查 filebeats 是否正常运行；状态码: {filebeats_response.status_code}')
filebeats_data = filebeats_response.json()
# 获取 filebeats 采集器数据
libbeat = filebeats_data['libbeat']
output = libbeat.get('output')
pipeline = libbeat.get('pipeline')
measurement = "filebeats"
tags = {
"port": f"{self.port}",
}
fields = {
"filebeat_output_read_errors": output.get('read').get('errors'),
"filebeat_output_write_errors": output.get('write').get('errors'),
"filebeat_pipeline_failed": pipeline.get('events').get('failed'),
}
# 指标数据
metrics = [
{
"measurement": measurement,
"tags": tags,
"fields": fields
}
]
return metrics
def run(self):
data = self.get_filebeats_metrics()
in_data = {
'M': data,
'input': "filebeats_collector"
}
return self.report(in_data)
Logstash 性能指标获取
Logstash 可以通过 HTTP 端口来公开内部指标，这些指标有助于监视 Logstash 的内部状态，但是出于安全考虑，默认情况下该功能是不开启的。我们可以通过在 Logstash 配置文件中开启如下配置：
# ------------ HTTP API Settings -------------
http.enabled: true
http.host: 0.0.0.0
http.port: 9600
默认情况下，监控 API 会尝试绑定到 tcp:9600. 如果此端口已被另一个 Logstash 实例使用，则需要使用 --api.http.port 指定的标志启动 Logstash 以绑定到不同的端口。
由于我们更关心的是 DataOps 的状态，所以针对于组件本身的状态在我们这个场景中是可以不进行采集的，那么我们需要关注的采集地址是：
curl -XGET 'localhost:9600/_node/stats/pipelines?pretty'
通过定时的对 Logstash 性能数据的获取，可以通过其中一些关键运行指标直接反应出 DataOps 的状态比如：
| 指标 | 单位 | 描述 |
|---|---|---|
| logstash_events_in | 条 | logstash 输入事件条数 |
| logstash_events_out | 条 | logstash 输出事件条数 |
| logstash_events_faild | 条 | logstash 失败事件条数 |
| logstash_events_duration_in_mills | ms | pipeline 中的事件持续时间 |
| logstash_plugins_inputs_events_queue_push_duration_in_millis | ms | 输入插件中 pipeline 推送的持续时间 |
| logstash_plugins_codecs_duration_in_millis | ms | ogstash codecs阶段延迟 |
| logstash_plugins_filters_duration_in_millis | ms | 过滤器插件中事件的持续时间 |
| logstash_plugins_output_duration_in_millis | ms | 输出插件中事件的持续时间 |
| logstash_reloads_failures | 个 | 失败的配置重新加载次数 |
可以通过 Datakit 的 pythond 采集来对 Logstash 性能指标进行采集，采集脚本如下：
import requests
from datakit_framework import DataKitFramework
class LogStash(DataKitFramework):
name = "logstash"
interval = 1 # 触发间隔，单位秒
port = 9600 # logstash 端口 默认9600
def get_logstash_metrics(self):
"""
获取LogStash采集器指标
"""
# 获取logstash数据
logstash_response = requests.get(f"http://localhost:{self.port}/_node/stats/pipelines?pretty")
if logstash_response.status_code != 200:
raise Exception(f'获取 logstash 数据失败, 请检查 logstash 是否正常运行；状态码: {logstash_response.status_code}')
logstash_data = logstash_response.json()
metrics = []
# 获取logstash采集器数据
pipelines = logstash_data.get('pipelines') # 中可能会有多个pipeline 此处需要循环
for pipeline_name, pipeline_info in pipelines.items():
# events
events = pipeline_info.get('events')
logstash_events_in = events.get('in')
logstash_events_out = events.get('out')
logstash_events_failed = logstash_events_in - logstash_events_out # 原始数据没有失败数据指标，需要自己计算
logstash_events_duration_in_millis = events.get('duration_in_millis')
# plugins
plugins = pipeline_info.get('plugins')
# plugins.inputs
inputs = plugins.get('inputs')
logstash_inputs_queue_push_duration_in_millis = 0
for input_info in inputs:
queue_push_duration_in_millis = input_info.get('events').get('queue_push_duration_in_millis')
logstash_inputs_queue_push_duration_in_millis += queue_push_duration_in_millis
# plugins.codecs,
codecs = plugins.get('codecs')
logstash_codecs_duration_in_millis = 0
for codec_info in codecs:
queue_push_duration_in_millis = codec_info.get('encode').get('duration_in_millis')
logstash_codecs_duration_in_millis += queue_push_duration_in_millis
# plugins.filters,
filters = plugins.get('filters')
logstash_filters_duration_in_millis = 0
for filter_info in filters:
queue_push_duration_in_millis = filter_info.get('events').get('duration_in_millis')
logstash_filters_duration_in_millis += queue_push_duration_in_millis
# plugins.outputs
outputs = plugins.get('outputs')
logstash_output_duration_in_millis = 0
for output_info in outputs:
queue_push_duration_in_millis = output_info.get('events').get('duration_in_millis')
logstash_output_duration_in_millis += queue_push_duration_in_millis
logstash_reloads_failures = pipeline_info.get('reloads').get('failures')
measurement = "logstash"
tags = {
"port": f"{self.port}",
"pipeline": pipeline_name
}
fields = {
"logstash_events_in": logstash_events_in,
"logstash_events_out": logstash_events_out,
"logstash_events_failed": logstash_events_failed,
"logstash_events_duration_in_millis": logstash_events_duration_in_millis,
"logstash_inputs_queue_push_duration_in_millis": logstash_inputs_queue_push_duration_in_millis,
"logstash_codecs_duration_in_millis": logstash_codecs_duration_in_millis,
"logstash_filters_duration_in_millis": logstash_filters_duration_in_millis,
"logstash_output_duration_in_millis": logstash_output_duration_in_millis,
"logstash_reloads_failures": logstash_reloads_failures,
}
metric_dict = {
"measurement": measurement,
"tags": tags,
"fields": fields
}
metrics.append(metric_dict)
return metrics
def run(self):
data = self.get_logstash_metrics()
in_data = {
'M': data,
'input': "logstash_collector"
}
return self.report(in_data)
Kafka 性能指标获取
kafka 的性能指标可以通过 JMX 来监控 Kafka 的运行状态。可以使用 jolokia 工具来使用 JMX 接口获取 kafka 的性能指标，如消息的总量、每秒消息数、总的吞吐量等指标。
在不重启 Kafka 的情况下，可以根据 Kafka 的 PID，使用如下命令进行指标采集。
java -jar /usr/local/datakit/data/jolokia-jvm-agent.jar --host 127.0.0.1 --port=8080 start <Kafka-PID> &
通过定时的对 Kafka 性能数据的获取，可以通过其中一些关键运行指标直接反应出 DataOps 的状态比如：
| 指标 | 单位 | 描述 |
|---|---|---|
| kafka_controller.ActiveControllerCount.Value | int | Controller 存活数量 |
| kafka_controller.OfflinePartitionsCount.Value | int | 下线分区数 |
| kafka_controller.GlobalPartitionCount.Value | int | 分区数 |
| kafka_replica_manager.UnderReplicatedPartitions.Value | int | 失效的副本分区 |
| kafka_controller.GlobalTopicCount.Value | int | Topic |
| kafka_log.OfflineLogDirectoryCount | int | 离线目录数 |
| kafka_request.TotalTimeMs.Mean | ms | 请求用时 |
Flink 性能指标获取
获取 Flink 的性能指标可以通过 修改 Flink 主配置文件 flink-conf.yaml ，添加 PrometheusReporter
metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
metrics.reporter.prom.port: 9250-9260
说明：metrics.reporter.prom.port 端口数根据集群 jobmanager 和 taskmanager 数量而定。
添加后可以使用如下命令测试：
curl http://ip:9250/metrics (~9260)
通过定时的对 Flink 性能数据的获取，可以通过其中一些关键运行指标直接反应出 DataOps 的状态比如：
| 指标 | 单位 | 描述 |
|---|---|---|
| JobManager.taskSlotsAvailable | int | 可用任务槽数量。 |
| JobManager.taskSlotsTotal | int | 任务槽总数。 |
| JobManager.numRegisteredTaskManagers | int | 已注册的任务管理器数量。 |
| JobManager.numRunningJobs | int | 正在运行的任务数量 |
| JobManager.numRestarts | int | 自该作业提交后的总重启次数，包括完全重启和细粒度重启。 |
Elasticsearch 性能指标获取
我们可以通过 Elasticsearch 上的 HTTP 上多个如： /_cat、/_cluster/state/metadata、/_stats 等多个 API接口，可以获取群集状态、节点信息、索引性能、分片存储空间等信息。
我们知道 Elasticsearch 的索引请求类似于传统数据库里面的写操作，如果我们 Elasticsearch 集群是作为 ELK 架构中写类型的，那么监控和分析索引（indices）更新的性能和效率就变得很重要。
| 名称 | 单位 | 描述 |
|---|---|---|
| indices_indexing_index_total | 吞吐量 | 索引的文档总数 |
| indices_indexing_index_time_in_millis | 性能表现 | 索引文档花费的总时间 |
| indices_search_fetch_time_in_millis | 性能表现 | 索引平均获取延迟 |
| indices_search_query_time_in_millis | 性能表现 | 索引平均查询延迟 |
| indices_indexing_index_current | 吞吐量 | 当前正在编制索引的文档数 |
| indices_refresh_total | 吞吐量 | 索引刷新总数 |
| indices_refresh_total_time_in_millis | 性能表现 | 刷新索引所花费的总时间 |
| indices_flush_total | 吞吐量 | 刷新到磁盘的索引总数 |
| indices_flush_total_time_in_millis | 性能表现 | 将索引刷新到磁盘上花费的总时间 |
| indices_merges_current_docs | 吞吐量 | 索引合并文档数 |
| indices_merges_total_stopped_time_in_millis | 性能表现 | 索引合并花费时间 |
| indices_number_of_pending_tasks | 吞吐量 | 等待处理任务数 |
ClickHouse 性能指标获取
获取 ClickHouse 的性能指标可以通过在 clickhouse-server 的 config.xml 配置文件中找到如下的代码段，取消注释，并设置 metrics 暴露的端口号（具体哪个自己造择，唯一即可）。修改完成后重启（若为集群，则每台机器均需操作）。
vim /etc/clickhouse-server/config.xml<prometheus> <endpoint>/metrics</endpoint> <port>9363</port> <metrics>true</metrics> <events>true</events> <asynchronous_metrics>true</asynchronous_metrics></prometheus>
- endpoint Prometheus 服务器抓取指标的 HTTP 路由
- port 端点的端口号
- metrics 从 ClickHouse 的 system.metrics 表中抓取暴露的指标标志
- events 从 ClickHouse 的 system.events 表中抓取暴露的事件标志
- asynchronous_metrics 从 ClickHouse 中 system.asynchronous_metrics 表中抓取暴露的异步指标标志
| 名称 | 单位 | 描述 |
|---|---|---|
| ClickHouse.tables | int | ClickHouse 中数据表数量 |
| ClickHouse.databases | int | ClickHouse 中数据库数量 |
| ClickHouse.uptime | s | ClickHouse 累计运行时间 |
| ClickHouse.insertion | int | ClickHouse 延迟 insert 数 |
在完成对 Beats、Logstash、Kafka、Flink、ES、Ck 等性能指标收集工作后我们可以通过构建场景视图的方式来直观的展示我们常见日志分析架构中 DataOps 的健康状态.
针对场景日志分析场景大数据架构的数据打标
同样从上图的日志分析场景的整体架构我们可以看出，如果要对流经 DataOps 数据进行打标染色那么就需要对 Beats 采集数据时、Logstash 处理数据时、Flink 消费数据、Elasticsearch 写入数据时为数据进行打标染色。
Beats 采集时写入时间戳
在 Beats 采集数据时，需要对 Beats 采集配置 YML 文件的 processors 添加时间配置比如：
processors:
- timestamp:
field: start_time
timezone: Asia/Shanghai
layouts:
- '2006-01-02 15:04:05'
- '2006-01-02 15:04:05.999'
test:
- '2019-06-22 16:33:51'
- drop_fields:
fields: [start_time]
再引入时间都我们重启采集器就可以在采集数据时就可以了。
Logstash 处理时添加时间戳
在 Logstash 处理数据时，需要对 Pipeline 处理配置 YML 文件的 ruby 添加时间配置比如：
input {
# 这是filebeat 发送数据接收的端口
beats {
port => "5044"
}
}
filter {
grok {
match => { "message" => "%{IP:remote_addr} (?:%{DATA:remote_user}|-) [%{GREEDYDATA:timestamp}] %{IPORHOST:http_host} %{DATA:request_method} %{DATA:request_uri} %{NUMBER:status} (?:%{NUMBER:body_bytes_sent}|-) (?:%{DATA:request_time}|-) "(?:%{DATA:http_referer}|-)" "%{DATA:http_user_agent}" (?:%{DATA:http_x_forwarded_for}|-) "(?:%{DATA:http_cookie}|-)""}
}
mutate {
convert => ["status","integer"]
convert => ["body_bytes_sent","integer"]
convert => ["request_time","float"]
}
geoip {
source=>"remote_addr"
}
date {
match => [ "timestamp","dd/MMM/YYYY:HH:mm:ss Z"]
}
useragent {
source=>"http_user_agent"
}
ruby{
code => "event.set('logstash_time',Time.new.strftime('%Y-%m-%d %H:%M:%S'))
event.set('beats_timestamp', event.get('@timestamp').time.localtime + 8*60*60)
event.set('@timestamp',event.get('beats_timestamp'))"
remove_field => ['beats_timestamp']
}
date {
match => [ "logstash_time", "ISO8601" ]
}
}
output {
# kafka的配置
kafka {
id => "logstash"
codec => json
topic_id => "logstash"
# kafka 所在的主机及端口
bootstrap_servers => "127.0.0.1:9092"
batch_size => 1
}
# stdout {
# codec => rubydebug
# }
}
更改配置后我们重启采集器就可以在处理数据后在每条数据中观测到 Logstash 处理的时间了
Flink 计算时间添加时间戳
import org.apache.flink.api.common.eventtime._
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.{DataStream, StreamExecutionEnvironment}
import org.apache.flink.util.Collector
import java.time.Duration
object NginxAccessLogPV {
def main(args: Array[String]): Unit = {
// 创建执行环境
val env = StreamExecutionEnvironment.getExecutionEnvironment
// 读取文本文件，每行表示一个访问日志
val logStream: DataStream[String] = env.readTextFile("nginx-access-log.txt")
// 转换日志流为 (时间戳, 1) 的元组流
val pvStream: DataStream[(Long, Int)] = logStream
.flatMap(new LogParser)
.assignTimestampsAndWatermarks(new LogTimestampExtractor)
.keyBy(0) // 按照时间戳进行分组
.sum(1) // 计算每个时间戳的 PV 总数
// 打印结果
pvStream.print()
// 执行任务
env.execute("Nginx Access Log PV")
}
// 自定义 FlatMapFunction，将每行日志转换为 (时间戳, 1) 的元组
class LogParser extends FlatMapFunction[String, (Long, Int)] {
override def flatMap(log: String, out: Collector[(Long, Int)]): Unit = {
// 解析日志，提取时间戳字段
val timestamp: Long = extractTimestamp(log)
// 发射元组 (时间戳, 1)
out.collect((timestamp, 1))
}
private def extractTimestamp(log: String): Long = {
// 解析日志中的时间戳字段并返回
// 在实际情况下，您需要根据实际日志格式进行解析
System.currentTimeMillis()
}
}
// 自定义 AssignerWithPunctuatedWatermarks，添加处理时间戳和生成水印
class LogTimestampExtractor extends AssignerWithPunctuatedWatermarks[(Long, Int)] {
override def extractTimestamp(pv: (Long, Int), previousTimestamp: Long): Long = pv._1 // 使用元组中的时间戳作为事件时间
override def checkAndGetNextWatermark(pv: (Long, Int), extractedTimestamp: Long): Watermark =
new Watermark(extractedTimestamp - Duration.ofSeconds(1).toMillis)
}
}
以处理 NGINX pv 数据为例，我们在收创建 streamsource 来消费 kafka 中数据时可以获取一个当前系统时间用来跟 Logstash 输出时间相减，计算出数据包在 kafka 中驻留时间，同时在我们 flink 完成计算逻辑后在 sink 前可以获取当前数据来计算出我们 flink 中业务处理所花费的时间，同时将这两个时间差作为指标传入到后端 ES、ck、kudu 存储中用于延时的计算
Elasticsearch 写入时添加时间戳
在 Elasticsearch 写入数据时，需要通过 pipeline 的方式来自动添加时间戳，首先我们需要配置时间戳 pipeline：
curl -XPUT -H 'Content-Type: application/json' http://localhost:9200/_ingest/pipeline/my_pipeline_id -d'
{
"description": "Adds a field to a document with the time of ingestion",
"processors": [
{
"set": {
"field": "es_timestamp",
"value": "{{_ingest.timestamp}}"
}
"date": {
}
}
]
}'
其次对已有的索引的配置进行更改，应用时间戳 pipeline配置
curl -XPUT -H 'Content-Type: application/json' http://localhost:9200/my_index-2023.03.16/_settings -d' { "settings": { "default_pipeline": "my_pipeline_id" } }'
然后我们就可以在 ES 中查询到我们数据写入的时间了
之后我们就可以根据 es 已有的数据来通过定时任务的方式来计算 DataOps 各个阶段的延时情况了，当然也可以通过在程序中提供数据接口的方式来上报 DataOps 各个阶段的延时情况。
做好 DataOps 观测让数据利用更高效
在 DataOps 给出的大数据场景示例中，对数据流程和关键指标的有效监控是确保数据处理的稳定性和高效性的关键。通过监控数据流程，团队可以及时发现和解决潜在的问题、瓶颈或错误，从而确保数据在 Pipeline 中的流动和处理是正常、高效和准确的。
关键指标的监控是衡量 DataOps 性能和质量的关键因素。通过跟踪关键指标如数据流速率、处理延迟、错误率和数据完整性，团队能够获得有关 DataOps 运行状况的实时数据。这些指标的监控可以帮助团队快速发现潜在问题，并及时采取行动，以确保数据的流动和处理能够满足业务的要求和实际需求。
通过合理选择和使用监控工具和技术，团队可以实时跟踪关键指标的变化，并将其可视化展示在仪表盘上。这样的可视化监控可以帮助团队直观地了解 DataOps 的性能和状态，快速发现异常情况，并采取适当的措施。
