Schedule icon
Script icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon

Solr Replica Recovery State Sentinel

Audits Apache SolrCloud collections for replicas stuck in down or recovery_failed states, alerting search engineers on Slack before cluster degradation.

Categories
DataInfrastructure

In distributed enterprise search platforms powered by Apache SolrCloud, collections are partitioned into shards and replicated across cluster nodes to provide high availability and load-balanced query throughput. When a Solr node reboots or loses ZooKeeper ephemeral leases, its local shard replicas automatically enter recovering state to replay transaction logs from the shard leader.

If network partitions occur during log replay or index files suffer disk checksum mismatches, the replica transitions into recovery_failed or down states. When unmanaged failed replicas persist, remaining healthy replicas become overwhelmed by incoming search traffic, and subsequent leader failures result in catastrophic whole-shard search dropouts.

This blueprint provides an automated SolrCloud availability sentinel. Running on a recurrent fifteen-minute schedule, it invokes the Solr Collections API CLUSTERSTATUS action, evaluates replica states across all collection shards, and delivers actionable Slack alerts with exact core reload commands to on-call search infrastructure engineers.

How it works

  1. Recurrent Pulse Trigger: The poll_solr_clusterstatus trigger (io.kestra.plugin.core.trigger.Schedule) initiates the audit every fifteen minutes.
  2. ClusterStatus API Query: The scan_collection_replica_states task (io.kestra.plugin.scripts.python.Script) queries /admin/collections?action=CLUSTERSTATUS, parsing the topology tree to identify replicas in down, recovering, or recovery_failed states.
  3. Degradation Gate: The evaluate_unhealthy_replicas flowable task (io.kestra.plugin.core.flow.If) branches based on whether any shard replicas are operating in degraded states.
  4. Slack Incident Alert: When degraded replicas are detected, alert_slack_solr_replica_failure (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) dispatches an actionable alert card detailing the offending replica, parent shard, and copy-paste remediation commands (action=RELOAD).
  5. Healthy Confirmation: When all replicas report active status, log_healthy_solr_replicas logs cluster health.
  6. Manifest Export: The export_solr_status_manifest task records an execution summary for platform telemetry pipelines.

Architecture diagram

flowchart TD
    A[Schedule: Every 15 Minutes] --> B[scan_collection_replica_states: Solr Collections API]
    B --> C{Degraded Replicas Found?}
    C -- Yes --> D[alert_slack_solr_replica_failure: Slack Webhook]
    C -- No --> E[log_healthy_solr_replicas: Log]
    D --> F[export_solr_status_manifest: Return JSON]
    E --> F

Use cases

  • E-Commerce Search Catalog Availability: Prevent degraded search relevancy and product lookup timeouts during heavy promotional traffic.
  • Post-Maintenance Index Rebuilding: Automatically verify that all replicas successfully resynchronized after node restarts or Solr minor version upgrades.
  • Multi-Shard Shard Quorum Monitoring: Ensure shards maintain minimum required replica counts before taking offline backups or executing schema updates.

Inputs

Name Type Default Description
solr_endpoint STRING "http://localhost:8983/solr" Base HTTP endpoint of the SolrCloud coordinator node.
target_collection STRING "production_catalog" Target Solr collection name to inspect.
slack_channel STRING "#search-reliability" Slack channel destination for search platform alerts.

Expected outputs

  • {{ outputs.scan_collection_replica_states.vars.has_degraded }}: Boolean flag indicating if any replicas are non-active.
  • {{ outputs.scan_collection_replica_states.vars.unhealthy_count }}: Number of degraded replicas discovered.
  • {{ outputs.scan_collection_replica_states.vars.total_replicas }}: Total replica count evaluated in the collection.
  • {{ outputs.scan_collection_replica_states.vars.top_replica }}: Identifier of the primary failing replica.
  • {{ outputs.scan_collection_replica_states.outputFiles['solr_replica_report.json'] }}: Structured JSON diagnostic report.

Prerequisites

  • Reachable Apache SolrCloud instance with HTTP API accessible on port 8983.
  • Incoming Webhook URL configured for your search platform Slack channel.

Secrets

  • SLACK_WEBHOOK_URL: Slack Incoming Webhook endpoint URL with permissions to post messages.

Quick start

  1. Configure SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Import this flow YAML into your Kestra workspace.
  3. Update solr_endpoint and target_collection with your production cluster details.
  4. Click Execute in the UI to run an initial replica availability probe.

Common pitfalls and troubleshooting

  • ZooKeeper Session Timeouts: A flapping replica is often a symptom of ZooKeeper session expiration (zkClientTimeout); check ZooKeeper latency if replicas cycle between recovering and active.
  • Leader Election Locks: Reloading a shard leader while replicas are recovering can trigger election timeouts; trigger reloads on individual follower replicas first using the CoreAdmin API.

How to extend

  • Add an automated collection reload task invoking /admin/collections?action=RELOAD&name=<collection> after human approval.
  • Extend checks to audit all collections dynamically using /admin/collections?action=LIST.
  • Automatically delete and re-create hopelessly corrupt replicas via DELETEREPLICA and ADDREPLICA.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.