Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© 2018 NHN FORWARD. All rights reserved.
NHN 모니터링의 현재와 미래
for 인프라 엔지니어
이대형
IT시스템운영팀
CONTENTS
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링의 절차
4. NHN 모니터링의 미래
NHN 모니터링의 현재
4 / 66
NHN 모니터링 시스템
Nsight NeTAISEE
HAWK
Saisei
Icinga2 Zabbix
Syslog NMSlogESXmon
CatsEye
GTM
InfraBoard SIS
DNSMon
*설명하기...
5 / 66
인프라 관점의 모니터링 시스템 커버리지
System Engineer
Network Engineer
Developer
Application
Middleware
OS
Hypervisor
Server(HW)
St...
6 / 66
• 별도 개발된 Beat 이용 필요한 항목 수집
토스트 클라우드 모니터링 시스템
System Engineer
Application
Middleware
OS/
Hypervisor
OSBeat
Logstash
...
모니터링의 변화
8 / 66
인프라의 변화
20182006~ 2005
web001.svr.example.com
web002.svr.example.com
web003.svr.example.com
 web.example.com
might...
9 / 66
1997 2002
솔루션의 변화
Network Monitoring System(NMS)
현재2011
Cloud Ready
Pub/Sub, AI
Monitoring as a Service
Whitebox Mo...
10 / 66
Application
Middleware
OS
Hypervisor
Server
Storage
Network
Monitor A
Monitor B
Monitor C
Developer
System Enginee...
11 / 66
자동 인지
• Service Scaling Up & Down
확장성(Scalability)
모니터링
시스템 삭제해제
신규
신규
등록
등록
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 / 66
협업
문제의 조기 발견 및 수정
 그래프, 대시보드, 이벤트 및 작업 공유를 통한 빠른 장애 대응
 팀 협업 채널을 통한 얼럿(Alert) 전파
잘 알려진 서비스 예
 Google Cloud Stat...
14 / 66
협업
모니터링의 절차
Collecting, processing, aggregating, and displaying real-time quantitative data about a system, such as query
cou...
16 / 66
cube by DaanDirk from the Noun Project
Gears by Pedro Santos from the Noun Project
collecting by Takao Umehara fro...
17 / 66
메트릭 (Metrics)
어떤 일이 일어나는가? , Not 왜 일어나고 있는가?(분석)
특정 시점에서 시스템과 관련된 값을 캡처
정의된 주기로 수집하여 시계열 데이터베이스(TSDB)에 저장
[bucket ...
18 / 66
메트릭 (Metrics)
어떤 일이 일어나는가? , Not 왜 일어나고 있는가? (분석)
특정 시점에서 시스템과 관련된 값을 캡처
정의된 주기로 수집하여 시계열 데이터베이스(TSDB)에 저장
19 / 66
자원 메트릭 (Resource metrics)
 다른 시스템이나 서비스에게 제공되는
자원의 상태
 예, 하드웨어 자원 메트릭
 CPUs
 Main Memory
 Network Interfaces
...
20 / 66
시스템 및 서비스에 간접적 영향
 패키지 설치 및 업데이트
 하드웨어 변경 및 폴트
 응용 프로그램 배포
이벤트의 상당 부분은 로그에 존재
 문제의 상당 부분을 미리 파악 가능
 이벤트 처리를 통...
NHN 인프라 모니터링의 미래
22 / 66
우리도 이제 Multi Region
 클라우드 환경에 적합한 구조의 운영도구가 절실
문제 발생 시, 분석을 위한 다양한 정보 필요
 고객보다 문제를 먼저 확인 할 수 있는 시스템 필요
 자산 및 기반...
23 / 66
NE 모니터링 커버리지
System Engineer
Network Engineer
Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Ne...
24 / 66
포괄적 커버리지 구현
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
...
25 / 66
포괄적 커버리지 구현
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liveness
...
26 / 66
우리가 바라보는 첫 번째 목표
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Live...
27 / 66
Ingest 관리의 어려움
 폴트 시 로그 유실
 로그 형태 변경 시 Grok 패턴 재작성 및 재시작 필요
운영 시스템 변경의 어려움
 교체 시 수집 중단에 따른 신규 버전 적용의 어려움 발생
로그 ...
28 / 66
로그 수집 시스템의 변화 필요성 증가(계속)
Ingest 관리 로그 처리
로그 검색
로그 저장소 관리
29 / 66
if [type] == "proxy_log" {
grok {
add_tag => ["swift", "proxy"]
patterns_dir => ["/etc/logstash/patterns"]
match =...
30 / 66
로그 수집 시스템의 변화 필요성 증가(계속)
로그 검색 - 검색 위주의 이벤트 확인
31 / 66
로그 검색 - 단순 로그 구분별 나열
로그 수집 시스템의 변화 필요성 증가(계속)
32 / 66
로그 처리 방식 변화
 처리 방식 단순화
 트리거에 의한 이벤트 알림
Docker swarm 기반 운영
 자가 치유(Self Healing)
 롤링 업데이트(Rolling Update)
 업데이트...
33 / 66
Ingress - Rsyslog v8.x
메시지 버퍼 – Logstash + Kafka
로그(스트림) 처리 및 알람 발생 - Graylog2
로그 인덱싱 - Elasticsearch
로그 수집 시스템 - ...
34 / 66
Step 1
 스풀링 & 디스크에 임시 저장
 버퍼 프로세스 준비
Step 2
 디스크에서 추출한 메시지 입력 버퍼로 이동
 필터, 메시지들의 구조화(Classify)
Step 3
 출력 버퍼로 ...
35 / 66
Extractor API
로그 수집 시스템 - 로그 필드 추출
Extractor 설정 GUI
36 / 66
로그 수집 시스템 - 스트림
관심 항목별 로그 스트림 분리
37 / 66
로그 수집 시스템 – 스트림 흐름
관심 항목 별 로그 스트림 분리
 Stream rules
All messages
User/Group
Operation
Package Operation
UG
Index
A...
38 / 66
스트림 API
로그 수집 시스템 – 스트림 설정
스트림 설정 GUI
39 / 66
rule “Combine src and dst field”
when
has_field(“src_ip”) && has_field(“dst_ip”)
then
let src_ip_comma = concat(to...
40 / 66
로그 수집 시스템 - 인덱싱 설정
Index Set을 통하여 로그 중요도에 따른 인덱싱 설정
약 3개월
약 1개월
샤드, 복제
41 / 66
로그 수집 시스템 – 인덱싱 흐름
Index Set을 통하여 로그 중요도에 따른 인덱싱 설정
All messages
User/Group
Operation
Package
Operation
UG
Index
A...
42 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시
43 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시
44 / 66
로그 수집 시스템 – 스트림 사용 예제
패키지 설치, 삭제 및 업데이트 감시
45 / 66
로그 수집 시스템 – 대시보드
패키지 설치, 삭제 및 업데이트 감시
46 / 66
하드웨어 이벤트 확인 및 알람 발생
 OS 커널 혹은 벤더 제공 소프트웨어를 통한 폴트 확인  이벤트 데이터
 대부분 하드웨어는 폴트 감지시 SNMPTrap에게 해당 이벤트 통보 가능
 Logsta...
47 / 66
로그 수집 시스템 모니터링 구현
Prometheus
Email by i cons from the Noun Project
Prometheus
Server
cAdvisor
Docker exporter
Graf...
48 / 66
로그 수집 시스템 - 모니터링
Graylog2
RSYSLOG v8
ElasticsearchLogstash Apache
Kafka
Host Manchine
JVM exporter
Graylog
exporte...
49 / 66
로그 수집 시스템 – 모니터링 대시보드
50 / 66
점진적 적용 필요
 로그 유입량 점진적 증가 필요
 로그 처리는 결국 문자열 처리  힙(Heap) 메모리 확인 필수
각 컴포넌트는 결국 관리 포인트
 부하에 따른 컴포넌트 확장 및 축소 가능 설계 ...
51 / 66
모니터링 대시보드 개선
또다른 이중화 고려
 Multi Data Center
 장애 대응 훈련
기반 연계 시스템 연동
 기반 시스템 연계
CI/CD 반영
그 외 기타 사항들
 접근 및 권한 제어
남...
52 / 66
우리가 바라보는 두번째 목표
Engineer / Developer
Application
Middleware
OS
Hypervisor
Server(HW)
Storage
Network
Logging Liven...
53 / 66
인프라 모니터링 시스템 개선
기회가 된다면 다음에…
© 2018 NHN FORWARD. All rights reserved.
Q&A
© 2018 NHN FORWARD. All rights reserved.
THANK YOU
56 / 66
APPENDIX
모니터링 방법론
 Problem Statement Method
 Workload Characterization Method
 The Use Method
 4 Golden Signal...
57 / 66
모니터링 방법론 - Problem Statement Method
성능 문제가 있다고 생각하는 이유는 무엇입니까?
본 시스템이 기존에도 잘 수행되었는가?
최근에 변경된 사항은 무엇이었나? (소프트웨어? 하드...
58 / 66
모니터링 방법론 – Workload Characterization Method
누가 부하(load)를 발생시키는가?
 PID, UID, IP address, …
왜 부하가 생기는가?
 Code path...
59 / 66
모니터링 방법론 - The Use Method
The Use Method by Brendan Gregg
http://www.brendangregg.com/usemethod.html
 사용률(Utiliza...
60 / 66
모니터링 방법론 - The Use Method(계속)
The Use Method by Brendan Gregg
 사용률(Utilization)
 100%는 병목 현상의 징후
 70% 일 경우도 오랜 ...
61 / 66
Request-based system metrics
 지연시간(latency)
 트래픽(traffic)
 에러(error)
 포화(saturation)
https://landing.google.co...
62 / 66
Agent
HTTP Server
200 OKHTTP GET /
Blackbox Monitoring
Agent
HTTP Server
GET /metrics
error_total
req_total
req_la...
63 / 66
Nagios/Icinga/Zabbix
• Disk Used : 92.00% (/home1)
Prometheus vs General NMS
Prometheus
• Disk would be usable for...
64 / 66
인프라 서비스 대시보드 - Staytus
http://staytus.co
65 / 66
인프라 서비스 대시보드 – Staytus(계속)
작업(Maintenance) 등록과 추적
66 / 66
인프라 서비스 대시보드 - Staytus(계속)
이슈의 등록, 추적, 변경 관리
67 / 66
로그 수집 시스템 – 테스트 플랫폼 코드
Docker Stack / Service 코드로 구성
 https://github.com/netman2k/graylog2-demo
Upcoming SlideShare
Loading in …5
×

8

Share

Download to read offline

[2018] NHN 모니터링의 현재와 미래 for 인프라 엔지니어

Download to read offline

인프라 모니터링을 위한 시스템을 구축하고 운영하는 데 있어, 다이내믹한 인프라 변화는 어려움으로 다가오고 있습니다.
본 세션에서는 인프라를 운영하는 팀 혹은 운영자 관점에서 바라본 미래 지향적 인프라 모니터링 시스템의 방향성과 이를 구현하기 위해 필요한 구성들을 공유하고자 합니다.

목차
1. NHN 모니터링의 현재
2. 모니터링의 변화
3. 모니터링 방법론
4. 모니터링 절차
5. NHN 모니터링의 미래

대상
- 인프라를 운영하는 시스템 엔지니어
- 인프라 모니터링 시스템에 관심이 있는 분

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

[2018] NHN 모니터링의 현재와 미래 for 인프라 엔지니어

  1. 1. © 2018 NHN FORWARD. All rights reserved. NHN 모니터링의 현재와 미래 for 인프라 엔지니어 이대형 IT시스템운영팀
  2. 2. CONTENTS 1. NHN 모니터링의 현재 2. 모니터링의 변화 3. 모니터링의 절차 4. NHN 모니터링의 미래
  3. 3. NHN 모니터링의 현재
  4. 4. 4 / 66 NHN 모니터링 시스템 Nsight NeTAISEE HAWK Saisei Icinga2 Zabbix Syslog NMSlogESXmon CatsEye GTM InfraBoard SIS DNSMon *설명하기 쉽도록 돕기 위한 중요 모니터링만 포함됨 Watchdog
  5. 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. 6 / 66 • 별도 개발된 Beat 이용 필요한 항목 수집 토스트 클라우드 모니터링 시스템 System Engineer Application Middleware OS/ Hypervisor OSBeat Logstash + Apache Kafka + Elasticsearch Grafana Ingest Aggregation Informative Dashboard Developer
  7. 7. 모니터링의 변화
  8. 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. 9 / 66 1997 2002 솔루션의 변화 Network Monitoring System(NMS) 현재2011 Cloud Ready Pub/Sub, AI Monitoring as a Service Whitebox Monitoring
  10. 10. 10 / 66 Application Middleware OS Hypervisor Server Storage Network Monitor A Monitor B Monitor C Developer System Engineer Network Engineer 포괄적 적용 범위
  11. 11. 11 / 66 자동 인지 • Service Scaling Up & Down 확장성(Scalability) 모니터링 시스템 삭제해제 신규 신규 등록 등록
  12. 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. 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. 14 / 66 협업
  15. 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. 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. 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. 18 / 66 메트릭 (Metrics) 어떤 일이 일어나는가? , Not 왜 일어나고 있는가? (분석) 특정 시점에서 시스템과 관련된 값을 캡처 정의된 주기로 수집하여 시계열 데이터베이스(TSDB)에 저장
  19. 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. 20 / 66 시스템 및 서비스에 간접적 영향  패키지 설치 및 업데이트  하드웨어 변경 및 폴트  응용 프로그램 배포 이벤트의 상당 부분은 로그에 존재  문제의 상당 부분을 미리 파악 가능  이벤트 처리를 통한 알람 발생 이벤트(Event)
  21. 21. NHN 인프라 모니터링의 미래
  22. 22. 22 / 66 우리도 이제 Multi Region  클라우드 환경에 적합한 구조의 운영도구가 절실 문제 발생 시, 분석을 위한 다양한 정보 필요  고객보다 문제를 먼저 확인 할 수 있는 시스템 필요  자산 및 기반 시스템과의 연계를 통한 빠른 확인 빠른 변화에 대한 대처 필요  쉽게 만들고 쉽게 버리자  오픈 소스 도구 활용 지금 우리에게 필요한 것은 무엇인가?
  23. 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. 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. 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. 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. 27 / 66 Ingest 관리의 어려움  폴트 시 로그 유실  로그 형태 변경 시 Grok 패턴 재작성 및 재시작 필요 운영 시스템 변경의 어려움  교체 시 수집 중단에 따른 신규 버전 적용의 어려움 발생 로그 수집 시스템의 변화 필요성 증가 LOG File by AdbA Icons ❤️ from the Noun Project Host machine
  28. 28. 28 / 66 로그 수집 시스템의 변화 필요성 증가(계속) Ingest 관리 로그 처리 로그 검색 로그 저장소 관리
  29. 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. 30 / 66 로그 수집 시스템의 변화 필요성 증가(계속) 로그 검색 - 검색 위주의 이벤트 확인
  31. 31. 31 / 66 로그 검색 - 단순 로그 구분별 나열 로그 수집 시스템의 변화 필요성 증가(계속)
  32. 32. 32 / 66 로그 처리 방식 변화  처리 방식 단순화  트리거에 의한 이벤트 알림 Docker swarm 기반 운영  자가 치유(Self Healing)  롤링 업데이트(Rolling Update)  업데이트 성공 후 교체 시도 Infrastructure as Code 신규 로그 수집 시스템
  33. 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. 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. 35 / 66 Extractor API 로그 수집 시스템 - 로그 필드 추출 Extractor 설정 GUI
  36. 36. 36 / 66 로그 수집 시스템 - 스트림 관심 항목별 로그 스트림 분리
  37. 37. 37 / 66 로그 수집 시스템 – 스트림 흐름 관심 항목 별 로그 스트림 분리  Stream rules All messages User/Group Operation Package Operation UG Index All in One Index 로그 유입 rules rules 인덱싱 인덱싱 스트림
  38. 38. 38 / 66 스트림 API 로그 수집 시스템 – 스트림 설정 스트림 설정 GUI
  39. 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. 40 / 66 로그 수집 시스템 - 인덱싱 설정 Index Set을 통하여 로그 중요도에 따른 인덱싱 설정 약 3개월 약 1개월 샤드, 복제
  41. 41. 41 / 66 로그 수집 시스템 – 인덱싱 흐름 Index Set을 통하여 로그 중요도에 따른 인덱싱 설정 All messages User/Group Operation Package Operation UG Index All in One Index 로그 유입 복제 / 샤드 보관 주기인덱싱 설정 Index Set Index Set 스트림
  42. 42. 42 / 66 로그 수집 시스템 – 스트림 사용 예제 패키지 설치, 삭제 및 업데이트 감시
  43. 43. 43 / 66 로그 수집 시스템 – 스트림 사용 예제 패키지 설치, 삭제 및 업데이트 감시
  44. 44. 44 / 66 로그 수집 시스템 – 스트림 사용 예제 패키지 설치, 삭제 및 업데이트 감시
  45. 45. 45 / 66 로그 수집 시스템 – 대시보드 패키지 설치, 삭제 및 업데이트 감시
  46. 46. 46 / 66 하드웨어 이벤트 확인 및 알람 발생  OS 커널 혹은 벤더 제공 소프트웨어를 통한 폴트 확인  이벤트 데이터  대부분 하드웨어는 폴트 감지시 SNMPTrap에게 해당 이벤트 통보 가능  Logstash + SNMPTrap Input 기능을 통하여 이벤트 처리 및 통보 가능  별도 관심 로그 스트림 구현 로그 수집 시스템 – 기타 활용 영역 Hardware SNMP Trap Logstash JSONEvent Graylog2 Alert OOB Network Service Network
  47. 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. 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. 49 / 66 로그 수집 시스템 – 모니터링 대시보드
  50. 50. 50 / 66 점진적 적용 필요  로그 유입량 점진적 증가 필요  로그 처리는 결국 문자열 처리  힙(Heap) 메모리 확인 필수 각 컴포넌트는 결국 관리 포인트  부하에 따른 컴포넌트 확장 및 축소 가능 설계 필요  각 컴포넌트 별 메트릭 수집 및 시각화 필요 컨테이너에 대한 이해 설정 관리의 자동화  수집 항목에 대한 설정 동기화  Salt/Puppet/Chef/Ansible 도구 활용 적용 시 어려운 점
  51. 51. 51 / 66 모니터링 대시보드 개선 또다른 이중화 고려  Multi Data Center  장애 대응 훈련 기반 연계 시스템 연동  기반 시스템 연계 CI/CD 반영 그 외 기타 사항들  접근 및 권한 제어 남은 과제와 목표는?
  52. 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. 53 / 66 인프라 모니터링 시스템 개선 기회가 된다면 다음에…
  54. 54. © 2018 NHN FORWARD. All rights reserved. Q&A
  55. 55. © 2018 NHN FORWARD. All rights reserved. THANK YOU
  56. 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. 57 / 66 모니터링 방법론 - Problem Statement Method 성능 문제가 있다고 생각하는 이유는 무엇입니까? 본 시스템이 기존에도 잘 수행되었는가? 최근에 변경된 사항은 무엇이었나? (소프트웨어? 하드웨어? 로드?) 성능 저하가 대기 시간(Latency) 또는 수행 시간으로 표현될 수 있습니까? 문제가 다른 사람이나 응용프로그램에 영향을 미칩니까? 환경(Environment)은 어땠나요?  Software, Hardware, Instance types? Versions? Configuration?
  58. 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. 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. 60 / 66 모니터링 방법론 - The Use Method(계속) The Use Method by Brendan Gregg  사용률(Utilization)  100%는 병목 현상의 징후  70% 일 경우도 오랜 기간 측정시, 짧은 주기에 발생된 100% 를 감출 수 있음  포화(Saturation)  대기 큐(Wait Queue)의 길이 또는 큐(Queue)에서 소비되는 시간으로 측정될 수 있음  에러(Error)
  61. 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. 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. 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. 64 / 66 인프라 서비스 대시보드 - Staytus http://staytus.co
  65. 65. 65 / 66 인프라 서비스 대시보드 – Staytus(계속) 작업(Maintenance) 등록과 추적
  66. 66. 66 / 66 인프라 서비스 대시보드 - Staytus(계속) 이슈의 등록, 추적, 변경 관리
  67. 67. 67 / 66 로그 수집 시스템 – 테스트 플랫폼 코드 Docker Stack / Service 코드로 구성  https://github.com/netman2k/graylog2-demo
  • Jiwon0658

    Apr. 13, 2021
  • sunggonSong

    Oct. 30, 2020
  • junshoong

    May. 8, 2020
  • ssuser83b6cd

    Apr. 13, 2020
  • iykim

    Feb. 20, 2020
  • jinhakkim

    Jan. 21, 2020
  • kimkaphwan0

    Jul. 7, 2019
  • hcJung

    May. 8, 2019

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

Views

Total views

3,237

On Slideshare

0

From embeds

0

Number of embeds

194

Actions

Downloads

115

Shares

0

Comments

0

Likes

8

×