인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다. 본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다. 목차 1. NHN 모니터링의 현재 2. 모니터링의 변화 3. 모니터링 방법론 4. 모니터링 절차 5. NHN 모니터링의 미래 대상 - 인프라를 운영하는 시스템 엔지니어 - 인프라 모니터링 시스템에 관심이 있는 분

1. © 2018 NHN FORWARD. All rights reserved.
NHN 모니터링의 현재와 미래
for 인프라 엔지니어
이대형
IT시스템운영팀

2. CONTENTS
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링의 절차
4. NHN 모니터링의 미래

3. NHN 모니터링의 현재

4. 4 / 66
NHN 모니터링 시스템
Nsight NeTAISEE
HAWK
Saisei
Icinga2 Zabbix
Syslog NMSlogESXmon
CatsEye
GTM
InfraBoard SIS
DNSMon
*설명하기 쉽도록 돕기 위한 중요 모니터링만 포함됨
Watchdog

5. 5 / 66
인프라 관점의 모니터링 시스템 커버리지
System Engineer
Network Engineer
Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
HAWK
ZABBIX NETA
Syslog
NMSlog
Logging Liveness
Check
Informative
Dashboard
Nsight
Watchdog
*설명하기 쉽도록 돕기 위한 중요 모니터링만 포함됨
...

6. 6 / 66
• 별도 개발된 Beat 이용 필요한 항목 수집
토스트 클라우드 모니터링 시스템
System Engineer
Application
Middleware
OS/
Hypervisor
OSBeat
Logstash
+
Apache
Kafka
+
Elasticsearch
Grafana
Ingest Aggregation Informative
Dashboard
Developer

7. 모니터링의 변화

8. 8 / 66
인프라의 변화
20182006~ 2005
web001.svr.example.com
web002.svr.example.com
web003.svr.example.com
 web.example.com
mighty-web.example.com

9. 9 / 66
1997 2002
솔루션의 변화
Network Monitoring System(NMS)
현재2011
Cloud Ready
Pub/Sub, AI
Monitoring as a Service
Whitebox Monitoring

10. 10 / 66
Application
Middleware
OS
Hypervisor
Server
Storage
Network
Monitor A
Monitor B
Monitor C
Developer
System Engineer
Network Engineer
포괄적 적용 범위

11. 11 / 66
자동 인지
• Service Scaling Up & Down
확장성(Scalability)
모니터링
시스템 삭제해제
신규
신규
등록
등록

12. 12 / 66
Long-term trend threshold
21:00 22.00 23.00 00.00 01.00 02.00
Fixed threshold
EMAIL
SMS
Sophisticated Alerting

13. 13 / 66
협업
문제의 조기 발견 및 수정
 그래프, 대시보드, 이벤트 및 작업 공유를 통한 빠른 장애 대응
 팀 협업 채널을 통한 얼럿(Alert) 전파
잘 알려진 서비스 예
 Google Cloud Status Dashboard https://status.cloud.google.com/
 Cloudflare System Status https://www.cloudflarestatus.com/
 New Relic https://newrelic.com/
 PagerDuty https://www.pagerduty.com/

14. 14 / 66
협업

15. 모니터링의 절차
Collecting, processing, aggregating, and displaying real-time quantitative data about a system, such as query
counts and types, processing times, and server lifetimes.
Site Reliability Engineering – O’Reilly 2016

16. 16 / 66
cube by DaanDirk from the Noun Project
Gears by Pedro Santos from the Noun Project
collecting by Takao Umehara from the Noun Project
Warning by Melissa Holterman from the Noun Project
Search by Mas Bro Mellow from the Noun Project
timer by 8ties® from the Noun Project
Collect
Metrics & Events
Stream
Processor Pipeline
Data Processing
OLAP
Database
(Timeseries)
Search Index
(Events)
Live Reports
Predict &
Automate
SLA
Alerting
Real-Time
Topology
Network topology by Vectors Market from the Noun Project
chart by shashank singh from the Noun Project
Light by Numero Uno from the Noun Project
모니터링 플로우
불필요 데이터 필터링
(Noise reduction)
데이터 저장 &
가공
리포팅 & 예측
(유용한 데이터)
수집

17. 17 / 66
메트릭 (Metrics)
어떤 일이 일어나는가? , Not 왜 일어나고 있는가?(분석)
특정 시점에서 시스템과 관련된 값을 캡처
정의된 주기로 수집하여 시계열 데이터베이스(TSDB)에 저장
[bucket 1234, response:OK, method: read] {(Wed 2:00pm, 3), (Wed 2:05pm, 2), (Wed 2:10pm, 8), ...}
[bucket 1234, response:OK, method: write] {(Wed 2:01pm, 1), (Wed 2:04pm, 2), (Wed 2:09pm, 7), ...}
[bucket 1234, response:FAIL, method: write] {(Wed 2:01pm, 1), (Wed 2:04pm, 0), (Wed 2:09pm, 0), ...}
[bucket 9876, response:OK, method: read] {(Wed 1:59pm, 2), (Wed 2:05pm, 4), (Wed 2:10pm, 3), ...}

18. 18 / 66
메트릭 (Metrics)
어떤 일이 일어나는가? , Not 왜 일어나고 있는가? (분석)
특정 시점에서 시스템과 관련된 값을 캡처
정의된 주기로 수집하여 시계열 데이터베이스(TSDB)에 저장

19. 19 / 66
자원 메트릭 (Resource metrics)
 다른 시스템이나 서비스에게 제공되는
자원의 상태
 예, 하드웨어 자원 메트릭
 CPUs
 Main Memory
 Network Interfaces
 Storage Devices
 Controllers
 Interconnects (bus)
메트릭의 종류
작업 메트릭 (Work metrics)
 시스템의 최상위 레이어인 응용 프로그램의 상태
 예, 웹 서버 작업 메트릭
 Throughput: Request per second
 Success: 2XX 응답률(%)
 Error: 5XX 응답률(%)
 Performance: 90% response time in 1s.

20. 20 / 66
시스템 및 서비스에 간접적 영향
 패키지 설치 및 업데이트
 하드웨어 변경 및 폴트
 응용 프로그램 배포
이벤트의 상당 부분은 로그에 존재
 문제의 상당 부분을 미리 파악 가능
 이벤트 처리를 통한 알람 발생
이벤트(Event)

21. NHN 인프라 모니터링의 미래

22. 22 / 66
우리도 이제 Multi Region
 클라우드 환경에 적합한 구조의 운영도구가 절실
문제 발생 시, 분석을 위한 다양한 정보 필요
 고객보다 문제를 먼저 확인 할 수 있는 시스템 필요
 자산 및 기반 시스템과의 연계를 통한 빠른 확인
빠른 변화에 대한 대처 필요
 쉽게 만들고 쉽게 버리자
 오픈 소스 도구 활용
지금 우리에게 필요한 것은 무엇인가?

23. 23 / 66
NE 모니터링 커버리지
System Engineer
Network Engineer
Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
HAWK
ZABBIX NETA
Syslog
NMSlog
Logging Liveness
Check
Informative
Dashboard
Nsight
Watchdog
*설명하기 쉽도록 돕기 위한 중요 모니터링만 포함됨
...

24. 24 / 66
포괄적 커버리지 구현
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
Check
Informative
Dashboard
Nsight
ZABBIX NETA
Syslog
NMSlog
HAWK

25. 25 / 66
포괄적 커버리지 구현
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
Check
Informative
Dashboard
Nsight
ZABBIX NETA
Dashboard
Syslog
NMSlog
Syslog
&
Event
HAWK
Checker
or
Collector

26. 26 / 66
우리가 바라보는 첫 번째 목표
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
Check
Informative
Dashboard
Nsight
ZABBIX NETA
Syslog
NMSlog
Syslog
&
Event
HAWK
Event
Dashboard

27. 27 / 66
Ingest 관리의 어려움
 폴트 시 로그 유실
 로그 형태 변경 시 Grok 패턴 재작성 및 재시작 필요
운영 시스템 변경의 어려움
 교체 시 수집 중단에 따른 신규 버전 적용의 어려움 발생
로그 수집 시스템의 변화 필요성 증가
LOG File by AdbA Icons ❤️ from the Noun Project
Host machine

28. 28 / 66
로그 수집 시스템의 변화 필요성 증가(계속)
Ingest 관리 로그 처리
로그 검색
로그 저장소 관리

29. 29 / 66
if [type] == "proxy_log" {
grok {
add_tag => ["swift", "proxy"]
patterns_dir => ["/etc/logstash/patterns"]
match => { 'message' => '%{SYSLOGTIMESTAMP:node_tz} %{HOSTNAME:hostname} %{NOTSPACE:swift_service}: %{NOTSPACE:client_ip} %
{NOTSPACE:remote_addr} %{SWIFT_PROXY_DATETIME:datetime} %{WORD:request_method} %{URIPATHPARAM:request_path} HTTP/%{NUMBER:httpversion}
%{NUMBER:status_int:int} %{NOTSPACE:referer} %{NOTSPACE:user_agent} %{NOTSPACE:auth_token} %{NOTSPACE:bytes_recvd:int} %{NOTSPACE:byte
s_sent:int} %{NOTSPACE:client_etag} %{NOTSPACE:transaction_id} %{NOTSPACE:headers} %{NUMBER:request_time:float} %{NOTSPACE:api_source}
%{NOTSPACE:log_info} %{NUMBER:request_start_time} %{NUMBER:request_end_time} %{NOTSPACE:policy_index:int}' }
}
로그 처리 - 복잡도 증가
 로그 필드 추출을 위한 GROK 구문 예
로그 수집 시스템의 변화 필요성 증가(계속)

30. 30 / 66
로그 수집 시스템의 변화 필요성 증가(계속)
로그 검색 - 검색 위주의 이벤트 확인

31. 31 / 66
로그 검색 - 단순 로그 구분별 나열
로그 수집 시스템의 변화 필요성 증가(계속)

32. 32 / 66
로그 처리 방식 변화
 처리 방식 단순화
 트리거에 의한 이벤트 알림
Docker swarm 기반 운영
 자가 치유(Self Healing)
 롤링 업데이트(Rolling Update)
 업데이트 성공 후 교체 시도
Infrastructure as Code
신규 로그 수집 시스템

33. 33 / 66
Ingress - Rsyslog v8.x
메시지 버퍼 – Logstash + Kafka
로그(스트림) 처리 및 알람 발생 - Graylog2
로그 인덱싱 - Elasticsearch
로그 수집 시스템 - 구성 컴포넌트
LOG File by AdbA Icons ❤️ from the Noun Project
Graylog2
RSYSLOG v8
ElasticsearchLogstash Apache
Kafka
Host Manchine

34. 34 / 66
Step 1
 스풀링 & 디스크에 임시 저장
 버퍼 프로세스 준비
Step 2
 디스크에서 추출한 메시지 입력 버퍼로 이동
 필터, 메시지들의 구조화(Classify)
Step 3
 출력 버퍼로 메시지 이동
 Elasticsearch 혹은 사용자 정의된 출력으로 이동
로그 수집 시스템 - 로그 처리 흐름
Input
Log Message
Ring Network Topology by ProSymbols from the Noun Project
Process
Buffer
Processor
Filter
Filter
Output
Buffer
Processor
Output
…
Output
Buffer
Input
Buffer

35. 35 / 66
Extractor API
로그 수집 시스템 - 로그 필드 추출
Extractor 설정 GUI

36. 36 / 66
로그 수집 시스템 - 스트림
관심 항목별 로그 스트림 분리

37. 37 / 66
로그 수집 시스템 – 스트림 흐름
관심 항목 별 로그 스트림 분리
 Stream rules
All messages
User/Group
Operation
Package Operation
UG
Index
All in One
Index
로그 유입 rules
rules
인덱싱
인덱싱
스트림

38. 38 / 66
스트림 API
로그 수집 시스템 – 스트림 설정
스트림 설정 GUI

39. 39 / 66
rule “Combine src and dst field”
when
has_field(“src_ip”) && has_field(“dst_ip”)
then
let src_ip_comma = concat(to_string($message.src_ip), “-”);
let src_dst = concat(src_ip_comma,to_string($message.dst_ip));
set_field(field:“src_dst_ip”, value: src_dst);
end
스트림 간 라우팅, 메시지 블랙리스팅, 메시지 변경 시 유리
 Rule(s) > Stage(s) > Pipeline
로그 수집 시스템 - 파이프라인(Pipeline)

40. 40 / 66
로그 수집 시스템 - 인덱싱 설정
Index Set을 통하여 로그 중요도에 따른 인덱싱 설정
약 3개월
약 1개월
샤드, 복제

41. 41 / 66
로그 수집 시스템 – 인덱싱 흐름
Index Set을 통하여 로그 중요도에 따른 인덱싱 설정
All messages
User/Group
Operation
Package
Operation
UG
Index
All in One
Index
로그 유입
복제 / 샤드
보관 주기인덱싱 설정
Index
Set
Index
Set
스트림

42. 42 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시

43. 43 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시

44. 44 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시

45. 45 / 66
로그 수집 시스템 – 대시보드
패키지 설치, 삭제 및 업데이트 감시

46. 46 / 66
하드웨어 이벤트 확인 및 알람 발생
 OS 커널 혹은 벤더 제공 소프트웨어를 통한 폴트 확인  이벤트 데이터
 대부분 하드웨어는 폴트 감지시 SNMPTrap에게 해당 이벤트 통보 가능
 Logstash + SNMPTrap Input 기능을 통하여 이벤트 처리 및 통보 가능  별도 관심 로그 스트림 구현
로그 수집 시스템 – 기타 활용 영역
Hardware
SNMP
Trap
Logstash
JSONEvent
Graylog2
Alert
OOB Network Service Network

47. 47 / 66
로그 수집 시스템 모니터링 구현
Prometheus
Email by i cons from the Noun Project
Prometheus
Server
cAdvisor
Docker exporter
Grafana
Web U/I
Dashboard
HTTP
AlertManager
PromQL
* exporter
Node exporter
System Engineer
Docker Swarm

48. 48 / 66
로그 수집 시스템 - 모니터링
Graylog2
RSYSLOG v8
ElasticsearchLogstash Apache
Kafka
Host Manchine
JVM exporter
Graylog
exporter
Elasticsearch
exporter
Logstash
exporter
Node exporter
Prometheus
Cerebro
Kafka
Manager

49. 49 / 66
로그 수집 시스템 – 모니터링 대시보드

50. 50 / 66
점진적 적용 필요
 로그 유입량 점진적 증가 필요
 로그 처리는 결국 문자열 처리  힙(Heap) 메모리 확인 필수
각 컴포넌트는 결국 관리 포인트
 부하에 따른 컴포넌트 확장 및 축소 가능 설계 필요
 각 컴포넌트 별 메트릭 수집 및 시각화 필요
컨테이너에 대한 이해
설정 관리의 자동화
 수집 항목에 대한 설정 동기화  Salt/Puppet/Chef/Ansible 도구 활용
적용 시 어려운 점

51. 51 / 66
모니터링 대시보드 개선
또다른 이중화 고려
 Multi Data Center
 장애 대응 훈련
기반 연계 시스템 연동
 기반 시스템 연계
CI/CD 반영
그 외 기타 사항들
 접근 및 권한 제어
남은 과제와 목표는?

52. 52 / 66
우리가 바라보는 두번째 목표
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
Check
Informative
Dashboard
Nsight
ZABBIX NETA
Dashboard
Syslog
NMSlog
Syslog
&
Event
HAWK
Checker
or
Collector

53. 53 / 66
인프라 모니터링 시스템 개선
기회가 된다면 다음에…

54. © 2018 NHN FORWARD. All rights reserved.
Q&A

55. © 2018 NHN FORWARD. All rights reserved.
THANK YOU

56. 56 / 66
APPENDIX
모니터링 방법론
 Problem Statement Method
 Workload Characterization Method
 The Use Method
 4 Golden Signals
Prometheus
 블랙박스 vs 화이트박스
 Prometheus vs General NMS
인프라 서비스 대시보드 – Staytus
로그 수집 시스템 – 테스트 플랫폼 코드

57. 57 / 66
모니터링 방법론 - Problem Statement Method
성능 문제가 있다고 생각하는 이유는 무엇입니까?
본 시스템이 기존에도 잘 수행되었는가?
최근에 변경된 사항은 무엇이었나? (소프트웨어? 하드웨어? 로드?)
성능 저하가 대기 시간(Latency) 또는 수행 시간으로 표현될 수 있습니까?
문제가 다른 사람이나 응용프로그램에 영향을 미칩니까?
환경(Environment)은 어땠나요?
 Software, Hardware, Instance types? Versions? Configuration?

58. 58 / 66
모니터링 방법론 – Workload Characterization Method
누가 부하(load)를 발생시키는가?
 PID, UID, IP address, …
왜 부하가 생기는가?
 Code path, stack trace
부하란?
 IOPS, throughput, type(e.g., Database Query), R/W data
시간에 따른 부하의 변화는?

59. 59 / 66
모니터링 방법론 - The Use Method
The Use Method by Brendan Gregg
http://www.brendangregg.com/usemethod.html
 사용률(Utilization)
 포화(Saturation)
 에러(Error)
Resource
Utilization (%)
Saturation
Errors
✓✗✓✓

60. 60 / 66
모니터링 방법론 - The Use Method(계속)
The Use Method by Brendan Gregg
 사용률(Utilization)
 100%는 병목 현상의 징후
 70% 일 경우도 오랜 기간 측정시, 짧은 주기에 발생된 100%
를 감출 수 있음
 포화(Saturation)
 대기 큐(Wait Queue)의 길이 또는 큐(Queue)에서 소비되는
시간으로 측정될 수 있음
 에러(Error)

61. 61 / 66
Request-based system metrics
 지연시간(latency)
 트래픽(traffic)
 에러(error)
 포화(saturation)
https://landing.google.com/sre/book/chapters/monitoring-distributed-systems.html
모니터링 방법론 - 4 Golden Signals
4 Golden Signals by Google

62. 62 / 66
Agent
HTTP Server
200 OKHTTP GET /
Blackbox Monitoring
Agent
HTTP Server
GET /metrics
error_total
req_total
req_latency
Whitebox Monitoring
Prometheus
블랙박스 vs 화이트박스

63. 63 / 66
Nagios/Icinga/Zabbix
• Disk Used : 92.00% (/home1)
Prometheus vs General NMS
Prometheus
• Disk would be usable for the next 12 hours
- name: node.rules
rules:
- alert: DiskWillFillIn12Hours
expr: predict_linear(node_filesystem_free_bytes{mountpoint="/rootfs"}[1h], 12*3600) < 0
for: 5m
labels: severity: page

64. 64 / 66
인프라 서비스 대시보드 - Staytus
http://staytus.co

65. 65 / 66
인프라 서비스 대시보드 – Staytus(계속)
작업(Maintenance) 등록과 추적

66. 66 / 66
인프라 서비스 대시보드 - Staytus(계속)
이슈의 등록, 추적, 변경 관리

67. 67 / 66
로그 수집 시스템 – 테스트 플랫폼 코드
Docker Stack / Service 코드로 구성
 https://github.com/netman2k/graylog2-demo