{"id":"IL-0026","org":"Blue Matador","date":"2019-06-15","docs":["https://github.com/SumoLogic/fluentd-kubernetes-sumologic/issues/121"],"title":{"en":"Kubernetes nodes hit SystemOOM because fluentd-sumologic log shipper pods had no memory limits","ko":"메모리 제한이 없는 fluentd-sumologic 파드가 메모리를 다 써서 운영 쿠버네티스 노드 두 대에 이틀 연속 SystemOOM 이 났다"},"domain":["kubernetes","aws","observability"],"impact":{"scope":"two nodes in the production cluster; no application pods restarted and no noticeable interruption","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When checking for restarted pods, look in every namespace, not only the application one. Set resource requests and limits on every pod, third-party ones in particular, so that one workload cannot exhaust a node. Investigate side signals such as the disk I/O spike while the logs still exist.","ko":"재시작된 파드를 확인할 때는 모든 네임스페이스를 본다. 이번에는 fluentd-sumologic 파드가 별도 네임스페이스에 있어 첫날 원인을 놓쳤다.\n\n모든 파드, 특히 서드파티 애플리케이션에는 리소스 요청과 제한을 지정한다. 제한이 있으면 메모리 문제를 고치지는 못해도 그 문제가 해당 파드들 밖으로 번지지 않게 막을 수 있다.\n\n보이는 문제는 증거가 남아 있을 때 근본 원인까지 파고든다. 이번에는 디스크 IO 가 늘어난 이유를 확인할 로그가 사라진 뒤였다."},"related":[],"sources":[{"url":"https://www.bluematador.com/blog/post-mortem-kubernetes-node-oom","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Two production nodes at Blue Matador, on two consecutive evenings in June 2019, reported SystemOOM events. In both cases the memory had been consumed by the fluentd-sumologic pods, the Ruby-based log shipper that forwards logs to Sumo Logic. Their manifest set no resource requests or limits, so nothing stopped them from growing until the whole node was short of memory. Kubernetes resolved each event by killing and restarting those pods, and no application pod was affected.\n\nThe first event was dismissed because the check for restarted pods looked only at the application namespace. After the second event the engineer restarted all sumologic pods so they started from low memory, then on Monday added the RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9 environment variable suggested in a GitHub issue and set memory requests of 128Mi and limits of 1024Mi (CPU 100m and 250m) on the pods. Node memory stayed stable in the following days.\n\nEach SystemOOM was preceded by heavy disk activity and a falling EBS Burst Balance on the node's root volume. Swap was not enabled, and the cause of that disk I/O was never found because the logs from before the events were no longer available.","ko":"Blue Matador 의 운영 쿠버네티스 클러스터에서 2019년 6월 15일과 16일 이틀에 걸쳐 서로 다른 노드 두 대에 SystemOOM 이벤트가 났다. 노드는 곧바로 회복했고 애플리케이션 파드는 재시작되지 않아 눈에 띄는 서비스 중단은 없었다. 매번 SystemOOM 과 함께 루트 볼륨의 EBS Burst Balance 가 낮아졌다는 경고가 왔다. EBS 지표는 늘 10분에서 15분 늦게 들어오므로 경고는 SystemOOM 보다 늦게 왔다. 그러나 CloudWatch 데이터를 보면 burst balance 가 가장 낮았던 시점은 SystemOOM 보다 앞섰다.\n\n원인은 로그 수집용 fluentd-sumologic 파드였다. 이 파드들이 노드 메모리를 다 쓰자 쿠버네티스가 이들을 죽이고 다시 띄워 메모리를 되찾았다. 다른 파드는 영향을 받지 않았다. Sumologic 쪽 로그량은 꾸준했고 문제 시점에 로그가 늘지 않았으므로, 로그 유입이 갑자기 늘어서 생긴 일은 아니었다. 매니페스트를 보니 fluentd-sumologic 에는 리소스 요청과 제한이 하나도 없었다.\n\n담당자는 일요일 저녁에 모든 sumologic 파드를 재시작해, 파드들이 메모리를 적게 쓰는 상태에서 다시 출발하게 했다. 월요일에는 GitHub 이슈에서 찾은 Ruby GC 설정을 환경 변수로 넣고, 메모리 요청 128Mi, 제한 1024Mi, CPU 요청 100m, 제한 250m 을 지정해 배포했다. 며칠 뒤 노드 메모리가 안정된 것을 확인했다.\n\nSystemOOM 과 함께 디스크 IO 가 늘어난 이유는 끝내 밝히지 못했다. 노드에서 free 와 swapon -s 로 확인한 결과 스왑은 꺼져 있었다. 담당자는 두 가지 가능성을 추정했다. 하나는 그때 fluentd-sumologic 파드가 로그를 많이 썼을 가능성이고, 다른 하나는 메모리가 부족할 때 로그를 많이 쏟아내는 쿠버네티스나 journald 로그 소스가 fluentd 설정에서 걸러지고 있었을 가능성이다. 문제 직전의 로그 파일은 이미 남아 있지 않아 더 파고들 수 없었다."},"trigger":{"en":"Memory use of the fluentd-sumologic log shipper pods grew until the node ran out of memory; log volume in Sumo Logic had been steady, so a burst of logs was not the cause.","ko":"메모리 요청과 제한 없이 배포된 fluentd-sumologic 파드가 노드 메모리를 계속 차지해 노드에 SystemOOM 이 났다."},"severity":"unknown","symptoms":["oom-killed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Blue Matador's own monitoring product alerted on the SystemOOM event, followed minutes later by a low EBS Burst Balance warning for the same node.","ko":"Blue Matador 의 자체 모니터링이 노드의 SystemOOM 이벤트 알림과 EBS Burst Balance 가 낮아졌다는 경고를 보냈다. 원인 파드는 Datadog 의 메모리 사용량 그래프에서 찾았다."},"components":["telemetry-agent","memory-limit"],"root_cause":"capacity","remediation":[{"text":{"en":"restarted all fluentd-sumologic pods so they started with low memory","ko":"모든 sumologic 파드를 재시작해, 파드들이 메모리를 적게 쓰는 상태에서 다시 출발하게 했다."}},{"text":{"en":"set RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR to 0.9 on the fluentd-sumologic pods","ko":"fluentd-sumologic 파드 스펙에 환경 변수 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR 를 \"0.9\" 로 넣어 배포했다."}},{"text":{"en":"added memory requests of 128Mi and limits of 1024Mi, and CPU requests of 100m and limits of 250m, to the fluentd-sumologic pods","ko":"fluentd-sumologic 에 메모리 요청 128Mi, 메모리 제한 1024Mi, CPU 요청 100m, CPU 제한 250m 을 지정했다."}}],"action_items":[{"text":{"en":"Apply default resource limits and resource quotas so that every pod runs with requests and limits","ko":"기본 리소스 제한과 리소스 쿼터를 함께 써서 모든 파드가 요청과 제한을 갖게 하는 작업을 백로그에 올렸다."}}],"contributing":["no-resource-limits","early-signal-ignored"],"recurrence_of":null,"symptoms_text":{"en":"On a Saturday at 5:12 pm, Blue Matador's own monitoring raised a SystemOOM event for one node in the production Kubernetes cluster. Four minutes later a second warning reported a low EBS Burst Balance on that node's root volume. CloudWatch data showed the burst balance had actually bottomed out at 5:02 pm, before the memory event; the warning arrived late because EBS metrics lag 10 to 15 minutes.\n\nThe engineer ran kubectl get pods and saw no application pod had died, and kubectl top nodes showed the node back at about 60% memory. With the node healthy and nothing restarted in the application namespace, the event was treated as a one-off and left for Monday.\n\nThe next evening, at 6:02 pm, a different node raised the same SystemOOM event, again followed by a low EBS Burst Balance warning; the burst balance had been falling for about 2.5 hours beforehand. Pods again looked fine and node memory sat just under 70%. Datadog memory graphs then showed that the node's memory had been taken by the fluentd-sumologic pods and dropped sharply at the moment of the SystemOOM: Kubernetes had killed and restarted those pods to reclaim memory. The restarts had been missed the day before because the fluentd-sumologic pods ran in a separate namespace that nobody checked.","ko":"2019년 6월 15일 토요일 오후 5시 12분에 자체 모니터링이 운영 클러스터의 노드 한 대에서 SystemOOM 이벤트가 났다고 알렸다. 4분 뒤에는 같은 노드의 루트 볼륨에서 EBS Burst Balance 가 낮다는 경고가 왔다.\n\n담당자가 kubectl get pods 로 확인했을 때 애플리케이션 파드는 하나도 죽지 않았다. kubectl top nodes 에서도 노드는 이미 회복되어 메모리 사용률이 60% 정도였다. 담당자는 일시적인 현상으로 보고 월요일에 살펴보기로 했다.\n\n다음 날 오후 6시 2분에 다른 노드에서 다시 SystemOOM 알림이 왔고, 4분 뒤 EBS Burst Balance 경고가 이어졌다. 이번에도 파드는 죽지 않았고 노드 메모리 사용률은 70% 바로 아래였다. CloudWatch 를 보면 burst balance 는 문제가 나기 전 2시간 반쯤에 걸쳐 내려가고 있었다.\n\nDatadog 의 메모리 그래프를 보니 SystemOOM 직전까지 노드 메모리를 많이 차지한 것은 fluentd-sumologic 파드였다. SystemOOM 시점에 이 파드들의 메모리 사용량이 급격히 떨어졌다. 토요일에 이를 놓친 것은 fluentd-sumologic 파드가 별도 네임스페이스에 있었고, 담당자가 그 네임스페이스를 확인하지 않았기 때문이다."},"updated_at":"2026-11-10T00:00:37.836685Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0026","org_slug":"blue-matador"}