Graph
Cases5 cases
1 to 5 of 5
IL-0367Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on themMicrosoft Azure2024- Symptoms
From 21:40 UTC on 18 July 2024, virtual machines in the Azure Central US region lost access to their disks, and the services running on those VMs failed. Azure SQL Database and SQL Managed Instance showed unhealthy nodes and login failures, Cosmos DB requests failed, and service management operations failed across many Azure services.
- Trigger
Routine changes to the VM host fleet led to a new allow list of VM host address ranges being generated and published to all Storage scale units in Central US. Recent network configuration changes had made some of the infrastructure file servers that hold the source data unreachable from the server generating the list, so the published list was incomplete.
- Root cause
- Component
- Contributing factor
- Detection
Service monitoring detected the drop in VM availability at 22:06 UTC while the allow list update was being published. SQL monitoring detected unhealthy nodes and login failures within one minute of SQL becoming unavailable, and monitoring flagged the availability drop for Cosmos DB, SQL DB and SQL DB Managed Instance at 22:14 UTC.
- Remediation
- Halted the allow list update workflow worldwide
- Paused all deployments in the Central US region
- Paused compute buildout deployments in all regions
- Updated the configuration of all Storage scale units in Central US, restoring storage availability by 02:55 UTC
- Started geo-failovers for SQL databases with automatic failover policies
- Restarted SQL gateway nodes to refresh their caches and route connections to the right nodes
- Forced completion of SQL failovers that had not completed
- Failed over the Cosmos DB control plane and active-passive accounts with a write region in Central US
- Cancelled customer-triggered graceful switch region operations that blocked Cosmos DB failovers
- Removed locks on Cosmos DB service metadata to force-complete stuck failovers
- Repaired impacted Cosmos DB partitions for single-region accounts
- Repaired backend nodes and failed Cosmos DB accounts back to Central US, redoing failback where it failed
- Action items
- Make the allow list generation workflow detect incomplete source information and halt
- Alert on storage requests rejected by allow list checks
- Deploy allow lists one Availability Zone and storage type at a time, over 24 hours
- Add VM health checks and an automatic stop to the allow list deployment workflow
- Reevaluate the policy for Microsoft-managed failover of SQL failover groups
- Fix the Cosmos DB failback workflow that broke some MongoDB drivers for MongoDB API accounts
- Fix Cosmos DB failback for accounts with private endpoints so it does not need redoing
- Make the storage data-plane firewall reject invalid allow lists and keep the last-known-good state
- Improve Azure NetApp Files monitors so impacting events are detected and classified in time
- Monitor more Azure NetApp Files service metrics to correlate similar events faster
- Make the SQL Service Fabric cluster location change notifications reliable under load
- Make SQL geo-failover workflows more robust so they complete
- Remove the issues that delayed 5% of Cosmos DB failovers
- Migrate Azure DevOps customer metadata to the right geography
- Decouple Azure NetApp Files regional reads and writes to keep this class of issue to one region
- Evaluate caching to reduce Azure NetApp Files reliance on stored utilization data
- Add automatic per-partition failover for Cosmos DB multi-region active-passive accounts
- Build the Resilient Ephemeral OS disk improvement so VMs survive storage incidents better
IL-0291GitLab.com's redis-sidekiq Sentinel could not elect a primary after a GCP host error, so Sidekiq was down for 30 minutesGitLab2023- Symptoms
GitLab.com showed widespread, erratic behaviour and more 500 errors for about 30 minutes while its redis-sidekiq Redis was down. Alerts in the #production channel began with Redis client errors and spread to error SLO violations on several services, such as the Webservice and API load balancer and Puma.
- Trigger
The VM of the primary node, redis-sidekiq-03-db-gprd, failed on a GCP host error and was reset and moved to another node.
- Root cause
- Component
- Contributing factor
- Detection
Several alerts in the #production channel, first Redis client errors and then error SLO violations on several services, such as the Webservice and API load balancer and Puma.
- Remediation
- Restarted the failed Redis node so Sentinel had enough nodes to elect a primary
- Action items
- Alert when the Sentinel service is down
- Make merge requests robust to Redis Sidekiq outages
- Lessons
An alert on a down Sentinel node would have kept enough nodes up to form a quorum when failover was needed, and could have avoided the incident entirely. Removing a noisy alert earlier may have let the down node go unnoticed.
IL-0241A database shard could not elect a new primary, and the Stripe API failed most requests in two periods on one dayStripe2019- Symptoms
On 10 July 2019 the Stripe API failed a substantial majority of requests twice, from 16:35 to 17:02 UTC and from 21:14 to 22:47 UTC. In the first period automated monitoring detected within a minute that a database cluster had failed to elect a new primary.
- Trigger
The primary node of a database cluster failed at 16:35 UTC while one shard had several stalled nodes. The second period was set off by rolling the election protocol back to the previous minor version at 20:42 UTC.
- Root cause
- Component
- Contributing factor
- Detection
Automated monitoring detected the failed election within a minute, and the team was alerted at 16:36 UTC. The second period was announced at 21:14 UTC by automated alerts that some shards in the cluster were unavailable.
- Remediation
- Restarted all nodes of the database cluster, which forced a successful primary election
- Updated the production configuration and restarted the database cluster's nodes
- Ramped traffic back up, putting services for user-initiated API requests first
- Action items
- Alert when nodes stop reporting their replication lag
- Alert when a shard enters a state that could trigger the election fault
- Work with the database maintainers on a fix for the underlying fault
- Add circuit breaking on failed operations to particular database clusters
- Use fault isolation to contain the impact of a single failed shard
- Limit the resources used by clients that keep retrying failed requests
- Add procedures and tooling that make rapid configuration changes during incident response safer
IL-0588AppOptics metrics APIs returned 5xx as Kafka partitions stayed leaderless after an AWS power event hit their ZooKeeperAppOptics2018- Symptoms
On May 31, 2018 from 21:53 UTC the metrics APIs of AppOptics and Librato returned a 5xx for a majority of incoming metric data. APM metrics and traces sent from AppOptics APM were affected, and many alert notifications were delayed.
- Trigger
A power event in one of AWS's availability zones in us-east-1 cut off nodes in several critical parts of the AppOptics and Librato infrastructure, including the ZooKeeper node that was then the leader of the ensemble coordinating the Kafka brokers.
- Root cause
- Component
- Contributing factor
- Remediation
- Restarted one ZooKeeper node by hand to force a leader election, after which the ensemble regained quorum
- Restarted every Kafka broker in a rolling restart until all partitions were back online
- Worked through the backlog, including the backlog of alerts, and resumed normal operations
- Action items
- Isolate the Kafka clusters better across availability zones and regions
- Stop sharing one ZooKeeper ensemble across Kafka clusters
- Run game days on this failure and check whether newer Kafka versions fix it
- Put in place more checks that notify the team earlier about subsystems that need extra help to recover
- Lessons
Running services across several availability zones and more than one Kafka cluster did not isolate the pipeline from the failure of one zone, because partitions of different clusters sat in the same zones and the clusters shared one ZooKeeper ensemble. More operational monitoring of the subsystems that needed help to recover would have led to a faster recovery.
IL-0388A Google Cloud live migration took a Discord Redis primary offline, and the failover broke API instances and then guildsDiscord2017- Symptoms
At about 14:01 PDT on 13 October 2017, Discord engineers were alerted to anomalies by real-time metrics and monitoring. A Redis instance that was the primary of a highly available cluster used by the API services had dropped offline after Google Cloud Platform migrated it automatically, and some API instances did not handle the failover to the secondary node correctly.
- Trigger
Google Cloud Platform automatically migrated the Redis instance that was the primary of a highly available cluster used by the API services, and the node incorrectly dropped offline.
- Root cause
- Component
- Contributing factor
- Detection
Real-time metrics and monitoring alerted engineers at 14:01 PDT. The second phase was seen at 15:41 as another anomaly in monitoring, and end user reports of servers appearing offline were escalated at 15:42.
- Remediation
- Ran a rolling restart of all API instances to clear the Redis connection issues
- Corrected the misconfigured edge caching rule for the expensive API route
- Disabled the problem API endpoint on the edge network
- Recovered the Cassandra cluster
- Ran a second rolling restart of all API instances for the latency left by the Cassandra issues
- Removed the misbehaving guilds node from the service hashring
- Forcefully restarted the misbehaving guilds node
- Restarted the whole service, forcing all users to reconnect
- Blocked traffic that relied on the failing push component to reduce its load
- Corrected the API setting that lets users reconnect quickly and safely
- Action items
- Fix the known issues with Redis failover within the coming weeks
- Change the cached route so this type of error does not degrade other services
- Monitor the signals that would have warned of the cascading failure
- Improve the reliability and failure handling of the affected services
- Roll out an update of the library with the suspected flaws
These 5 cases involve Database and Database failover manager. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause3
Configuration change1 case
- Contributing factor
- Organisation
Cloud provider outage2 cases
- Contributing factor
- Organisation
Software defect2 cases
- Contributing factor