Schedule icon
Return icon
Produce icon
Consume icon
Switch icon
If icon
SlackIncomingWebhook icon
Log icon

Solace Event Mesh Synthetic Delivery and Round-Trip Latency Sentinel

Verify Solace PubSub+ broker delivery with synthetic message produce and consume health probes. Alert Slack on transit latency breaches.

Categories
DataInfrastructure

Solace PubSub+ event brokers power mission-critical event-driven architectures across banking, aerospace, retail, and IoT ecosystems. In high-throughput event meshes, silent degradations such as message spool saturation, queue bind timeouts, network buffer bloat, or slow client acknowledgement loops can cause latency spikes or message stalls without fully dropping TCP connections.

Passive connection monitoring and port health checks fail to detect whether the broker can actively accept, persist, serialize, and dispatch messages to consumers within operational service level agreements (SLAs).

This blueprint implements an automated Day 2 operations canary sentinel for Solace PubSub+. On an automated schedule, Kestra publishes a persistent synthetic probe with a unique correlation ID to a topic destination (canary/health/probe) routed to a subscribed canary queue, consumes the message within a bounded poll window, measures round-trip transit duration in milliseconds, validates message delivery integrity, and pages on-call teams via Slack when transit latency breaches configured thresholds.

How it works

  1. periodic_canary_schedule triggers the sentinel flow on a 15-minute schedule (disabled by default for initial broker setup).
  2. record_probe_dispatch_time captures the baseline dispatch timestamp using io.kestra.plugin.core.debug.Return.
  3. publish_canary_probe publishes a JSON canary payload with a unique execution correlation ID to the target Solace topic destination (canary/health/probe) using io.kestra.plugin.solace.Produce in PERSISTENT delivery mode with an explicit broker acknowledgement timeout.
  4. consume_canary_probe polls the subscribed canary queue using io.kestra.plugin.solace.Consume with a 10-second bounded duration (maxDuration: PT10S) and single-record limit (maxMessages: 1).
  5. classify_delivery_health evaluates message delivery and computes round-trip transit latency:
    • PUBLISH_FAILED: If the producer failed to acknowledge the message write.
    • TIMEOUT_UNCONSUMED: If the published message was not retrieved within the 10-second polling window.
    • SLA_BREACH: If the measured transit latency exceeds latency_sla_ms.
    • HEALTHY: If delivery succeeded within the latency threshold.
  6. route_delivery_health uses io.kestra.plugin.core.flow.Switch to branch on the evaluated classification. When degraded or timed out, it checks alert_mode: ALERT dispatches structured notifications to Slack via io.kestra.plugin.slack.notifications.SlackIncomingWebhook, while AUDIT_ONLY logs findings without alerting.
  7. log_sentinel_audit_complete records a concluding log entry on every run to maintain continuous telemetry in Kestra execution history.
  8. A flow-level errors handler catches network partitions, DNS resolution failures, or broker authentication rejections and pages on-call operators.

What you get

  • Active end-to-end synthetic health verification of Solace PubSub+ event brokers without external monitoring agents.
  • Continuous round-trip transit latency measurement in milliseconds.
  • Early detection of message spool saturation, queue binding stalls, and consumer timeouts.
  • Dual operating modes: ALERT for active incident paging and AUDIT_ONLY for establishing baseline latency profiles.
  • Resilient error handling that alerts operators if broker endpoints become completely unreachable.

Who it's for

  • Messaging Platform Engineers and SREs maintaining production Solace PubSub+ broker clusters.
  • Enterprise Integration Architects operating high-volume event meshes for financial transactions and order processing.
  • DevOps teams standardizing Day 2 synthetic canary testing across event-driven infrastructure.

Why orchestrate this with Kestra

Solace PubSub+ provides CLI and SEMP monitoring tools, but does not natively execute recurring end-to-end synthetic publish-consume cycles or route SLA breaches to collaboration tools. Kestra orchestrates declarative, version-controlled workflows with built-in secret masking, precise scheduling, conditional branching, native Slack alerts, and complete execution audit logging.

Prerequisites

  • A running Solace PubSub+ software broker or Solace Cloud instance reachable from the Kestra worker environment.
  • A dedicated canary health queue provisioned on the Solace Message VPN (e.g. canary.health.queue).
  • Broker credentials with produce and consume permissions on the canary queue.
  • A Slack incoming webhook URL for dispatching alerts.

Secrets

  • SOLACE_USERNAME: Broker username authorized to produce and consume messages on the canary queue.
  • SOLACE_PASSWORD: Password for the Solace broker user.
  • SLACK_WEBHOOK: Slack incoming webhook URL for alerting channels.

Note for Kestra Open-Source (OSS): Secrets are configured as base64-encoded environment variables formatted as SECRET_<NAME> (e.g. SECRET_SOLACE_USERNAME, SECRET_SLACK_WEBHOOK).

Inputs

Name Type Default Allowed Values Description
solace_host STRING "localhost:55555" Hostname and port Solace SMF messaging interface host:port
solace_vpn STRING "default" Valid VPN name Message VPN name on the Solace broker
canary_topic STRING "canary/health/probe" Valid topic path Solace topic destination for synthetic canary publish
queue_name STRING "canary.health.queue" Valid queue name Dedicated queue subscribed to the canary topic
queue_type SELECT "DURABLE_NON_EXCLUSIVE" Access types Solace queue access type
latency_sla_ms INT 2000 Positive integer Max round-trip transit latency in ms
alert_mode SELECT "ALERT" "ALERT", "AUDIT_ONLY" Operational alerting mode on breach

Outputs

  • {{ outputs.publish_canary_probe.messagesCount }}: Total number of synthetic messages published to the queue.
  • {{ outputs.consume_canary_probe.messagesCount }}: Total number of canary messages retrieved from the queue.
  • {{ outputs.classify_delivery_health.value }}: Health classification verdict (HEALTHY, SLA_BREACH, TIMEOUT_UNCONSUMED, PUBLISH_FAILED).

Quick start

  1. Start a local Solace PubSub+ Standard broker container using Docker on host port 8180 and 55555 (avoiding port 8080 collision with Kestra UI):

    docker run -d
    --name kestra-solace
    -p 8180:8080
    -p 55555:55555
    --shm-size=1g
    --env username_admin_globalaccesslevel=admin
    --env username_admin_password=admin
    --ulimit nofile=2448:1048576
    solace/solace-pubsub-standard:latest

  2. Connect the broker container to your Kestra Docker network:

    docker network connect YOUR_KESTRA_NETWORK kestra-solace

    Verify your network name with docker network ls.

  3. Provision the canary queue on the Solace broker using the Solace CLI or Web Admin interface:

    docker exec -i kestra-solace /usr/sw/loads/currentload/bin/cli -A -s cliscripts/create_queue.cli << 'EOF' enable configure message-spool message-vpn default create queue canary.health.queue permission all consume subscription topic canary/health/probe no shutdown end EOF

  4. Add the SOLACE_USERNAME, SOLACE_PASSWORD, and SLACK_WEBHOOK secrets to your Kestra environment.

  5. Import this blueprint into your Kestra instance.

  6. Run the flow manually with alert_mode: AUDIT_ONLY to verify connectivity and benchmark baseline transit latency.

  7. Enable periodic_canary_schedule to begin automated 15-minute synthetic health sweeps.

How to extend

  • Add multi-region mesh probing by executing synthetic produce and consume cycles across distinct Solace broker nodes in separate availability zones.
  • Route degraded performance alerts to PagerDuty or Opsgenie using Kestra notification plugins based on consecutive failure counts.
  • Persist latency measurements into a time-series database such as InfluxDB or Prometheus using complementary Kestra database tasks.
  • Extend the probe payload to include binary or Avro-serialized data structures to validate multi-protocol gateway translation.

Links

Pitfalls

  • Queue and topic subscription requirement: The target canary.health.queue must be pre-provisioned on the Solace broker with permission all consume, no shutdown, and an active topic subscription to canary/health/probe (e.g. subscription topic canary/health/probe). The Kestra Solace Produce task publishes to the topic destination, and the broker routes messages to the subscribed queue for the Consume task.
  • Web UI port collision: The Solace broker's default web admin management interface listens on port 8080, which conflicts with Kestra's web UI. Always map container port 8080 to host port 8180 (e.g. -p 8180:8080). The messaging interface uses port 55555.
  • Container network resolution: When Kestra and Solace run in separate Docker containers, localhost:55555 refers to the Kestra container. Use the container hostname kestra-solace:55555 on a shared Docker bridge network.
  • Inactive consumers and exclusive queues: When using DURABLE_EXCLUSIVE queue types, only one consumer can bind at a time. If an external client holds an active exclusive bind, the sentinel's Consume task will fail. Use DURABLE_NON_EXCLUSIVE for shared canary testing.
See How

New to Kestra?

Use blueprints to kickstart your first workflows.