로그·모니터링 과부하 Logging / monitoring overhead

원인 ID in-monitoring · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

장애가 나면 로그가 폭증하고 로그를 동기로 넘기는 서버는 로그 때문에 더 느려집니다.

왜 오류가 나며 로그·지표 전송량 폭증 → 그러면 로그 수집기가 밀리고 동기 전송하는 서버는 대기 → 화면에서는 장애 때 뚝뚝 끊김·멈춤이 로그 때문에 더 심해짐

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 비동기 전송, 샘플링, 버퍼 넘치면 버리기, 같은 오류 로그는 묶어서 보내기.
인프라팀 할 일: 로그 수집기 용량을 장애 때 폭증량 기준으로 확보, 수집기 적체 경보.
그래프에서는: 가끔 무작위로 튐 · 로그 전송량, 로그 수집기 대기열
확인할 곳: 서버의 초당 로그 줄 수·바이트와 로그 수집 에이전트의 대기열·버린 수를 틱 시간과 함께 봄. 멈춘 스레드가 있으면 bcc offcputime -p로 로그 쓰기·전송에서 기다리는지
이러면 맞음: 틱이 튄 시각에 로그 양이 평소의 수십 배로 솟고 게임 스레드의 대기 시간이 로그 쓰기·전송 호출 스택에 몰려 있음
이러면 아님: 로그 양이 평소와 같거나 게임 스레드가 로그 쪽에서 기다리지 않으면 로그 폭증은 장애의 결과일 뿐이므로, 처음 오류를 낸 원인을 따로 찾음
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Logging in C# Microsoft
.NET 로그 메서드는 동기라서, 저장소가 느리면 바로 쓰지 말고 빠른 저장소에 먼저 쓴 뒤 나중에 옮기도록 권장
Asynchronous loggers Apache Software Foundation
비동기 로깅은 짧은 폭증을 큐로 흡수하지만 출력이 계속 느리면 큐가 차서 가장 느린 출력 속도로 떨어지거나 정책에 따라 로그를 버림(Discard)
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
스레드가 멈춰 CPU를 떠난 시간(off-CPU)을 호출 스택별로 합산, -p로 프로세스 지정