New to Kestra?
Use blueprints to kickstart your first workflows.
Audits Apache SolrCloud collections for replicas stuck in down or recovery_failed states, alerting search engineers on Slack before cluster degradation.
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.
poll_solr_clusterstatus trigger (io.kestra.plugin.core.trigger.Schedule) initiates the audit every fifteen minutes.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.evaluate_unhealthy_replicas flowable task (io.kestra.plugin.core.flow.If) branches based on whether any shard replicas are operating in degraded states.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).log_healthy_solr_replicas logs cluster health.export_solr_status_manifest task records an execution summary for platform telemetry pipelines.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
| 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. |
{{ 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.SLACK_WEBHOOK_URL: Slack Incoming Webhook endpoint URL with permissions to post messages.SLACK_WEBHOOK_URL in your Kestra namespace secrets.solr_endpoint and target_collection with your production cluster details.zkClientTimeout); check ZooKeeper latency if replicas cycle between recovering and active./admin/collections?action=RELOAD&name=<collection> after human approval./admin/collections?action=LIST.DELETEREPLICA and ADDREPLICA.