monitoring-ingestion-pipeline

使用 Grafana MCP 监控摄取管道

摄取管道（nodejs/）是 PostHog 的 Node.js 事件处理层。 它从 Kafka 消费事件（由 capture 服务生产），让这些事件经过 处理步骤（人员解析、分组分配、属性覆盖等）， 并将富化后的事件生产到面向 ClickHouse 的 Kafka 主题。

同一套代码库通过 posthog-app Helm chart（gold-chart 迁移）部署为 多个 K8s Deployment。每个 Deployment 设置 PLUGIN_SERVER_MODE，并通过两个默认的 Prometheus 标签在指标中加以区分：

• ingestion_pipeline — 值：analytics、heatmaps、clientwarnings、errortracking
• ingestion_lane — 值：main、overflow、historical、async、turbo

app 标签（由 K8s Pod 标签设置）与 Deployment 名称一致，是所有遥测域中最通用的范围过滤器。

本技能教你如何使用 Grafana MCP 工具来 发现实时指标， 而不是死记那些会随着代码演进发生变化的指标名称。

环境上下文

Grafana MCP 连接到一个 单一的 Grafana 实例，该实例限定于某一个环境。 如果用户没有明确指定，请 询问他们想调查哪个环境：

• prod-us — 美国生产环境（us-east-1）
• prod-eu — 欧洲生产环境（eu-central-1）

大多数摄取应用指标会因为所连接的 Grafana 不同而具有环境特定性——它们不带 environment 标签。CloudWatch 指标同样限定于所连接的 Grafana 的 AWS 账户。

跨环境比较需要切换 Grafana 实例（在单个会话中无法做到）。

所有数据源 UID、仪表盘 UID、ingestion_pipeline/ingestion_lane 标签值 以及 ClickHouse 的 type 标签值在 prod-us 和 prod-eu 之间都 完全相同。

关键差异：

• ingestion-analytics-turbo Deployment 仅存在于 prod-us。
• 两个环境都使用独立于 events 集群的 专用摄取 MSK 集群—— 消费者指向 msk-ingestion 而不是 events （prod-us：c21；prod-eu：posthog-prod-eu-ingestion-2026-05-04）。
• CloudWatch 集群 ID 因区域后缀而异（见下文拓扑章节）。

可观测性全景

六个遥测域，经证实它们在 prod-us 和 prod-eu 之间完全一致：

域	数据源 UID	发现工具	范围过滤器
应用指标（VictoriaMetrics）	victoriametrics	list_prometheus_metric_names	见下方指标前缀
应用指标（实时）	victoriametrics-realtime	同上	同上（保留期更短、分辨率更高）
日志	P44D702D3E93867EC（Loki-logs）	list_loki_label_names	app=~"ingestion-.*"
性能剖析	pyroscope	list_pyroscope_profile_types	见下方 Pyroscope 服务
CloudWatch（ElastiCache、MSK、RDS）	P034F075C744B399F	query_prometheus	环境特定的集群 ID
仪表盘	无	search_dashboards	查询 "ingestion" 或 Deployment 名称

数据源注意事项：

• 不要使用主 Loki（P8E80F9AEF21F6940）——它在两个环境中都会间歇性返回 502。务必使用 Loki-logs（P44D702D3E93867EC）。
• 不要使用 CloudWatch Root（PAAE47F430CFD1449）——它仅存在于 prod-us。

稳定的路标

这些事实很少变化，且难以动态发现。

部署角色

所有 PLUGIN_SERVER_MODE=ingestion-v2 部署（即 "analytics ingestion" 系列），以及专用模式。 每个 golden-chart 部署都运行在与部署名称匹配的独立命名空间中。

部署名称	模式	管道	通道	消费者组	消费主题（EU 示例）
ingestion-analytics-main	ingestion-v2	analytics	main	ingestion-analytics-main	ingestion-analytics-main-512
ingestion-analytics-overflow	ingestion-v2	analytics	overflow	ingestion-analytics-overflow	ingestion-analytics-overflow-128
ingestion-analytics-historical	ingestion-v2	analytics	historical	ingestion-analytics-historical	ingestion-analytics-historical-128
ingestion-analytics-async	ingestion-v2	analytics	async	ingestion-analytics-async	ingestion-analytics-async-8
ingestion-analytics-turbo	ingestion-v2	analytics	turbo	ingestion-analytics-turbo	ingestion-analytics-turbo-1024
ingestion-clientwarnings-main	ingestion-v2	clientwarnings	—	ingestion-clientwarnings-main	ingestion-clientwarnings-main-32
ingestion-heatmaps-main	ingestion-v2	heatmaps	—	ingestion-heatmaps-main	ingestion-heatmaps-main-128
ingestion-errortracking-main	ingestion-errortracking	errortracking	—	ingestion-errortracking-main	ingestion-errortracking-main-128
ingestion-errortracking-overflow	ingestion-errortracking	errortracking	—	ingestion-errortracking-overflow	ingestion-errortracking-overflow-32
logs-ingestion	ingestion-logs	—	—	logs-ingestion	ingestion-logs
traces-ingestion	(traces)	—	—	traces-ingestion	ingestion-traces
recordings-blob-ingestion-v2	recordings-blob-ingestion-v2	—	—	session-recordings-blob-v2	ingestion-sessionreplay-main-256
recordings-blob-ingestion-v2-overflow	recordings-blob-ingestion-v2	—	—	session-recordings-blob-v2-overflow	ingestion-sessionreplay-overflow-32

说明：

• ingestion-analytics-turbo 仅存在于 prod-us。
• 主题分区数因环境而异（例如，main 在美国为 1024，在 EU 为 512）。
• 每个部署还有一个 DLQ 主题（ingestion-analytics-main-dlq 等）。
• KEDA 自动扩缩容查询在迁移期间会同时引用新旧消费者组名称 （例如，groupId=~"ingestion-events|ingestion-analytics-main"）。

指标前缀

此处的每个前缀都可以通过 list_prometheus_metric_names 实时发现， 使用 datasourceUid: "victoriametrics" 和 regex: "<prefix>.*"。

前缀	域	关键 scope 标签
ingestion_*	核心 ingestion 应用指标（约 80 个指标）	app、ingestion_pipeline、ingestion_lane
ingestion_lag_ms*	每分区延迟（主要延迟信号）	groupId、partition
consumed_batch_*	Kafka 消费者批量处理	topic、groupId
consumer_batch_* / consumer_background_*	消费者循环健康状态	topic、groupId
kafka_broker_*	librdkafka broker 统计信息	broker_id、broker_name、consumer_group
kafka_consumer_*	消费者再均衡、分配	groupId、type
events_pipeline_*	旧版 pipeline 步骤指标	step_name
person_*	Person 处理（约 30 个指标）	db_write_mode、operation、method
group_*（非 AWS）	Group 处理	operation
personhog_*	PersonHog gRPC 客户端 + 服务	method、source、client
overflow_redirect_*	有状态 overflow 路由	type、result、decision、operation
cookieless_*	无 Cookie 模式	—
http_request_duration_seconds	HTTP 健康/就绪服务器	method、route、status_code
recording_blob_ingestion_v2_*	会话回放 ingestion	app
logs_ingestion_*	日志 ingestion pipeline	app
error_tracking_* / cymbal_*	错误跟踪 pipeline	app
kminion_kafka_*	KMinion 消费者组延迟与 topic offset	group_id、topic_name、partition_id
aws_msk_kafka_*	MSK broker 侧 JMX 指标	environment
warpstream_agent_*	WarpStream agent 指标（约 10 个指标）	virtual_cluster_id、agent_group、operation
kube_* / container_*	K8s 资源	namespace=~"ingestion-.*"、container=~"ingestion-.*"
pg_* / pgbouncer_*	Postgres exporter	因情况而异
ClickHouseMetrics_* / ClickHouseProfileEvents_* / ClickHouseAsyncMetrics_*	ClickHouse 集群健康状态	type（=集群角色）
kafka_connect_*	连接 ClickHouse 的 Kafka Connect 桥接	namespace、connector
posthog_celery_clickhouse_*	来自 Django celery 的 CH 健康监控	scenario

Redis 拓扑

摄取 worker 依赖最多五个 Redis 实例。 Redis 健康状况由摄取侧指标和 CloudWatch ElastiCache 指标推断得出。

Redis 实例	ElastiCache 集群（prod-us）	环境变量	用途
Ingestion Redis	ingestion-prod-redis	INGESTION_REDIS_HOST	溢出状态、pub/sub 协调
PostHog/Primary Redis	posthog-solo	POSTHOG_REDIS_HOST	计费/配额、限制、通用
Cookieless Redis	cookieless-prod-redis	COOKIELESS_REDIS_HOST	Cookieless 服务器哈希模式
CDP Redis	cdp-delivery-prod-redis	CDP_REDIS_HOST	CDP Hog 函数投递
Dedup Redis	ingestion-duplicates-prod-redis	DEDUPLICATION_REDIS_HOST	事件去重

摄取侧 Redis 指标：overflow_redirect_redis_*、cookieless_redis_error。 基础设施侧：CloudWatch 数据源 P034F075C744B399F。

prod-eu 使用相同的逻辑集群名称，但端点后缀不同。 prod-eu 的 primary Redis 为 posthog-prod-redis-encripted（原文如此——该拼写错误存在于实际集群名称中）。 事件限制 Redis（ingestion-prod-redis）是一个与 primary 分离的可写集群—— capture-analytics 和摄取 worker 都通过 EVENT_RESTRICTIONS_REDIS_URL 使用它。

Kafka 拓扑

摄取 worker 通过各自独立的生产者/消费者配置与 三个 Kafka 系统交互：

1. MSK 摄取集群（消费侧）—— KAFKA_CONSUMER_METADATA_BROKER_LIST。 Capture 在此生产；摄取 worker 在此消费。承载所有 ingestion-analytics-*、 ingestion-errortracking-*、ingestion-heatmaps-*、ingestion-clientwarnings-* 主题。 两个环境都有专用集群（prod-us：c21，12 个 broker；prod-eu：posthog-prod-eu-ingestion-2026-05-04）。 KMinion：kminion-msk-ingestion。

2. WarpStream 摄取 VC（输出侧）—— KAFKA_WARPSTREAM_PRODUCER_METADATA_BROKER_LIST。 摄取 worker 在此生产所有发往 ClickHouse 的输出（clickhouse_events_json、 clickhouse_person、clickhouse_groups、clickhouse_heatmap_events、clickhouse_ai_events_json 等）。 集群内 WarpStream agent（warpstream-ingestion-v2）采用多可用区池；明文传输，无 TLS。 KMinion：kminion-warpstream-ingestion。

3. MSK 摄取集群（反馈/DLQ 生产者）—— 与第 1 项相同的物理集群， 通过 KAFKA_INGESTION_PRODUCER_METADATA_BROKER_LIST 使用不同的生产者配置。 用于将事件路由回摄取系统的 overflow/DLQ/异步主题。

• MSK（事件/分析）—— 最初的事件集群。在迁移期间仍承载部分旧版主题和 ClickHouse 消费者组。prod-us：posthog-prod-us-events-2026-03-08 （12 个 broker，kafka.m7g.8xlarge）；prod-eu：posthog-prod-eu-events-2025-10-16（15 个 broker）。 KMinion：kminion-msk-analytics。

WarpStream 虚拟集群—— 每个 VC 都是一个由 S3 支撑的独立逻辑集群，拥有自己的 agent 池、KMinion 实例和主题命名空间：

VC name	Topics carried	KMinion instance
warpstream-ingestion-v2	clickhouse_events_json, clickhouse_person, clickhouse_person_distinct_id, clickhouse_groups, clickhouse_ai_events_json, clickhouse_heatmap_events, clickhouse_app_metrics2, clickhouse_tophog, clickhouse_ingestion_warnings, distinct_id_usage_events_json, log_entries, team_event_partitioned_events_json	kminion-warpstream-ingestion
warpstream-replay-v2	ingestion-sessionreplay-main-*, clickhouse_session_replay_events, clickhouse_session_replay_features	kminion-warpstream-replay
warpstream-logs	ingestion-logs, clickhouse_logs	kminion-warpstream-logs
warpstream-traces	ingestion-traces, clickhouse_traces	kminion-warpstream-traces
warpstream-shared	clickhouse_document_embeddings, error tracking fingerprint/issue topics, document_embeddings_input	kminion-warpstream-shared
warpstream-calculated-events	cohort_membership_changed (US only)	kminion-warpstream-calculated-events
warpstream-cyclotron	CDP topics (cdp_cyclotron_hog*, cdp_internal_events, etc.)	kminion-warpstream-cyclotron
warpstream-warehouse-pipelines	data_warehouse_source_webhooks, data_warehouse_sources_jobs (US only)	kminion-warpstream-warehouse-pipelines

WarpStream Agent 指标：warpstream_agent_* 前缀（约 10 个指标）。 关键指标：control_plane_operation_counter（按 operation）、file_cache_client_fetch_local_or_remote_counter（缓存命中/未命中）。 标签：virtual_cluster_id、agent_group（default、general、multi-az）。 仪表盘：warpstream（Agent Overview）、dbfj5c31spa1ogf（MSK vs WarpStream — Active Produce Topics）。 仅限美国的个人仪表盘（未同步至 EU）：8e93b023-…（CH Consumer Lag）、 ws-coarse-lag-explore（Coarse Lag exploration）。

Postgres 拓扑

DB	Aurora 集群（prod-us）	摄取 PgBouncer
主应用 DB	posthog-cloud-prod-us-east-1（2x db.r8g.16xlarge）	ingestion-default-pgbouncer.posthog.svc.cluster.local
Persons DB	posthog-cloud-persons-prod-us-east-1（3x db.r8g.24xlarge）	ingestion-events-pgbouncer.posthog.svc.cluster.local

Postgres 指标通过 prometheus-postgres-exporter 和 prometheus-postgres-persons-exporter 采集。

prod-eu：posthog-cloud-prod-eu-central-1 和 posthog-cloud-persons-prod-eu-central-1。

ClickHouse 拓扑

ClickHouse 是摄取管道产生的事件的最终下游消费者。 摄取 worker 从不直接与 CH 通信——它们将数据发布到 Kafka topic，CH 通过其内置 Kafka 引擎和 Kafka Connect（DuckLake）消费这些 topic。 CH 的健康状况直接影响用户感知的摄取质量：如果 CH 消费落后， 用户就会看到过期数据。

集群角色（通过 ClickHouseMetrics_* 上的 type 标签发现）：

type 标签	角色	备注
events	主分析事件集群	消费 clickhouse_events_json
online	在线/快速查询集群	从 events 复制
offline	离线/批量查询集群	从 events 复制
medium	中型表	Persons、groups
small	小型/配置表	写入不频繁
sessions	会话回放数据	消费 session recording topic
logs	日志集群	消费 logs topic
logs-new-schema	日志新 schema 迁移	迁移目标
ai-events	AI/LLM 事件	消费 AI events topic
endpoints	API endpoints 集群	轻量
migrations	迁移专用	Schema 变更
aux / ops	辅助/运维	维护
batch-exports	批量导出	prod-us 有此集群；prod-eu 可能不存在
test	测试集群	可能并非所有环境都有

大多数 type 标签值在 prod-us 和 prod-eu 中相同。像 batch-exports 或 test 这样的细微差异 可能只存在于某一个环境中。

从 Kafka 到 ClickHouse 的两条消费路径：

ClickHouse 现在主要从 WarpStream 摄取 VC（摄取 worker 产生其输出的位置）读取，而不是直接从 MSK 读取。

1. ClickHouse Kafka Engine — CH 原生功能。指标前缀为 ClickHouseProfileEvents_Kafka* （例如 KafkaMessagesPolled、KafkaRowsRead、KafkaRowsRejected、KafkaCommitFailures）。 消费者组：clickhouse_events_json（prod-us）、group1 / group1_recent（prod-eu）。 这些组同时存在于 MSK analytics 和 WarpStream ingestion 上 — 使用正确的 KMinion 实例来区分：WarpStream 用 kminion-warpstream-ingestion，MSK 用 kminion-msk-analytics。
2. Kafka Connect — 运行在 kafka-connect 命名空间中，使用 DuckLake sink connector。 指标前缀为 kafka_connect_* 和 kafka_connect_ducklake_sink_task_metrics_*。 消费者组：connect-events-ducklake*。

面向 ingestion 运维人员的关键健康信号：

• kminion_kafka_consumer_group_topic_lag{app_kubernetes_io_instance="kminion-warpstream-ingestion", group_id=~"clickhouse_events_json|group1|group1_recent", topic_name="clickhouse_events_json"} — WarpStream 路径（主路径）上 ingestion 输出与 CH 消费之间的 lag
• kminion_kafka_consumer_group_topic_lag_seconds，使用相同的组过滤条件 — 同上，单位为秒
• ClickHouseProfileEvents_KafkaRowsRejected — CH 无法解析/插入的行数
• ClickHouseProfileEvents_FailedInsertQuery — 插入失败（schema 问题、分区过多等）
• ClickHouseAsyncMetrics_MaxPartCountForPartition — 分区数上升 = 合并压力
• ClickHouseMetrics_ReadonlyReplica — 因落后而转为只读的副本
• ClickHouseAsyncMetrics_ReplicasMaxAbsoluteDelay — 最大复制延迟
• posthog_celery_clickhouse_table_parts_count / _table_row_count — Django 侧的 CH 健康监控

Pyroscope 服务

在 golden-chart 迁移期间，旧格式（ingestion/{name}）和新格式（{namespace}/{name}）在 Pyroscope 中同时存在。 优先使用新格式 {namespace}/{name}。

服务名称（新格式）	部署
ingestion-analytics-main/ingestion-analytics-main	主 analytics
ingestion-analytics-overflow/ingestion-analytics-overflow	Overflow lane
ingestion-analytics-historical/ingestion-analytics-historical	Historical lane
ingestion-analytics-async/ingestion-analytics-async	Async lane
ingestion-analytics-turbo/ingestion-analytics-turbo	Turbo lane（仅 prod-us）
ingestion-heatmaps-main/ingestion-heatmaps-main	热力图
ingestion-clientwarnings-main/ingestion-clientwarnings-main	客户端警告
ingestion-errortracking-main/ingestion-errortracking-main	错误跟踪
ingestion-errortracking-overflow/ingestion-errortracking-overflow	错误跟踪 overflow
logs-ingestion/logs-ingestion	日志 ingestion
traces-ingestion/traces-ingestion	链路 ingestion
recordings/recordings-blob-ingestion-v2	会话回放
recordings/recordings-blob-ingestion-v2-overflow	会话回放 overflow

Profiling 类型：process_cpu:cpu:nanoseconds:cpu:nanoseconds、 wall:wall:nanoseconds:wall:nanoseconds、 memory:inuse_space:bytes:inuse_space:bytes、 memory:inuse_objects:count:inuse_space:bytes。

Grafana 仪表盘

UID	标题	关注点
ingestion-analytics	Ingestion - Analytics	按 pipeline 细分的分析指标
ingestion-health	Ingestion - Health	所有 ingestion 服务的健康概览
ingestion-pipelines	Ingestion - Pipelines	按 lane 细分的 pipeline 步骤
ingestion-reliability	Ingestion - Reliability	事件趋势、处理延迟 SLO、重启、端到端延迟
ingestion-person-processing	Ingestion -- Person Processing	Person 存储、合并、缓存
ingestion-group-processing	Ingestion -- Group Processing	Group 存储
ingestion-sessionreplay	Ingestion - Session Replay	Replay blob pipeline
capture	Capture	Capture 侧的 ingestion 指标 (概览)
bexr9fnja75z4f	Kafka Deduplicator	事件去重 pipeline
pl-ingestion-slas	Ingestion — SLIs / SLOs / SLAs	基于 ingestion_sli_* 指标的 SLI/SLO 视图 (仅美国)
warpstream	Warpstream Agent Overview	Agent 健康、控制平面运维、文件缓存
dbfj5c31spa1ogf	MSK vs Warpstream — Active Produce Topics	并排对比 produce 量
8e93b023-a544-4a3b-8fac-123459d4eb84	WarpStream: ClickHouse Consumer Lag	WarpStream 主题上的 CH 消费者延迟 (仅美国)
ws-coarse-lag-explore	WarpStream Coarse Lag — Explore	Agent 上报的延迟 (仅美国, 个人仪表盘)
personhog-service	Personhog service	PersonHog 延迟分解
dbfgkwxs3gw8owd	KMinion Consumer Group Lag	按 group 划分的消费者延迟 (包括 CH group)
logs	Logs (product)	日志 ingestion
vm-clickhouse-cluster-overview	ClickHouse (集群概览)	QPS、内存、磁盘、复制、parts、合并
clickhouse-ingestion-overview-20260615	ClickHouse Ingestion Layer Overview	Ingestion 层 CH 集群健康与资源
clickhouse-keeper	ClickHouse Keeper	ZooKeeper 替代方案健康状态
fe469e59-e10a-465a-9dac-ac8f6f82dc9a	ClickHouse Stuck Merge Loop Investigation	停止推进的合并
cdzv7o1635n9ca	Kafka Connect	Kafka Connect 任务、延迟、DuckLake sink
fdrcd04np3hfkf	ClickHouse - Kafka consumption	CH Kafka engine 消费统计 (仅欧洲)

发现工作流

Prometheus / VictoriaMetrics

1. list_prometheus_metric_names —— datasourceUid: "victoriametrics"、regex: "ingestion_.*"，用于枚举应用指标
2. 选择一个指标，然后对其范围调用 list_prometheus_label_names —— 查看可用维度
3. list_prometheus_label_values —— 发现某个标签的实际值 （例如在 ingestion_event_dropped_total 上的 labelName: "cause"）
4. 使用 PromQL 调用 query_prometheus —— 始终按 app 或 ingestion_pipeline 限定范围，并设置时间范围

用其他前缀重复上述操作：consumed_batch_*、person_*、personhog_*、 overflow_redirect_*、ClickHouseMetrics_*、kafka_connect_* 等。

Loki（日志）

1. list_loki_label_names —— datasourceUid: "P44D702D3E93867EC"
2. 对 app 调用 list_loki_label_values —— 找到 ingestion 容器（值类似 ingestion-analytics-main、logs-ingestion 等）
3. query_loki_logs —— 例如 {app=~"ingestion-.*"} |= "error" 或 {namespace="clickhouse"} |= "Exception"

Pyroscope（性能分析）

1. list_pyroscope_profile_types —— data_source_uid: "pyroscope"
2. fetch_pyroscope_profile —— matchers: '{service_name="ingestion-analytics-main/ingestion-analytics-main"}'、 profile_type: "process_cpu:cpu:nanoseconds:cpu:nanoseconds"

仪表板

1. search_dashboards —— 查询 "ingestion" 或 "clickhouse" 或某个具体部署名称
2. get_dashboard_by_uid —— 使用已知 UID（例如 "ingestion-health"）获取面板详情
3. get_dashboard_panel_queries —— 从现有面板中提取 PromQL

Redis / ElastiCache

• Ingestion 侧：在 VictoriaMetrics 中发现 overflow_redirect_redis_*、cookieless_redis_* 指标
• 基础设施：用于 ElastiCache 的 CloudWatch 数据源 P034F075C744B399F （CPU、内存、连接数、延迟）。 集群 ID：ingestion-prod-redis、posthog-solo（prod-us 主集群）、 ingestion-duplicates-prod-redis、cookieless-prod-redis

Postgres / Aurora

• Ingestion 侧：发现 postgres_error_total、person_*、group_* 指标
• 基础设施：prometheus-postgres-exporter 和 prometheus-postgres-persons-exporter 指标
• CloudWatch RDS：数据源 P034F075C744B399F，集群 ID 为 posthog-cloud-prod-us-east-1 / posthog-cloud-persons-prod-us-east-1

ClickHouse

• 集群健康：使用正则 "ClickHouseMetrics_.*" 或 "ClickHouseProfileEvents_.*" 调用 list_prometheus_metric_names， 用 type 标签限定集群角色（例如 type="events"）
• Kafka 引擎健康：正则 "ClickHouseProfileEvents_Kafka.*"
• Kafka Connect：正则 "kafka_connect_.*" —— 用 namespace="kafka-connect" 限定范围
• 消费者延迟（桥梁）：kminion_kafka_consumer_group_topic_lag，配合 group_id=~"clickhouse_events_json|group1|group1_recent|connect-events-ducklake.*" 和 topic_name="clickhouse_events_json"。 重要： WarpStream 路径（主路径）需用 app_kubernetes_io_instance="kminion-warpstream-ingestion" 限定范围， 或 MSK 路径使用 "kminion-msk-analytics"。
• 日志：{namespace="clickhouse"} |= "Exception" 或 {namespace="kafka-connect"}
• 仪表板：vm-clickhouse-cluster-overview、clickhouse-ingestion-overview-20260615、 cdzv7o1635n9ca、8e93b023-a544-4a3b-8fac-123459d4eb84（WarpStream CH 消费者延迟）

关键指标域

要查找的内容类别。使用上述前缀可实时发现具体指标。

Kafka 消费者健康状况 — 批处理持续时间、每批消费的消息数、消费者组 分配/再均衡事件、消费者延迟（通过 KMinion）。指标：consumed_batch_*、 kafka_consumer_*、kminion_kafka_consumer_group_topic_lag*，按 group_id 限定范围。

管道处理 — 步骤级延迟和错误率、管道结果分布 （已摄取、已过滤、已丢弃、已进入 DLQ）。指标：events_pipeline_step_ms、 events_pipeline_step_error_total、ingestion_pipeline_results，按 result 分组。

Person/group 存储 — person 刷新延迟、缓存命中率、Postgres 写入延迟、 合并失败、属性大小。指标：person_*、group_*、personhog_*。

输出 — 向 ClickHouse 目标主题的 Kafka 生产。消息大小、延迟、错误。 指标：ingestion_outputs_*，按 topic 分组。

溢出路由 — 有状态溢出决策、用于溢出状态的 Redis 操作。 指标：overflow_redirect_*，按 type、result、decision 分组。

ClickHouse 下游健康状况 — CH 集群 QPS、内存、磁盘、合并压力、 复制延迟、Kafka 引擎消费（读取/拒绝/失败的行数）、Kafka Connect 任务健康状况和消费者延迟。这可告诉你事件是否真正到达 查询层。指标：ClickHouseMetrics_*、ClickHouseProfileEvents_*、 ClickHouseAsyncMetrics_*，按 type 限定范围；kafka_connect_*，按 namespace 限定范围。

K8s 资源 — container_* 和 kube_*，用于 CPU、内存、重启、HPA 状态。 范围：namespace=~"ingestion-.*"、pod=~"ingestion-.*"（或 CH 摄取 Pod 使用 namespace="clickhouse"、 pod=~"chi-ingestion-.*"）。

调查操作手册

参见 references/investigation-playbooks.md， 了解涵盖以下内容的分步工作流：健康检查、事件丢弃、延迟、消费者延迟、 person 处理（包括 persons 数据库的 pganalyze 查询级视图）、 Kafka/MSK 问题、Redis、Postgres、会话回放、ClickHouse 下游健康状况、 单分区延迟（键控成本诊断，移交给 querying-tophog 技能进行 actor 识别），以及跨环境比较。