트레이스와 텔레메트리
트레이스와 텔레메트리 (Traces and telemetry)
메트릭, 로그, 트레이스, 프로파일은 관찰 가능성의 네 기둥을 이뤄요. 관찰 가능성의 네 기둥을 상호 연관시키면 애플리케이션과 인프라에 대한 전체적인 관점을 만드는 데 도움이 돼요.
출처: 문서
본문
메트릭, 로그, 트레이스, 프로파일은 관찰 가능성의 기둥을 이뤄요.
메트릭 (Metrics)
메트릭은 시스템 상태의 높은 수준의 그림을 제공해요. 메트릭은 숫자 값이고 알려진 임계값과 비교할 수 있으므로 알림의 기초가 돼요. 알림은 백그라운드에서 계속 실행되며 값이 예상 범위 밖에 있으면 트리거돼요. 이것은 보통 무언가 진행 중이라는 첫 번째 신호이며 발견이 처음 시작되는 곳이에요. 메트릭은 무언가 일어나고 있음을 나타내요.
로그 (Logs)
로그는 정보 컨텍스트를 만드는 단일 프로세스의 활동에 대한 감사 추적을 제공해요. 로그는 애플리케이션 서비스에서 발생하는 일을 상세히 설명하는 원자적 이벤트로 작용해요. 메트릭이 정량적(숫자)이고 구조화된 반면, 로그는 정성적(텍스트)이며 구조화되지 않거나 반구조화돼 있어요. 이들은 더 높은 수준의 세부 정보를 제공하지만 상당히 더 높은 데이터 볼륨을 만드는 대가를 치러요. 로그는 애플리케이션에 무슨 일이 일어나고 있는지 알려줘요.
트레이스 (Traces)
트레이스는 데이터 경로의 각 단계나 작업에서 무슨 일이 일어나는지 알려줌으로써 관찰 가능성 그림에 추가해요. 트레이스는 무언가가 잘못되고 있는 위치의 지도를 제공해요. 트레이스는 데이터 흐름 경로의 각 단계가 완료되는 데 걸리는 시간을 그래픽으로 표현해요. 예를 들어 HTTP 요청, 데이터베이스 조회, 서드파티 서비스 호출이 얼마나 걸리는지를 보여줘요. 요청이 시작·종료되는 위치와 시스템이 어떻게 응답하는지 보여줄 수 있어요. 이 데이터는 요청 흐름을 추적하는 능력이 없었다면 예상하거나 찾지 못했을 곳에서 문제 영역을 찾고 그 영향을 평가하는 데 도움을 줘요.
프로파일 (Profiles)
프로파일은 애플리케이션이 CPU 시간과 메모리 같은 컴퓨팅 리소스를 어떻게 활용하는지 이해하는 데 도움을 줘요. 이는 최적화하고 성능·효율성을 개선할 특정 코드 라인이나 함수를 식별하는 데 도움이 돼요.
트레이스를 사용하는 이유 (Why traces?)
메트릭 자체만으로는 근본 원인을 찾고 복잡한 문제를 해결하기에 충분하지 않아요. 로그도 마찬가지인데, 상당한 양의 정보를 포함할 수 있지만 복잡한 환경의 서로 다른 구성 요소 간 상호작용과 의존성의 컨텍스트가 부족해요. 관찰 가능성의 각 기둥은 문제의 근본 원인을 규명할 때 각자의 고유한 강점이 있어요. 관찰 가능성 전략의 최대 가치를 얻으려면 그것들을 연관시킬 수 있어야 해요.
트레이스는 서비스 간의 관계를 보여주는 고유한 능력이 있어요. 어떤 서비스가 내 서비스의 업스트림에 있는지 식별하는 데 도움을 주는데, 내 서비스의 문제로 어떤 서비스가 부정적 영향을 받을 수 있는지 이해하고 싶을 때 유용해요. 트레이스는 또한 내 서비스의 다운스트림에 있는 서비스 식별에도 도움을 줘요. 애플리케이션은 다운스트림 서비스에 의존하므로, 그 서비스의 문제가 내 서비스가 보고하는 높은 오류나 대기 시간의 원인일 수 있기 때문에 가치가 있어요. 예를 들어, 실패하는 데이터베이스와 영향을 받는 모든 실패 엣지 엔드포인트를 직접 볼 수 있어요.
트레이스와 exemplars를 사용하면 메트릭 데이터 포인트에서 관련 트레이스로 이동할 수 있어요. 또는 트레이스에서 로그로, 그리고 그 반대로 로그에서 트레이스로 이동할 수도 있어요.