𝗚𝗿𝗮𝗳𝗮𝗻𝗮 𝗔𝗹𝗹𝗼𝘆와 𝗟𝗼𝗸𝗶를 이용한 중앙 집중식 로깅
예전에는 로그를 찾으려면 특정 서버에 SSH로 접속하여 grep 명령어를 실행해야 했습니다.
장애가 발생하면 어떤 서버에 에러가 있는지 모르는 경우가 많습니다. 결국 여러 호스트를 돌아다니며 눈으로 타임스탬프를 맞추려 애쓰게 됩니다. 속도가 생명인 상황에서 이런 방식은 한계가 있습니다.
저는 중앙 집중식 로깅으로 전환했습니다. 이제 모든 서버의 모든 로그 라인이 한곳에 모입니다. 각 호스트에서 Grafana Alloy를 사용하여 로그를 Loki로 전송합니다.
왜 이 스택인가요?
- ELK는 무겁습니다. Elasticsearch는 너무 많은 유지보수와 하드웨어 자원을 요구합니다.
- Loki는 전체 텍스트 대신 레이블(label)을 인덱싱합니다. 덕분에 운영 비용이 저렴하고 관리가 쉽습니다.
- SaaS 도구는 서버 규모가 커질수록 비용이 급격히 증가합니다.
- Alloy는 Grafana에서 내놓은 새로운 표준 에이전트입니다. 효율적이고 신뢰할 수 있습니다.
설정 방법
Alloy는 각 호스트의 파일을 읽습니다. host, environment, service와 같은 레이블을 추가한 뒤, 이를 Loki로 푸시합니다. 또한 Slack 봇도 구축했습니다. 이 봇은 Loki API를 호출하여 팀원들이 채팅 채널을 벗어나지 않고도 로그를 가져올 수 있게 해줍니다.
실제 겪었던 문제들:
- 권한 문제: Alloy는 자체 사용자로 실행됩니다. 앱 로그에 대한 접근 권한이 제한되어 있으면 Alloy는 아무런 오류 메시지 없이 실패합니다. alloy 사용자를 앱 그룹에 추가해야 합니다.
- 혼합된 OS 환경: Debian, Ubuntu, RHEL 서버가 섞여 있을 수 있습니다. 각 OS에 맞는 패키지 관리자를 사용해야 합니다.
- 기존 에이전트: 오래된 로그 전송 도구가 중복 전송을 일으킬 수 있습니다. 배포 과정에서 이를 찾아 제거해야 합니다.
- 멀티라인 로그: Java 스택 트레이스는 여러 줄에 걸쳐 나타납니다. 멀티라인 정규식(regex)이 없으면, 하나의 에러가 40개의 쓸모없는 개별 항목으로 쪼개지게 됩니다.
레이블(Label)의 황금률
레이블에 카디널리티(cardinality)가 높은 데이터를 넣지 마세요. Request ID나 User ID를 레이블로 사용해서는 절대 안 됩니다. 이는 인덱스를 망가뜨립니다. 서비스 이름이나 환경(environment) 같은 항목에만 레이블을 사용하고, 그 외의 모든 것에는 필터를 사용하세요.
결과
중앙 집중식 로깅은 로그를 메트릭(metric)으로 바꿔줍니다. 사람이 문제를 인지할 때까지 기다리는 대신 에러율에 따라 알람을 보낼 수 있습니다. 장애가 발생했을 때, Slack 명령어 하나만으로 답을 찾을 수 있습니다.
Optional learning community: https://t.me/GyaanSetuAi