옵저버빌리티란?
IT 환경 관리를 위한 새로운 접근법으로 근본적인 원인을 파악하는 관찰자이다.
옵저빌리티 환경을 구성해서 시스템의 내부동작을 이해하고, 전체적인 IT 시스템을 포괄적으로 이해할 수 있다.
모니터링 vs. 옵저버빌리티
모니터링🖥️
모니터링은 메트릭을 수집하고 분석해서 이상현상을 감지하고 경고하는 것이다.
즉, 어떤 문제(What)가 언제 발생(When)했는지를 파악한다.
❓따라서 "왜(Why)"? 라는 원인을 파악하지는 않는다.
옵저버빌리티🔬
이에 비해서 옵저버빌리티는 메트릭, 로그, 트레이스를 전체 시스템관점에서 수집하고, 시각화하고 분석한다.
메트릭: 시간 주기에 따라 측정되는 시계열 수치 데이터로그: 시스템 프로세스의 이벤트 기록트레이스: 사용자의 요청이 처리될 때까지 지나가는 전체 기록
이는 왜 문제가 발생했고(Why), 어떻게 발생하는 지(How)에 초점을 맞춘다.
❗따라서, "왜(Why)"? 라는 근본적인 원인을 파악하는 것이다.
왜 옵저버빌리티가 중요한가?
클라우드 확산으로 서비스가 구조가 모놀리식에서 MSA 구조로 전환되면서 사용자의 요청을 처리하기 위해서 세분화된 여러 서비스간의 상호 작용이 필요했다.
따라서 그만큼 세분화 된 여러 서비스들이 얽히고 섥히면서 어떠한 영역에서 문제가 발생했는 지를 파악하는 옵저버빌리티는 더욱 중요한 관점이 되었다.
AWS EKS의 Logging
크게 3가지 종류의 로깅이 있다.
Control Plane Logging, Application Logging, Node Logging
Control Plane Logging
AWS EKS의 Control Plane은 AWS에서 완전관리형으로 관리된다. 하지만 이러한 완전 관리되는 Control Plane에도 로깅이 필요할 수도 있다.
기본적으로 비활성화되어 있으므로, 이를 로깅하기 위해서는 직접 Control Plane의 자원에📦 로깅이 필요한 대상을 지정해서 활성화 해주면 된다.
이렇게 Control Plane의 자원에 로깅을 지정해서 활성화하면 자동으로 Amazon CloudWatch에 로그 그룹이 생성되고, 로그 스트림을 확인할 수 있다.
Application Logging
애플리케이션이 로그라는 것은 파드에 구성되는 실제 서비스 즉, 컨테이너의 로그를 의미한다.
컨테이너의 특정 위치에 로그가 기록되도록 하고, 이러한 컨테이너에 접근해서 직접 명령어를 통해 로그를 확인할 수 있다.
Node Logging
워커노드 자체에서 발생하는 호스트(EC2)의 로그정보나, Data Plane에서 발생하는 로그 정보를 지칭한다.
AWS EKS에서 공식적으로 제공하는 Node Logging은 없으므로 사용자가 별도의 도구를 설치하고 로그 정보를 수집해야한다.
fluentbit🐦
이러한 Node Logging에 바로 fluentbit🐦를 사용한다.
먹이를 수집해서 전달하는 어미새의 느낌..!
각 노드에 데몬셋 형태로 설치되며 application 로그, host 로그, data plane 로그 총 3가지 유형의 로그 정보를 수집한다.
이러한 fluentbit🐦 또한 수집한 로그 정보를 Amazon CloudWatch에 전달하여 로그 그룹을 생성하고 로그 스트림을 기록한다.
이렇게 전달된 로그 정보는 CloudWatch의 기능인 Log Insight나 Container Insights 등으로 가시성있게 확인할 수 있다.
- Container Insights
🔥프로메테우스란?
프로메테우스는 서비스 디스커버리로 대상을 지정해서 메트릭(시계열 데이터)를 수집하고 시각화하며 알림 기능을 제공하는 오픈소스 모니터링 도구이다.
🪄서비스 디스커버리(Service Discovery)란?
"자동으로 메트릭을 수집할 대상을 찾는 것"
클라우드 환경에서는 서버나 서비스가 자주 추가되거나 제거되고, IP 주소가 변하는데 이를 프로메테우스가 서비스 디스커버리를 통해 자동으로 대상을 찾는다.
⚠️단, 실제 서비스가 아닌 "방식"일 뿐이다. 이 "방식"이 동작하도록 구현해 주는 것은 "Service Monitor"이다.
서비스 모니터(Service Monitor)란?
"어떤 서비스의 메트릭을 수집할 것인지, 어떤 주기로 수집할 것인지" 등의 설정이 담긴 kubernetes 리소스. 프로메테우스는 아러한 서비스 모니터를 보고, exporters에 접근하여 메트릭을 수집한다.
✅ 즉, Service Monitor에 정의된 정보를 바탕으로 서비스 디스커버리가 "동작"하는 것이다.
프로메테우스의 구조
프로메테우스의 중추적인 역할을 하는 프로메테우스 서버의 구조부터 살펴보자.
이러한 프로메테우스 서버는 3개의 모듈로 구성되는데 각 모듈의 역할은 다음과 같다.
Retrival, TSDB, HTTP Server
Retrival: 서비스 디스커버리를 수행하고, 메트릭을 수집하는 모듈TSDB: 수집한 시계열 데이터를 저장하는 스토리지 엔진HTTP Server: HTTP 통신을 위한 모듈
동작 과정
-
Retrival에서 서비스 디스커버리를 통해 메트릭을 수집할 대상을 찾는다. (서버나 애플리케이션)
(서비스 모니터를 통해서 동작함) -
이후 대상 서비스(프로메테우스 타깃)으로부터 exporter가 메트릭을 추출하고 변환한다.
이러한 "exporter가 메트릭을 추출하고 변환한다"는 표현은 exporter가 모니터링할 대상 서비스나 외부 시스템의 메트릭을 추출하고 프로메테우스의 메트릭 포멧으로 변환한다는 의미이다.
- 추출되고 변환된 메트릭을 Retrival가 exporter로부터 pull하여 가져온다.
(이처럼 프로메테우스는 pull 방식으로 메트릭을 가져온다.)
- 수집된 메트릭은 TSDB를 통해 스토리지 영역에 저장한다.
만일 별도의 스토리지 영역이 지정되지 않은 경우 로컬영역에 데이터를 저장한다.
(☸️쿠버네티스에서는 파드 내부의 emptyDir가 된다.)
Pushgateway
만일 직접 서버에서 프로메테우스로 메트릭을 보내는 경우, 프로메테우스 서버는 Pull 방식만을 지원함에 따라 별도의 작업을 수행하는 대상이 필요하다.
이를 위해 Pushgateway를 구성하게 되는데, Pushgateway로 서버에서 Push 메트릭이 수행되면 프로메테우스 서버는 Pushgateway에 Pull하여 해당 메트릭을 가져온다.
Alertmanager
프로메네티우스는 Alertmanager를 통해서 CloudWatch의 기능과 동일하게 정의한 경보 규칙에 따라 문제 상황이 발생하면 이메일이나 슬랙을 통해서 경보를 보낼 수 있다.
Data Visualization
프로메테우스는 메트릭 데이터를 시각화하기 위한 기본 WEB UI를 제공한다. 사용자는 이 UI를 통해 프로메테우스 쿼리 언어(PromQL)로 데이터를 조회하고, 그 결과를 그래프나 차트 형태로 볼 수 있다.
☀️ Grafana
❗하지만 보다 복잡하고 다양한 시각화 기능이 필요한 경우 Grafana 같은 외부 도구와 함께 사용하는 것이 일반적이다. Grafana는 프로메테우스와 잘 통합되어, 보다 다양하고 세밀한 대시보드를 구성할 수 있게 해준다.
fluentbit vs. Prometheus
fluentbit
- 주 사용 목적: 로그 처리 및 전달
- 데이터 종류: 텍스트 로그 파일, 이벤트 로그 등
- 기능: 로그 데이터의 수집, 정제(파싱, 필터링), 버퍼링, 전달. 대상으로는 Elasticsearch, Kafka 등이 있음.
Prometheus
- 주 사용 목적: 메트릭 기반 모니터링
- 데이터 종류: 시계열 데이터, 시스템 및 애플리케이션의 성능
- 기능: 메트릭 데이터의 수집(Pull 방식), 저장, 쿼리, 경고 설정 및 알림.
같이 사용하는 경우
Fluent Bit는 로그 관리에 초점을 맞추고, Prometheus는 메트릭 기반 모니터링에 초점을 맞춘다. 따라서, 로그와 메트릭 모두를 중요시하는 시스템에서는 두 도구를 함께 사용하여 전반적인 모니터링 및 로그 관리 솔루션을 구성할 수 있다.
따로 사용하는 경우
특정 환경이나 요구 사항에 따라 한 도구만을 사용할 수도 있다. 예를 들어, 단순히 애플리케이션의 로그 관리와 분석이 주 목적이라면 Fluent Bit만을 사용할 수 있다. 반면, 시스템의 성능 모니터링과 알람이 주 목적이라면 Prometheus만을 사용할 수 있다.
