Operate and Monitor Data Streams

GoldenGate-side monitoring

• Confirm that the Data Stream resource is present and available in the Distribution Service.

• Monitor records and bytes sent, operation counts, DDL counts, table activity, and network statistics where exposed by the UI or service metrics.

• Review Distribution Service logs for authentication, trail lookup, position lookup, schema generation, size truncation, and WebSocket disconnect errors.

• Monitor the source Extract and trail generation independently. A healthy WebSocket cannot deliver data that is not reaching the trail.

Consumer metrics

Metric	Why it matters
Connection state and reconnect count	Detects network, authentication, proxy, and service instability.
Last received and last committed pos	Separates data arrival from successfully durable processing. Log a hash or protected value if positions are considered sensitive.
Records and bytes by type/table	Identifies unexpected volume, filtering errors, and skew.
Processing latency	Time from op_ts to durable downstream commit. Account for source and consumer clock differences.
Internal queue depth and oldest queued age	Detects backpressure before memory exhaustion.
Schema/metadata version changes	Detects DDL and contract changes.
Duplicate and idempotency conflict counts	Validates delivery and checkpoint behavior.
Dead-letter and validation failures	Shows records that require manual or automated remediation.

Buffer and capacity planning

bufferSize controls the byte threshold at which the service flushes its in-memory message queue to the client. A larger value can improve batching efficiency but can increase per-message memory use and latency. A smaller value can reduce latency but increase message overhead. It is not a durable queue, does not replace trail retention, and does not remove the need for consumer backpressure controls.

• Test with representative transaction sizes, LOBs, DDL, table count, and peak throughput.

• Set WebSocket and proxy maximum message sizes above the largest expected batch.

• Use bounded queues and fail fast rather than allowing unbounded memory growth.

• Separate network receive, validation, downstream I/O, and checkpoint commits so each stage can be measured.

Reconnect strategy

• Reconnect from the last durable checkpoint, not the last merely received record.

• Use exponential backoff with a maximum delay and jitter.

• Reset the delay after a stable connection.

• Classify nonretryable failures such as invalid credentials or an unavailable saved position and raise an operator alert instead of retrying forever.

• Preserve the same output contract during recovery. If the stream configuration changed, complete compatibility validation before resuming.

Multiple consumers

Data Streams does not provide a Kafka-style consumer group or server-managed per-consumer offset. Each independent client must maintain its own checkpoint and receives records according to its connection and begin value. Do not share one checkpoint among concurrently active consumers unless an external coordinator guarantees single ownership and ordered checkpoint updates.

Change management

• Version the Data Stream configuration and generated AsyncAPI YAML with the consumer release.

• Test create, connect, steady-state processing, disconnect, restart, retained-position failure, DDL, large records, and credential rotation.

• Deploy compatible consumer code before enabling new payload fields or schema changes.

• Keep a rollback plan that preserves the last known-good checkpoint and configuration.