Schedule icon
Query icon
Switch icon
SlackIncomingWebhook icon
If icon
Loop icon
Log icon

SingleStore Pipeline Ingestion Stall & Auto-Restart Sentinel

Audit SingleStore streaming pipelines, detect stalled or error states, dispatch Slack incident alerts, and automate START PIPELINE recovery.

Categories
DataInfrastructure

SingleStore is a high-performance, distributed SQL database engineered for operational and real-time analytical workloads. Its native Pipelines feature provides scalable, exactly-once streaming ingestion from Kafka, AWS S3, Google Cloud Storage, Azure Blob Storage, and file systems directly into relational tables without third-party ETL plumbing. In production, unannounced schema drift, corrupted JSON payloads, expired cloud storage access keys, or transient upstream broker timeouts cause pipelines to enter an Error state and halt ingestion. When a pipeline stops, real-time dashboards and analytics applications serve increasingly stale data without raising query-level SQL errors. This blueprint provides continuous automated surveillance over information_schema.PIPELINES and information_schema.PIPELINES_ERRORS, classifies ingestion health, escalates incident alerts to Slack, and safely executes START PIPELINE remediation to recover streaming data flows.

How it works

  1. Scheduled trigger (every_fifteen_minutes) initiates diagnostic pipeline health checks every 15 minutes, with manual runs supported via customizable inputs.
  2. Diagnostic probe (probe_stalled_pipelines) connects to SingleStore over the MySQL wire protocol (port 3306) via io.kestra.plugin.jdbc.mysql.Query and queries information_schema.PIPELINES joined with recent error details from information_schema.PIPELINES_ERRORS for any pipeline whose state is not Running.
  3. Classification logic evaluates the query output using Pebble templating, discerning whether any pipelines are in an Error state (CRITICAL), manually stopped (WARNING), all operating normally (HEALTHY), or if the database connection failed (PROBE_FAILED).
  4. Routing task (route_by_pipeline_health) switches execution along dedicated paths according to the classified severity.
  5. On CRITICAL or WARNING states, structured Slack incident cards notify operations channels with impacted database names, pipeline identifiers, failure counts, and remediation states.
  6. Guarded remediation (check_remediation) checks whether auto_restart is enabled and dry_run is disabled. If confirmed, restart_pipelines iterates across stalled pipelines and executes START PIPELINE commands to safely resume streaming ingestion.
  7. On PROBE_FAILED, dedicated alerts notify administrators of unreachable ports or authentication failures.
  8. Audit log task (log_audit_summary) writes execution metadata and evaluated pipeline counts to task logs.

What you get

  • Automated continuous surveillance of SingleStore streaming pipelines across all databases and schemas.
  • Rapid detection of stalled pipelines and extracted error diagnostics before data freshness SLAs breach.
  • Automated self-healing recovery that safely dispatches START PIPELINE commands for failed ingestion streams.
  • Differentiated incident routing separating active failure errors from intentionally stopped pipelines.
  • Full execution traceability and audit logging without leaking database credentials in logs or alert payloads.

Who it's for

  • Data Engineers and Analytics Platform Teams operating streaming ingestion into SingleStore.
  • Database Administrators managing real-time analytical tables and high-throughput data pipelines.
  • Site Reliability Engineers ensuring continuous operational metric ingestion and dashboard freshness.

Why orchestrate this with Kestra

  • Declarative YAML definition unifies streaming pipeline health monitoring, conditional error triage, and automated self-healing into version-controlled GitOps workflows.
  • Native MySQL JDBC plugin connectivity communicates directly with SingleStore's native wire protocol without external agent daemons or Python container overhead.
  • Built-in conditional routing and looping isolate discovery, dry-run safety gates, and recovery executions without custom scripts.
  • Immutable execution history provides operational evidence documenting pipeline recovery timelines and error recurrence patterns.
  • Cloud-native scheduling and flow-level error-trapping ensure continuous sentinel operation independent of external cron infrastructure.

Prerequisites

  • SingleStore cluster running with MySQL wire compatibility enabled (default port 3306).
  • Database user with read permissions on information_schema.PIPELINES and information_schema.PIPELINES_ERRORS, plus administrative privileges to run START PIPELINE.
  • Slack incoming webhook URL for operational incident dispatch.

Secrets

  • SINGLESTORE_USERNAME: Username for authenticating to the SingleStore MySQL wire protocol port.
  • SINGLESTORE_PASSWORD: Password for the SingleStore database user.
  • SLACK_WEBHOOK_URL: Incoming webhook URL for posting incident cards to Slack.

Quick start

  1. Configure SINGLESTORE_USERNAME, SINGLESTORE_PASSWORD, and SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Deploy this blueprint to your Kestra instance and trigger an initial run with dry_run: true to verify connectivity against your SingleStore cluster.
  3. Review the execution log in the Kestra UI to verify pipeline query execution from information_schema.PIPELINES.
  4. Enable the every_fifteen_minutes schedule trigger to activate automated continuous monitoring and remediation.

How to extend

  • Add CLEAR PIPELINE ERRORS FOR <pipeline>; preceding START PIPELINE for pipelines blocked by error buffer limits.
  • Integrate PagerDuty alerting via io.kestra.plugin.pagerduty.notifications.PagerDutyAlert for high-priority production data landing stalls.
  • Attach Kafka lag checks to compare upstream topic offset consumer positions with SingleStore committed batch timestamps.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.