이전 글에서 메트릭, 로그, 추적을 개별적으로 살펴보았다면 이번 글에서는 각각의 상관관계를 구성하고, 실습을 통해 메트릭, 로그, 추적을 연계한다. 이들의 상관관계를 구성하기 위해서 이그젬플러, 스팬 메트릭 등 기술이 존재한다.
이번 글 내용은 대부분 실습 내용이며 각 데모들은 다음과 같은 특징이 있다.
1. 각 애플리케이션은 쿠버네티스 혹은 리눅스에서 직접 실행하여 신호를 생성할 수 있다.
2. 그라파나 관측 가능성 오픈소스를 주로 사용하지만, 오픈서치 등 다른 관측 가능성도 구현할 수 있다.
3. 단순한 상관관계에 그치지 않고 복잡한 여러가지 기능을 추가한다. 예를 들어, 이그젬플러, 스팬 메트릭, 서비스 그래프를 사용해서 문맥이 풍부하고, 원인 분석이 가능하도록 관측가능성을 구현한다.
데모들은 다음과 같이 구성되어 있다
1. 다양한 관점에서 근본 원인을 분석하는 방법을 소개한다. 추적에서 메트릭을 생성하는 방법은 비용을 절감하고 신속하게 관측 가능성을 구축하는 좋은 방법이다.
2. TNS 에서는 그라파나 관측 가능성이 제공하는 상관관계에 대해서 자세히 설명한다.
3. 오픈텔레메트리를 도입하여 그라파나, 오픈서치 등 다양한 솔루션과 연계하고 관측 가능성을 구현하는 방법을 설명한다.
4. 커스텀 메트릭, 추적, 로그를 직접 개발하여 관측 가능성을 구축한다.
5.1 상관관계
1장에서 공부했듯이 메트릭, 로그, 추적은 다음과 같은 상관관계를 갖고있다
상관관계 구현할 방법으로서
- 기본적으로 개발 툴에서 지원하는 상관관계를 활용 (ex: 로그와 추적 간 상관관계는 그라파나에서 기본적으로 제공해주는 기능을 활용)
- 상관관계 표준을 구현 (ex: 이그젬플러, 메트릭 생성기(스팬메트릭) 등을 활용해 구현
- 추가 개발을 통해서 구현 (ex: 메트릭과 로그 간 상관관계는 표준이 없고 개발 툴에서도 지원을 안하기 때문에 레이블, 타임스탬프, 네이밍 규칙, 계측 API 등 방법으로 메트릭과 로그 간 상관관계를 구현해야됌)
5.1.1 메트릭에서 추적으로
프로메테우스는 이그젬플러를 관리하기 위해서 메모리에 별도로 공간을 할당하고 이를 저장한다. 이그젬플러 저장소는 모든 시리즈의 메모리에 이그젬플러를 저장하는 고정 크기 원형 버퍼로 구현된다. 이 기능을 활성화하면 프로메테우스가 스크래핑한 이그젬플러를 저장할 수 있다. 구성 파일 블록 스토리지 내 이그젬플러를 사용하여 원형 버퍼의 크기를 제어할 수 있다. traceID=<trace-id>만 있는 이그젬플러는 메모리 내 이그젬플러 저장소를 통해 대략 100바이트 메모리를 사용한다. 그리고 그라파나 미미르에는 메모리에 이그젬플러를 저장하는 기능이 포함되어 있으며 예시 스토리지는 프로메테우스와 유사하게 구현된다. 이그젬플러를 설정하기 위해 두가지 방법이 있다
1. 그라파나에서 프로메테우스 데이터 소스 내 이그젬플러 설정을 수정한다
2. 프로메테우스 설정을 변경하고 재시작한다
이그젬플러는 주어진 시간 간격에서 측정된 추적의 샘플링이다. 이그젬플러는 시계열 데이터 내 높은 카디널리티를 가진 메타데이터를 구별하는데 도움을 주고, 메트릭은 집계 보기를 제공하는 데 탁월하다. 이 둘을 통해 서로 단점을 보완하며 이그젬플러를 통해 메트릭과 추적을 연결한다. 예를 들어, 사용자의 80퍼 이상이 2초 이내에 웹사이트에 접근할 수 있지만 일부 지연이 발생하고 있다. 수집된 데이터에서 이그젬플러를 통해 높은 대기시간을 나타내는 거래를 추적할 수 있다.
5.1.2 추적에서 메트릭으로
메트릭 생성기는 추저게서 메트릭을 생성(파생)하는 템포 컴포넌트다. 디스트리뷰터는 수신된 스팬을 인제스터와 메트릭 생성기에 기록한다. 메트릭 생성기는 스팬을 처리하고, 프로메테우스 원격 쓰기 프로토콜을 사용하여 프로메테우스 데이터 소스에 메트릭을 기록한다. 메트릭 생성기 내부에서는 서비스 그래프, 스팬 메트릭 등 프로세서를 이용하여 스팬을 수집하고 버킷, 합계, 개수 등 다양한 메트릭을 생성한다.
- 서비스 그래프는 그라파나 대시보드에서 서비스 간의 상관관계를 시각적으로 표현한다
- 스팬 메트릭은 프로메테우스에서 처리 개수, 처리 지연에 관련된 메트릭을 자동생성한다
스팬 메트릭을 이용하여 쉽게 이그젬플러를 구현할 수 있다. 예를 들어, 요청-오류-기간 메트릭을 포함하여 수집된 추적 데이터에서 메트릭을 생성할 수 있다.
5.1.3 로그에서 추적으로
그라파나 대시보스에서 로그 데이터 소스 내 파생 필드를 사용하면 Trace ID 를 포함하는 Log to Trace 를 구현할 수 있다. 추가로 오픈텔레메트리에서는 로그 -> 추적으로 어떻게 이동을 구현하기 위해 로깅 내 고유한 traceId, spanId 를 추가하도록 구현되어있다
5.1.4 추적에서 로그로
Trace Id 에 로그를 포함해서, 추적에서 로그로 이동을 구현할 수 있다. 이도 마찬가지로 그라파나에서 간단한 구성만으로 구현이 가능하다
5.1.5 메트릭에서 로그로
아직까지 matric <-> log 간 상관관계 표준이 정의되어 있지 않으며, 보통 다음과 같은 방법으로 상관관계를 구현하였다
- 레이블, 태그 지정
- 타임스탬프 사용
- 네이밍 규칙 사용
- 계측 API 를 소스에 구현
보통 어플리케이션에서 로깅 라이브러리 를 통해 생성하는 태그, 레이블과 프로메테우스 익스포터에 지정할 태그, 레이블을 맞춰주면 메트릭과 로그를 일치시키는 것이 어렵지 않다. 즉, 익스포터 -> 프로메테우스 -> 그라파나 순서로 저장 및 검색되는 메트릭에 붙여진 레이블과 동일한 레이블을 가진 로그를 찾으면 된다.
