Cloudera Manager 의 Event Server 는 클러스터에서 발생한 이벤트(서비스 상태 변화, 로그에서 추출한 알람 조건 등)를 색인해 두고 CM 의 이벤트 검색과 알림 발송에 쓴다. 이 저장소의 상한을 정하는 설정이 eventserver_max_index_size 다.
단위는 용량이 아니라 이벤트 개수다. 화면의 설명도 "Event Server 저장소의 최대 크기입니다(단위: 이벤트 수)" 로 나온다. 상한을 넘으면 가장 오래된 이벤트부터 순차적으로 지워져 한도 아래로 돌아간다. 기본값은 5,000,000 — 즉 500만 건이다.
이 값을 MB 나 바이트로 오해하기 쉽다. 그렇게 보면 5,000,000 이 5TB 또는 5MB 로 읽히는데 어느 쪽도 맞지 않는다. 설정을 바꾸기 전에 CM 화면의 설명 문구를 직접 확인하는 편이 안전하다.
이벤트 개수는 CM UI 의 Diagnostics → Events 에서 조건 없이 검색해 결과 건수로 가늠한다. 실제 디스크 사용량은 Event Server 역할이 도는 호스트에서 인덱스 디렉터리를 직접 본다.
# Event Server 역할의 데이터 디렉터리 (설정에서 실제 경로 확인)
du -sh /var/lib/cloudera-host-monitor /var/lib/cloudera-service-monitor 2>/dev/null
du -sh /var/lib/cloudera-scm-eventserver
경로는 Cloudera Management Service → Event Server → 구성 에서 인덱스 디렉터리 항목으로 확인한다.
이벤트 수와 디스크 사용량은 비례하지만 이벤트 하나의 크기가 내용에 따라 다르므로 정확한 환산식은 없다. 현재 개수와 현재 사용량으로 이벤트당 평균 크기를 구한 뒤 목표 용량을 역산하는 정도가 현실적이다.
줄이면 오래된 이벤트부터 삭제되고 검색 가능한 기간이 짧아진다. 서비스 동작 자체에는 영향이 없다 — 이벤트는 이력 조회와 알림 트리거에 쓰이는 데이터일 뿐이다.
한도를 낮출 만한 상황은 두 가지다. 디스크가 부족한 경우, 그리고 이벤트 검색이 느려진 경우다. 반대로 감사나 장기 분석 목적으로 오래된 이벤트가 필요하면 낮추지 않는다.
Cloudera Management Service → Event Server → 구성 에서 값을 바꾸고 Event Server 역할을 재시작한다. 재시작 중에는 이벤트가 수집되지 않으므로 그 구간의 이벤트는 유실될 수 있다.
값을 낮추기 전에 이벤트가 왜 많이 쌓이는지 먼저 본다. 특정 서비스가 같은 이벤트를 반복 발생시키는 상태라면 한도를 낮추는 것은 증상만 가리는 조치이고, 정작 필요한 이벤트가 밀려 나가게 된다. 이벤트 종류별 분포를 검색해 상위 발생원을 확인한 뒤 그 원인을 먼저 처리한다.
Event Server 와 별개로 Host Monitor · Service Monitor 도 각자의 시계열 저장소를 갖고 있고 디스크를 많이 쓴다. 디스크 압박이 원인이라면 Event Server 만 볼 것이 아니라 세 역할의 저장 한도를 함께 본다. Service Monitor 의 시계열 보존 설정과 Host Monitor 의 저장 한도는 각각 별도 항목이다.