[PostgreSQL] 운영에 필요한 로그 세팅 6가지

 

운영하는 프로젝트의 이슈를 대응 하려면 어떻게 해보는 것일까요?

 

• 누가 인입 했는지
• 누가 어떤 이력을 남겼는지
• 어디서 성능 저하가 발생하는 건지
• 어떤 이유로 에러가 발생하는 건지

어떻게 확인 할 수 있을 까요?  바로 로그를 까보는 것입니다.

이슈 대응의 네비게이션이 바로 로그라는 것이죠

 

그래서 운영하면서 세팅하면 좋은 10가지를 소개해주려고 합니다.

 

1. log_statement : 어떤 쿼리를 기록할 것인가
2. log_min_duration_statement : 슬로우 쿼리 추척
3. log_lock_waits : 락 대기 탐지
4. log_temp_files : 디스크 임시 파일 기록
5. log_min_messages : 로그 레벨 설정
6. log_autovacuum_min_duration : autovacuum 추적

 

이것들은 PostgreSQL에서 postgresql.conf에서 설정하는 값들 입니다.

 

 

 

 

log_statement - 어떤 쿼리를 기록할 것인가

 

실행되는 쿼리 중 어떤 종류의 쿼리를 남길지 세팅하는 것입니다. 

 

• none(기본값) : 아무 쿼리도 기록하지 않음
• ddl : DDL만 로깅 (CREATE, ALTER, DROP)
• mod : DDL + DML을 로깅 (INSERT, UPDATE, DELETE)
• all : 모든 쿼리를 로깅 (이건 개발환경에만 사용하자..)

log_statement = 'mod'

 

 

 

 

log_min_duration_statement - 슬로우 쿼리는 몇 초 이상인가

 

설정된 시간(ms)보다 오래 걸린 쿼리만 로깅합니다.

0으로 설정하면 모든 쿼리 시간을 로깅하게 됩니다.

 

• -1(기본값) : 로깅을 하지 않음
• N : N(N은 자연수)ms 이상 걸린 쿼리만 로깅

log_min_duration_statement = 1000  # 1초 이상인 경우에만 기록

 

 

 

 

log_lock_waits - 락 대기 탐지

 

쿼리가 락 대기(교착 상태)로 인해 지연될 때를 로깅합니다.

즉, 하나의 트랜잭션이 다른 트랜잭션을 Block 할 때 탐지하게 됩니다.

 

• off(기본 값) : 로깅하지 않음
• on : 락 대기 상황이 발생하면 로깅

log_lock_waits = on
deadlock_timeout = 1s  # 1초 이상 락 대기 하면

예시 로그 출력

2024-04-30 14:22:10.123 KST [12345] user@mydb LOG:  process 12345 still waiting for ShareLock on transaction 98765 after 1000.123 ms
2024-04-30 14:22:10.123 KST [12345] user@mydb DETAIL:  Process holding the lock: 12344. Wait queue: 12345.
2024-04-30 14:22:10.123 KST [12345] user@mydb STATEMENT:  UPDATE orders SET status = 'done' WHERE id = 123;

 

 

 

 

log_temp_files - 디스크 임시 파일 기록

 

대용량 테이블의 정렬, 해시 조인(HASH JOIN), 해시 집계(HASH AGGREGATE) 의 작업 공간을 초과했을 때 디스크에 임시 파일을 생성하게 될 때를 로깅합니다.

즉, 큰 작업이 실행되는 것을 탐지 하려고 하는 것입니다.

 

• -1(기본값) : 로깅하지 않음
• 0 : 모든 임시 파일을 로그에 기록
• N : N(N은 자연수) 단위는 KB, MB, GB로도 설정 가능

log_temp_files = 1MB

 

 

 

 

log_min_messages - 로그 레벨 설정

 

로그 레벨을 설정하는 것입니다.

 

• debug5 : 디거깅용 (정보가 아주 많음)
• debug4 : 디거깅용 (정보가 쬐끔 많음)
• debug3 : 디거깅용 (정보 많음)
• debug2 : 디거깅용 (정보가 보통)
• debug1 : 디거깅용 (정보가 조금)
• info : 일반 정보 수준
• notice : 경미한 경고, 진행 중 알림
• warning(기본값) : 주의가 필요
• error : 오류가 발생
• log : 관리자가 정의한 일반 로그 메시지
• fatal : 세션 종료 수준의 심각 오류
• panic : 서버 프로세스 전체 종료 필요

# 운영 환경에 권장 : error
log_min_messages = warning

 

 

 

 

log_autovacuum_min_duration - autovacuum 추적

 

UPDATE, DELETE 같은 DML이 발생하면 원래 행(Old Row) 을 바로 삭제 하지 않고 Dead Tuple로 남겨 둡니다.

그래서 한 테이블의 전체 약 20% 이상 쌓이면 autovacuum이 실행됩니다.

 

autovacuum이란 PostgreSQL의 내부 청소부(=GC, Garbage Collector)이며 청소 작업이 얼마나 오래 걸렸는지 로깅합니다.

즉, 설정된 시간(ms)보다 오래 Autovacuum이 걸렸는지 확인하는 것입니다.

 

• -1(기본값) : 로깅하지 않음
• N : N(N은 자연수)ms 이상 걸린 작업만 로깅

log_autovacuum_min_duration = 1000  -- 1초 이상 걸리면 로그로 남김

로그 예시

LOG:  automatic vacuum of table "public.orders": index scans: 1
       pages: 10000 removed, 50000 remain
       tuples: 300000 removed, 1200000 remain
       buffer usage: 200000 hits, 50000 misses, 100000 dirtied
       avg read rate: 50.000 MB/s, avg write rate: 20.000 MB/s
       system usage: CPU 2.00s/1.50u sec elapsed 3.50 sec

 

 

 

 

마무리

 

예전에는 몰랐지만 이제 2년차 3년차 성장하면서 백엔드를 공부하는데

운영을 하며 로그가 정말 기본과 기초가 된다는걸 항상 느낍니다.

 

 

 

감사합니다.