어느 날 지표 저장소가 메모리 부족으로 죽습니다. SaaS를 쓰는 팀이라면 서버 대신 이번 달 청구서가 뛰어오르고요. 트래픽이 늘지도 않았고 새 서비스를 붙이지도 않았어요. 범인을 찾아보니 지난주 배포에 들어간 지표 한 줄입니다. 요청 경로를 레이블(label)로 붙였을 뿐인데요. 😅 관측성 정리와 OpenTelemetry 지표 정리에서 지표에 사용자 ID 같은 값을 넣지 말라고 했는데요. 실제 사고는 그렇게 대놓고 나지 않습니다. 대부분은 "이건 값이 몇 개 안 되겠지" 하고 붙인 레이블이 생각보다 많은 값을 가지면서 터지죠.
지금까지 이 시리즈에서 속성 이름을 꽤 여러 개 지었습니다. order.id, db.system, http.request.method 같은 것들이요. 별생각 없이 지은 이름도 있고 어디서 본 듯한 이름도 있었죠. 그런데 이름은 정말 아무래도 괜찮을까요? 🤔 스팬 하나만 놓고 보면 그렇습니다. http.method라고 적든 request_method라고 적든 내가 읽으면 되니까요. 문제는 그 스팬이 나 혼자 만든 게 아닐 때 시작됩니다. 이름이 갈리면 잃는 것 상황을 그려 보겠습니다. 주문 서비스는 직접 계측해서 http.metho
남은 신호는 로그 하나입니다. 그런데 지표 정리까지 왔다면 좀 이상하게 느껴질 거예요. 로그는 이미 다들 쓰고 있잖아요. 😅 파이썬이면 logging, Node라면 Pino나 Winston을 붙여 두고 잘 돌아가는데 여기에 또 새로운 걸 얹어야 하나 싶죠. OpenTelemetry도 같은 생각을 했습니다. 그래서 로그만 다른 길을 갔어요. 이 글에서는 그 선택이 무엇이었는지, 그리고 기존 로그를 추적과 이어 붙이는 방법을 다루겠습니다. 로그만 접근이 달랐던 이유 추적과 지표는 OpenTelemetry가 새로 표준을 만들었습니다.
수집기 정리까지 오면서 흘려보낸 건 추적뿐이었습니다. 추적은 요청 하나를 아주 자세히 보여 주지만 "지난 한 시간 동안 오류율이 몇 퍼센트였나"에는 답하지 못해요. 요청 하나하나를 다 뒤져 세야 하니까요. 지표, 로그, 추적 정리에서 정리했듯 그건 지표(metric)의 몫입니다. 이 글에서는 지표를 만드는 계측기(instrument) 종류를 고르는 법, 속성을 붙일 때 조심할 것, 그리고 Prometheus까지 연결하는 과정을 다루겠습니다. 계측기는 네 가지 지표를 만들려면 먼저 미터(meter)를 얻고 거기서 계측기를 만듭니다.
지금까지 만든 구조에는 선이 하나뿐이었습니다. 애플리케이션이 백엔드로 직접 보내는 선이요. 서비스가 둘일 때는 아무 문제가 없죠. 그런데 스무 개가 되면 어떨까요? 백엔드 주소를 바꾸려면 스무 곳을 고쳐 배포해야 합니다. 어떤 속성을 모든 서비스에 붙이기로 했다면 역시 스무 곳이고요. 백엔드가 잠깐 죽으면 스무 개의 애플리케이션이 각자 재시도하다 메모리에 데이터를 쌓습니다. 😰 관측을 위해 넣은 코드가 서비스를 위협하는 셈이죠. 이 글에서는 그 사이에 두는 수집기(Collector)를 다루겠습니다. 파이프라인 세 조각 수집기는 텔
OpenTelemetry 추적 정리에서 만든 트리는 깔끔했지만 한계가 있었습니다. 프로세스 하나 안에서만 이어진다는 것이요. 주문 서비스가 결제 서비스를 HTTP로 부르면 어떻게 될까요? 결제 서비스 입장에서는 그냥 요청 하나가 들어온 겁니다. 자기가 누구의 자식인지 알 도리가 없으니 새 추적을 시작하죠. 결과적으로 사용자 눈에는 한 번의 주문인데 추적은 두 개로 쪼개집니다. 😅 서비스가 늘어날수록 이 조각은 많아지고, 정작 알고 싶은 "이 주문 요청이 어디서 시간을 썼나"는 답할 수 없게 돼요. 이 글에서는 경계를 넘어 추적을
OpenTelemetry 정리에서 계측 코드가 API에만 의존하면 백엔드를 갈아 끼울 수 있다는 이야기를 했는데요. 그때 만든 스팬은 greet 하나뿐이었습니다. 이름을 붙이고 끝낸 게 전부였죠. 실제로는 여기서부터가 어렵습니다. 요청 하나를 처리하는 동안 스팬을 하나만 만들면 "이 요청이 200밀리초 걸렸다"까지만 알 수 있고, 반대로 함수마다 만들면 화면이 스팬으로 뒤덮여 오히려 안 보이거든요. 😅 이 글에서는 스팬에 무엇을 담는지, 어느 단위로 나누는 게 쓸모 있는지, 그리고 만든 추적을 Jaeger에서 어떻게 확인하는지를
추적(trace)을 처음 붙일 때 Jaeger를 골랐다고 해 볼게요. Jaeger가 주는 라이브러리를 받아 서비스 곳곳에 스팬을 만드는 코드를 심었고, 잘 돌아갑니다. 그런데 반년 뒤 팀이 다른 백엔드로 옮기기로 합니다. 무엇을 다시 해야 할까요? 심어 둔 계측 코드 전부입니다. 😅 몇 년 전까지는 이게 기본값이었습니다. 관측 도구를 고르는 일이 곧 그 도구를 코드에 새겨 넣는 일이었고, 한번 새기면 되돌리기 어려웠죠. 지금은 다릅니다. 계측 코드는 그대로 두고 환경 변수 하나만 바꾸면 텔레메트리(telemetry)가 다른 곳으로
관측성 정리에서 미리 정하지 않은 질문에 답하려면 원시 이벤트를 남겨야 한다고 했는데요. 그러면 다음 질문이 따라옵니다. 어떤 형태로 남길까? 앞 글에서 던진 자가 진단 세 질문을 다시 꺼내 보면 답이 셋으로 갈립니다. "지금 오류율이 얼마인가"는 숫자 하나로 답하고, "그 사용자의 요청에 무슨 일이 있었나"는 사건 기록으로 답하고, "요청이 어느 서비스에서 시간을 썼나"는 요청의 여정으로 답해야 하거든요. 이 세 형태가 지표(metric), 로그(log), 추적(trace)입니다. 2017년쯤부터 "관측성의 세 기둥"이라는 말로