Backend Server Monitoring and Alarm System collectd + Graphite + Grafana + Zabbix
2016년 2월 21일, '우리 안의 소리' 한종원 ([email protected])
발표 내용• 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