Backend Server Monitoring and Alarm System collectd + Graphite + Grafana + Zabbix

2016년 2월 21일, '우리 안의 소리' 한종원 (addnull@gmail.com)

발표 내용• Monitoring and Alarm 다시 보기

• 요구사항 정리

• 시스템 구축

• collectd / Graphite / Grafana / Zabbix

• Monitoring Metrics

• Alarm Triggers

• Live Demo

3

Monitoring and Alarm 다시 보기 "Money doesn't grow on trees"

4

Monitoring and Alarm 다시 보기• 질문 !!!

• 그거 왜 하는데?

• 이미 잘되는 다른 서비스나 패키지 붙여 쓰는 거 아닌가?

• 금방 할 수 있지?

• 기능 개발할 시간도 바쁜데...

5

Monitoring and Alarm 다시 보기• 정말 왜 필요한가?

• 사실 옛날에도 필요했는데... -> 서버가 죽었나 살았나 단순 확인

• 지금은 cloud computing 시대

• 서버 자체가 일시적인 자원(instance)-> 언제든지, 계획여부와 상관없이 유실될 수 있다.

• 전체 시스템의 장애를 허용하되, 복구를 빠르게 한다.

• 그리고 scalability !!! 전체 시스템의 크기가 매우 유동적

6

Monitoring and Alarm 다시 보기• 서버(instance)가 유실 또는�자원 필요량이 급격하게�늘어나는걸 대비

• 즉, 지금 모니터링 알람은�단순한 서버의 생사여부�확인을 넘어서, 충분히 잘 �동작(서비스)하고 있는지�확인해야한다. (예: API call response가 300ms안에 들어오는가?)

7

Monitoring and Alarm 다시 보기• 그럼, 이미 잘되는 다른 서비스나 패키지 붙여 쓰면 될까?

• 상용 서비스(APM)

• 최소 75 USD per month per 1 host

• 배보다 배꼽이 더 비싼 가격

• Open Source

• 엄청나게 다양한 프로젝트와 툴들이 개발 진행 중 또는�중단되었음

8

Monitoring and Alarm 다시 보기• 만능 솔루션은 없었다..

• 너무 다양한 요구사항과 use case들 (뒤에서 설명)

• 상당한 노력과 시간 그리고 어쩌면 자본까지 필요

• 기능 개발할 시간도 부족한데, 이거 우선 순위를�어떻게 해야될까?

9

10

요구사항 정리

11

요구사항 정리• 가격: open source를 최대한 활용해서 무료로 구축

• 측정 metric

• cpu/memory/disk/network usage

• server time offset

• API call response (HTTP status code)

• API call elapsed time

12

요구사항 정리• (continues) 측정 metric

• AWS 관련

• Estimated billing

• S3: total number/size of object

• SQS: message count (normal queue / dead lettter queue)

• 단, 1개의 all-in-one solution을 쓰기 보다는,잘 만들어진 작은 module들을 조립해서 구축하자. (UNIX philosophy: "Do One Thing and Do It Well")

13

시스템 구축

14

시스템 구축• 전체 system overview

15

시스템 구축• 각 단계별, 관련된 open source list

• http://graphite.readthedocs.org/en/latest/tools.html

• 무려 70개가 넘는 project가 진행중 또는 중단

16

시스템 구축• 그래서 제 선택은요..

17

collection collectdforwarding Carbon(Graphite)

store and indexing Whispher(Graphite)visualization Grafana, Zabbix

시스템 구축• 전체 system overview with open source project

18

시스템 구축 :: collectd

19

시스템 구축 :: collectd• 'collectd' 소개

• 'C'로 작성된, 매우 빠른�metric 수집 툴

• Linux OS에 관련된 거의 모든�metric이 plugin 형태로 제공된다.

• 단, metric 수집만 할 뿐,그외 forwarding, indexing,visualization 기능은 없거나�아주 단순한 기능만 있음.

20

시스템 구축 :: collectd• 설정 예시

21

Hostname MY_HOSTNAME FQDNLookup true LoadPlugin syslog !<Plugin syslog> LogLevel info </Plugin> !LoadPlugin battery LoadPlugin cpu LoadPlugin df LoadPlugin disk LoadPlugin entropy LoadPlugin interface LoadPlugin irq LoadPlugin load LoadPlugin memory LoadPlugin processes LoadPlugin swap LoadPlugin users LoadPlugin write_graphite

<Plugin df> FSType rootfs FSType sysfs FSType proc FSType devtmpfs FSType devpts FSType tmpfs FSType fusectl FSType cgroup IgnoreSelected true </Plugin> !<Plugin write_graphite> <Node "example"> Host "my_host.com" Port "2003" Protocol "udp" LogSendErrors true Prefix "collectd/" Postfix "" StoreRates true AlwaysAppendDS false EscapeCharacter "_" </Node> </Plugin> !<Include "/etc/collectd/collectd.conf.d"> Filter "*.conf" </Include>

시스템 구축 :: Graphite

22

시스템 구축 :: Graphite• 'Graphite' 소개

• 3개의 하위�module로 구성

• visualization기능은 'Grafana'로 대신함

23

forwardingvisualization

store and indexing

시스템 구축 :: Graphite

24

forwardingvisualization

store and indexing

시스템 구축 :: Graphite• 'Graphite'의 visualization 기능은 'Grafana'에 비해서 기능이 부족.

25

시스템 구축 :: Grafana

26

시스템 구축 :: Grafana• 'Grafana' 소개

• 오직 visualzation(dashboard) 기능에 집중한 module

27

시스템 구축 :: Grafana• 'Grafana'는 'Graphite'의 'whisper' DB와 연동했다.

28

시스템 구축 :: Grafana• 'Grafana' 소개

• live demo - http://play.grafana.org/

• 'Graphite'의 graph 여러개를 모아서 하나의 dashboard로�구성하기 쉽다.

• real time update 및 play list(여러 dashboard를�번갈아가면서 보여주는 기능) 등 visualization 관련 유용한�기능을 지원

29

시스템 구축 :: Zabbix

30

시스템 구축 :: Zabbix• 'Zabbix' 소개

• Monitoring과 alarm에�관한 거의 모든 기능을 가진�all-in-one 프로젝트

• 하지만, alarm 기능만�사용하기로 했다.(다른 기능들은 약간 old fashion)

• 매우 강력한 alarm trigger customize 지원

31

Monitoring Metrics

32

Monitoring Metrics• 'carbon(Graphite)'으로 metrics을 forwarding한다.

• forwarding 방법은 크게 2가지로 나뉜다.

• 일정 시간(예: 10초)동안 기록된 값의 평균/최대/최소 등 aggregate value를 저장

• 예: API call count, API response elapsed time

• 최종 1개의 값만 저장 (매번 overwrite)

• 예: CPU/memory/disk/network usage, server time offset

33

Monitoring Metrics• 일정 시간(예: 10초)동안 기록된 값의 평균/최대/최소 등

aggregate value를 저장

34

Monitoring Metrics• 최종 1개의 값만 저장 (매번 overwrite)

35

Alarm Triggers

36

Alarm Triggers• Alarm은 필요한 것만 정확하게 전달되어야한다.

37

Alarm Triggers• 현재 상태를 2가지로 구분한다.

• 'OK' (문제가 없을때), 'PROBLEM' (문제가 있을때)

• 초기 상태(T0)에서 다음 상태(T1)으로 변화는 4가지가 있다.

• 'OK' -> 'OK': 문제없음

• 'OK' -> 'PROBLEM': 문제 최초 발생

• 'PROBLEM' -> 'PROBLEM': 문제가 해결되지 않은 상태에서 문제가 또 발생

• 'PROBLEM' -> 'OK': 문제가 해결

38

Alarm Triggers• 초기 상태(T0)에서 다음 상태(T1)로 변화 시에 alarm 전달

39

Alarm Triggers• 너무 빠른 상태 변화는 무시해야한다. (예: 일시적 장애 발생 또는 복구)

40

Alarm Triggers• 너무 빠른 상태 변화는 무시해야한다. (예: 일시적 장애 발생 또는 복구)

• 'Zabbix' trigger에서는 최근 n번에 대해서 평균/최소/최대�같은 aggregation을 지원한다.

• 예:"{v0.min(#3)} > 0.1" 'v0' 값의 가장 최근 3개의 값의 최소값이 0.1 초과일 때만 trigger가 발동한다."{v0.max(#3)} < 0.05" 'v0' 값의 가장 최근 3개의 값의 최대값이 0.05 미만일 때만 trigger가 발동한다.

41

Alarm Triggers• "{v0.min(#3)} > 0.1"

"{v0.max(#3)} < 0.05"

42

Alarm Triggers• 문제가 발생된 상태에서 또 다시 문제가 발생했을 때,

alarm을 전달하는 경우와 아닌 경우를 구분해야한다.

• 예:API server 내부 logic 오류로 인해서 500 response 발생�-> 발생할 때마다 계속 반복적으로 alarm 전달�� Server CPU 사용율이 100%가 계속 유지됨�-> 최초 발생 1회만 전달

43

Live Demo

44

발표 내용 review• Monitoring and Alarm 다시 보기

• 요구사항 정리

• 시스템 구축

• collectd / Graphite / Grafana / Zabbix

• Monitoring Metrics

• Alarm Triggers

• Live Demo

45