Chapter 5.2 그라파나 o11y와 상관 관계

TNS는 관찰가능성을 구현한, 그라파나의 레퍼런스 어플리케이션입니다. 현재 그라파나는 TNS보다는 MLT를 추천합니다. 먼저 TNS에 대해서 이해하고 추후에 MLT도 다루어 보도록 하겠습니다.

1. TNS는 추적, 메트릭, 로그를 사용한 상관관계에 집중합니다.
2. MLT는 프로파일을 추가하였으며, 오픈텔레메트리를 도입하였습니다. RED 대시보드를 제공하며, 다양한 마이크로서비스를 제공합니다.

유튜브 동영상을 제공합니다. 참고하시면 쉽게 이해하는데 도움이 됩니다.

대부분의 예제는 쿠버네티스에서 실행됩니다.

1. 레퍼런스 어플리케이션 #1
2. 레퍼런스 어플리케이션 #2
3. 레퍼런스 어플리케이션 #3
4. 레퍼런스 어플리케이션 #4
5. 레퍼런스 어플리케이션 #5
6. 레퍼런스 어플리케이션 #6

데모의 특징

관찰가능성과 이상탐지를 실습하기 위한 좋은 데모의 조건은 아래와 같습니다.

1. 부하 생성기를 통해서 의미 있는 트랜잭션을 생성할 수 있어야 합니다.
2. 관찰가능성은 에러를 해결하는 좋은 방법입니다. 데모는 다양한 유형의 에러를 생성할 수 있어야 합니다.
3. 지연시간, 자원소모량, 처리개수 등 의미 있는 메트릭과 로그, 추적을 출력해야 합니다.

그라파나 TNS 데모는 위의 조건을 만족시키는 유용한 데모입니다. 이번 데모는 오픈텔레메트리를 사용하지 않습니다. 관찰가능성을 구현하기 위해서 오픈텔레메트리는 필수가 아닙니다.

가장 익숙하고 편한 개발언어와 툴을 사용해서, 관찰가능성을 구현하는 것을 권장합니다.

데모 어플리케이션 설치 및 구성

아래와 같은 순서로 진행됩니다. 구체적인 절차는 아래와 같습니다.

미니쿠베를 시작합니다.

minikube start --vm-driver=none --kubernetes-version v1.20.0 --memory=12000 --cpus=2

차트를 추가합니다.

helm repo add grafana https://grafana.github.io/helm-charts

템포를 설치합니다.

helm upgrade --install tempo grafana/tempo

프로메테우스를 설치합니다.

kubectl apply -f prometheus-service.yaml
kubectl apply -f prometheus-deployment.yaml
kubectl apply -f prometheus-claim0-persistentvolumeclaim.yaml
cp prometheus.yml /tmp/hostpath-provisioner/default/prometheus-claim0

로키를 설치합니다.

kubectl apply -f loki-service.yaml
kubectl apply -f loki-deployment.yaml

프롬테일을 설치합니다.

values.yaml을 아래처럼 저장합니다.

config:
  clients:
    - url: http://loki:3100/loki/api/v1/push

아래의 헬름 명령어를 실행합니다.

helm install promtail grafana/promtail -f values.yaml

그라파나를 설치합니다. 버전은 8.5.4 입니다.

조금 더 자동화가 필요합니다. 이러한 방식으로 설치하는 것은 솔직히 좋지 않은 방법입니다.

예를 들어 YAML에서 컨피그맵으로 변환하거나, YAML에서 헬름 차트로 변환되어야 합니다. 오픈소스 툴을 사용하면 쉽게 변환하지만, 시간이 필요합니다.

kubectl apply -f grafana-service.yaml
kubectl apply -f grafana-deployment.yaml
kubectl apply -f grafana-claim2-persistentvolumeclaim.yaml
kubectl apply -f grafana-claim1-persistentvolumeclaim.yaml
kubectl apply -f grafana-claim0-persistentvolumeclaim.yaml
cp datasources.yaml /tmp/hostpath-provisioner/default/grafana-claim0
cp datasources.yaml /tmp/hostpath-provisioner/default/grafana-claim1
cp datasources.yaml /tmp/hostpath-provisioner/default/grafana-claim2
cp dashboards.yaml /tmp/hostpath-provisioner/default/grafana-claim0
cp dashboards.yaml /tmp/hostpath-provisioner/default/grafana-claim1
cp dashboards.yaml /tmp/hostpath-provisioner/default/grafana-claim2
cp -rf dashboards/ /tmp/hostpath-provisioner/default/grafana-claim0
cp -rf dashboards/ /tmp/hostpath-provisioner/default/grafana-claim1
cp -rf dashboards/ /tmp/hostpath-provisioner/default/grafana-claim2

어플리케이션을 설치합니다.

kubectl apply -f .

그라파나 데이터 소스 구성

신호를 이해하는 방법

시스템을 이해하고, 원인을 분석하고, 장애를 해결하는 프로세스는 다양합니다. 개인적인 성향도 있고, 팀의 문화도 다양합니다.

프로세스는 동적이고 유연해야 되는데, 아래의 그림처럼 다양한 방법으로 지원하고 있습니다.

초당 처리 개수와 지연시간을 출력하는 대시보드입니다.

Exemplar를 통해서, 추적 화면으로 이동할 수 있습니다.

추적에서 근본 원인 분석을 할 수 있습니다.

추적에서 다시 로그로 이동할 수 있습니다. 로그에서 디버깅을 합니다.

로그에서 에러가 발견되었습니다. 원인을 분석하고 디버깅합니다.

다시 추적으로 이동해서, 지연시간과 문맥을 확인합니다.

메트릭으로 돌아와서, 처리개수를 포함하는 버킷을 찾습니다.

서비스 별 버킷이 출력됩니다.

빌더를 통해서 간단하게 히스토그램(분포도)을 적용합니다.

히스토그램으로 보면, 주기적으로 지연이 발생합니다.

Exemplar를 활성화하면, 지연이 발생한 추적을 출력합니다.

지연이 발생한 추적으로 이동합니다.

db 서비스에서 지연이 발생할 것을 확인할 수 있습니다.

추적에서 문맥을 이해했습니다.

상세한 에러 메세지를 보기 위해서 로그로 이동합니다.

로그에서 에러 메세지를 확인합니다.

또 다른 에러 메세지를 발견했습니다.

추적으로 이동해서, 에러가 발생한 트랜잭션을 분석합니다.

로그는 텍스트 위주라서 이해하기 어렵습니다. 잘 정리되고 문맥이 풍부한 추적은 원인분석이 더 쉽습니다.

추적에서는 동시성, 리소스 풀 제한, 락, 메모리 부족, 네트워크 지연, 병렬 처리 등 어플리케이션 내부에서 발생하지만 쉽게 보이지 않는 문제점을 해결할 수 있는 실마리를 제공합니다.

운영자는 아래처럼 메트릭 대시보드를 통해서, 시스템에 문제가 있는지 쉽게 이해할 수 있습니다.

메트릭은 우선 임계점을 정합니다. 임계점에 도달하면 알람을 통지하는 것이 일반적입니다.

로그에서 발견되는 에러도 알람과 연계합니다. 알람을 통해서 운영자에게 에러 발생 여부를 통지합니다.

메트릭과 로그의 알람은 무분별하고 반복적이지 않도록 개발되어야 합니다.

동일한 레이블을 사용한 메트릭과 로그 화면을 동기화 할 수 있습니다.

아래의 그림처럼 메트릭을 변경하면, 로그에도 자동적으로 변경이 반영됩니다.