Query icon
Request icon
Script icon
Switch icon
Log icon
SlackIncomingWebhook icon
If icon
Schedule icon
Webhook icon

Apache Pinot Consuming Segment Commit Stall and Consumer Lag Guard

Audit Apache Pinot real-time consuming segment commit stalls and partition lag, trigger pause-resume recovery, and verify fresh record arrival with Kestra.

Categories
Data

Apache Pinot ingests streaming events from Apache Kafka, Amazon Kinesis, and Apache Pulsar into volatile consuming segments. When a segment reaches its configured size or duration limit (realtime.segment.flush.threshold.rows or threshold.time), it enters a distributed commit protocol to seal the segment and persist it to deep storage. In high-throughput production clusters, transient deep storage timeouts, ZooKeeper leader elections, or segment upload errors can leave a segment's consumer thread wedged mid-commit: the Controller's /consumingSegmentsInfo endpoint then reports either no responding replica for a segment that should be consuming, a replica explicitly in NOT_CONSUMING state, or a CONSUMING replica whose lastConsumedTimestamp has gone stale.

When a segment commit stalls, the consumer thread on that partition ceases reading new messages, causing consumer lag to climb relentlessly and preventing downstream real-time analytics queries from observing newly arrived transactions. This blueprint automates continuous segment health auditing across Pinot real-time tables, evaluates these per-replica consumer signals against operational SLAs, safely executes an authorized pause-and-resume cycle to break stuck commit locks, and verifies that active ingestion resumes cleanly on the Pinot broker.

How it works

  1. Scheduled or Webhook Trigger: The flow triggers either on an hourly schedule (0 * * * *, shipped disabled for safe onboarding) or instantly via an authenticated webhook endpoint triggered by Prometheus Alertmanager or Kafka consumer lag alarms.
  2. Broker SQL Ingestion Telemetry: The probe_broker_metrics task (io.kestra.plugin.jdbc.pinot.Query) queries Apache Pinot over the JDBC driver (jdbc:pinot://<controller-host>:9000, which the driver resolves against the Controller) to extract current total row counts and the latest ingested event timestamp.
  3. Controller Consuming Segment Introspection: The probe_consuming_segments task (io.kestra.plugin.core.http.Request) invokes the Pinot Controller REST API endpoint (GET /tables/{tableName}/consumingSegmentsInfo) using secret bearer authentication to retrieve, per segment, each replica's consumer state, last-consumed timestamp, and per-partition records lag.
  4. Operational Health Evaluation: The evaluate_segment_health task (io.kestra.plugin.scripts.python.Script) parses the real per-replica response: a segment with no reporting replica, or a replica reporting NOT_CONSUMING, or a CONSUMING replica whose lastConsumedTimestamp is older than max_commit_stall_seconds is classified as a wedged commit; a CONSUMING replica whose per-partition recordsLagMap exceeds max_allowed_consumer_lag_records is classified as critical lag. The flow classifies the cluster state into HEALTHY, STALLED_COMMIT, or CRITICAL_LAG.
  5. Multi-Branch Flow Routing: The route_by_operational_state task (io.kestra.plugin.core.flow.Switch) routes execution based on the classified outcome:
    • HEALTHY: Emits an informational audit log confirming nominal consumption and active row progression.
    • NO_CONSUMING_SEGMENTS: Logs a warning when no consuming segments are discovered, indicating an uninitialized or paused real-time table.
    • STALLED_COMMIT: Immediately alerts the streaming operations Slack channel. If auto_remediate is true and dry_run is false, it executes automated recovery: pauses table consumption (POST /tables/{tableName}/pause), resumes table consumption (POST /tables/{tableName}/resume) to recycle stalled worker threads, re-queries the broker with verify_broker_ingestion to prove that fresh data is committing, and logs the remediation result.
    • CRITICAL_LAG: Sends an actionable warning alert to Slack specifying that partition lag has crossed tolerance bounds without a stuck commit lock.
  6. Top-Level Error Safeguards: Any communication timeout or authentication failure in broker queries or controller API calls routes directly to the errors handler, notifying the engineering team with execution context.

What you get

  • Zero-Downtime Commit Stall Recovery: Unsticks frozen partition consumer threads via automated controller pause-and-resume orchestration without restarting Pinot Server pods or dropping state.
  • Dual-Plane Health Verification: Combines broker SQL data-plane queries with controller control-plane REST telemetry for end-to-end visibility.
  • Safe Dry-Run Protection: Enforces a strict two-flag safety gate (auto_remediate: false and dry_run: true by default) so operators can safely observe drift diagnostics before enabling automated recovery.
  • Post-Recovery Verification: Re-queries the Pinot broker after recovery actions to prove that table row counts are advancing before resolving incidents.
  • Audit History & Observability: Retains full execution logs, segment status snapshots, and Slack notifications within Kestra's version-controlled audit trail.

Who it's for

  • Real-Time Data Platform Engineers managing high-throughput Apache Pinot OLAP clusters consuming from Kafka, Kinesis, or Pulsar.
  • Site Reliability Engineers (SREs) responsible for real-time analytical query SLAs and automated self-healing infrastructure.
  • Analytics Engineers operating hybrid Pinot tables who require guaranteed ingestion freshness for user-facing dashboards.

Why orchestrate this with Kestra

Apache Pinot's native controller reports segment statuses via REST APIs, but it lacks built-in self-healing policies, automated multi-step recovery workflows, and cross-system alerting integrations. Custom shell cron scripts or manual curl commands lack centralized execution history, secret masking, and verification gates.

Kestra provides a declarative, Git-versioned framework to orchestrate Pinot JDBC queries and Controller REST calls. With Kestra, timeout handling, credential masking, conditional branching, and incident alerts are declared in clean YAML. If a network blip occurs, Kestra's declarative retries prevent false alarms, while every recovery action is permanently recorded for compliance and post-mortem analysis.

Prerequisites

  • A running Apache Pinot cluster (v0.12.0+) with Broker and Controller services accessible from Kestra worker nodes. Locally testable via the official apachepinot/pinot:latest Docker image.
  • An active real-time table configured with a streaming ingestion source (such as Apache Kafka or Apache Pulsar).
  • Administrative access to the Pinot Controller REST API.
  • A Slack Incoming Webhook URL for operational incident dispatch.

Secrets

  • PINOT_BROKER_USER: Username for authenticating JDBC queries against the Pinot Broker (leave empty if unauthenticated).
  • PINOT_BROKER_PASSWORD: Password for authenticating JDBC queries against the Pinot Broker.
  • PINOT_CONTROLLER_AUTH_TOKEN: Bearer token for authenticating administrative requests against the Pinot Controller REST API.
  • PINOT_GUARD_WEBHOOK_KEY: Secret authentication key securing the event-driven Kestra webhook trigger.
  • SLACK_WEBHOOK_URL: HTTPS endpoint for delivering structured incident alerts and remediation summaries to Slack.

Quick start

  1. Configure Secrets: In your Kestra workspace, navigate to Administration -> Secrets and create PINOT_BROKER_USER, PINOT_BROKER_PASSWORD, PINOT_CONTROLLER_AUTH_TOKEN, PINOT_GUARD_WEBHOOK_KEY, and SLACK_WEBHOOK_URL.
  2. Local Testing Setup: If testing locally, launch Apache Pinot's streaming quickstart, which starts a real Kafka topic and a real-time table so consuming segments actually exist to audit (the batch quickstart has none):
    docker run --name pinot-quickstart -p 9000:9000 -d apachepinot/pinot:1.2.0 QuickStart -type stream
    
  3. Execute in Dry-Run Mode: Click Execute in Kestra with dry_run: true and auto_remediate: false. Verify that probe_broker_metrics and probe_consuming_segments execute successfully and log current cluster telemetry.
  4. Enable Scheduled Monitoring: Once validated against your cluster endpoints, toggle disabled: false on the hourly_schedule trigger to maintain continuous 24/7 protection.

How to extend

  • Prometheus Metric Export: Append an io.kestra.plugin.core.http.Request task to push detected consuming lag and commit stall durations into Prometheus Pushgateway for Grafana dashboarding.
  • Automatic Segment Reload: Chain io.kestra.plugin.jdbc.pinot.Query to execute an administrative segment reload when non-consuming sealed segments exhibit CRC verification discrepancies.
  • Kafka Consumer Group Alignment: Connect this workflow with flows/kafka-consumer-lag-sentinel.yaml to cross-correlate Pinot consuming partition offsets with Kafka broker log end offsets.
  • PagerDuty Escalation: Replace or augment the Slack notification task with io.kestra.plugin.pagerduty.notifications.PagerDutyAlert to page on-call SREs when stalls persist across consecutive executions.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.