Postgres CDC: metrics and observability #6125

Context

Follow-up from #5988. The connector currently exposes no CDC-specific metrics. Standard Feldera connector metrics capture some information, but CDC has operational characteristics that benefit from purpose-built observability.

Candidates

Event-level

• `cdc_events_total` — counter, labeled by event type (`insert`, `update`, `delete`, `relation`, `truncate`, `begin`, `commit`)
• `cdc_events_filtered_total` — counter of events skipped due to `source_table` filtering

Replication progress

• `cdc_confirmed_flush_lsn` — gauge, current slot's `confirmed_flush_lsn` (from Postgres)
• `cdc_last_received_lsn` — gauge, last LSN we received from etl
• `cdc_replication_lag_bytes` — gauge, WAL bytes between `last_received_lsn` and `confirmed_flush_lsn`
• `cdc_replication_lag_seconds` — gauge, time-based lag (if extractable from events)

Batch flush

• `cdc_batch_flush_duration_seconds` — histogram, time from `write_events` receipt to `async_result.send()`
• `cdc_pending_confirmations` — gauge, size of the `waiting` vec in the completion watcher task
• `cdc_batch_bytes` — histogram, size of batches pushed to InputQueue

Health

• `cdc_pipeline_state` — gauge (0=paused, 1=running, 2=terminated)
• `cdc_postgres_connection_errors_total` — counter

Open questions

1. How do other Feldera connectors expose custom metrics? Is there a pattern to follow?
2. Is `InputConsumer::set_custom_metrics` the right hook?
3. Which of these are worth the implementation cost vs nice-to-have?
4. Any metrics we should NOT expose for security reasons (e.g., does the slot name leak anything)?

Related

• Mentioned as a gap in the #5988 follow-up list