반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
스토리지 관리
예방 점검
APM Solution
애플리케이션 관리
URL 관리
브라우저 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
AI 인공지능
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
잘파세대(Z세대 + 알파 세대)에 대한 모든 것
SMS를 통한 서버관리는 꼭 이렇게 해야만 한다?!
이화정
2024.02.22
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
네트워크 정보 수집 프로토콜의 모든 것 (SNMP, RMON, ICMP, Syslog)
Gartner에서 진행한 연구에 따르면 기업에서 서버의 다운타임이 발생할 경우, 시간당 약 748억 ~ 1,202억의 손실 비용이 발생한다고 합니다.
또한 서버 다운타임등 서버를 제대로 관리하지 못했을 경우에는, 금전적인 손실뿐 아니라 고객이탈이나 브랜드이미지 하락 등의 치명적인 손실도 입게 되죠.
따라서 올바른 서버 관리를 통해 문제를 미리 예방하고, 혹여나 문제가 발생할 경우에는 빠르게 대응할 수 있어야 합니다. 그렇다면
'올바른 서버 관리'란 정확히 무엇을 의미하는 걸까요?
ㅣ올바른 서버 관리를 위한 첫 걸음
ⓒoutsource2india
올바른 서버 관리를 위한 첫걸음은 바로 '통합 서버 관리' 도구의 도입입니다. 가장 많이 활용하는 도구가 바로 SMS(Server Management System)죠.
SMS는 복잡한 IT 인프라를 효과적으로 관리하고, 모니터링할 수 있는 해결책을 제공하여, 서버 사태를 쉽게 파악하고, 필요한 조치를 신속하게 처리할 수 있도록 도와줍니다.
SMS는 기업의 서비스 안정성과 비즈니스 연속성을 보장하는 데 필수적인 도구인 셈이죠. 최근에는 관리하는 서버의 규모와 상관없이 대부분 SMS을 사용하고 있습니다.
하지만 SMS를 도입하고 구축만 한다고 해서, 모든 과제를 해결할 수 있을까요?
ㅣSMS를 제대로 활용하는 방법
SMS를 '제대로' 활용하기 위해서는 단순한 모니터링을 넘어, 문제 발생 시 알림을 받고 이를 통해 신속하게 문제를 해결할 수 있는 적극적인 조치가 필요합니다.
적극적인 조치 중의 대표적인 예이자 서버 관리의 핵심은 바로 '감시 설정'입니다. 그렇다면 구체적으로 '감시 설정'을 통해 어떻게 서버를 관리해야 하는지, 이를 위한 SMS의 조건은 무엇인지 살펴보겠습니다.
최적화된 감시 설정 값을 간편하게 설정할 수 있어야 한다
SMS의 감시항목설정은 사용자가 기본적인 모니터링 환경을 빠르게 구축할 수 있도록 간편하게 설정할 수 있어야 합니다. 통합 서버 관리에 대한 경험이 부족한 사용자더라도, 제품을 쉽게 설정하고 사용할 수 있도록
최적화된 감시 설정 값을 제공
해야 하죠. 예를 들면 CPU 사용률이 몇% 였을 때 심각하고 위험한지를 각 항목별로 제공해야 합니다.
Zenius SMS의 경우 사용자의 OS에 따라 감시 설정 항목(CPU 사용률, MEM 사용률 등)의 심각도와 임계치 조건은 어떻게 해야 하는지 기본적인 디폴트 값을 제공합니다.
더불어서 제니우스만의 최적의 감시 설정 가이드라인을 제공하여, 복잡한 설정 과정을 거치지 않더라도 모니터링할 수 있도록 도와주죠. 물론 기업과 조직의 환경에 맞춰 감시 설정을 조정할 수 있습니다.
필수적인 감시 설정 기능을 갖추고 있어야 한다
또한 SMS의 감시 항목을 설정할 때는
필요한 주요 기능으로 구성
되어야 합니다. 사용자는 복잡한 설정 절차 없이 필요한 감시 항목을 설정해야 하고, 서버 관리에 소요되는 시간을 줄일 수 있어야 하기 때문이죠.
예를 들어 시스템의 중요한 지표(예: CPU 사용량, 메모리 사용량, 디스크 I/O 사용률)를 확인할 수 있는 감시 항목 설정이 있는지, 각 감시 항목에 대해 심각도 수준과 임계치를 설정할 수 있는지, 다양한 방식의 알림 방식 기능을 제공하는지 등을 직관적으로 확인할 수 있어야 합니다.
Zenius SMS의 경우 사용자에게 꼭 필요한 기능(감시 항목, 서버, 심각도, 임계치, 알림 설정, 복구 스크립트 등)만 집중할 수 있도록 구성되어 있습니다.
감시 항목에서는 사용 중인 OS를 설정하고, 원하는 감시 항목을 선택하여, 원하는 서버를 감시 설정 할 수도 있죠. 또한 심각도와 임계치 설정에서는 무해-주의-위험-긴급-치명 각 값에 맞게 임계치 값을 설정할 수 있습니다.
예를 들어 '긴급'이라는 항목에 80%라고 설정했는데 임계치 값이 80%를 넘어설 경우, 사용자에게 즉각적으로 알려줍니다. 또한 지속시간을 1분 발생 횟수를 1이라고 설정할 경우, 1분을 넘길 때 사용자에게 알림을 통보해 주죠.
알림 통보 서비스가 잘 갖춰져 있어야 한다
감시 항목 설정 중
알림 통보는 서버를 관리하는 데 있어 매우 중요한 기능
입니다. 서버에 문제점이 발생할 경우, 사용자에게 즉각적으로 알려줄 수 있는 장치이기 때문이죠. 또한 문제가 더 심각해지기 전에 신속하게 조치를 취할 수 있게 해주며, 시스템의 다운타임을 최소화하는 데 결정적인 역할을 합니다.
이 밖에도 알림 통보 기능에서는 사용자의 업무 환경과 선호도에 따라, 알림의 유형이나 수신자를 유연하게 선택할 수 있어야 합니다.
Zenius SMS를 예를 들어 살펴보면 감시 설정에 임계값을 초과하거나, 예상치 못한 이벤트가 발생했을 때 다양한 형태로 알림 서비스를 제공하고 있습니다. 이메일, 문자 Push App은 물론 외부 연동을 통해 슬랙이나, 카카오톡으로도 편리하게 알람을 받아볼 수 있죠.
이 밖에도 알림의 임계값과 조건, 적용 시간이나 요일, 알림을 받을 사용자도 별도로 지정할 수 있습니다.
자동화 복구스크립트 기능을 제공해야 한다
서버에 문제가 감지되었을 때는 알림 통보 기능뿐만 아니라,
사전에 정의된 스크립트를 자동으로 실행하여 문제를 신속하게 해결
할 수 있어야 합니다. 예를 들어 데이터베이스 서버의 응답 지연이 감지될 때 '캐시를 클리어하고 서비스를 재시작해 줘!'라는 스크립트 실행을 통해 즉각적으로 문제를 해결할 수 있어야 하죠.
이러한 자동화 복구스크립트 기능은 사용자가 알림을 받고 대응하기까지의 시간을 대폭 줄여줄 수 있고, 이에 따라 시스템 다운타임을 최소화할 수 있습니다. 또한 반복적이거나 단순한 문제 해결 과정을 자동화함으로써, 더 중요한 작업에 집중할 수 있겠죠.
위에 언급한 내용을 Zenius SMS를 통해 살펴보면, 장비에 장애가 발생할 경우 즉시 복구스크립트가 구동되어 문제를 자동적으로 해결할 수 있게 합니다.
예를 들어 A 서버에 임계치를 80%로 설정한 후, 복구스크립트를 통해 'C라는 방법으로 조치를 취해줘!'라고 미리 설정할 경우 자동적으로 문제를 해결할 수 있죠. 이러한 자동화 복구스크립트 기능은 수백 혹은 수천 대의 서버와 장비를 효율적으로 관리할 수 있어, 관리 부담을 줄이는 데 매우 효과적입니다.
또한 '정상 복구 시 통보' 옵션을 설정하면, 복구 스크립트가 완료됨에 따라 알림 통보를 사용자에게 재차 알려줍니다. 이 과정을 통해 사용자는 만족도와 제품에 대한 신뢰도를 높일 수 있겠죠.
감시 항목들을 한눈에 관리할 수 있어야 한다
이젠 앞에서 감시 설정하고 등록했던 감시 항목들을 모니터링할 수 있어야 하겠죠? 이때 중요한 점은
필수적인 감시 항목은 보여주되, UI는 단순화
해야 한다는 점입니다. 이는 주요 감시 항목의 상태를 신속하게 파악하고, 문제가 발생했을 때 즉각적으로 대응하기 위해서죠.
또한 감시 항목 상태를 색상 코드(예: 녹색은 정상, 노란색은 경고, 빨간색은 심각)와 아이콘으로 구분하여, 사용자가 감시 항목의 상황을 즉각적으로 인식할 수 있도록 해야 합니다.
Zenius SMS의 경우 주요 감시 항목들의 현황을 통합적으로 모니터링할 수 있습니다. 불필요한 항목들을 줄이고 핵심적인 항목들만 선별하여, 서버의 감시 항목을 신속하게 모니터링할 수 있죠.
감시 현황은 직관적인 UI가 중요한 만큼, 심각도 현황(정상-무해-주의-위험-긴급-치명)을 색상으로 구분하여 문제가 생겼을 때 신속하게 대응할 수 있도록 구성하였습니다. 또한 사용자의 환경에 맞춰 필수적인 감시 항목을 쉽게 선택하여 모니터링할 수 있습니다.
이 밖에도 많은 서버의 감시 항목을 관리하다 보면, 중요한 감시 항목을 추가하지 못한 상황이 발생할 수 있는데요. 최악의 경우에는 막대한 손실 비용 발생 등의 심각한 결과를 초래할 수 있겠죠.
이에 따라 감시 현황은 더더욱 직관적으로 모니터링할 수 있어야 합니다. 주요한 감시 항목을 실수로 설정하지 않더라도, 신속하게 파악하고 등록하여 대처할 수 있기 때문이죠. Zenius SMS는 감시 설정해 둔 항목 수가 예상과 다를 경우(예: 만약 관리하는 서버에 감시 항목이 2건이어야 하는데 → 1건으로 표기된 경우) 미등록 건 감시 항목을 조회하여 등록할 수 있습니다.
주요 감시 항목을 설정하고 동작여부에 '미등록' 항목으로 검색하면, 감시 설정하지 않은 항목을 조회할 수 있죠. 이처럼 Zenius SMS은 자칫 놓칠 수 있는 주요 감시 항목도 신속하게 찾아 등록할 수 있습니다.
。。。。。。。。。。。。
지금까지 살펴본 것처럼 Zenius와 같은 SMS를 통해서
서버를 한눈에 모니터링하고, 감시 설정 기능을 통해 체계적으로 관리하며, 문제 발생 시 다양한 알림과 자동화된 복구스크립트로 문제점을 신속히 해결
해야 합니다. Zenius SMS 대규모 서버자원을 관리하고 있는 한 고객사 관계자의 말씀으로 이 글을 마무리하려고 합니다.
"이 많은 서버의 감시 항목들을 휴일 없이 24시간 동안 지켜볼 수는 없잖아요. 그래서 서버를 통합 관리할 수 있는 Zenius SMS을 도입했죠. 이용하면서 좋았던 점은 감시 현황 페이지를 통해 한눈에 감시 항목을 관리할 수 있어 편리하다는 점이에요.
감시 설정을 걸어둔 항목들이 많아 종종 등록을 못한 경우가 발생해도, 직관적으로 확인하고 감시 항목을 추가할 수 있어요. 특히 복구 스크립트 기능을 애용하는 편인데요. 서버에 장애가 발생했을 때 복구 스크립트를 미리 걸어두면, 장비에 장애가 발생해도 신속하게 문제 해결을 할 수 있어 매우 만족스럽습니다!"
#SMS
#서버
#서버관리
#서버모니터링
#Zenius
#ZeniusSMS
#통합서버관리
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
옵저버빌리티 향상을 위한 제니우스 대표 기능들
옵저버빌리티 향상을 위한 제니우스 대표 기능들
이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다.
2023.04.19
2023년 상반기 협력업체 상생 세미나 성료…”신규 기능 소개, 상생 지속 도모”
2023년 상반기 협력업체 상생 세미나 성료…”신규 기능 소개, 상생 지속 도모”
지난 21일 본사 8층 대회의실에서 ‘2023년 상반기 협력업체 상생 세미나’를 진행했습니다. 브레인즈컴퍼니는 급변하는 IT인프라 시장 환경에 적극 대응하고 협력사와의 협력을 더욱 강화하기 위해 협력업체 상생 세미나를 운영하고 있습니다. 올해부터 세미나를 상, 하반기 2회 실시하기로 하였는데요, 기존에 EMS를 설치 및 활용하는 교육 중심에서 제니우스의 새로운 기능을 소개하는 중심으로 세미나에 변화를 주었습니다. 이날 행사는 먼저 프리세일즈팀에서 회사 소개를 하였고, 이어서 Technical Consulting 팀 정채린 차장이 제니우스 8.0의 신규 기능을 소개하였는데요, 20개 이상의 신규 기능에는 WNMS, ERMS, 웹토폴로지 등이 포함되어 있습니다. 그리고 막간을 이용해 통합로그관리, Zenius LogManager을 소개하는 시간도 가졌습니다. WNMS는 분산된 AP 장비의 상태를 한 곳에서 통합 모니터링할 수 있을 뿐만 아니라, AP 장비의 Up/Down 링크, WAN Traffic 등을 실시간으로 모니터링하고, AP 장비의 부하를 효율적으로 컨트롤하도록 접속자 수, 사용자 수, 최대 동시접속자 수 등의 근거데이터를 모니터링하고 자료로 확보할 수 있습니다. ERMS(Event Relation Management System)은 문제 원인 추적을 위한 이벤트의 연관성을 분석하는 기능입니다. 기존 서비스맵의 기능에 AND/OR, 이상 등의 다양한 연산조건 및 통보기능을 추가하여 개별적 이벤트가 아닌 복합적인 이상 상황을 감지할 수 있습니다. 웹토폴로지는 기존에는 CS 형식으로 제공되었던 토폴로지맵의 활용도를 높이기 위해 Web기반으로 구현하여 오버뷰와 함께 활용할 수 있도록 구현하였습니다. 마지막은 클라우드 모니터링을 소개하고 시현을 통해 클라우드 가상화 자원을 모니터링하여 가상 자원의 적절한 운영 효율성을 향상시킬 수 있는지 선 보였습니다. 이번 세미나에는 영진인포텍, 한신정보, 시원 등 협력업체 관계자뿐만 아니라 디와이, 더존비즈온 같은 고객사에서도 참여했습니다. 참여한 협력업체는 이런 형식의 세미나가 자주 있었으면 좋겠다, 그리고 정기적인 온라인 교육을 희망한다는 의견을 주셨습니다. 반면 참여한 고객사는 제니우스 8.0으로 업그레이드를 결정하는 데 많은 도움이 되었다고 합니다. 세미나를 주관한 소감은 “제품 중심으로 소개하는 세미나는 처음인데 예상보다 질문이 많았고 관심이 뜨거운 것을 보고 앞으로 제품을 소개하는 기회를 자주 가지면 좋겠다”입니다. 참여해 주신 모든 분께 감사 인사 전합니다.
2023.06.23
시스템 장애, Zenius EMS 솔루션으로 정확하고 효과적으로 관리하는 법
시스템 장애, Zenius EMS 솔루션으로 정확하고 효과적으로 관리하는 법
IT 시스템은 서버, 네트워크, 애플리케이션이 밀접하게 상호작용하는 다계층 구조로 운영됩니다. 이런 환경에서 발생하는 장애는 더 이상 단일 장비의 문제가 아니라, 여러 구성 요소가 연쇄적으로 영향을 주고받으며 서비스 품질에 직결됩니다. 예를 들어 한 서버의 경고는 단순한 일시적 리소스 부하에 불과할 수 있지만, 동시에 다른 계층에서 오류가 발생하면 곧바로 서비스 중단으로 이어질 수 있습니다. 반대로 특정 장비에서 치명적인 이벤트가 발생하더라도, 전체 서비스 아키텍처 차원에서는 영향도가 제한적인 경우도 흔히 발생합니다. 하지만 실제 운영 현장에서는 이런 복잡한 상황이 그대로 고려되지 못하는 경우가 많습니다. 많은 관제 환경이 여전히 장비 단위의 심각도에만 의존하기 때문에, 실제 서비스 영향과 상관없이 불필요한 알람이 쏟아지거나 반대로 중요한 장애 신호를 놓치는 일이 반복되곤 합니다. 그 결과 운영자는 수많은 이벤트 속에서 우선순위를 정하기 어렵고, 대응 속도 역시 느려질 수밖에 없습니다. Zenius EMS 솔루션의 핵심 모듈인 ERMS(Event Relation Management System)는 이러한 한계를 보완합니다. 개별 이벤트를 단순히 나열하는 대신, 규칙(Rule)으로 연계해 서비스 단위의 장애 여부를 판단하고 운영자가 즉시 상황을 이해할 수 있도록 도와줍니다. 덕분에 단순히 “어느 장비에서 문제가 발생했는가”를 넘어, “서비스 전체가 지금 어떤 상태인가”라는 더 중요한 질문에 답할 수 있습니다. 이번 글에서는 구체적인 구성 방법, 그리고 실제 운영 환경에서의 활용 사례를 통해, IT 시스템 장애를 어떻게 더 정확하고 효과적으로 관리할 수 있는지 살펴보겠습니다. Zenius EMS 솔루션의 ERMS 기능은?! 먼저 장비 관점에서의 이벤트 모니터링과 ERMS가 이벤트를 처리하는 방식이 어떻게 다른지 살펴보겠습니다. - 장비 관점에서의 이벤트 모니터링 CPU 사용률 경고, 프로세스 다운, 네트워크 지연 등 각 장비에서 발생하는 이벤트를 개별적으로 수집하고 표시하는 방식입니다. 특정 장비의 상태를 빠르게 확인할 수 있다는 장점이 있지만, 서비스 전체의 영향도를 파악하기에는 한계가 있습니다. - ERMS 이벤트 발생 로직 : 장비에서 발생한 이벤트들에 대한 Rule 설정으로 , 서비스 관점에서의 장애 모니터링 ERMS는 장비에서 발생한 여러 이벤트를 단순 나열하지 않고, 규칙(Rule)으로 연계해 종합적으로 해석하는 방식입니다. 여러 이벤트의 조합을 통해 서비스 단위의 장애 여부를 표현하기 때문에, 운영자는 불필요한 알람에 휘둘리지 않고 실제로 중요한 신호에 집중할 수 있습니다. Zenius EMS 솔루션의 ERMS 기능구성 및 확인절차 ERMS를 제대로 활용하기 위해서는 먼저 서비스 등록과 모니터링 확인 절차를 거쳐야 합니다 Step 1. [ ERMS > 설정 > 등록 ] : 신규 서비스를 등록 합니다. ① 서비스명 : 모니터링 페이지에 보여질 서비스명 입력 ② 연산 조건 : 연산 조건을 선택/입력하여 이벤트를 발생 시킬 조건 설정 - OR : 하위 서비스 또는 대상들의 상태가 하나라도 발생하면 설정한 심각도로 상태 표현 - AND : 하위 서비스 또는 대상들의 상태가 전부 발생하면 설정한 심각도록 상태 표현 - 사용자정의 : 하위 서비스 또는 대상들의 상태가 설정한 수 이상일 경우 설정한 심각도로 상태 표현 - 심각도별 개수 : 하위 서비스 또는 대상들의 심각도별 개수가 설정한 값 이상일 경우 상태 표현 ③ 심각도 : 연산 조건에 따른 이벤트 발생 시 보여지는 심각도 설정 - 인프라/감시설정의 심각도와 별개로 발생시킬 심각도 지정> 하위대상 - 선택한 서비스 대상 중 가장 높은 심각도 등급으로 상태 표시 ④ 서비스 대상 : 연산 조건에 따라 이벤트를 발생 시킬 대상 선택 - 서비스 : ERMS에 등록 된 서비스 선택 - 장비/대상 : 다른 인프라에 등록 된 장비 선택 - 감시설정 : 다른 인프라에 등록 된 감시설정 선택(서비스 대상 설정은 곧 ‘서비스 장애를 어떻게 정의할 것인가’와 직결되므로, 인프라 구조와 서비스 흐름을 고려해 신중히 지정해야 합니다.) ⑤ 이벤트 제목 : 연산 조건에 만족하여 이벤트 발생 시 보여지는 명칭 ⑥ 통보설정 : 이벤트 발생 시 설정된 통보방법 및 수신자에게 통보 되도록 설정 * SMS, 이메일, 메신저 등 다양한 채널과 연동할 수 있으며, 사전에 통보 방법이 반드시 정의되어 있어야 합니다. 운영자, 서비스 담당자, 온콜 팀 등 그룹 단위 지정이 가능해, 장애 대응 체계와 긴밀하게 연결됩니다. Step 2. [ ERMS > 모니터링 ] : 등록 확인 앞서 등록한 서비스와 Rule이 정상적으로 반영되었는지 모니터링 화면에서 확인합니다. 트리 구조로 전체 → 그룹 → 서비스 → Rule → 장비 단위까지 계층적으로 점검할 수 있어, 설정 누락이나 오작동 여부를 쉽게 파악할 수 있습니다. Zenius EMS 솔루션의 ERMS 활용 가이드 ERMS를 실제 환경에서 적용할 수 있는 대표적인 사례를 살펴보겠습니다. Case 1. 연관 서비스 간 이벤트 관리 ERMS를 활용하면 서로 다른 인프라에서 발생한 이벤트를 하나의 논리적 서비스 단위로 묶어 관리할 수 있습니다. 이를 통해 단일 장비 경보가 아니라, 실제 서비스 차원의 장애 인지가 가능해집니다. [Web 서비스와 연관 된 감시설정을 등록한 사례] 웹 서비스와 관련된 CPU 사용률, 프로세스 상태, 네트워크 연결 상태 등 여러 감시설정을 하나의 서비스로 등록합니다. 등록된 서비스는 “N개 이상 이벤트 발생 시”라는 조건으로 Rule을 구성합니다. 조건이 충족되면 서비스 메인 담당자(예: 홍길동)에게 SMS, E-mail 등으로 자동 통보가 이뤄집니다. 이를 통해 운영자는 단순히 경보를 나열하는 대신, 서비스 전체의 관점에서 중요한 신호만 걸러내어 신속히 대응할 수 있습니다. Case 2. 이중화 구성 관리 이중화 서버나 네트워크 장비 환경에서는 한쪽 노드가 장애를 겪더라도 서비스는 계속 유지될 수 있습니다. 하지만 양쪽 노드가 동시에 장애를 겪는 순간 서비스는 치명적인 상황에 빠지게 됩니다. ERMS는 이러한 특성을 Rule로 정의해 긴급 상황을 빠르게 알릴 수 있습니다. [이중화 구성에 대한 관리 사례] (1)신규 서비스 등록 시 이중화 구성 된 서버의 “서버다운” 감시설정 선택 (2)연산 조건, 심각도, 이벤트 제목 등을 설정하여 해당 조건에 대한 이벤트 발생 시 표현 될 정보 설정 - 연산 조건 : 이중화 구성에 대한 Rule 설정임으로 연산 조건은 “AND”로 설정 - 심각도 : 연산 조건 만족 시 발생할 이벤트 등급 - 이벤트 제목 : 해당 이벤트 발생 시 보여지는 명칭 (상황 심각성을 인지 할 수 있는 문구로 작성) (3)수신자/통보방법 설정을 통해 이벤트 발생 시 해당 서버에서 운영중인 서비스와 연관 된 담당자들에게 긴급 상황에 대한 인지가 가능하도록 합니다. 이를 통해 단일 장애에 과잉 반응하지 않으면서도, 실제 서비스 전체에 영향을 주는 상황은 놓치지 않고 빠르게 인지할 수 있습니다 Case 3. 서비스맵을 통한 시각화 모니터링 ERMS는 등록된 서비스를 시각화해 한눈에 파악할 수 있는 서비스맵 기능을 제공합니다. Sunburst, Bubble 형태의 차트를 활용하면 전체 서비스 구조와 이벤트 상태를 직관적으로 확인할 수 있습니다. [오버뷰 기능을 통한 시각화 사례] EMS > 설정 > 컴포넌트에서 “ERMS 서비스맵” 컴포넌트를 등록합니다. 이름, 제목, 서비스, 차트 종류(Sunburst/Bubble), 표시 단계 수 등을 설정합니다. 이후 등록된 컴포넌트를 오버뷰 화면에 추가합니다. ERMS 서비스 단위의 이벤트 현황이 시각적으로 표시됩니다. 다른 컴포넌트(성능 지표, 이벤트 이력 등)와 조합하면, 장애 상황과 성능 상태를 통합적으로 모니터링할 수 있습니다. 색상 변화, 계층 구조, 아이콘 조합 등을 통해 복잡한 운영 상황을 직관적으로 해석할 수 있습니다. 이를 통해 운영자는 이벤트 목록이 아닌 서비스 단위의 전체 그림을 기반으로 문제를 인지하고 대응 우선순위를 판단할 수 있습니다. [Sunburst, Bubble 차트종류] (1)오버뷰 구성 시 앞에서 생성한 컴포넌트를 추가하여 ERMS 서비스 단위 기준 이벤트와 다양한 컴포넌트와의 조합을 통해 전체적인 운영상황을 시각화하여 가시적인 모니터링이 가능 합니다. [ERMS 서비스 상태 오버뷰 시각화 구성] Zenius EMS 솔루션의 ERMS 구체적 활용 효과 기존 이벤트 관리 환경에서는 장애 여부를 개별 장비의 심각도만으로 판단했습니다. 이 때문에 중요도가 낮은 장비에서 발생한 이벤트라도 ‘치명’으로 기록되면, 실제 서비스 영향과 무관하게 서비스 전체가 그대로 ‘치명’ 장애로 표시되곤 했습니다. 반대로 여러 장비에서 동시에 문제가 발생해 서비스에 큰 부담을 주는 상황임에도, 단일 이벤트 기준만으로는 이를 제대로 드러내기 어려웠습니다. 결국 서비스 차원에서 실질적인 장애 여부를 구분하기 힘들었고, 운영자는 불필요한 경보와 오판 속에서 효율적인 대응이 어려웠습니다 ERMS를 도입하면 이런 한계를 극복할 수 있습니다. 이벤트 간의 연관 관계를 규칙(Rule)으로 정의하여 단순한 장비 경보가 아니라 서비스 단위의 장애를 판정할 수 있기 때문입니다. 예를 들어, A 장비에서 ‘치명’ 이벤트가 발생하고 동시에 B 장비에서 ‘주의’ 이벤트가 발생한다면, 이를 묶어서 서비스 전체를 ‘긴급’ 상태로 표현할 수 있습니다. 이처럼 서비스 관점에서 장애를 재정의하면 실제 영향이 큰 상황만 선별적으로 드러나고, 불필요한 알람은 크게 줄어듭니다. 운영자는 개별 이벤트에 매달릴 필요 없이 서비스 전체 상태를 기준으로 명확하게 판단할 수 있으며, 그 결과 대응의 정확성과 속도가 모두 향상됩니다. 서비스 품질 관리 또한 한층 안정적으로 이루어집니다. IT 시스템 장애는 이제 단순히 개별 장비 이벤트만으로는 정확히 판단하기 어렵습니다. Zenius EMS 솔루션의 ERMS 모듈은 이벤트를 서비스 단위의 규칙으로 묶어 해석함으로써, 불필요한 알람을 줄이고 실제로 중요한 장애만 명확히 드러냅니다. 서비스 등록과 Rule 설정, 시각화 기능을 통해 운영자는 장애 발생 시점을 더 빠르게 파악하고 우선순위를 명확히 정할 수 있으며, 결과적으로 서비스 안정성과 운영 효율성을 동시에 확보할 수 있습니다. 즉, ERMS는 IT 시스템을 장비 중심의 모니터링에서 서비스 중심의 관리로 전환하게 만드는 핵심 도구라 할 수 있습니다.
2025.09.09
AWS Opensearch(오픈서치) Alerting plugin 활용 방법
AWS Opensearch(오픈서치) Alerting plugin 활용 방법
AWS OpenSearch(오픈서치)는 핵심 기능을 확장하기 위해 다양한 Plugin을 제공합니다. 이를 통해 운영 환경에 맞게 안정적이고 효율적인 기능을 추가할 수 있습니다. 그중에서도 Alerting Plugin 은 조건 기반 탐지와 알림 기능을 제공하며, 보안 모니터링이나 장애 대응 같은 영역에서 자주 활용됩니다. 특정 이벤트를 실시간으로 감시하고, 정의한 조건을 만족할 경우 자동으로 알림을 발생시켜 운영자의 대응 속도를 높일 수 있습니다. 이번 글을 통해서 Alerting Plugin의 주요 구성 요소와, 실제 적용 과정에서 고려해야 할 부분을 함께 살펴보겠습니다. 1. Alerting plugin이란? 보안기능의 기본은 특정 조건에 대한 탐지설정을 하고 설정한 탐지 조건에 만족하는 데이터를 찾게 되면 원하는 형태로 알림을 발생시키는 것입니다. Alerting 은 Opensearch 내에 데이터를 탐지 대상으로 하여 기본 탐지 기능을 안정적으로 제공하는 plugin 입니다. Opensearch 문서에서는 대략적으로 아래 키워드로 설명 하고 있습니다. - Monitor: 검색조건에 해당하는 쿼리를 작성하고, 실행주기를 설정합니다. 여기에서 정의된 쿼리의 실행 결과는 Trigger 의 입력 데이터로 사용됩니다. - Trigger: 입력되는 쿼리 결과를 기준으로 실제 행위를 발생시키는 조건을 정의합니다. - Alert: Trigger 에서 정의된 조건이 만족하는 경우 Alert 이라는 이벤트를 생성합니다. - Action: Alert 이 발생했을 때 수정행 할 작업을 정의합니다. - Notification: Alert 이 발생했을 때 전송되는 알림 메시지를 정의합니다. 2. 어떤 버전을 사용하면 될까? Alerting 기능은 Opensearch 1.1.0 버전부터 제공된다고 되어 있지만, 알림(Notification) 기능이 추가되는 2.0 이후 버전부터 활용성이 높아졌다고 생각되네요. 개발의 편의성이나 시각적인 결과를 원한다면 OpenSearch Dashboards에 도입되는 2.9 버전 부터가 OpenSearch Dashboards 에 도입되기 때문에 시각적인 결과확인이 가능하여 개발이나 테스트 시에 도움이 많이 될 수 있습니다. Openserach 가 설치되어 있다면 다음 방법으로 plugin 상태를 확인해 볼 수 있는데요. curl -X GET http://localhost:9200/_plugins/_alerting 결과 opensearch-alerting 2.16.0.0 opensearch-notifications 2.16.0.0 opensearch-notifications-core 2.16.0.0 실제 사용해봤던 버전은 2.10, 2.16 으로 기능상으로 큰 차이는 없었기에 적당한 버전을 선택하여 사용하면 될 것 같네요. 아래는 openserach-dashboard 명령어로 설치된 plugin 리스트를 확인한 결과입니다. ./opensearch-dashboards-plugin list --allow-root alertingDashboards@2.16.0.0 anomalyDetectionDashboards@2.16.0.0 assistantDashboards@2.16.0.0 customImportMapDashboards@2.16.0.0 ganttChartDashboards@2.16.0.0 indexManagementDashboards@2.16.0.0 mlCommonsDashboards@2.16.0.0 notificationsDashboards@2.16.0.0 observabilityDashboards@2.16.0.0 queryWorkbenchDashboards@2.16.0.0 reportsDashboards@2.16.0.0 searchRelevanceDashboards@2.16.0.0 securityAnalyticsDashboards@2.16.0.0 securityDashboards@2.16.0.0 아래는 Opensearch Dashboard 에서 설치된 plugin 을 메뉴로 확인상태 입니다. 이처럼 필요한 플러그인을 적절한 버전으로 설치했다면, 이제 Alerting의 핵심 기능인 Monitor 와 Trigger 설정 방법을 살펴보겠습니다. 3. Monitor 실제로 탐지를 수행하고 alert을 발생시키기 위한 trigger의 입력 값이 되는 검색조건과 실행 주기를 설정하는 부분입니다. Monitor 는 Alerting 의 출발점이자 이후 Trigger, Alert, Action 으로 이어지는 전체 탐지 프로세스의 기반이 되는 구성 요소입니다. 아래와 같이 몇 가지 검색조건을 구분하는 기능을 제공하는데, Per Query Monitor, Per Bucket Monitor에 대해서 먼저 알아보겠습니다. - Per Query Monitor 설정한 쿼리 결과의 개수를 그대로 Trigger 조건의 입력 값으로 사용하도록 처리하는 방식이기 때문에 기본적이면서 단순 조건을 처리할 때 주로 사용하는 방식입니다. 예를 들어 시스템 로그를 대상으로 특정 사용자에 대한 로그인 실패 이력을 조건으로 건다고 했을때 아래와 같은 쿼리가 가능합니다. { "size": 0, "query": { "bool": { "must": [ { "bool": { "must": [ { "match_phrase": { "userid": { "query": "root", "slop": 0 } } }, { "match_phrase": { "action": { "query": "failed_password", "slop": 0 } } } ] } } ], "filter": [ { "bool": { "must": [ { "range": { "@timestamp": { "from": "now-30m", "to": "now" } } } ] } } 쿼리에 만족하는 조건이 있다면 아래와 같은 결과가 나타납니다. { "_shards": { "total": 9, "failed": 0, "successful": 9, "skipped": 0 }, "hits": { "hits": [], "total": { "value": 4, "relation": "eq" }, "max_score": null }, Per Query Monitor 은 위와 같은 결과가 나왔을 경우 trigger 조건에 만족한다면 단일 alert 이 한 개 발생하는 방식입니다. - Per Bucket Monitor 이 방식은 쿼리에 Aggregation 를 설정하여 Bucket 단위 별로 trigger 조건을 검사하고 alert 을 발생시키는 방식입니다. Per Query Monitor 과 동일한 조건의 쿼리에 아래와 같은 Aggregation query 가 추가되는 형태입니다. "aggregations": { "by_agg": { "terms": { "field": "host.keyword", "order": [ { "_count": "desc" }, { "_key": "asc" } ] } } } host 라는 필드로 group by 와 같은 집계를 하면 결과는 host 단위의 buckets 가 생성되고 각각의 bucket 에 개수가 포함되게 됩니다. 각각의 bucket 에 포함된 개수가 trigger 조건에 만족한다면 만족하는 만큼 alert 이 발생하게 되는데 이 부분이 Per Query Monitor 방식과 차이점이 되겠습니다. { ... "aggregations": { "by_agg": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "doc_count": 2, "key": "testhostname1" }, { "doc_count": 2, "key": "testhostname2" } ] } } } - Monitor API curl -X POST "https://localhost:9200/_plugins/_alerting/monitors/_search?pretty=true" -k -H "Content-Type: application/json" -d '{}' 아래와 같이 등록한 monitor 정보를 JSON 포맷으로 조회할 수 있습니다. Monitor 관련 몇 가지 API를 소개합니다. Create, Update 등 기본적인 기능 외에 설정한 Monitor 를 실행 시킬 수 있는 Monitor RUN API 도 제공 됩니다. 필요에 따라서 자신의 시스템에서 직접 실행시키는 로직을 구현해 볼 수 도 있을 것 같구요. 설정 내용을 미리 시뮬레이션 해서 결과를 테스트 해볼 수 있는 기능으로 활용해도 좋을 것 같습니다. Monitor Create POST _plugins/_alerting/monitors Monitor Update PUT _plugins/_alerting/monitors/<monitor_id> Monitor Delete DELETE _plugins/_alerting/monitors/<monitor_id> Monitor Run POST _plugins/_alerting/monitors/<monitor_id>/_execute 4. Trigger Trigger 는 Monitor 에 설정한 쿼리의 결과를 입력으로 Alert 을 발생 시킬 조건을 설정하는 과정입니다. 이 부분도 Per Query Monitor 과 Per Bucket Monitor 방식이 차이가 있습니다. Per Query Monitor는 쿼리의 결과가 단순 개수(hits)이기 때문에 개수 연상에 대한 true, false 로 결과를 얻습니다. 물론 결과가 true 인 경우에만 alert 이 발생하는 조건이 되겠죠. Per Bucket Monitor 방식은 개수 조건을 설정 하는 건 동일하지만 Aggregation 문에 정의된 key 명을 parent_bucket_path 에 맞춰 줘야 된다는게 다른 점입니다. Trigger condition 에서 설정한 조건이 만족한다면 bucket 단위로 결과 구해지게 됩니다. [ { "doc_count": 3, "key": "testhostname1" }, { "doc_count": 4, "key": "testhostname2" } ] 만약 실제로 이런 결과가 나왔다면 alert testhostname1, testhostname2 두 개의 alert 이 발생하게 됩니다. 5. Alert Monitor -> Trigger 조건이 만족하였다면 Alert 이라는 단위의 알림이 생성됩니다. Alert 은 Action 과 연계되었을 때 외부로 통보 등의 전달 기능을 수행할 수가 있고, 이런 연계 설정이 없다면 단순히 alert 이라는 데이터가 하나 신규로 생성되었다고 보면 됩니다. Opensearch Dashboard Alerts 메뉴에서는 아래와 같이 발생된 Alert 이 조회 됩니다. Alert 단위 별로 구체적으로 확인할 수 있는 방법은 없는 것 같고, Opensearch Dashboard 에서는 조회할 수 있는 정보는 이 정도가 전부인 것 같습니다. Alert은 발생 시점부터 Completed 될 때까지 아래 상태로 관리가 됩니다. - Active 조건이 만족하여 발생된 상태이고 아무런 처리가 되지 않은 상태라고도 합니다. - Acknowledged 관리자가 확인했다 정도의 의미를 부여할 수 있을 것 같은데요. 이 상태로 변경된 후부터 조건이 만족 했는데도 Alert 이 발생하지 않는 것처럼 보여질 수도 있습니다. 하지만 특정 시점이 되면 다시 Alert 이 발생하게 되는데 좀 애매한 운영 상태라고 보여집니다. 정확한 것은 이 상태 이후 실제 Alert을 발생시키는 조건이 해제 되었다가 다시 조건이 만족하게 된다면 Alert 이 발생하게 됩니다. Alert이 계속 발생되는 조건이라면 계속 Acknowledged 상태가 유지 되는 거라서 추가 Alert 이 발생되지 않는다는 오해에 소지가 있을 수도 있겠네요. 1번과 같이 Acknowledged 상태라도 조건이 만족하고 있는 상태라면 기존 상태가 유지가 되고, 2번 처럼 조건이 불만족 상태가 되면 상태는 Completed 상태가 되어 Alert 은 종료 처리됩니다. 3번처럼 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다. - Completed Alert이 발생하는 조건 즉 Trigger 조건이 만족하지 않는 경우 기존 발생된 Alert 상태는 Completed 상태로 전환됩니다. 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다. 개발 중에 이슈 사항 중 하나였다면 Completed 상태를 관리자가 임의로 변경할 수 없다는 것입니다. Alerting 시스템의 철학인지는 모르겠지만 상태 변경은 Acknowledged 만 가능하다는 것입니다. 즉 Completed는 Alerting 자체에서 조건의 만족 상태에 따라 변경해 주는 상태이고, 개발중인 시스템에서 Completed 상태를 별도로 운영하기 위해서는 자체적인 상태 처리 로직이 추가 되어야 됩니다. -Alert API curl -XGET "https://localhost:9200/_plugins/_alerting/monitors/alerts?pretty=true" -k 아래와 같이 발생한 Alert 리스트를 JSON 포맷으로 조회할 수 있습니다. 6. Action Alert 이 발생했을 때 관리자에게 통보하는 방식과 통보 메시지 등을 설정하는 기능입니다. Channel 이라는 설정을 하게 되는데 쉽게 말하면 통보 수단을 의미하는 거고 기본적으로 아래와 같은 통보 수단을 제공합니다. 기존에 자체적인 alert 처리 서비스가 있어서 이 서비스를 활용하고자 Custom webhook 방식을 사용했습니다. Action > Notification 에서 정의하는 Message 를 JSON 형식으로 우리의 alert 처리 서비스에 전달하는게 목적입니다. 전체적인 Action > Notification 설정은 아래와 같습니다. - Message 통보 수단을 통해 전달된 메시지 내용을 정의합니다. { "alertmessage": { "monitor": "{{ctx.monitor.name}}", "monitorid": "{{ctx.monitor._id}}", "trigger": "{{ctx.trigger.name}}", "severity": "{{ctx.trigger.severity}}", "period_start": "{{ctx.periodStart}}", "period_end": "{{ctx.periodEnd}}", "results": {{#toJson}}ctx.results{{/toJson}}, "deduped_alerts": [ {{#ctx.dedupedAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.dedupedAlerts}} ], "new_alerts": [ {{#ctx.newAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.newAlerts}} ], "completed_alerts": [ {{#ctx.completedAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.completedAlerts}} ] } } Message 에 사용할 수 있도록 제공되는 대략적인 정보 입니다. - ctx.monitor : Moniter 설정 정보 - ctx.trigger : Trigger 설정 정보 - ctx.newAlerts : 신규 생성 Alert 정보 - ctx.completedAlert : 완료된 Alert 정보 - ctx.dedupedAlerts : 기존 생성된 Alert 중복 생성 정보 ctx 내용 전체를 확인해 보면 활용할 수 있는 내용이 그렇게 많지는 않습니다. 목표로 했던 기능 중에 Alert 서비스에 발생된 Alert 의 실제 쿼리 범위 시간을 구해야 되는 했던 기능이 있었습니다. 아래 두 가지 값이 제공되어 값을 확인해 보니 조건 쿼리가 실행되는 interval 시간으로 확인 되어 실제로 사용하지는 못했습니다. ctx.periodStart ctx.periodEnd 대신 ctx.periodEnd 시간에 실제 쿼리 내에 정의된 time range 값을 계산하여 실제 쿼리 범위 시간을 구하는 방식으로 처리 했습니다. - Perform action Alert 단위에 대한 Action 처리 방식은 아래와 같은 종류도 설정할 수 있습니다. - Per execution: 조건을 만족하는 alert 이 여러 개여도 action 은 한번만 처리. - Per alert: 조건을 만족하는 alert 이 여러 개면 각각마다 action 을 수행함. 우리는 각각의 Alert 마다 action 처리가 필요하기 때문에 Per alert 방식을 사용했고, Actionable alerts 아래와 같이 설정 했습니다. - New: 신규 Alert 에 대한 Action 처리를 위해서 반드시 필요한 부분이고 - De-duplicated: 이미 생성된 Alert 에 대해 동일한 조건이 만족되었을 때 Action 을 처리할 것인가를 설정하는 내용입니다. 기존 생성된 Alert 의 상태 정보를 업데이트 시켜 주기 위해서는 이 설정을 추가해줘야 됩니다. - Completed: 발생된 Alert 의 조건이 만족하지 않게 된 경우 Action 처리 여부를 설정합니다. 기존 발생된 Alert을 자동으로 완료 처리해주려면 이 설정을 추가해줘야 됩니다. Action 에서 설정된 내용 데로 통보 수단을 통해 충실히 전달된다면, 실제 서비스 로직 에서 제대로 처리해줘야만 됩니다. - Notication message 처리 Alert 을 처리하는 서비스 로직 에서는 아래 같이 Alerting Notication 으로 message 를 전달 받게 됩니다. 자체 서비스 로직 에서는 이 정보를 분석하여 발생된 Alert 를 관리하는 기능을 구현할 수 있습니다. 어떤 감시설정으로 발생된 Alert 인지를 식별할 수 있는 정보입니다. 서비스 로직에서 감시설정, Alert 을 식별하여 처리하는데 필요한 정보 입니다. priod_start, period_end : 감시설정의 조건 쿼리가 실행되는 interval 시간 입니다. 만약 쿼리문에 time range 값이 아래처럼 정의 되어 있고 alert 이 발생된 시점에 time range 를 구하려 한다면 위의 시간 값 만으로는 어렵습니다. "range": { "@timestamp": { "from": "now-30m", "to": "now", "include_lower": true, "include_upper": true, "boost": 1 } } } } Period_start 에 30m을 더하거나 period_end 에서 30m 빼는 방식으로 실제 time range 값을 구할 수 있었습니다. results[0].aggregations.by_agg.buckets 이 값에서는 검색조건 결과에 해당하는 buckets 결과 값을 구체적으로 조회할 수 있습니다. New_alerts : 신규 생성 alert deduped_alerts : 기존 발생된 alert completed_alerts : 완료된 alert 위와 이 서비스 로직에서 alert 의 상태를 구분하여 처리할 수 있습니다. 7. 마치며 이번 글에서는 Alerting Plugin 기능을 큰 카테고리별로 나누어, 주로 OpenSearch Dashboard 를 기반으로 설명했습니다. Alerting Plugin 은 기본적인 API 를 제공하므로, 위에서 다룬 모든 기능은 REST API 를 통해서도 동일하게 활용할 수 있습니다. 따라서 Alerting Plugin 을 탐지 엔진으로 잘 활용한다면, 운영 환경에서 안정적이고 효율적인 탐지 체계를 구축할 수 있습니다.
2025.09.15
다음 슬라이드 보기