{"id":"IL-0202","org":"Honeycomb","date":"2023-11-05","docs":[],"title":{"en":"A burst of queries and database writes exhausted connection pools and memory on Honeycomb's ingest hosts, and Kubernetes crash-loop back-off kept failed hosts offline so ingest capacity stayed too low to recover","ko":"갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다"},"domain":["kubernetes"],"impact":{"scope":"api.honeycomb.io US1 Event Ingest: a bit over 1h10m of partially available ingestion and about 5 minutes of complete ingestion outage","users":"unknown","region":"US1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Load shedding and auto-scaling were in place, yet a burst that arrived faster than the cache could spread its writes still took the ingest hosts down. During recovery, Kubernetes' crash loop back-off worked against the operators: the hosts that had failed stayed offline while the fleet needed every host. Clients that retry whole OTel batches after a partial drop can multiply traffic many times over, so per-source rate limits were what finally stabilised ingest.","ko":"Honeycomb 은 이번 장애를 이미 대비책이 있던 장애의 변형으로 보았다. 이번 장애는 그 대비책 일부를 비켜 가는 방식으로 일어났다. 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남으면서 급하게 늘린 용량을 깎아 먹었다. OTel 처럼 배치 단위로 성공과 실패를 알리는 프로토콜에서는 서버가 일부만 버려도 클라이언트가 배치 전체를 다시 보내 트래픽이 크게 불어날 수 있다."},"related":[],"sources":[{"url":"https://status.honeycomb.io/incidents/0l5rw6nppv2s","kind":"official-status","license":"unknown","archived":null}],"summary":{"en":"On November 5, 2023, Honeycomb's US1 event ingestion was partly available for a little over 1 hour 10 minutes and completely down for about 5 minutes. A sudden, very large number of queries from many separate connections reached the ingest hosts before auto-scaling could react; Honeycomb suspects recent optimisations to its ingest code, which shifted the workload somewhat, slowed auto-scaling down. The requests set off many database writes that interfered with each other and clogged the connection pools. This happened faster than the cache, which would have avoided that work, could spread the writes to all hosts, and it drove up memory use on the ingest hosts until they died.\n\nLoad shedding did not prevent the restarts. When engineers scaled up the fleet, Kubernetes' crash loop back-off kept the previously failing hosts offline, so capacity stayed too low. Engineers cut off most ingest for a few minutes to build back enough ingest hosts, which recovered the system quickly. By the time the hosts were back, the writes had gone through and the caches had refreshed themselves, but some customers were still sending more than 20 times their usual traffic, probably whole-batch OTel retries. Honeycomb temporarily lowered the rate limits for those sources until the traffic subsided, and the pipeline became stable.\n\nHoneycomb describes this as a variation of earlier incidents for which it already had mitigations, but this time the failure got around some of them.","ko":"11월 5일 일요일 Honeycomb 의 US1 이벤트 수집은 1시간 10분 남짓 일부만 동작했고, 약 5분 동안은 완전히 멈췄다. 몇 분 사이에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔고, 이 요청들이 데이터베이스 쓰기를 대량으로 일으켰다. 쓰기들이 서로 부딪치면서 커넥션 풀이 막혔다. 이 작업을 건너뛰게 해 주는 캐시가 쓰기 결과를 아직 모든 호스트에 전파하지 못한 때였다. 그 결과 수집 호스트의 메모리 사용량이 빠르게 늘었고, 호스트들이 죽었다. 오토스케일링은 그보다 늦게 반응했다. 최근 수집 코드를 최적화하면서 워크로드 특성이 조금 바뀐 것이 오토스케일링을 늦췄을 수 있다.\n\n로드 셰딩이 있었는데도 수집 호스트들은 재시작을 되풀이했다. 엔지니어들이 호스트 수를 수동으로 크게 늘렸지만, 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남아 용량이 모자랐다. 일부 발신처의 공격적인 재시도도 겹쳤다. 엔지니어들은 몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다. 그 뒤 시스템은 빠르게 회복했다.\n\n호스트가 모두 돌아왔을 때는 쓰기가 끝났고 캐시도 스스로 갱신된 상태였다. 그래도 일부 고객이 평소의 20배가 넘는 트래픽을 보내 클러스터가 안정되지 못했다. OTel 프로토콜은 스팬 배치 전체에 성공이나 실패 하나로만 응답한다. Honeycomb 은 배치 가운데 일부만 버려도 클라이언트가 빠진 부분을 채우려고 배치 전체를 다시 보냈을 것으로 추정했다. 이 고객들의 트래픽에 걸린 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮추자 수집 파이프라인 전체가 안정됐다."},"trigger":{"en":"An abnormally large number of queries arrived from many separate connections within a few minutes.","ko":"몇 분 사이에 여러 곳에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔다."},"severity":"sev1","symptoms":["high-error-rate","high-latency","crash-loop","service-unavailable","database-overloaded"],"timeline":{"detected_after":"13m","resolved_after":"1h15m"},"date_kind":"incident","detection":{"en":"Standard alerting notified the on-call engineers about ingestion performance and stability, and the automated load-shedding mechanisms added notifications when they tripped. The first status post, about alerts on a higher than normal error rate and response time, went up at 18:28 PST (02:28 UTC), 13 minutes after the 02:15 UTC start.","ko":"기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 자동 로드 셰딩 장치도 작동하면서 알림을 더 보냈다. 상태 페이지 첫 공지는 18:28 PST 에 올라왔다."},"components":["database","cache"],"root_cause":"capacity","remediation":[{"text":{"en":"Scaled the ingest fleet up manually and aggressively","ko":"엔지니어들이 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다."}},{"text":{"en":"Cut off most ingest for a few minutes so the ingest hosts could come back with enough capacity","ko":"몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다."}},{"text":{"en":"Temporarily lowered the rate limits for the most aggressive traffic sources until their traffic subsided","ko":"가장 공격적으로 트래픽을 보내던 발신처의 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮춰 클러스터를 안정시켰다."}}],"action_items":[{"text":{"en":"Keep the ingest fleet scaled up to prevent a repeat while longer-term fixes are worked on","ko":"장기 해결책을 마련하는 동안 같은 장애가 반복되지 않도록 수집 호스트 수를 늘려 두었다."}},{"text":{"en":"Decide on the projects that will address these failure paths","ko":"이번 장애 경로를 막을 프로젝트를 정하는 일에 집중한다."}}],"contributing":["retry-storm","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"Standard alerting paged Honeycomb's on-call engineers about the performance and stability of event ingestion, and the automated load-shedding mechanisms tripped and sent further notifications. The status page described a higher than normal error rate and response time on the ingestion service.\n\nFrom about 02:15 UTC, customers sending events to the API ingestion endpoint saw processing slow down and fail on and off, until ingestion stopped completely for a few minutes. The system came back briefly at 02:50 UTC but was not fully stable until 03:30 UTC. The incident severity was raised to critical as more ingestion traffic was dropped.\n\nLoad shedding was meant to drop traffic early enough to stop ingest hosts from failing one after another, but the ingest fleet still went through a series of restarts. Engineers scaled the fleet up by hand to add capacity, and then saw that Kubernetes' crash loop back-off was holding the hosts that had already failed offline, so the cluster still did not have enough capacity.\n\nSome traffic sources retried so aggressively that it looked like a thundering herd, and some customers were sending more than 20 times their usual traffic. Honeycomb first took this for a backfill, then suspected retries: the OTel protocol can only report success or failure for a whole batch of spans, so when Honeycomb dropped part of a batch, clients likely re-sent the entire batch.","ko":"02:15 UTC 무렵부터 API 수집 엔드포인트의 이벤트 처리가 느려졌다. 실패는 났다가 멎기를 되풀이했고, 끝내 몇 분 동안 수집이 완전히 멈췄다. 기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 상태 페이지 첫 공지는 수집 서비스의 오류율과 응답 시간이 평소보다 높다는 알림을 조사하고 있다는 내용이었다.\n\n시스템을 지키려는 자동 로드 셰딩도 작동해 알림을 더 보냈다. 로드 셰딩은 트래픽 일부를 일부러 버려 수집 호스트가 연쇄로 죽는 것을 막는 장치다. 트래픽을 더 공격적으로 버리도록 로드 셰딩이 걸려 있었는데도 수집 호스트들은 재시작을 되풀이했다. 18:45 PST 에는 버려지는 수집 트래픽이 늘어 장애 등급을 critical 로 올렸다.\n\n엔지니어들은 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다. 그런데 앞서 실패한 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 계속 오프라인으로 남았고, 클러스터 전체 용량은 여전히 모자랐다. 트래픽을 보내던 일부 발신처는 공격적인 재시도를 한꺼번에 쏟아냈다.\n\n02:50 UTC 에 시스템이 잠깐 회복했지만 완전히 안정된 것은 03:30 UTC 였다. 호스트가 모두 돌아온 뒤에도 클러스터는 안정되지 않았다. 일부 고객이 평소의 20배가 넘는 트래픽을 보내고 있었다. 엔지니어들은 처음에 과거 데이터를 한꺼번에 다시 보내는 백필로 생각했지만, 곧 예상하지 못한 재시도 동작을 의심했다."},"updated_at":"2026-11-10T00:00:40.915597Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0202","org_slug":"honeycomb"}