OTel 과 CloudWatch 구분하기 (MSK 모니터링)

요약 : 애플리케이션은 OTel, 인프라는 CloudWatch

 

OTel 과 Loki,  Tempo, Thanos 를 이용해서 Grafana에서 모니터링을 추가할 계획.

 

그 중에 Kafka 의 DLT 의 개수를 표출해주는 것을 추가하려고 했는데, datasource를 type: prometheus 를 선택해서 하니 데이터가 나오지 않음. 

 

JVM 메트릭(jvm_memory_used_bytes) 으로 code query를 진행했을 때는 정상적으로 나오는 것을 확인 -> Otel Java Agent 덕분에.

- 수집(Collection) : EKS 내의 각 pod가 생성될 때 OTel Operator가 Java Agent를 자동으로 주입.

이 에이전트가 JVM 내부에서 발생하는 데이터를 실시간으로 가로챔

- 전송(Export) : 수집된 데이터는 OTLP(OpenTelemetry Protocol) 형식을 거쳐서 gRPC 통신으로 OTel Collector에 전달

- 저장(Storage) : 타 계정(현재 다른 모니터링 aws account)에 위치한 OTel Collector는 이를 받아서 Thanos로 보냄.

 Thanos는 Prometheus 메트릭을 최대 1년까지 장기보관 가능

- 시각화(Visualization) : 최종적으로 Grafana에서 Thanos를 데이터 소스로 지정하여 쿼리해 지표 표출

 

--

 

왜 kafka 은 No Data로 나왔을까? 

이유는 관리형 서비스의 특성 때문이었다.

 

보통 자가 구축한 Kafka는 브로커의 JMX(Java Management Extensions) 포트를 통해 메트릭을 직접 긁어 오지만,

AWS MSK는 완전 관리형 서비스라 브로커 내부 시스템에 직접 접근하여 긁어(스크립) 오는게 제한적.

 

현재 인프라 구성되어있는 OTel Java Agent는 애플리케이션 관점이며, 브로커 서버의 관점이 아니다.

서버 자체의 지표는 Thanos 저장소에 쌓이지 않는 것이 정상

 

--

 

따라서, 억지로 Thanos에 밀어넣는게 아닌 AWS 환경에 최적화된 CloudWatch를 이용,병행 해서 효율적으로 사용하는 것을 선택.

 

데이터 소스는 Thanos가 아닌 CloudWatch 데이터 소스 선택

핵심 지표는  MessagesInPerSec -> 초당 메시지 인입량