{"id":"IL-0041","org":"PrometheusKube","date":"2020-11-11","docs":["https://github.com/fluent/fluent-bit/issues/2416","https://github.com/fluent/fluentd/issues/2411","https://github.com/fluent/fluent-bit/issues/1935","https://docs.fluentd.org/monitoring-fluentd/monitoring-prometheus","https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/"],"title":{"en":"fluent-bit silently stopped shipping application logs from one node to Elasticsearch","ko":"fluent-bit 이 오류 없이 멈춰 운영 노드 한 대의 애플리케이션 로그가 Elasticsearch 로 전혀 가지 않았다."},"domain":["kubernetes","observability"],"impact":{"scope":"application logs from one production node","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A log shipper can fail without an error message and with metrics that simply stop moving, so error-based alerts never fire; throughput alerts or end-to-end checks can catch it. Open source software can break in ways nobody expects, and sometimes the way out is to switch to a different shipper fast, node by node. A new shipper that starts from scratch replays every old log on the node and needs to be slowed down.","ko":"오픈소스 소프트웨어가 어떻게 망가질지는 미리 알 수 없고, 때로는 다른 도구로 빨리 갈아탈 수 있어야 한다. 로그 전송 에이전트는 오류 지표만으로 감시할 수 없다. 이번처럼 지표가 오류 없이 멈추면 아무것도 잡히지 않는다. fluentbit_output_proc_bytes_total 의 5분 비율처럼 전송량에 알림을 걸 수 있다. 트래픽은 밤에 줄고 낮에 늘어 기준값 하나로는 맞지 않으므로, 낮과 밤 기준을 따로 둔다. 테스트 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검도 방법이다. 다만 이런 알림이 울려도 그 자리에서 할 수 있는 조치가 마땅치 않다."},"related":[],"sources":[{"url":"https://web.archive.org/web/20220123082409/https://prometheuskube.com/why-we-switched-from-fluent-bit-to-fluentd-in-2-hours","kind":"blog","license":"unknown","archived":"https://web.archive.org/web/20220123082409/https://prometheuskube.com/why-we-switched-from-fluent-bit-to-fluentd-in-2-hours"}],"summary":{"en":"PrometheusKube shipped application logs from its Kubernetes nodes to Elasticsearch with fluent-bit. On one node, fluent-bit stopped sending most records while staying silent: no error in its logs, and Prometheus metrics that only stopped growing. The team first chased an Elasticsearch write queue rejection and added CPU to Elasticsearch, which removed that error but not the problem. Rollbacks, upgrades and configuration changes did nothing. Debug logging showed the affected instance going quiet after its initial sync, and fluent-bit issue #2416 described the same behaviour without a fix.\n\nUnable to fix fluent-bit in time, the team replaced it with Fluentd. They built a Fluentd deployment configuration and rolled it out one node at a time, starting with the affected node: node affinity placed Fluentd on a node and anti-affinity removed fluent-bit from it. Fluentd then failed with buffer overflow errors because, starting from scratch, it was pushing all of the old logs on that node at once, and Elasticsearch was barely keeping up. Raising flush_thread_count and tuning flush_interval, as Fluentd issue #2411 advises, did not help, and neither did a larger buffer. Slowing Fluentd down did: flush_thread_count 1 and a flush_interval of 5 seconds, plus the Position DB feature so already-ingested data is skipped. With that, Fluentd shipped logs without errors and was rolled out to every node.\n\nThe write-up adds that alerting on a shipper's throughput is hard: a rate threshold on fluentbit_output_proc_bytes_total needs different values for day and night, and a black-box check that writes a log line and looks for it in Elasticsearch is the other option.","ko":"PrometheusKube 는 3년 넘게 fluent-bit 으로 로그를 보냈고, 여러 번 업그레이드하는 동안 문제가 없었다. 그런데 운영 환경에서 노드 한 대의 애플리케이션 로그가 완전히 끊겼다. fluent-bit 은 오류를 하나도 남기지 않은 채 로그를 보내지 않았다. 디버그 로그를 보면 해당 인스턴스는 처음 동기화 뒤 아무 일도 하지 않았다. 원문은 코드 안의 교착 상태나 무시된 오류를 원인으로 추정한다. GitHub 이슈 #2416 에 같은 상황이 올라와 있었지만 해결책은 없었다.\n\n팀은 fluent-bit 버그를 당장 고칠 수 없다고 보고 Fluentd 로 바꾸기로 했다. 노드 어피니티로 문제의 노드에만 Fluentd 를 먼저 띄우고 안티 어피니티로 그 노드에서 fluent-bit 을 뺀 다음, 노드 하나씩 넓혀 가는 방식이었다. 몇 시간 뒤 Fluentd 가 `BufferOverflowError error=\"buffer space has too many data\"` 를 내며 로그 전송이 완전히 멈췄다. Fluentd 이슈 #2411 의 조언대로 flush_thread_count 를 늘리고 flush_interval 을 조정하고 버퍼 크기도 키웠지만 같은 오류가 났다. Elasticsearch 도 다시 일부 요청을 거부했다.\n\nFluentd 는 로그를 처음부터 다시 읽으면서 그 노드에 쌓인 오래된 로그를 전부 다시 보내고 있었다. 팀은 오히려 속도를 늦췄다. flush_thread_count 를 1로 줄이고 flush_interval 을 5초로 늘렸고, 이미 보낸 데이터를 건너뛰게 해 주는 Position DB 기능을 켰다. 그러자 로그가 느리지만 오류 없이 전송되었고, 팀은 노드 하나씩 Fluentd 배포를 마쳤다."},"trigger":null,"severity":"unknown","symptoms":["monitoring-down"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"A developer reported missing production logs; no alert fired because fluent-bit's metrics showed no errors.","ko":"운영 환경 로그 일부가 빠져 있다는 개발자의 메시지로 알았다. fluent-bit 의 Prometheus 지표는 오류를 보이지 않고 값만 멈춰 있어서 모니터링은 이 상황을 잡지 못했다. 지표가 늘지 않는 것도 이슈 #1935 로 보고된 다른 버그였다."},"components":["telemetry-agent","elasticsearch-opensearch"],"root_cause":"software-bug","remediation":[{"text":{"en":"added CPU to the Elasticsearch virtual machines, which cleared the write queue rejections","ko":"Elasticsearch 스레드 큐 오류를 보고 Elasticsearch 가상 머신에 CPU 를 늘렸다. 오류는 사라졌지만 로그 누락의 원인은 아니었다."}},{"text":{"en":"rolled out Fluentd one node at a time, using node affinity to place Fluentd and anti-affinity to remove fluent-bit","ko":"노드 어피니티로 Fluentd 를 놓고 안티 어피니티로 fluent-bit 을 빼는 방식으로, 노드 하나씩 Fluentd 를 배포했다."}},{"text":{"en":"lowered Fluentd's flush_thread_count to 1 and set flush_interval to 5 seconds so the backlog of old logs did not overflow the buffer","ko":"오래된 로그가 한꺼번에 밀려 버퍼가 넘치지 않도록 Fluentd 의 flush_thread_count 를 1로 줄이고 flush_interval 을 5초로 늘렸다."}},{"text":{"en":"enabled Fluentd's Position DB so already-ingested data was skipped","ko":"Fluentd 의 Position DB 기능을 켜서 이미 보낸 데이터를 건너뛰게 했다."}}],"action_items":[{"text":{"en":"Build monitoring for Fluentd on its Prometheus integration, including a throughput alert with separate day and night thresholds or a black-box log check","ko":"Fluentd 의 Prometheus 연동으로 모니터링 패키지를 만든다. 5분 동안 보낸 바이트 비율에 낮과 밤 기준을 따로 두는 알림이나, 로그를 계속 남기고 Elasticsearch 에 들어왔는지 확인하는 블랙박스 점검을 적용한다."}}],"contributing":["monitoring-blind-spot","known-bug-unpatched"],"recurrence_of":null,"symptoms_text":{"en":"On a Tuesday morning a developer reported that some production logs were missing. Only the logs from a single node were gone; the other nodes kept shipping normally through fluent-bit, the log shipper the team had run for more than three years.\n\nfluent-bit's own logs showed Elasticsearch rejecting some bulk requests with \"rejected execution of processing of [...][indices:data/write/bulk[s][p]]\", reporting \"EsThreadPoolExecutor[name = name-logs/write, queue capacity = 200, ... active threads = 2, queued tasks = 206 ...]\". The write thread pool queue was full. The queue capacity could not be configured, so the team gave the Elasticsearch virtual machines more CPU. The error went away, but the logs from the node were still missing: it had been a red herring. Comparing one noisy pod on that node with what reached Elasticsearch confirmed most of its records were lost.\n\nfluent-bit reported no error at all, and its Prometheus metrics showed nothing unusual: the metrics existed but simply stopped increasing (a separate bug, fluent-bit issue #1935). Rolling back minor versions, upgrading to the latest version and changing configuration parameters did not help. Only with debug logging turned on did the difference show: after the initial sync, the fluent-bit instance on the affected node stopped logging any actions while the instances on other nodes logged a lot, which pointed to a deadlock or a swallowed error.\n\nThe replacement brought its own symptom. A few hours after Fluentd started on the node, it failed with \"[warn]: #0 emit transaction failed: error_class=Fluent::Plugin::Buffer::BufferOverflowError error=\"buffer space has too many data\"\" and stopped shipping entirely, while Elasticsearch again rejected some requests.","ko":"화요일 아침 개발자가 운영 환경 로그 일부가 빠져 있다고 알려 왔다. 이상하게도 빠진 로그는 노드 한 대에서 나온 것뿐이었다.\n\nfluent-bit 로그를 보니 Elasticsearch 가 일부 요청을 받지 않고 있었다. 오류는 `rejected execution of processing of` 로 시작했고, `BulkShardRequest [[index-2020.11.11][0]] containing [2434] requests`, `queue capacity = 200`, `queued tasks = 206` 이 찍혀 있었다. Elasticsearch 에 요청을 처리할 스레드가 모자란다는 뜻이었다.\n\n큐 용량은 설정으로 바꿀 수 없어서 팀은 Elasticsearch 를 돌리는 가상 머신에 CPU 를 늘렸다. Elasticsearch 를 다시 띄우자 이 오류는 사라졌지만, 로그가 빠지는 원인은 따로 있었다. 해당 노드의 fluent-bit 지표를 보니 문제는 계속되고 있었다. 그 노드에서 로그를 많이 남기는 파드 하나의 로그를 Elasticsearch 와 대조해 보니 대부분이 빠져 있었다.\n\n마이너 버전 롤백, 최신 버전 업그레이드, 여러 설정 변경을 해 봤지만 아무것도 듣지 않았다. fluent-bit 의 Prometheus 지표에도 오류는 없었다. 지표는 있었지만 값이 늘지 않았을 뿐이다. 디버그 로그를 켜고 나서야, 문제의 fluent-bit 인스턴스가 처음 동기화를 마친 뒤 아무 동작도 기록하지 않는다는 것을 알았다. 다른 노드의 인스턴스는 로그를 많이 남기고 있었다."},"updated_at":"2026-11-10T00:00:38.358782Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0041","org_slug":"prometheuskube"}