Cases3 cases

1 to 3 of 3

1. IL-0286 An exercise cleanup destroyed Honeycomb's Kafka brokers, leaving partitions leaderless and ingest crash-looping

   Honeycomb2025

   Symptoms

   On 5 December, during the cleanup after a zonal failover exercise in production, Honeycomb destroyed Kafka brokers on purpose as a runbook step, and several topic partitions lost every broker that held them and became fully leaderless. Any Honeycomb team or environment whose assigned partitions were all unavailable could no longer have its data ingested.

   Container crash loopData lossNode disk fullMonitoring outage

   Trigger

   During the cleanup that rebalances workloads after a successful zonal failover exercise, Honeycomb followed its runbook and destroyed Kafka brokers on purpose. Older, in-sync brokers were killed by accident, so some topic partitions lost every broker that held them.

   Root cause

   Operator error

   Component

   Message broker

   Contributing factor

   No safeguard on destructive changeUnrepresentative stagingSignal buried in noiseHarmful manual action

   Detection

   Responders noticed through the alerting noise that the ingest service Shepherd had gone into a crash loop more than an hour earlier. On Saturday morning they saw that the Kafka balancing jobs were not progressing and disk usage had not improved, and once the metadata topics were repaired, SLO processing triggers fired about ~18h of late data.

   Remediation

   • Marked the impacted partitions read-only on the producer side, which stopped Shepherd's crash loop
   • Ran partition reassignments to bring customers back to normal
   • Turned off the Kafka autobalancer and left a manual reassignment plan running overnight
   • Reduced local retention on Kafka to rely on S3 tiered storage for longer retention
   • Repaired the broken _confluent-tier-state and __consumer_offsets partitions, which unblocked SLO processing
   • Turned off ingest to stop the brokers from running out of disk
   • Turned off tiered storage, which freed the broker disk space at once
   • Reopened ingest, which ended the customer impact
   • Truncated the fully damaged Retriever partitions and left them read-only
   • Extended the binlog retention of the MySQL read-only replica because Activity Log could not publish to Kafka
   • Patched Retriever so its nodes could idle live and serve old data despite broken offsets
   • Made a one-time offset reset work in Retriever
   • Evacuated to a new Kafka cluster with new topics and partitions
   • Booted an Activity Log database instance from 9 December and replicated from it to limit data loss
   • Cleaned up the older Kafka clusters

   Action items

   • Consolidate internal documentation better as the company grows

   Lessons

   Many elements of this outage were already known: similar outages, workaround plans, RFCs, migrations and procedures for running such exercises safely existed, but the documents were unknown outside their authors or hard to find. Flexible, locally controlled work is easy to defer again and again in favour of urgent work, and Honeycomb wants to notice when deferring becomes a reflex. Many key interventions came from people who no longer owned the components, which shows drift between team boundaries and the coupling inside the system. The pre-production clusters were too small to reproduce the flaw, and tests on a cluster closer to production would have made catching it much more likely. Coordination and public communication were also hard: senior engineers tended to take the lead automatically, and customers said the updates gave too much detail about minor beta features.

   View case
2. IL-0280 Kafka brokers in many New Relic cells ran out of disk, leaving US data collection and alerting unusable for hours

   New Relic2021

   Symptoms

   On 29 July 2021, data collection and alerting in New Relic's US region became unusable for many customers for several hours. It began with one unresponsive Kafka broker in a single cell of NRDB, New Relic's telemetry data platform, and over the following hours Kafka brokers in more and more cells failed as their disks filled up.

   Node disk fullThroughput degradationMonitoring outage

   Trigger

   Responders used an incident response tool to extend Kafka data retention for the degraded cell so that its backlog would not be lost. The retention increase was larger than usual, and the tool applied it to all cells of the same type, not only the affected one.

   Root cause

   Operator error

   Component

   Message broker

   Contributing factor

   Harmful manual actionNo staged rolloutSignal buried in noiseUnverified assumption

   Detection

   Engineers saw a Kafka broker in one cell become unresponsive on the morning of 29 July. Later a monitoring alert warned that disk space was running low, but it fired together with unrelated warnings from several other systems and was missed.

   Remediation

   • Restarted the unresponsive Kafka broker by hand, while the automated restart was also running
   • Resolved the disk space problem on the Kafka brokers, after which service recovered slowly

   Lessons

   Cell isolation is the strongest protection against a widespread disruption, and emergency tools have to respect it just as normal operations do. Emergency response tools must be safe to use in chaotic situations without losing their ability to work. Engineers' attention is limited, so incident response processes and alerts need regular review to direct it at the most important signal.

   View case
3. IL-0337 EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas

   Amazon Web Services2011

   Symptoms

   From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these "stuck" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.

   Storage disconnected or stale mountsNetwork unreachableControl plane lagHigh error rateFailover failureData loss

   Trigger

   During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.

   Root cause

   Operator error

   Component

   Cloud block storageDatabase

   Contributing factor

   Automation amplificationRetry stormNo headroomExcessive blast radiusSignal buried in noise

   Remediation

   • Rolled back the incorrect traffic shift, which restored network connectivity
   • Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT
   • Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT
   • Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space
   • Changed the EBS control plane so new EBS-backed instance launches stopped failing
   • Moved spare server capacity physically from across the US East Region into the degraded cluster
   • Adjusted the negotiation throttles so the new servers could join without flooding the old ones
   • Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog
   • Restored the remaining volumes from S3 snapshots taken early in the event
   • Restored volumes on failed machines that had no snapshot after forensic work
   • Intervened by hand on the RDS multi-AZ instances that did not fail over automatically

   Action items

   • Audit the change process and add automation to prevent the traffic shift mistake
   • Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events
   • Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes
   • Test and deploy the fix for the race condition that crashed EBS nodes
   • Fix the RDS bug that kept multi-AZ instances from failing over automatically
   • Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow
   • Make the EBS control plane aware of Availability Zones so it sheds load when over capacity
   • Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster
   • Offer multiple Availability Zones to Amazon VPC customers
   • Provide better tools for building multi-AZ applications that survive the loss of a zone
   • Host free webinars and publish whitepapers on fault-tolerant architecture
   • Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models
   • Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume
   • Send more frequent and detailed customer updates and staff developer support more widely during events
   • Develop tools that show through the APIs whether instances are impaired

   Lessons

   AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.

   View case

By root cause1