https://www.facebook.com/groups/InfraEngineer Especially lab in here https://github.com/gnu-gnu/infra-meetup

1. 모니터링 with Prometheus :
Prometheus 와 함께하는
모니터링 및 시각화
제3회 IT인프라엔지니어 밋업(2020/04/23)
심근우(geunwoo.j.shim@gmail.com)

2. 소개
• 데이터센터 운영과 관련된 시스템을 개발 / 운영하고 있습니다.
• Spring Cloud, Apache kafka, Kubernetes 를 주로 다루고 있으며 이와 관련된 운영을
위해 Ansible, Prometheus, Loki 등을 사용합니다.
• 개인 블로그 https://springboot.cloud 에서 여러가지 오픈소스의 활용과 관련된 포스팅
을 하고 있습니다.
(요즘은 개인적인 일을 준비하느라 잠시 블로그를 뜸하게 하고 있습니다.)

3. 오늘의 주제
운영 중인 시스템에 모니터링이라는 것의 필요성을 느끼기 시작한 분들을 대상
으로 하여 아래와 같은 것에 대해 개괄적인 내용을 알아볼 것입니다.
1. 모니터링이란?
2. Prometheus란?
3. Prometheus의 활용
1. Prometheus 설치
2. 몇 가지 Target의 설정을 통한 Prometheus 사용
3. Grafana를 통한 대시보드 구성
4. Production을 위한 고려 사항

4. 모니터링이 왜 필요할까…?
열심히 개발한 시스템을 드디어 릴리즈했다!
잘 돌아가겠지?

5. 잘 돌아간다??
잘 돌아가게 하는 방법
장애를 몰아낸다 부적을 쓴다 기도한다
서비스를 구동 시키고 안 되면 그 때 확인하는 식의 운영은 이 수준과 다를 바가 없음

6. 모니터링이 왜 필요할까…?
그럼 시스템이 죽지 않으면 끝일까?

7. 모니터링이란?
• 시스템의 값을 수집, 저장, 집계, 분석, 전달하는 프로세스
• 이러한 행위를 수행하는 시스템이 모니터링 시스템
• 모니터링과 모니터링 시스템은 단순히 특정 대상이 죽었는지 살았는지, 성
능이 어느 정도인지 나타내는 것을 넘어서 해당 대상이 요구 사항을 충족하
며 동작하고 있는지를 알려주고, 문제가 생겼을 때 해결의 실마리를 제공해
주며, 시스템과 관련된 의사 결정에 도움을 주어야 함
• 이러한 것들을 통해서 시스템의 안정적인 운영 및 그에 관한 의사 결정에 필
요한 인사이트를 얻을 수 있음

8. 그럼 모니터링을 알아 보자
• 모니터할 대상은 무엇인가? VM, 컨테이너, 미들웨어, 애플리케이션 등등등…
• 어떤 것을, 무엇을 사용하여 모니터링할 것인가?
• 프로파일링 데이터 : 수집하고자 하는 컨텍스트 확인
ex) tcpdump
• 이벤트 로그 : 이벤트에 대한 컨텍스트가 기록된 것 (트랜잭션, 요청, 애플리케이션 동작, 디버그 데이터 등)
ex) ElasticStack, Splunk Insights
• 요청 트레이싱 : 관심 기능을 통과하는 이벤트에 대한 추적
ex) zipkin, jaeger
• 메트릭 : 다양한 이벤트에 대한 시계열 데이터의 집계
ex) prometheus
• 등등등 …

9. 그래서 뭘 쓸까?
모니터링 솔루션을 검색 해 보니
연관 키워드 : 서버, 시스템, 장애,
네트워크, 통합, 실시간, 보안, 운영,
성능, 관제, 수집, 사용량 등등등…
솔루션 : 뭐가 뭔지 모르겠지만
무지 많다…
각각의 특성이 있다!

10. 뭐가 있는지 약간 알아보면…
뭔가 좀 이것 저것 섞여 있다는 생각이 든다면?
정상!
각 모니터링 솔루션들은 수집하고자 하는
대상이나 항목이 다르고, 제공하는 기능의
범위도 다르기 때문

11. Prometheus란?
• 2012년 SoundCloud社 에서 개발한 모니터링 시스템
• 2015년에 공개
• 현재는 Apache 2.0 라이선스를 따르고 있음
• 2016년 CNCF 재단의 2번째 프로젝트가 됨

12. Prometheus는 그럼 특징이 뭔가?
• 오픈소스
(Commercial support가 없는 건 아니지만 3rd party 이다)
• 시계열(Time-series) 메트릭에 특화. 그럼 로그는?
Loki (https://github.com/grafana/loki)를 고려 해 볼만하다
• 데이터 수집, 저장, 조회, 시각화, 알람을 모두 포함하는 full system
• Pull-based system
(Push를 지원 안 하는 것은 아님!)
• Service Discovery를 지원하여 Dynamic environment 에 매우 적합
(Azure, EC2, GCE, Consul, DNS, openstack, kubernetes 등등…)

13. 그러면…
이제 Prometheus를 써보자

14. Prometheus 서버 구성
- pull과 push는 어떤 경우에 쓰나.
- pull
- 일반적인 경우에 적합, 프로메테우스가 Job/Exporter에 요청을
보내서 정보를 수집
- push
- 일회성 Job은 프로메테우스가 요청을 날리는 것을 받지 못하고 사
라질 수 있으므로 push가 적합
- 네트워크 구성상 내부 대역에 접근을 차단한 경우는 Job은
Pushgateway로 metric을 push하고 외부 Prometheus가
Pushgateway의 정보를 pull

15. Prometheus Config의 기본구조
- 커맨드라인의 인자를 통한 설정
- 데이터 저장소 (기본은 ./data)
- 리텐션 기간 (기본 15일)
- write-ahead log 압축
- https://prometheus.io/docs/prometheus/latest/storage/
- 가변 설정은 YAML 형식의 설정 파일로
- https://prometheus.io/docs/prometheus/latest/configuratio
n/configuration/
- https://github.com/prometheus/prometheus/blob/master/
documentation/examples/prometheus.yml

16. 대상 설정 - VM
- Node Exporter
- *NIX 커널의 OS 에서 동작하는 go로 작성된 메트릭 수집기
- https://github.com/prometheus/node_exporter
- 시스템 설정에 따라 일부 값이 수집되지 않을 수도 있는데 당황하지 말
고 sysctl 로 수집되지 않는 파라미터를 조정 해 주도록 하자

17. 대상 설정 - 컨테이너
- cAdvisor exporter
- cAdvisor란 컨테이너의 리소스 메트릭을 제공해주는 도구
- 도커 컨테이너의 리소스 메트릭을 엔드포인트로 노출할 수 있으며
- 쿠버네티스에서는 DaemonSet으로 구동하여 사용할 수 있음
- https://github.com/google/cadvisor

18. 대상 설정 - Spring Boot 애플리케이션
- Actuator + Micrometer Registry Prometheus
- micrometer는 Spring Boot 2.x 부터 도입된 metrics façade
- https://docs.spring.io/spring-
boot/docs/current/reference/html/production-ready-
features.html#production-ready-metrics
- 필요한 의존성
- 1.4.x가 최신이긴한데, Spring Boot 의 현 시점 Current 기준(2.2.6)
으로는 같이 올려보니 No Such Method 가 일부 동작에서 남
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
- application.properties 노출
- Metric Tag에 Custom이 필요하다면
- /actuator/prometheus Endpoint에서
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beans
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>1.3.7</version>
</dependency>

19. 시각화 구성
- Grafana와 Prometheus의 연동
- 프리셋을 통한 대시보드 구성
- PromQL과 Visualization 을 이용한 커스텀 대시보드 구성
- Prometheus 의 data model 이해
- 몇 가지 자주 사용하는 PromQL 소개

20. - 고가용성
- Federation
- 장기 저장
- Remote Endpoints and Storage
- Kafka, ElasticSearch, Cortex, Thanos…
- Remote 작업은 대상에 따라 Read 혹은 Write 할 수 있는 작업이 정해져 있음
- https://prometheus.io/docs/operating/integrations/#remote-
endpoints-and-storage
- write only : ElasticSearch, kafka, Thanos…
- read / write : Cortex, InfluxDB, Postgresql…
Production에 적용하기 위해 생각 해 볼 것들
- 모니터링도 시간과 자원을 소모하는 작업이다.
- 시스템의 가용 자원
- 데이터는 얼마나 차지할까?
- 샘플 당 평균 1~2바이트 내외를 차지한다고 가정하고
2바이트로 계산하는 것이 여유로움
- 많은 시계열을 수집할 수록 더 많은 용량을 차지함
- 잦은 수집을 할 수록 더 많은 용량을 차지함
- 보관 기간(retention)을 오래 잡을 수록 더 많은 용량을 차지함
- 메트릭을 처리하는데 부하는 어느 정도일까?
- topk 쿼리를 통해 알아 볼 수 있음
- 알람
- 문제가 생기면 알아채는 것이 중요하다
- Prometheus의 AlertManager나 Grafana의 Alarm 기능
아이콘 출처 : https://icons8.com/icons/set/server

21. 감사합니다
발표에서 시연한 실습 자료는
https://github.com/gnu-gnu/infra-meetup
에서 확인하실 수 있습니다.