목차
- 왜 rsyslog만으로는 점점 버거워졌을까
- rsyslog Loki 마이그레이션에서 Loki와 Promtail을 어떻게 볼까
- 마이그레이션 설계: 한 번에 바꾸지 말고 두 단계로
- 권장 아키텍처
- 실전 구현: rsyslog에서 Loki로 넘기는 기본 구성
- 1. Promtail 설정 준비
- 2. rsyslog에서 Promtail로 포워딩
- 3. 설정 검증과 서비스 재시작
- 4. 테스트 로그 보내기
- ⚠️ 실제로 많이 겪는 문제와 해결 방법
- 1. 메시지는 들어오는데 라벨이 예상과 다를 때
- 2. rsyslog는 보냈다고 하는데 Promtail에서 안 받을 때
- 3. 중복 수집이 생길 때
- 4. 라벨을 너무 많이 붙여서 쿼리가 무거워질 때
- 검증: rsyslog Loki 마이그레이션이 제대로 끝났는지 확인하는 방법
- 마이그레이션 이후 운영 방식이 어떻게 바뀌었나
- 정리와 다음 단계
- 자주 묻는 질문
- Q1. rsyslog를 완전히 없애야 하나요?
- Q2. Promtail은 파일만 읽는 도구인가요?
- Q3. 처음부터 구조화 로그(JSON)를 강제해야 하나요?
- Q4. 가장 먼저 챙길 검증 포인트는 뭔가요?
rsyslog Loki 마이그레이션 경험: 레거시 로그 시스템 현대화
운영 서버가 늘어나면 로그가 제일 먼저 말을 걸어옵니다. 처음엔 rsyslog 하나로도 잘 굴러가거든요. 파일로 남기고, 필요한 서버로 포워딩하고, 급하면 grep으로 뒤지면 되니까요. 그런데 장애가 길어지고 서버 수가 늘어나면 이야기가 달라집니다. 이번 글은 제가 실제로 진행했던 rsyslog Loki 마이그레이션 경험을 바탕으로, 레거시 로그 시스템을 어떻게 현대화했는지 정리한 내용입니다.
먼저 현재 시점 기준으로 짚고 갈 점이 하나 있습니다. Promtail은 2026년 3월 2일부로 EOL(지원 종료) 상태라서, 신규 구축이라면 Grafana Alloy도 함께 검토하는 게 맞습니다. 다만 이미 rsyslog와 Promtail을 쓰고 있거나, 단계적으로 Loki로 옮겨야 하는 환경이라면 이 글의 접근은 여전히 꽤 현실적이더라고요. 특히 리눅스 로그 관리, 중앙 집중식 로그, 그리고 조회 동선 단축이 고민이라면 더 그렇습니다.
저도 처음엔 "rsyslog 잘 돌아가는데 굳이 바꿔야 하나?" 싶었습니다. 막상 옮겨보니 검색성, 라벨(label, 분류용 메타데이터), 대시보드 연동이 확실히 다르더라고요. 반대로 아무 생각 없이 옮기면 기존 syslog 습관 때문에 삽질도 꽤 합니다. 여기서 중요한 포인트는 한 번에 뒤엎지 말고, 수집 계층과 조회 계층을 분리해서 천천히 옮기는 것입니다.
기존 rsyslog 기반 수집과 Promtail, Loki, Grafana가 어떻게 연결되는지 한눈에 보여주는 아키텍처 이미지입니다.
왜 rsyslog만으로는 점점 버거워졌을까
rsyslog는 여전히 아주 좋은 도구입니다. 특히 Syslog 생태계에서는 검증이 끝난 축에 가깝습니다. 문제는 "수집은 잘하는데, 분석과 검색은 별도 고민이 필요하다"는 점입니다. 서버 수가 늘고 장애가 복합적으로 얽히기 시작하면, 그 차이가 생각보다 크게 느껴집니다.
- 서버별 로그 파일 위치가 제각각이면 장애 때 동선이 길어집니다.
- 포워딩만 해두고 검색 체계가 약하면 결국 SSH 접속 후 grep에 의존하게 됩니다.
- 애플리케이션 로그와 시스템 로그를 함께 보려면 포맷 통일이 필요합니다.
- 운영자가 바뀌거나 시간이 지나면 "어디에 뭐가 쌓이는지" 문서보다 실서버가 더 진실이 됩니다.
제가 겪었던 가장 큰 문제는 장애 시점 상관관계(correlation, 연관 분석)가 너무 느렸다는 점이었습니다. 예를 들어 웹 서버에서 502가 튀고, 뒤에서 인증 서비스가 지연되고, 같은 시간대에 커널 메시지까지 흔들리면 이걸 시간축으로 모아봐야 하거든요. rsyslog만으로 불가능한 건 아니지만, 편하게 하기는 어렵습니다. 그래서 결론은 명확했습니다. 수집은 rsyslog의 장점을 활용하고, 조회와 분석은 Loki 쪽으로 넘기자. 이게 제가 정리한 rsyslog Loki 마이그레이션의 핵심 방향이었습니다.
rsyslog Loki 마이그레이션에서 Loki와 Promtail을 어떻게 볼까
쉽게 말해 Loki는 로그 저장소이자 검색 엔진 역할을 하고, Promtail은 로그를 모아서 Loki로 보내는 에이전트입니다. Prometheus가 메트릭을 다루듯이, Loki는 로그를 라벨 기반으로 다루는 느낌이라고 보시면 됩니다. 다만 2026년 기준으로는 Promtail보다 Grafana Alloy가 앞으로의 기본 경로라는 점은 꼭 같이 기억하셔야 합니다.
| 구성요소 | 역할 | 마이그레이션에서의 포인트 |
|---|---|---|
| rsyslog | 로그 수집, 필터링, 포워딩 | 기존 서버 설정을 최대한 유지하면서 다음 수집 계층으로 전달 |
| Promtail | 로그 수신 또는 파일 테일링 | 기존 환경에서 syslog 수신 지점 또는 파일 수집 지점으로 활용 가능 |
| Loki | 로그 저장 및 질의 | 라벨 설계가 성패를 좌우 |
| Grafana | 조회, 대시보드, 탐색 | 운영자가 가장 체감하는 개선 지점 |
| Grafana Alloy | 차세대 수집 에이전트 | 신규 구축이나 장기 운영 기준으로 우선 검토 |
많이 헷갈리는 부분이 하나 있습니다. "Promtail이 파일만 읽는 거 아니었나?" 저도 처음엔 그렇게 생각했었습니다. 그런데 Promtail은 Syslog Receiver 설정도 지원합니다. 그래서 기존 rsyslog가 잘 깔려 있다면, rsyslog가 TCP로 Promtail에 넘기고 Promtail이 Loki로 적재하는 구조가 꽤 현실적입니다. 이 방식이 좋은 이유는 레거시 환경을 한 번에 뜯어고치지 않아도 되기 때문입니다.
마이그레이션 설계: 한 번에 바꾸지 말고 두 단계로
제가 추천드리는 방식은 아래 순서입니다. 이 흐름이 rsyslog Loki 마이그레이션에서 제일 덜 아프더라고요.
- 1단계: 기존 rsyslog는 유지하고, Promtail 또는 Alloy를 syslog 수신기로 세웁니다.
- 2단계: Grafana에서 검색과 대시보드를 검증한 뒤, 필요한 서버부터 파일 수집이나 구조화 로그로 확장합니다.
이렇게 하면 롤백도 쉽습니다. 장애가 나도 rsyslog는 원래 하던 일을 계속하니까요. 운영에서는 이 안정감이 정말 큽니다.
기존 rsyslog를 유지한 채 Promtail을 앞단 수신기로 추가하고, 이후 Loki 조회 환경을 점진적으로 확장하는 전환 방식입니다.
권장 아키텍처
- 애플리케이션/시스템 로그 발생
- 로컬 rsyslog가 표준 syslog 포맷으로 정리
- rsyslog가 TCP로 Promtail에 전달
- Promtail이 라벨을 붙여 Loki로 전송
- Grafana에서 검색, 필터링, 시각화
중요한 포인트! 라벨은 많이 붙인다고 좋은 게 아닙니다. host, job, facility 정도처럼 조회에 꼭 필요한 축만 먼저 가져가세요. 처음부터 프로그램명, PID, path, 환경명, 팀명, 서비스명까지 다 라벨로 올리면 쿼리보다 라벨 관리가 더 힘들어집니다.
실전 구현: rsyslog에서 Loki로 넘기는 기본 구성
이제 실제 설정입니다. 아래 예시는 "Promtail이 syslog를 받고 Loki에 넣는 구성"입니다. 이미 Loki, Grafana, Promtail 서비스가 준비되어 있다는 전제로 적겠습니다. 설치 방식은 배포판 패키지, 바이너리, 컨테이너 등 환경마다 다르니 여기서는 마이그레이션 구성 자체에 집중하겠습니다.
1. Promtail 설정 준비
Promtail 설정에는 positions 파일이 자주 등장합니다. 파일 테일링이나 journal 수집에서는 어디까지 읽었는지 기억하는 데 중요하거든요. 다만 이 글처럼 syslog receiver만 쓰는 경로라면 중복 수집 방지의 핵심은 positions 파일보다 수집 경로 분리와 송신 설계에 있습니다. 이 부분은 저도 초반에 헷갈렸습니다.
sudo mkdir -p /etc/promtail
sudo mkdir -p /var/lib/promtail
sudo chown -R promtail:promtail /var/lib/promtail다음은 Promtail 설정 예시입니다.
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /var/lib/promtail/positions.yaml
clients:
- url: http://loki.example.internal:3100/loki/api/v1/push
scrape_configs:
- job_name: syslog
syslog:
listen_address: 0.0.0.0:1514
listen_protocol: tcp
idle_timeout: 60s
label_structured_data: true
labels:
job: syslog
relabel_configs:
- source_labels: ['__syslog_message_hostname']
target_label: host
- source_labels: ['__syslog_message_app_name']
target_label: app
- source_labels: ['__syslog_message_severity']
target_label: severity여기서 제가 실제로 많이 썼던 건 relabel_configs입니다. syslog 헤더에서 넘어온 값을 바로 host, app 같은 라벨로 바꿔주면 Grafana 탐색이 훨씬 편해집니다. 처음엔 라벨 이름을 제 멋대로 만들다가 쿼리 통일이 안 돼서 다시 정리했었는데, 운영팀 여러 명이 같이 볼 거면 naming rule부터 맞춰두는 게 좋습니다.
2. rsyslog에서 Promtail로 포워딩
rsyslog는 omfwd 모듈로 Promtail 쪽으로 보낼 수 있습니다. TCP를 권장하는 이유는 운영에서 안정성이 더 좋기 때문입니다. UDP는 편하지만 장애 상황에서 조용히 놓치는 메시지가 생기면 답답하더라고요. 특히 Promtail 쪽은 RFC5424 계열 syslog 포맷과 octet-counted framing 조합이 가장 무난했습니다.
# /etc/rsyslog.d/90-promtail.conf
*.* action(
type="omfwd"
protocol="tcp"
target="promtail.example.internal"
port="1514"
Template="RSYSLOG_SyslogProtocol23Format"
TCP_Framing="octet-counted"
KeepAlive="on"
queue.type="linkedList"
)queue.type="linkedList"를 넣은 이유도 꼭 짚고 넘어가야 합니다. 원격 수신기가 잠깐 죽거나 네트워크가 흔들릴 때, 큐가 없으면 송신 쪽이 막히거나 손실을 체감하기 쉬워집니다. 다만 운영 환경에 따라 디스크 큐나 재시도 옵션까지 더 챙겨야 할 수 있으니, 중요한 서비스라면 여기서 한 번 더 보수적으로 잡는 걸 권합니다.
3. 설정 검증과 서비스 재시작
설정 파일을 넣었다고 바로 끝은 아닙니다. 문법 검사를 먼저 하고, 서비스 상태를 짧게라도 확인해야 뒤탈이 적습니다. 이 단계에서 1분만 더 써도 나중에 1시간 덜 헤매더라고요.
sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl restart promtail
sudo systemctl status rsyslog --no-pager
sudo systemctl status promtail --no-pagerrsyslog는 재시작 전에 rsyslogd -N1로 문법 검사를 꼭 하세요. 이거 안 하고 바로 재시작했다가 로그 수집 전체가 멈추면 진짜 식은땀 납니다.
4. 테스트 로그 보내기
테스트는 꼭 단순해야 합니다. logger 한 줄로 시작하세요. 괜히 복잡한 애플리케이션 로그부터 확인하면 어디서 막혔는지 추적이 어렵습니다.
logger -t migration-test "rsyslog to promtail to loki test message"
curl -s http://127.0.0.1:9080/ready
curl -s http://loki.example.internal:3100/ready여기서 ready 응답이 나온다고 끝난 건 아닙니다. 실제로 Grafana Explore에서 라벨이 원하는 대로 붙는지까지 봐야 합니다. 운영에서는 이 마지막 한 단계가 제일 중요하더라고요.
Promtail의 syslog 수신 설정과 rsyslog의 omfwd 전달 관계를 시각적으로 정리한 구성 이미지입니다.
⚠️ 실제로 많이 겪는 문제와 해결 방법
여기부터가 진짜 운영 이야기입니다. 문서만 보면 금방 끝날 것 같았는데, 저는 여기서 시간을 꽤 썼습니다. rsyslog Loki 마이그레이션은 개념보다 디테일에서 더 많이 막히더라고요.
1. 메시지는 들어오는데 라벨이 예상과 다를 때
Promtail이 syslog 헤더를 내부 라벨로 들고 오는데, relabel_configs에서 이름을 잘못 참조하면 Grafana에서 host가 비어 보일 수 있습니다. 이 경우는 대부분 입력값 이름을 잘못 쓴 겁니다. 예를 들어 hostname, app-name 같은 식으로 감으로 쓰면 안 되고, Promtail이 제공하는 내부 라벨 이름을 기준으로 맞춰야 합니다.
- host가 비면 __syslog_message_hostname 확인
- 앱 이름이 비면 __syslog_message_app_name 확인
- 심각도가 안 잡히면 __syslog_message_severity 확인
2. rsyslog는 보냈다고 하는데 Promtail에서 안 받을 때
이건 네트워크와 포맷 두 가지를 같이 보셔야 합니다. TCP 포트가 열려 있는지 먼저 확인하고, 그다음 syslog 포맷을 맞춰야 합니다. 저도 한 번은 포트는 맞게 열어두고 템플릿을 기본값으로 둬서 Promtail 파싱이 애매하게 꼬인 적이 있었습니다. 그 뒤로는 RSYSLOG_SyslogProtocol23Format을 먼저 의심합니다.
ss -lntp | grep 1514
sudo journalctl -u promtail -n 50 --no-pager
sudo journalctl -u rsyslog -n 50 --no-pager3. 중복 수집이 생길 때
이 부분도 자주 나옵니다. 기존에 파일 테일링과 syslog 포워딩을 동시에 물려두면 같은 로그가 두 번 들어갈 수 있습니다. 특히 /var/log/messages를 Promtail이 읽고 있는데, 같은 메시지를 rsyslog가 또 syslog receiver로 보내면 조회 화면에서 두 줄로 보여요. 처음엔 "Loki가 복제했나?" 싶었는데 아니더라고요. 수집 경로를 한 로그 소스당 하나로 정리해야 합니다.
4. 라벨을 너무 많이 붙여서 쿼리가 무거워질 때
라벨은 검색에 좋지만, 남발하면 관리 포인트가 폭증합니다. 저는 초기에 프로그램명, 파일경로, 환경명, 인스턴스명, 팀명까지 다 넣었다가 나중에 정리하느라 더 힘들었습니다. 운영에서 오래 가는 구성은 의외로 단순합니다.
| 항목 | 처음 욕심낸 구성 | 지금 추천하는 구성 |
|---|---|---|
| host | 사용 | 사용 |
| job | 사용 | 사용 |
| app | 사용 | 선택적 사용 |
| path | 라벨로 사용 | 가급적 지양 |
| pid | 라벨로 사용 | 지양 |
| team/env | 모두 라벨화 | 정말 필요한 것만 |
검증: rsyslog Loki 마이그레이션이 제대로 끝났는지 확인하는 방법
설정이 끝났다고 바로 성공은 아닙니다. 운영에서는 "수집된다"보다 "원하는 방식으로 검색된다"가 더 중요합니다. 저는 아래 체크리스트로 마이그레이션 완료 여부를 봤습니다.
- 테스트 메시지가 Loki에 들어오는지 확인
- host 라벨로 서버별 필터링이 되는지 확인
- 같은 시간대 다른 서버 로그를 한 화면에서 비교 가능한지 확인
- 기존 rsyslog 경로와 신규 Loki 경로 결과가 크게 어긋나지 않는지 샘플 비교
- 장애 상황에서 운영자가 SSH보다 Grafana를 먼저 열게 되는지 확인
Grafana Explore에서는 보통 이런 식으로 보기 시작했습니다.
{job="syslog",host="web-01"}
{job="syslog",app="nginx"}
{job="syslog",severity="err"}드디어 원하는 대로 host 기준으로 잘 걸리고, 애플리케이션별로도 묶이기 시작하면 그때부터 체감이 옵니다. "아, 이제 장애 볼 때 여기부터 보면 되겠구나" 하는 느낌이요. 이거 진짜 편하더라고요.
Grafana Explore에서 host, app, severity 라벨로 로그를 필터링하고 시간축으로 비교하는 결과 화면 이미지입니다.
마이그레이션 이후 운영 방식이 어떻게 바뀌었나
가장 큰 변화는 로그 확인 동선이 짧아졌다는 점입니다. 예전에는 "어느 서버지? 어떤 파일이지? 압축됐나? rotate됐나?"부터 시작했는데, 지금은 일단 Grafana에서 시간대와 호스트를 좁혀보고 필요할 때만 서버에 들어갑니다. 중앙 집중식 로그 체계의 장점이 여기서 확실히 보입니다.
- 장애 초동 대응 속도가 빨라집니다.
- 서버별 로그 위치를 전부 외우지 않아도 됩니다.
- 운영 인수인계가 쉬워집니다.
- 애플리케이션 로그와 시스템 로그를 함께 보기 편해집니다.
물론 단점도 있습니다. Loki 쪽 저장 정책, 라벨 설계, 대시보드 표준화는 결국 운영팀이 책임져야 합니다. 그래서 저는 마이그레이션을 "도구 교체"보다 운영 습관 교정에 가깝게 봅니다. 혹시 지금도 grep과 SSH에 너무 의존하고 계신가요? 그렇다면 rsyslog를 버리라는 뜻이 아니라, 조회 계층만이라도 현대화해보시라고 말씀드리고 싶네요.
정리와 다음 단계
rsyslog Loki 마이그레이션은 생각보다 거창한 프로젝트가 아닐 수도 있습니다. 핵심은 rsyslog를 적으로 보지 않는 겁니다. 기존 수집 안정성은 살리고, Promtail 활용 또는 Alloy 전환을 통해 Loki에 연결해서 검색 경험을 개선하면 됩니다. 제가 직접 해보니 한 번에 완벽하게 옮기려는 순간부터 어려워지더라고요. 반대로 syslog receiver 하나 붙이고, 라벨 몇 개만 정리해도 금방 효과가 납니다.
정리하면 이렇습니다.
- 수집은 보수적으로: 기존 rsyslog를 유지합니다.
- 조회는 현대적으로: Loki와 Grafana로 검색 동선을 줄입니다.
- 라벨은 절제해서: host, job 같은 핵심부터 시작합니다.
- 중복 수집은 반드시 제거: 파일 테일링과 syslog 전달 경로를 겹치지 않게 합니다.
다음 글에서는 Loki 쿼리 정리와 라벨 설계 실전, 그리고 systemd-journald와 함께 가져갈 때 어떤 점을 조심해야 하는지 다뤄볼 예정입니다. 블로그의 이전 글에서 다뤘던 로그 로테이션 설계 내용과 연결해서 보시면 흐름이 더 잘 잡히실 거예요.
레거시 rsyslog 중심 운영과 Loki 기반 현대화 운영의 차이를 요약 비교한 인포그래픽 이미지입니다.
자주 묻는 질문
Q1. rsyslog를 완전히 없애야 하나요?
아닙니다. 많은 환경에서 rsyslog는 여전히 좋은 전처리와 전달 계층입니다. 저도 처음엔 완전 교체를 고민했는데, 실제로는 공존 전략이 훨씬 안정적이었습니다.
Q2. Promtail은 파일만 읽는 도구인가요?
아닙니다. syslog 수신 구성도 가능합니다. 다만 현재는 Promtail이 EOL이라서, 새로 시작하는 환경이라면 Grafana Alloy를 먼저 검토하는 편이 맞습니다.
Q3. 처음부터 구조화 로그(JSON)를 강제해야 하나요?
꼭 그렇지는 않습니다. 저는 먼저 중앙 수집과 조회 체계를 만들고, 그다음 서비스별로 구조화 로그를 넓혀갔습니다. 순서를 잘 잡는 게 중요합니다.
Q4. 가장 먼저 챙길 검증 포인트는 뭔가요?
중복 수집 여부와 라벨 품질입니다. 로그가 들어오는 것만 보면 반쪽 성공입니다. 검색이 잘 되어야 진짜 성공이거든요.
'IT > Linux' 카테고리의 다른 글
| [Linux] iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드 (0) | 2026.07.08 |
|---|---|
| [Linux] 컨테이너 없이 리눅스 네임스페이스로 프로세스 격리하기: 실제 사례 연구 (0) | 2026.07.07 |
| [Linux] Linux 커널 튜닝으로 보는 네트워크 I/O 벤치마크 분석 (0) | 2026.07.05 |
| [Linux] CentOS 7에서 AlmaLinux 9로: 성공적인 서버 마이그레이션 전략과 실제 경험 (1) | 2026.07.01 |
| [Linux] 리눅스 시스템 장애, 프로세스 비정상 종료 원인 분석 및 해결 사례 연구 (0) | 2026.07.01 |
| [Linux] Linux Namespace 격리 기술, 실제 적용과 검증 방법 (0) | 2026.06.27 |
