| 구분 | 역할 | 위치(CDP 기본) | 형식 |
|---|---|---|---|
| 운영 로그(glog INFO/WARNING/ERROR) | 데몬 동작 · 오류 진단 | /var/log/impalad/impalad.INFO 등 |
텍스트 |
| 감사 로그(audit) | 누가 언제 무슨 쿼리를 실행 · 차단당했는지 | /var/log/impalad/audit/ |
JSON(쿼리당 1줄) |
| 계보 로그(lineage) | 컬럼 단위 출처 · 파생 관계 | /var/log/impalad/lineage/ |
JSON |
세 파일 모두 impalad 가 직접 생성한다. Cloudera Manager Agent 가 이 디렉터리를 감시해 lineage 는 Atlas 로 보내고, audit 은 Ranger 로 수집된다.
운영 로그는 --max_log_files(severity 별 보관 개수, 기본 10, 0 이면 무제한) 와 --max_log_size(MB) 로 Impala 가 자체 회전한다. --logbufsecs 를 0 으로 두면 삭제 스레드가 계속 돌므로 피한다.
감사 로그는 --audit_event_log_dir 지정으로 켜지고(로컬 디스크여야 함), --max_audit_event_log_file_size(기본 쿼리 5000건마다 새 파일), --max_audit_event_log_files(보관 개수, 기본 0 = 무제한) 로 관리한다. CM 필드는 "Impala Daemon Maximum Audit Log File Size" 와 "Number of Impala Daemon Audit Log Files to Retain" 이다. 디스크 풀 등 로깅 오류 시 데몬이 즉시 종료되는 것이 기본이며 --abort_on_failed_audit_event=false 로 끌 수 있다.
계보 로그는 --lineage_event_log_dir 과 --max_lineage_log_file_size(기본 5000) 만 있고 보관 개수 옵션이 없다. 디렉터리를 바꿀 때는 서비스를 멈추고 기존 lineage 파일과 impalad_lineage_wal 을 새 경로로 복사한 뒤 재시작해야 유실이 없다.
"N일 보존" 같은 시간 기준 정책은 Impala 내장 옵션으로는 안 된다. 로컬 파일 옵션은 디스크가 차지 않게 하는 가드레일로만 작게 두고, 컴플라이언스 보존은 수집 단에서 잡는다.
| 관리 대상 | 어디서 | 방식 |
|---|---|---|
/var/log/impalad 로컬 파일이 디스크를 채우는 것 |
Impala(CM) | 파일 개수 · 크기 |
| 감사를 며칠 · 몇 년 보존할지 | Ranger Solr TTL(ranger.audit.solr.config.ttl, ranger.audit.solr.config.delete.trigger) + HDFS/클라우드 아카이브 |
시간 기준 |
| 계보 조회 · 영속 | Atlas(HBase 그래프 + Solr 인덱스) | 메타데이터 |
Ranger 감사가 노드 디스크를 채우는 전형적 원인이 Solr TTL 미설정이다. 쿼리 텍스트에 PII 가 들어갈 수 있으므로 Impala 로그 redaction 도 함께 설정한다.
운영 로그(impalad.INFO) 는 glog 가 심볼릭 링크 구조로 자체 회전하므로 logrotate 를 끼우면 깨진다. audit/lineage 는 Impala 가 쿼리 수 기준으로 유니크한 파일명으로 이미 회전하고 HUP reopen 을 지원하지 않으므로 logrotate 의 rename → reopen 모델이 맞지 않는다. copytruncate 는 유실 구간과 sparse 파일을 만들 수 있어 감사 로그에 부적합하다. 닫힌 파일을 압축 · 삭제하는 것만 남으므로 find 가 단순하고 안전하다.
#!/bin/bash
# /usr/local/sbin/impala-audit-lineage-cleanup.sh
AUDIT_DIR="/var/log/impalad/audit"
LINEAGE_DIR="/var/log/impalad/lineage"
COMPRESS_AFTER=7
DELETE_AFTER=90
for d in "$AUDIT_DIR" "$LINEAGE_DIR"; do
[ -d "$d" ] || continue
find "$d" -type f ! -name '*.gz' -mtime +"$COMPRESS_AFTER" -exec gzip -9 {} \;
find "$d" -type f -name '*.gz' -mtime +"$DELETE_AFTER" -delete
done
# /etc/cron.d/impala-log-cleanup
30 1 * * * root /usr/local/sbin/impala-audit-lineage-cleanup.sh
-mtime +7 이므로 현재 쓰기 중인 최신 파일은 자연히 제외된다. 굳이 logrotate 를 쓴다면 nocreate, nocopytruncate, compress, delaycompress, maxage 90 으로 회전 없이 압축 · 삭제만 시키고 logrotate -d 로 먼저 dry-run 한다.
Kudu 에서 "로그" 는 두 가지다. 운영 로그(glog, --log_dir 기본 /var/log/kudu/, --max_log_files, --max_log_size) 는 Impala 와 똑같이 관리한다. WAL(--fs_wal_dir) 은 진단 로그가 아니라 Raft 합의 · 복구용 데이터 구조라 절대 수동으로 지우면 안 된다. Kudu 가 --log_segment_size_mb 단위로 롤오버하고 LogGCOp 가 내구성에 필요 없는 세그먼트를 자동 GC 한다. WAL 디스크가 문제면 삭제가 아니라 --log_min_segments_to_retain, --log_max_segments_to_retain, --log_target_replay_size_mb 튜닝, flush 압박 완화, 디스크 증설로 푼다. --tablet_history_max_age_sec(1.10 부터 기본 1주) 는 MVCC 히스토리 보존이지 로그 정리가 아니다.
Kudu 는 audit · lineage 파일을 만들지 않는다. 접근 감사는 Ranger 통합으로, 계보는 Kudu 테이블을 읽고 쓰는 Impala/Spark 가 생성해 Atlas 로 보낸다.