[인프라] 프로메테우스 아키텍처

참고

• 프로메테우스 오픈소스 모니터링 시스템

구조

• 다음 이미지는 프로메테우스의 전반적인 아키텍처를 보여줍니다.
• 프로메테우스는 서비스 검색을 통해 데이터 수집 다생을 발견합니다.
• 익스포터를 통해 데이터 수집이 가능한 자체적인 계측 애플리케이션이나 서드파티 애플리케이션 등이 데이터 수집 대상이라 할 수 있습니다.
• 수집된 데이터가 저장되면 PromQL 을 이용해 대시보드에서 활용 되거나 알림 매니저를 통해 알림이 발송되고 알림은 다시 무선 호출, 이메일 같은 통보로 바뀝니다.

클라이언트 라이브러리

• 메트릭은 애플리케이션에서 마법처럼 튀어나오는 것이 아닙니다.
• 누군가 메트릭을 만들기 위한 계측 코드를 추가해야 합니다.
• 바로 이 부분이 클라이언트 라이브러리가 관여하는 부분입니다.
• 보통 2~3 중의 코드로 메트릭을 정의하고, 제어하려는 코드에 인라인으로 원하는 계측 기능을 추가할 수 있습니다.
• 이를 직접 계측 이라고 부릅니다.

익스포터

• 실행하는 모든 코드를 통제하거나 해당 코드에 항상 접근할 수 있는 것은 아니므로, 직접 계측 추가가 실제로 수행할 수 있는 옵션이 아닌 경우도 있습니다.
• 예를 들어 운영체제 커널이 HTTP 를 통해 프로메테우스 형식을 갖는 메트릭을 항상 출력하지는 않습니다.
• 대부분 시스템 커널 같은 소프트웨어에는 메트릭에 접근할 수 있는 인터페이스가 있습니다.
• 이러한 인터페이스는 대부분의 리눅스 메트릭에서 필요한 사용자 정의 구문 분석과 처리가 필요한 부가적인 형식이거나, SNMP 처럼 잘 정립된 표준일 수도 있습니다.
• 익스포터 는 가져오고 싶은 메트릭을 애플리케이션 바로 옆에 배치하는 소프트웨어 입니다.
• 익스포터는 프로메테우스로부터 요청을 받아서, 애플리케이션에서 요청된 데이터를 수집하고, 데이터를 올바른 형식으로 변환한 다음, 마지막으로 프로메테우스에 대한 응답으로 데이터를 반환합니다.
• 익스포터는 애플리케이션의 메트릭 인터페이스를 프로메테우스의 게시 형식으로 변환하는 일대일 방식의 작은 프록시라고 생각해도 좋습니다.

서비스 검색

• 계측할 모든 애플리케이션이 준비되고 익스포터가 실행되면, 프로메테우스는 이들이 어디에 있는지 파악해야 합니다.
• 이를 통해 프로메테우스는 무엇을 모니터링해야 할 지를 알게 되며, 모니터링 대상이 응답하지 않는 경우도 파악할 수 있습니다.
• 동적 환경에서 애플리케이션과 익스포터 목록은 금방 유효기간이 만료되기 때문에 목록을 한 번만 제공해서는 안됩니다.
• 이 떄문에 서비스 검색이 필요합니다.

데이터 수집

• 서비스 검색 과 레이블 재지정은 모니터링되는 대상 목록을 알려줍니다.
• 이제 프로메테우스는 메트릭을 자여와야 합니다.
• 프로메테우스는 수집(Scrape) 이라 불리는 HTTP 요청을 보내 메트릭을 가져오는 작업을 수행합니다.
• 수집에 대한 응답은 구문 분석 후 저장 장치에 저장됩니다.
• 데이터 수집 요청이 성공했는지, 그리고 얼마나 오래 걸렸는지 같은 유용한 메트릭이 일부 추가되었습니다.
• 데이터 수집 요청은 정기적으로 발생합니다.
• 일반적으로 각 대상에 10~60 초마다 요청을 보내도록 구성할 수 있습니다.

풀 방식과 푸시 방식

• 프로메테우스는 Pull 기반의 시스템입니다.
• 프로메테우스는 구성에 따라 데이터의 수집 시기와 대상을 결정합니다.
• 또한, 얼마나 자주 모니터링 할지를 모니터링 대상이 결정하는 푸시 기반 시스템도 있습니다.