What does AceMQ Apache Druid support include?

Druid support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, ingestion pipeline review, segment and compaction strategy, cluster sizing and tiering, CVE and patch advisory, quarterly health checks, and upgrade or migration support. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

Our Kafka ingestion keeps falling behind. Where do you start?

With the supervisor status and per-partition consumer lag, because those two together tell you whether tasks are failing or simply undersized. The most common cause is indexing tasks dying and being restarted in a loop, which keeps the supervisor reporting as running while offsets barely move — often from a parse exception on a malformed record, or a task exceeding its heap on a high-cardinality dimension. The second most common is task slot starvation: the number of tasks per supervisor multiplied by taskDuration exceeds the total worker capacity across MiddleManagers, so new tasks queue rather than run. We fix the failing tasks first for immediate relief, then right-size task count and duration against partition count so the problem doesn't return under the next traffic increase.

How fast do you respond to a Druid production outage?

P1 emergencies — ingestion stopped, segments unavailable, queries failing cluster-wide — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends, and holidays.

Query performance has degraded slowly over a year. What causes that pattern?

Almost always segment proliferation with compaction not running. Druid answers a query by fanning out to every segment covering the time range, and the Broker merges the results — so cost scales with segment count, not just data volume. Streaming ingestion produces many small segments by design, and auto-compaction is supposed to consolidate them into target-sized segments afterward. When compaction is unconfigured, disabled during an incident and never re-enabled, or perpetually starved of task slots by streaming supervisors, segment count grows every day and query latency decays with it. We check the Coordinator's compaction status, give compaction its own capacity, and then backfill-compact the historical periods that accumulated while it was off.

Do you support Imply as well as open source Apache Druid?

Yes. We support self-managed Apache Druid, Imply Enterprise, and Imply Polaris. Imply packages Druid with additional tooling and its own management layer, but the underlying segment model, ingestion mechanics, and query fan-out behaviour are the same — which is where nearly all production incidents originate. We are careful about the boundary: where a problem is genuinely inside a vendor's proprietary component we will say so and help you drive it through their support rather than pretending to fix it.

Should we be using rollup, and why did enabling it make our segments bigger?

Rollup pre-aggregates rows that share identical values across every dimension at the chosen queryGranularity, so its benefit depends entirely on how much repetition exists in your dimension set. Adding one high-cardinality dimension — a request id, a session id, a full user agent string — makes nearly every row unique, at which point rollup compresses nothing while still paying the indexing cost, and the extra dimension's own index grows the segment. The fix is to move high-cardinality fields out of the rolled-up datasource, or to keep a separate non-rolled-up datasource for the queries that genuinely need per-event detail. We size this from your actual dimension cardinalities rather than from a rule of thumb.

How is AceMQ Apache Druid support priced?

Support is an annual contract priced on cluster size, required SLA tier, and coverage hours — not per incident and not per ticket. That structure exists so nobody hesitates to page us during an outage. Quotes are returned within 24 hours and scoped against your actual deployment, including node roles and tier layout, rather than a server count on a form.

Druid Support

24/7 Apache Druid Support with a 15-Minute Emergency SLA

AceMQ supports Apache Druid in production — Kafka supervisors falling behind, segments that never hand off to deep storage, brokers timing out because a query touches fifty thousand segments, and compaction that quietly stopped running months ago. Every ticket reaches a named senior engineer who knows your tier layout.

Senior Apache Druid engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical Apache Druid by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a Apache Druid outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior Apache Druid engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

Apache Druid problems we fix every week

These are real symptoms from real Apache Druid production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Real-time data is hours behind Kafka with no error in the UI

What we check firstSupervisor status for failed or repeatedly restarting indexing tasks, then per-partition consumer lag. A task that dies and is resurrected on a loop keeps the supervisor reported as running while the offsets barely advance, so the lag is the only honest signal.

Typical resolution1–2 hours

Segments are built but never become queryable

What we check firstWhether handoff completed — deep storage writes succeeding, metadata store entries created, and Historical nodes with free capacity to load them under the current load rules. Handoff waits for a Historical to accept the segment, so a full tier stalls it indefinitely.

Typical resolution1–3 hours

Broker queries time out on wide time ranges but work on narrow ones

What we check firstHow many segments the query fans out to. Too-fine segmentGranularity over a long retention produces tens of thousands of small segments, and the merge cost at the Broker dominates before any Historical is even busy.

Typical resolution2–4 hours

Query performance degrading steadily week over week

What we check firstAuto-compaction status in the Coordinator. Compaction that is unconfigured, disabled, or starved of task slots leaves the cluster accumulating small segments forever — performance decays on a schedule rather than falling over, which is why it goes unnoticed for months.

Typical resolution1–3 hours

Ingestion tasks queue and never start

What we check firstMiddleManager worker capacity against the number of concurrent supervisors and their task counts. Long-running realtime tasks hold slots for the full task duration, so a handful of streaming supervisors can consume every slot and starve batch ingestion completely.

Typical resolutionUnder 2 hours

Segment sizes exploded after enabling rollup

What we check firstDimension cardinality in the ingestion spec. Rollup only compresses rows that share every dimension value, so one high-cardinality dimension — a request id, a session id, a raw user agent — reduces the rollup ratio to nearly nothing while the index grows. queryGranularity matters just as much.

Typical resolution2–4 hours

Recent data queries suddenly hitting slow cold-tier segments

What we check firstCoordinator load rules. A period-based rule that no longer covers your actual query window, or a tier with insufficient capacity, silently moves recent segments to a cheaper tier or leaves them unloaded and served from deep storage.

Typical resolutionUnder 2 hours

Coordinator or Overlord flapping, cluster state inconsistent

What we check firstZooKeeper health and metadata store latency together. Druid depends on both for coordination and segment bookkeeping, and a slow PostgreSQL or MySQL metadata database presents as Druid instability rather than as a database problem.

Typical resolutionSame day

Resolution times reflect typical Apache Druid engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

Apache Druid problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

Apache Druid Streaming Ingestion Lag Remediation

Digital Advertising Exchange

Resolving Kafka supervisor lag caused by task slot exhaustion, oversized ingestion tasks, and handoff failures to deep storage.

Apache DruidKafkaKubernetes

Read case study

Support

Apache Druid Query Performance Support

Retail Analytics Provider

Ongoing support for broker timeouts and unpredictable query latency driven by segment sizing, cache behavior, and processing thread contention.

Apache DruidKafkaKubernetes

Read case study

Assessment

Apache Druid Tiered Historical Architecture Assessment

Energy Utility Operator

Assessment of historical tiering, retention rules, and replication factors to align infrastructure cost with how data is actually queried over time.

Apache DruidS3Kubernetes

Read case study

What's Included

Everything in your Apache Druid support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Ingestion stopped, segments unavailable, brokers timing out, or a Coordinator that won't hold a stable view of the cluster. A senior engineer joins a live bridge within 15 minutes with access to diagnose.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the ingestion spec, granularity, or capacity change that prevents recurrence. Delivered as standard, not on request.

Ingestion Pipeline Review

Kafka and Kinesis supervisor specs, task count and duration sizing, late-arriving data handling, and the schema and rollup decisions that determine segment size long before anyone sees a slow query.

Segment & Compaction Strategy

Segment granularity matched to retention and query patterns, auto-compaction configured with dedicated task capacity, and target segment sizing that keeps the Broker's fan-out cost manageable.

Cluster Sizing & Tiering

Per-role JVM heap and direct memory tuning for Broker, Historical, MiddleManager, and Coordinator, plus hot and cold tier load rules that match where your queries actually land.

Upgrades & Migrations

Rolling version upgrades across the full node set in the correct order, moves between self-managed and Imply, deep storage migrations, and migrations onto Druid from Elasticsearch or a warehouse.

Anywhere You Run It

We support Apache Druid wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

Apache Druid 26 – 31 (self-managed)Imply Enterprise & Imply PolarisDruid Operator on KubernetesOpenShiftAWS (EC2, EKS, S3 deep storage)Microsoft Azure (AKS, Blob deep storage)Google Cloud (GKE, GCS deep storage)HDFS deep storageZooKeeper & PostgreSQL/MySQL metadata storeKafka & Kinesis streaming ingestionBare metal & on-premiseAir-gapped / no outbound access

Why AceMQ

What you get that you don't get elsewhere

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your tier layout, your supervisor specs, and your retention rules — so a P1 call opens with a hypothesis rather than a tour of your cluster.

No Tier-1 Triage Layer

You reach a senior Druid engineer directly by phone, email, or Slack. Nobody collects details to hand off, and no escalation approval stands between you and someone who can read a supervisor payload.

We Understand the Whole Process Set

Druid is six coordinating services with different memory models and failure modes. Most incidents are misattributed to the process that reported the error rather than the one that caused it — Historical capacity showing up as a Broker timeout, for instance.

Ingestion and Query, Not Just One

Query performance in Druid is decided at ingestion time by granularity, rollup, and partitioning. We fix the spec that created the segments rather than tuning around the segments you already have.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am supervisor failure is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.

Full-Stack, Including the Dependencies

We diagnose across Kafka, ZooKeeper, the metadata database, deep storage latency, the JVM, and Kubernetes. Druid rarely fails alone, and its dependencies fail in ways that look like Druid bugs.

FAQ

Apache Druid support questions

Druid Degrades on a Schedule Long Before It Breaks

Segment sprawl, stalled compaction, and starved task slots build for months without an alert. Whether you need emergency response tonight or a contract that catches them early, AceMQ staffs every engagement with a named senior Druid engineer. Quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.