{"id":"IL-0287","org":"MongoDB","date":"2025-10-07","docs":[],"title":{"en":"One overloaded shard of MongoDB's internal monitoring database delayed Atlas metrics, alerts and cluster operations","ko":"Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다"},"domain":["database","observability"],"impact":{"scope":"Delayed or missing metrics in Atlas and Cloud Manager dashboards, Host Down alerts not firing, and delayed Atlas cluster management operations such as provisioning and resizing, intermittently over about 2 days; customer clusters and data were not affected","users":"MongoDB Atlas and Cloud Manager customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.mongodb.com/incidents/rdzgw5xds7gx","kind":"official-status","archived":"https://web.archive.org/web/20260412051102/https://status.mongodb.com/incidents/rdzgw5xds7gx"}],"summary":{"en":"MongoDB Atlas and Cloud Manager monitoring systems rely on an internal, sharded database cluster. High-traffic collections in it had not been sharded, so their load was concentrated on one shard and created a hotspot when load rose, and inefficient query patterns such as full collection scans added strain on that shard during normal operation. The postmortem dates the incident to October 6 and 7, when a rollout of an updated internal software version produced a temporary spike in resource demand, and together these overwhelmed the shard and delayed metrics ingestion and Atlas cluster operations. MongoDB applied mitigations to stabilise the system and then fixed the long-term causes; the status page marked the incident resolved at 20:03 UTC on 7 October 2025. There was no loss of data and no effect on the availability or performance of customer applications.","ko":"MongoDB Atlas 와 Cloud Manager 의 모니터링과 운영 시스템은 샤드로 나뉜 내부 데이터베이스 클러스터에 기댄다. 이 클러스터에서 트래픽이 많은 컬렉션 여럿이 샤딩되지 않은 채 샤드 하나에 몰려 있었고, 전체 컬렉션 스캔 같은 비효율적인 쿼리가 평소에도 그 샤드를 눌렀다. 여기에 새 내부 소프트웨어 버전을 롤아웃하면서 자원 사용량이 일시적으로 치솟아 그 샤드가 감당하지 못했다.\n\n2025년 10월 6일과 7일에 걸쳐 지표 수집이 늦어져 Atlas 대시보드에 운영 데이터가 제때 나오지 않았다. Host Down 알림이 울리지 않았고, 프로비저닝과 크기 조정 같은 클러스터 관리 작업이 늦어졌다. 상태 페이지에는 10월 7일 13:42 UTC 에 조사를 시작했다는 공지가 올라왔다. 이어 17:44 에 원인을 찾아 바로잡는 조치를 했다는 공지, 19:32 에 수정을 적용했다는 공지, 20:03 에 해결됐다는 공지가 올라왔다. MongoDB 는 먼저 시스템을 안정시키는 조치를 한 뒤 장기적인 근본 원인을 해결했다. 고객 클러스터와 데이터는 영향을 받지 않았다."},"trigger":{"en":"The rollout of an updated internal software version caused a temporary spike in resource demand on the internal database cluster.","ko":"새 내부 소프트웨어 버전을 롤아웃하는 동안 자원 사용량이 일시적으로 치솟아, 이미 부하가 몰려 있던 샤드의 부하가 예상한 한도를 넘었다."},"severity":"unknown","symptoms":["monitoring-down","database-overloaded","uneven-load"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Took corrective actions to stabilise the system and monitored their effect","ko":"원인을 찾아 바로잡는 조치를 하고 그 효과를 지켜봤다. 그동안 Host Down 알림, 지표, 일부 Atlas 클러스터 작업은 계속 늦거나 빠질 수 있었다."}},{"text":{"en":"Implemented a fix and monitored the results until the incident was resolved","ko":"수정을 적용하고 결과를 지켜봤으며, 이후 장애가 해결됐다."}}],"action_items":[{"text":{"en":"Shard the collections with concentrated load to spread traffic over more nodes","ko":"부하가 몰리는 컬렉션을 샤딩해 트래픽을 여러 노드에 고르게 나누고 샤드 하나에 몰리는 부하를 던다."}},{"text":{"en":"Optimise inefficient queries","ko":"비효율적인 쿼리를 최적화해 자원 사용을 개선하고 평소 작업의 지연을 줄인다."}},{"text":{"en":"Provision additional infrastructure capacity for higher traffic","ko":"늘어난 트래픽을 감당하도록 인프라 용량을 더 확보했다."}},{"text":{"en":"Refine capacity planning to anticipate future load spikes, using metrics from this event","ko":"앞으로의 부하 급증을 미리 내다보도록 용량 계획 절차를 다듬는다."}},{"text":{"en":"Redesign software rollouts to account for the predictable rise in resource demand during a rollout","ko":"롤아웃 중 예상할 수 있는 자원 수요 증가를 감안하도록 새 소프트웨어 버전 배포 절차를 다시 설계한다."}},{"text":{"en":"Keep monitoring how the sharding and query changes resolve the hotspots","ko":"엔지니어링 팀이 샤딩 전략과 쿼리 최적화의 성능을 계속 지켜보며 핫스팟이 제대로 풀렸는지 확인한다."}},{"text":{"en":"Expand the detection of elevated load conditions for faster anomaly detection and response","ko":"높은 부하 상태를 감지하는 피드백 장치를 넓혀 이상을 더 빨리 찾고 대응한다."}}],"contributing":["inefficient-query","no-spare-capacity"],"recurrence_of":null,"symptoms_text":{"en":"On 7 October 2025 MongoDB reported a delay in the metric ingestion pipeline of MongoDB Atlas and Cloud Manager. Metrics in Atlas dashboards arrived late or went missing, Host Down alerts did not fire, and Atlas cluster management operations such as provisioning and resizing were delayed, while customer clusters themselves stayed healthy and available.\n\nThe first investigation found high resource usage on one shard of the internal database cluster that backs the Atlas and Cloud Manager monitoring systems. Further review showed that high-traffic collections on that cluster were not sharded and sat on that single shard, that queries such as full collection scans added load to it, and that a rollout of an updated internal software version raised resource use beyond what had been expected. The postmortem describes partial impact that came and went over approximately 2 days.","ko":"MongoDB Atlas 와 Cloud Manager 에서 지표 수집 파이프라인이 늦어졌고, Atlas 대시보드의 지표가 늦거나 빠졌다. Host Down 알림이 울리지 않았고, 프로비저닝과 크기 조정 같은 Atlas 클러스터 관리 작업이 늦어졌다.\n\n영향은 약 이틀 동안 간헐적으로 나타났다. 고객 클러스터의 상태, 가용성, 데이터 무결성은 영향을 받지 않았다.\n\n처음 조사에서는 내부 백엔드 데이터베이스 클러스터의 샤드 하나에서 자원 사용량이 높은 것이 보였다. 더 살펴보니 트래픽이 많은데 샤딩하지 않은 컬렉션이 그 샤드에 몰려 있었고, 전체 컬렉션 스캔 같은 비효율적인 쿼리가 부하를 키우고 있었다."},"updated_at":"2026-11-14T12:33:54.240420Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0287","org_slug":"mongodb"}