끊겨도 스팬은 남는다

한 줄 요약

전파가 끊겨도 각 서비스의 스팬은 멀쩡히 남습니다. 그래서 증상이 "트레이싱이 안 된다" 가 아니라 "요청의 뒷부분이 안 보인다" 로 나타납니다.

왜 진짜 요청이 오가야 하나

앞 모듈들에서 전파와 컬렉터를 다뤘습니다. 그런데 그 실습들이 도는 곳에는 요청이 오가지 않아서, 전파가 끊기는 현상 자체가 일어나지 않았습니다. OTCA 가 가장 많이 묻는 자리인데도요.

끊긴 것은 조용하다

전파가 끊겨도 각 서비스의 스팬은 멀쩡히 남습니다. 화면을 열면 트레이스가 있고 이름도 시간도 정상입니다. 다만 하나로 이어지지 않을 뿐입니다.

그래서 증상이 "트레이싱이 안 된다" 가 아니라 "왜 이 요청의 뒷부분이 안 보이지" 입니다. 원인을 찾기가 훨씬 어렵습니다.

1. 라이브러리가 헤더를 안 붙인다      직접 만든 HTTP 클라이언트가 흔하다2. 프록시가 헤더를 지운다             허용 목록에 traceparent 가 없다3. 큐를 건너갈 때 잃는다              메시지 본문에 넣어 손으로 이어야 한다4. 스레드·비동기 경계에서 끊긴다      컨텍스트가 따라가지 않는다

뒤의 둘이 특히 조용합니다. HTTP 는 헤더를 보면 알 수 있지만, 큐와 비동기는 들여다볼 곳이 마땅치 않습니다.

알아채려면 부모 없는 스팬의 비율을 지표로 두어야 합니다. 어느 서비스에서 늘 뿌리 스팬이 만들어진다면 그 앞이 끊긴 것입니다.

스팬이 도착했는데 화면에 없을 때

실습을 만들면서 실제로 물린 자리입니다. 컬렉터 로그에는 스팬이 들어왔다고 찍히는데 화면에는 아무것도 없었습니다.

타임스탬프가 원인이었습니다. 작은 수를 넣었더니 1970년으로 색인됐고, 기본 조회 범위(최근)에서 찾지 못했습니다. 그리고 Jaeger 의 질의 API 는 시간 범위를 안 주면 빈 결과를 돌려줍니다.

실무에서 진짜 중요한 것

부모 없는 스팬의 비율을 지표로 둡니다. 전파가 끊긴 것을 사람이 알아채는 사실상 유일한 방법입니다. 어느 서비스에서 늘 뿌리 스팬이 만들어진다면 그 앞이 끊긴 것이고, 그러면 지점을 지목할 수 있습니다.

큐와 비동기 경계는 손으로 이어야 합니다. HTTP 는 계측 라이브러리가 헤더를 붙여 주지만, 메시지 본문에 컨텍스트를 넣고 꺼내는 일은 아무도 대신 해 주지 않습니다. 큐를 쓰는 구간이 있다면 그 구간의 전파는 설계 단계에 넣어야 합니다.

스팬이 안 보이면 타임스탬프부터 봅니다. 나노초가 아닌 값을 넣으면 1970년으로 색인되어 기본 조회 범위에서는 영원히 찾을 수 없습니다. 컬렉터 로그에 "받았다" 가 찍히는데 화면이 비어 있으면 거의 이 경우입니다.

다음 실습에서 이것들을 진짜 컬렉터와 진짜 요청 위에서 직접 확인합니다.