인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다.
본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다.
목차
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링 방법론
4. 모니터링 절차
5. NHN 모니터링의 미래
대상
- 인프라를 운영하는 시스템 엔지니어
- 인프라 모니터링 시스템에 관심이 있는 분
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/
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)
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
*설명하기 쉽도록 돕기 위한 중요 모니터링만 포함됨
...
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
37. 37 / 66
로그 수집 시스템 – 스트림 흐름
관심 항목 별 로그 스트림 분리
Stream rules
All messages
User/Group
Operation
Package Operation
UG
Index
All in One
Index
로그 유입 rules
rules
인덱싱
인덱싱
스트림
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
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시
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
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
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