[ 00 ] 로그 검색 · 원인 분석
10억 줄에서
원인 한 줄을,
3초에.
Logline 은 쏟아지는 로그를 색인해, 장애를 일으킨 한 줄을 찾아 사람이 읽는 문장으로 돌려줍니다.
logline why --since 03:00
원인 줄: 03:12:07.412ERRORpayments-apiacquire timeout · db-main 32/32pool 32/32 timeout
payments-api 가 03:12:07 에 DB 커넥션 풀(32/32)이 가득 차 결제 요청 1,204건을 거절했습니다.
01제품
결과 화면을 열면
원인이 맨 위에 있습니다.
- 1
질의창 필드와 파이프(
|)로 좁히고why로 끝낸다 - 2
원인 줄 고정 스크롤해도 맨 위에 남는다
- 3
문장 요약 원인을 한국어 한 문장으로
- 4
되감기 장애 30분 전부터 다시 본다
02기능
찾고, 박아 두고,
되감고, 묶는다.
-
F-01
문장 요약
로그 묶음을 사람이 읽는 한국어 한 문장으로 바꿉니다. 근거가 된 줄이 문장 아래에 붙습니다.
1 문장
-
F-02
원인 고정
찾은 줄을 결과 맨 위에 박아 두고, 나머지 줄을 그 둘레로 정렬합니다.
2.84 s
-
F-03
시간 되감기
장애 직전 30분의 로그를 같은 질의로 다시 엽니다. 질의를 고쳐 쓸 필요가 없습니다.
−30 min
-
F-04
조용한 알림
같은 원인에서 나온 알림 1,204개를 한 건으로 묶어, 새벽의 휴대폰이 한 번만 울립니다.
1,204 → 1
03작동 방식
원본 한 줄이
문장이 되기까지.
-
03.1 수집
원본을 그대로 받는다
{"ts":"2026-09-25T03:12:07.412Z","svc":"payments-api","level":"error","msg":"acquire timeout","pool":"db-main","in_use":32,"max":32,"waiters":1204}쓰던 수집기가 보내는 JSON 한 줄. 형식을 바꾸지 않습니다.
-
03.2 색인
필드로 쪼개 색인한다
- ts
- 2026-09-25 03:12:07.412
- svc
- payments-api
- level
- error
- pool
- db-main
- in_use/max
- 32/32
- waiters
- 1,204
모든 필드가 질의 조건이 됩니다. 10억 줄 검색이 3초 안에 끝나는 이유입니다.
-
03.3 문장
원인을 문장으로 옮긴다
payments-api 가 03:12:07 에 DB 커넥션 풀(32/32)이 가득 차 결제 요청 1,204건을 거절했습니다.
형광으로 칠한 곳이 원인입니다. 나머지는 그 결과입니다.
04가상 고객
새벽이 짧아진 팀들.
[ 가상 수치 — 실제 고객이 아닙니다 ]
- 1,284팀이 장애 대응에 씁니다
- 2.8 s원인 줄에 닿기까지 중앙값
- −41%도입 뒤 줄어든 장애 시간
06자주 묻는 것
자주 묻는 것.
Q-01기존 로그 수집기를 바꿔야 하나요?
아니요. Fluent Bit · Vector · OpenTelemetry Collector 가 보내는 JSON 을 그대로 받습니다. 서버에 따로 설치할 에이전트는 없습니다.
Q-02문장 요약은 어떤 언어로 나오나요?
한국어가 기본이고 워크스페이스 설정에서 영어·일본어로 바꿀 수 있습니다. 필드 이름과 값은 번역하지 않고 원문 그대로 둡니다.
Q-03데이터는 어디에 저장되나요?
기본은 서울 리전입니다. 기업 요금제는 직접 운영하는 S3 호환 버킷을 저장소로 지정할 수 있습니다.
Q-04무료 요금제에 기간 제한이 있나요?
없습니다. 하루 1 GB 수집 · 3일 보존 안에서는 계속 무료입니다. 넘치는 날은 그날 수집만 멈추고, 쌓인 로그는 지우지 않습니다.
Q-05요약이 틀리면 어떻게 하나요?
문장마다 근거가 된 로그 줄이 붙어 있어 바로 원본을 확인할 수 있습니다. "틀림" 으로 표시하면 같은 원인 묶음에서 다시 계산합니다.
07시작