최신 시스템은 몇 년 전과 비교하면 매우 다릅니다. 개발 조직은 기존의 모놀리스 아키텍처 구축에서 벗어나 고도로 분산된 인프라에서 실행되는 컨테이너화된 애플리케이션을 개발하는 방향으로 전환했습니다.
이러한 변화로 인해 시스템의 내재적 복원력은 본질적으로 향상되었지만, 전체적으로 복잡성이 증가함에 따라 문제 발생 시 근본 원인을 효과적으로 파악하고 해결하는 것이 더 중요하고 어려워졌습니다.
이 문제에 대한 해결책 중 하나는 서비스 및 인프라의 상태를 효율적으로 모니터링할 수 있는 도구와 플랫폼을 활용하는 것입니다. 이를 위해 이 게시물에서는 Prometheus로 서비스 및 인프라를 모니터링하는 모범 사례에 대해 설명합니다. 또한 현재 사용하고 있는 복잡하고 고도로 분산된 시스템 환경을 모니터링하는 데 Prometheus만으로는 부족한 이유에 대해서도 설명합니다.
Prometheus가 무엇인가요?
Prometheus는 오픈 소스 모니터링 및 알림 툴킷으로, 2012년 SoundCloud가 클라우드 네이티브 메트릭을 모니터링하기 위해 처음 개발했습니다.
모니터링 및 통합 가시성 에 로그, 메트릭 및 추적 등 세 가지 기본 데이터 유형이 있습니다. 메트릭은 시계열 데이터에서 서비스 수준 목표(SLO) 및 서비스 수준 지표(SLI)를 추적하는 데 도움이 되는 데이터 스톱워치 역할을 합니다.
카디널리티가 높은 메트릭에는 고유한 레이블 조합(예: user_id, region)이 많기 때문에 Prometheus의 저장 및 쿼리 성능에 부담을 줄 수 있습니다. 그러나 많은 고객이 기능이 많은 통합 가시성 환경을 필요로 하기 때문에, 요즘에는 대부분의 기업은 수집기를 통합하고 세 가지 데이터 소스 모두에서 데이터를 수집하기 위해 OpenTelemetry를 도입하고 있습니다.
Prometheus로 무엇을 모니터링할 수 있나요?
기업은 Prometheus로 모니터링하여 서비스 및 인프라 성능에 관한 메트릭 데이터를 수집할 수 있습니다. 사용 사례에 따라 Prometheus 지표에는 CPU 사용율, 메모리 사용량, 총 요청, 초당 요청, 요청 수, 예외 수 등의 성능 마커가 포함됩니다. 이렇게 수집한 메트릭 데이터를 효과적으로 활용하면 기업이 적시에 시스템 문제를 파악하는 데 도움이 될 수 있습니다.
Prometheus 서버 아키텍처
Prometheus 아키텍처는 실제 모니터링 기능을 수행하는 Prometheus 서버의 핵심입니다. Prometheus 서버는 시계열 데이터베이스, 데이터 검색 담당자, HTTP 서버의 세 가지 주요 구성 요소로 이루어져 있습니다.
시계열 데이터베이스
이 구성 요소는 메트릭 데이터를 저장하는 역할을 합니다. 이 데이터는 시계열로 저장되며, 이는 데이터가 동일한 메트릭 및 레이블링된 차원 집합에 속하는 일련의 타임스탬프 데이터 포인트로 데이터베이스에 표시된다는 의미입니다.
데이터 검색 담당자
이 구성 요소는 이름에서 알 수 있듯이 애플리케이션, 서비스 또는 기타 시스템 인프라 구성 요소일 수 있는 “대상”에서 메트릭을 가져옵니다. 그런 다음 수집한 메트릭을 시계열 데이터베이스로 전송합니다. 데이터 검색 담당자는 대상에서 Prometheus 인스턴스라는 HTTP 엔드포인트를 스크래핑하여 메트릭을 수집합니다.
기본적으로 메트릭 엔드포인트는 < 호스트 주소 >/metrics입니다. 대상을 모니터링하기 위해 Prometheus 내보내기를 사용하여 Prometheus를 구성합니다. 기본적으로 내보내기는 대상에서 메트릭을 가져와서 적절한 형식을 지정하고 /metrics 엔드포인트를 노출하여 데이터 검색 담당자가 시계열 데이터베이스에 저장할 데이터를 가져올 수 있도록 지원하는 서비스입니다. 스크랩이 불가능한 작업에서 메트릭을 전송하려면 Prometheus Pushgateway를 사용하여 수명이 짧은 서비스 수준 배치 작업에서 Prometheus가 스크랩할 수 있는 중개 작업으로 시계열을 전송할 수 있습니다.
HTTP 서버
이 서버는 시계열 데이터베이스에서 데이터를 가져오기 위해 Prometheus 쿼리 언어(PromQL)로 작성된 쿼리를 수락합니다. HTTP 서버는 Prometheus 그래프 UI 또는 Grafana 같은 기타 데이터 시각화 도구에 사용되여 유용하고 사용자에게 친숙한 형식으로 메트릭을 쿼리하고 시각화할 수 있는 인터페이스를 개발자와 IT 담당자에게 제공합니다.
Prometheus 알림 관리
Prometheus Alertmanager도 특별히 언급해야 할 기능입니다. Prometheus 구성의 한도 규칙을 설정하면 한도를 초과할 때 알림을 보낼 수 있습니다. 이런 일이 발생하면 Prometheus 서버는 Alertmanager에게 알림을 전송합니다. 그다음 Alertmanager는 알림에 대한 중복 제거, 그룹화하고 이메일 또는 기타 알림 통합 도구를 통해 적절한 담당자에게 전달합니다.
Prometheus만으로는 부족한 이유
아시다시피 최신 개발 아키텍처는 10여 년 전의 아키텍처보다 훨씬 더 복잡해졌습니다. 오늘날의 시스템에는 Kubernetes 클러스터와 같이 컨테이너화된 애플리케이션 및 서비스를 실행하는 많은 서버가 포함되어 있습니다. 이러한 서비스는 느슨하게 결합되어 서로 호출하여 최종 사용자에게 기능을 제공합니다. 구조적으로 이러한 서비스를 분리해서 여러 클라우드 환경에서도 실행할 수 있습니다. 이러한 시스템의 복잡성으로 인해 장애의 원인이 불분명해질 수 있습니다.
조직은 이러한 문제를 해결하기 위해 시스템 동작에 대한 깊은 인사이트가 필요하며, 이를 위해 로그 이벤트 데이터를 집계하고 수집하는 것이 매우 중요합니다. 이 로그 데이터는 성능 메트릭과 관련 있으므로 조직이 효율적인 근본 원인 분석에 필요한 인사이트와 컨텍스트를 확보할 수 있습니다. Prometheus는 메트릭을 수집하지만 로그 데이터는 수집하지 않습니다. 따라서 자체적으로 효과적인 사고 대응을 지원하는 데 필요한 수준의 세부 정보를 제공하지 않습니다.
또한, Prometheus가 대규모로 확장하면 문제가 발생하는데 고도로 분산된 최신 시스템에서는 피할 수 없는 상황입니다. 여러 인스턴스에 대한 메트릭을 쿼리하고 집계할 목적으로 Prometheus를구축한 것이 아닙니다. 이렇게 구성하려면 조직의 Prometheus 배포에 복잡성을 더 추가해야 합니다. 이로 인해 전체 시스템에 대한 종합적인 관점을 얻는 과정이 복잡해지는데, 이는 효율적인 사고 대응 수행에 매우 중요한 측면입니다.
마지막으로, Prometheus는 메트릭 데이터를 장기간 보관할 수 없습니다. 이러한 유형의 과거 데이터에 대한 액세스는 복잡한 환경을 관리하는 조직에 매우 유용할 수 있습니다. 우선, 조직에서는 이러한 메트릭을 분석하여 몇 달 또는 1년에 걸쳐 발생한 패턴을 감지하여 특정 기간의 시스템 사용량을 파악할 수 있습니다. 이러한 인사이트로 시스템이 한계에 도달했을 때 확장 전략을 수립하는 데 도움이 됩니다.
Kubernetes 통합 모니터링 컬렉션
Prometheus는 SLO 및 SLI에 대한 상위 수준의 메트릭을 수집하는 훌륭한 도구이지만 사이트 신뢰성 엔지니어와 보안 분석가는 로그를 상세히 조사하여 정확히 무엇이 잘못되었는지 찾아야 합니다. 그렇기 때문에 로그, 메트릭, 추적 등 모든 데이터 유형에 걸쳐 통합된 원격 분석을 수집하는 것이 중요합니다. 구식 레거시 프로세스와 사고방식을 혁신하고 최신 모범 사례를 사용하여 최상의 디지털 고객 경험을 보장해야 합니다.
이러한 모든 문제를 해결하는 가장 좋은 방법은 Sumo Logic의 OpenTelemetry 수집기의 통합 Kubernetes 모니터링을 활용하고 최신 헬름 차트를 설정는 것입니다. 또한, Sumo Logic의 Otel Remote Management를 사용하면 수집기를 설정하고 관리하는 시간을 아낄 수 있습니다. 이 수집기와 병행하여 Prometheus 데이터를 집계할 수는 있지만, 인프라에 특정 난해한 기술이 필요하지 않는 한 메트릭의 미들웨어로 사용할 이유는 없습니다. 예를 들어, PromQL에 대한 숙련도나 Sumo Logic 모니터링 환경에서는 사용할 수 없는 특정 히스토그램이 필요한 경우입니다.
OpenTelemetry를 표준으로 사용하면 수집 공간을 줄이고 계측 시간을 절약하여 효과적인 보안 및 모니터링 모범 사례를 구현하는 데 도움이 됩니다.
더 자세히 알고 싶으신가요? Kubernetes 모니터링 모범 사례 살펴보세요.
