Prometheus를 통한 서버 모니터링
가변적 인프라에 대한 서버의 자원 수집 및 모니터링
서비스가 가장 바쁜 성수기 시즌.
인프라를 운영하면 가장 많이 듣는 이야기가 있습니다.
“현재 서버 상태 어떤가요?”
AWS를 사용하는 회사 서비스 특성상 단순 지표의 경우 CloudWatch를 통해 확인이 가능합니다.
하지만 아래와 같은 물음은 어떨까요?
“현재 디스크 사용률과 메모리 사용률이 어떤가요?”
클라우드의 환경이 보편화되면서 우리는 서버를 쉽게 생성하고 쉽게 삭제합니다. 예전엔 한정적이고 고정된 인프라만 운영관리를 하였다면 최근에는 서비스 상태에 따라 언제든 생성될 수 있는 인프라를 운영하여야 합니다.
가변적 인프라에 대한 서버의 자원 수집 및 모니터링.
오늘 이야기하고자 하는 부분입니다.
서버 모니터링 이란?
서버 모니터링이란 위의 예시에서 말하였던 서버의 상태 즉 시스템이 안정적으로 구동이 되는지를 확인하기 위한 감시체계입니다.
마이리얼트립에서 제공하는 서비스가 안정적으로 돌아가기 위해 각 서버의 자원과 네트워크를 감시하고 또 임계치를 구성하여 해당 임계치를 초과하는 서버에 대해 즉각적인 알림을 주는 시스템입니다.
서비스를 운영하는 부분에 있어 매우 중요하기 때문에 유료 서비스를 사용하거나, 오픈소스를 통해 직접 구성하기도 합니다.
서버 모니터링을 진행할 수 있는 오픈소스는 매우 많습니다.
Elasticsearch + Logstash + Kibana (ELK)를 활용하는 방법 또는 Telegraf + InfluxDB를 활용하는 방법과 같이 Agent에서 Push 하는 방식과 Prometheus와 같이 Pull 하는 방식이 존재하며, 위 방식 모두 서버 모니터링에서 많이 사용됩니다. 최근에는 경량화를 위해 Merticbeat + Elasticsearch 같은 방법도 인기가 있습니다.
Push ? Pull? 당신의 선택은?
아래의 구성도는 Filebeat -> AWS SQS -> Logstash -> Elasticsearch를 사용하여 부하분산에 초점을 맞춘 서버 모니터링 구성도 입니다.
(초기에 이렇게 구성을 하고자 구상을 했습니다.)
각 Agent에서는 Filebeat을 통해 메트릭 로그를 수집하고 이를 Queue로 보냅니다. Queue에 등록된 로그는 Collector에서 취합하여 Elasticsearch로 저장합니다. 각 Agent에서 수집 서버의 접속 정보를 통해 직접 호출하기 때문에 각 서버는 수집 서버의 정보를 알고 있어야 하며, 수집 서버에 부하를 줄 수 있기 때문에 앞단의 Queue를 통해 딜레이를 줍니다. 하지만 이러한 부분은 즉시성을 보장해야 하는 모니터링 시스템에 맞지 않고 메트릭 정보가 바뀔 때마다 Agent에 일괄 배포를 하여야 해서 ‘모니터링을 위한 모니터링 시스템 및 배포 시스템’을 별도로 구성해야 합니다.
그것과는 반대로 Prometheus는 각 Agent로 exporter라는 모듈을 사용하고 Prometheus Server에서 각 exporter로 Pull 하는 방식을 사용합니다. exporter를 구동만 하고 Prometheus Server에서 필요한 메트릭을 가져가는 방식으로 구동이 됩니다. 배포도 Prometheus Server 만 대응하면 되기 때문에 앞의 Push 방식에 비해 간결합니다.
마이리얼트립의 서버 모니터링을 구성하면서 저는 아래의 요건을 체크하였습니다.
1. CPU, MEM, DISK, Network 정보를 수집할 수 있어야 합니다. 또 상황에 따라 JVM 모니터링과 같은 부분이 추가될 수 있습니다.
2. 서버는 가변적입니다. 서버가 증감될 때 자동으로 수집이 이루어져야 합니다.
3. 구성이 쉽고 개발자 누구든 쉽게 고칠 수 있어야 합니다.
4. EC2에 사용되는 태깅을 활용해 라벨을 붙일 수 있어야 합니다.
Prometheus로 Pick!
위와 같은 요건을 검토하면서 Prometheus는 EC2의 DescribeInstance를 활용하여 서버의 증감을 체크할 수 있었고 Tag 정보도 유연하게 가져와 커스텀 라벨을 붙이기 용이하다는 것을 알게 되었습니다.
또 Prometheus는 Prometheus Server와 각각의 exporter들이 존재합니다. 서버의 CPU, MEM, DISK Usage를 수집하는 node_exporter, MySQL 서버의 메트릭을 수집하는 mysqld_exporter 그리고 JVM Heap 모니터링을 위한 jmx_exporter 등 다양한 exporter를 통해 원하는 메트릭을 수집할 수 있습니다.
보다 자세한 내용은 Prometheus 공식 사이트에서 확인할 수 있습니다.
[https://prometheus.io/docs/instrumenting/exporters/]
그리하여 Prometheus를 활용한 서버 모니터링 시스템의 구성도를 아래와 같이 구성하게 되었습니다.
이제 해봅시다!
그럼 실제 반영한 내역을 작성해보겠습니다. 현재 마이리얼트립에서 관리하는 서버 Agent에 아래의 코드를 배포하여 일괄 설치를 진행하였습니다.
curl -L -O https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz && tar zxf node_exporter-0.18.1.linux-amd64.tar.gz && mv node_exporter-0.18.1.linux-amd64 node_exporter && rm node_exporter-0.18.1.linux-amd64.tar.gz그 후 서비스에 등록하여 인스턴스가 재부팅해도 수집할 수 있도록 등록하였습니다. 이 부분은 ubuntu와 amazon linux 1을 나누어 진행하였습니다.
아래는 Amazon Linux 1 서비스 등록 예시입니다.
Collector 역할을 할 Prometheus Server에는 아래와 같이 yml 파일을 설정하였습니다.
이렇게 수집된 데이터는 Grafana를 통해 모니터링을 진행하고 있습니다.
Alert의 경우 Prometheus의 AlertManager로 구성할 수 있으나, 가시성 및 각 서비스를 운영하는 개발자가 유연하게 대응할 수 있도록 Grafana의 Alert기능을 활용하였습니다. 알림은 Slack, Email, OpsGenie 등으로 전달할 수 있습니다.
결론
다시 처음의 질문이었던 “현재 서버 상태 어떤가요?”와 “현재 디스크 사용률과 메모리 사용률이 어떤가요?”를 생각해봅니다.
Prometheus를 통해 수집된 데이터를 Grafana를 통해 대시보드를 만들어 제공하였고 이를 통해 각 개발자분들이 메트릭을 보며 예측할 수 있으며, 임계치에 대한 알림을 통해 즉시 대응도 가능해졌습니다. 실제 마이리얼트립에서 서비스하는 인프라에 대해서도 해당 정보를 기반으로 의사결정을 수행하고 있습니다.
데브옵스에게 있어 모니터링은 사후 대응만이 아닌 선 대응도 필요합니다. 문제가 나기 전에 예측을 할 수 있어야 하고 현재 사용하는 서버의 문제는 없는지 미리 알 수 있어야 하죠.
마이리얼트립에서는 이런 업무의 효율성 확보와 더불어 코드로서의 인프라 관리를 위한 동료를 모시고 있습니다. 아래의 채용페이지를 방문해주세요!
