들어가기 앞서운영 중인 애플리케이션의 로그가 OpenSearch 에 eks-log 라는 단일 인덱스로 저장되고 있다. 인덱스를 주기적으로 정리하기 위해 로그 삭제 정책을 걸어놨지만, 그럼에도 불구하고 수동으로 로그를 지워야 하는 경우가 있다. 이때, 단일 인덱스이기 때문에 Kibana 의 Dev tool 을 이용해 로그의 @timestamp 를 기준으로 삭제하려고 하면 시간이 오래걸리고 Timeout이 발생하기도 한다. 이를 해결하기 위해 월별로 인덱스를 나누어 저장하고자 한다.설정 방법Fluent Bit 구성파일에서 날짜별 인덱스 생성을 위해서는 es 출력 플러그인의 Index 항목을 동적으로 설정해야 한다. Fluent Bit에서는 ${TAG}, ${UUID}, ${HOSTNAME} 등과 함께 ${t..

들어가기 앞서현재 운영 중인 서비스는 DMZ 영역과 내부망을 분리하여 보안을 강화하였으며, 각 영역에 EKS 클러스터를 구축하여 운영하고 있다. DMZ 영역의 EKS 클러스터에는 웹 서버, 보안 솔루션, API 게이트웨이 파드 등을 배포하였고, 내부망 EKS 클러스터에는 실제 서비스 파드를 운영하고 있다. 문제는 DMZ 영역의 API 게이트웨이 파드에서 사용하는 3rd party 솔루션이 과도한 양의 로그를 생성하고 있다는 점이다. OpenSearch로 전송되는 로그는 주간 기준 약 20억 건에 달하며, 이는 내부망 대비 약 2배 수준이다. 이로 인해 OpenSearch가 로그 처리에 과도한 리소스를 소모하게 되었고, 메모리 사용률이 급증하면서 이전 포스팅에서 설명한 Failed to flush chun..

들어가기 앞서이전에 포스팅한 "Failed to flush chunk" 에러를 해결한 뒤 이번엔 새로운 경고 메세지가 발견되었다. DMZ 망의 EKS 클러스터에 DeamonSet 으로 배포된 Fluent-Bit 의 컨테이너가 반복적으로 재시작되면서 아래와 같은 경고 메세지를 출력하였다.[warn] [http_client] cannot increase buffer: current=512000 requested=544768 max=512000 이 경고 메시지는 HTTP 클라이언트가 데이터를 수신하는 동안 버퍼 크기를 늘리려 했지만, 설정된 최대값(512000 바이트)에 도달하여 실패했음을 의미한다. 해결 방버을 Github 의 Bug Report 와 StackOverflow 에서 열심히 서칭한 결과.. 다음..

들어가기 앞서현재 운영중인 서비스는 Logging 과 Monitoring 이 모두 구축되어 있다. 모니터링의 경우 Jennifer k8s, Jennifer apm, cloudwatch 를 통합하여 사용하고 있다. 로그의 경우 Fluent bit 이 수집하여 OpenSearch 와 Cloudwatch Logs 에 저장하여 관리하는 중이다. fluent bit 은 운영중인 EKS 클러스터의 노드그룹에 Deamonset 으로 배포되어 있다. 문제는 특정 시점부터 fluent bit이 배포된 노드들의 메모리와 디스크 사용률이 우상향하는 현상이 발생하였다. 임시방편으로 Fluent bit 을 배포하는 데몬셋을 rollout 하여 메모리와 디스크를 다시 정상화시켰으나 동일 현상이 지속되었다. fluent bit 컨..