반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
클라우드(Cloud) 관리와 AWS가 뭔가요?
[행사] 브레인즈컴퍼니 전략사업본부 ‘happy 호프데이’
이화정
2023.11.17
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[전시회] ‘CDA 컨퍼런스’를 통해 해법을 제시한 브레인즈컴퍼니
지난 11월 01일 수요일, 전략사업본부에서
깜짝 호프데이
가 열렸어요? 브레인즈컴퍼니의 전략사업본부에서 화합의 장을 도모하기 위해 주최하게 된 것인데요.
이처럼 브레인즈컴퍼니는
‘임직원들이 행복하게 일하는 환경’을 중요
하게 생각하고 있어요. 업무에 지쳐있다 싶을 때쯤! 호프데이와 같은 이벤트를 꾸준히 진행하고 있죠.
브레인저분들과 맛있는 음식도 먹으며 '술'이라는 매개체를 통해, 조금은 흐트러지고 편한 모습으로 함께 했어요. 특히 다른 팀원 분들과 릴레이식 인사를 하며 가까워질 수 있던 기회이기도 했답니다.
분위기가 무르익어가고 얼굴도 익어갈 때쯤(?) 소소한 경품 이벤트 시간을 가졌어요. 브레인즈컴퍼니는 선물에 진심이니까요! 추첨식 상품 게임, 가위바위보 게임, 테이블당 팀별로 퀴즈 또한 진행했는데요. 행사의 열기가 더 뜨겁고 화기애애 진 것 같아요?
일과를 마치고 조금은 지칠 수 있던 시간이었지만 맥주와 맛있는 음식, 그리고 그 무엇보다 ‘브레인저’와 함께해서 더 소중했던 수요일 저녁 밤이었어요.
앞으로도 브레인즈컴퍼니는, 임직원 여러분들이 행복하게 일할 수 있는 환경을 제공할 수 있도록 지속적으로 노력할게요!
#호프데이
#사내문화
#행사
#이벤트
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
효과적인 쿠버네티스 모니터링을 위한 6가지 고려사항
효과적인 쿠버네티스 모니터링을 위한 6가지 고려사항
컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes, K8s)는 자동화된 확장성과 자가 복구 기능을 통해 서비스의 안정성과 운영 효율성을 높이는 장점이 있습니다. 따라서 다양한 마이크로서비스 아키텍처(MSA)와 클라우드 환경에서 널리 활용되고 있습니다. 그러나 쿠버네티스는 파드(Pod), 노드(Node), 네트워크 등 각 요소가 끊임없이 동적으로 변화하며 상호작용하는 복잡한 구조이기 때문에, 체계적이고 세밀한 모니터링 없이는 운영에 어려움을 겪을 수 있습니다. 그렇다면 효과적인 쿠버네티스 모니터링을 위한 필수 고려사항은 무엇인지 6가지로 나눠서 알아보겠습니다. [1] 파드 및 컨테이너 모니터링 파드(Pod)와 컨테이너는 쿠버네티스에서 애플리케이션이 실행되는 가장 기본적인 단위이자 핵심 구성 요소입니다. 따라서 애플리케이션의 가용성과 성능을 안정적으로 유지하기 위해서는 각 파드와 컨테이너의 상태를 정밀하게 모니터링 하는 것이 중요합니다. 파드가 제대로 스케줄링되지 않거나, 컨테이너가 크래시 루프(CrashLoopBackOff) 상태에 빠지면 애플리케이션 성능이 저하되거나 서비스가 중단될 수 있습니다. 이러한 문제를 사전에 방지하려면 각 파드의 CPU, 메모리 사용량, 네트워크 I/O와 같은 자원 사용 현황을 실시간으로 모니터링하는 체계가 필요합니다. 특히, 자원 사용량을 지속적으로 추적하여 비정상적인 사용 패턴이나 과부하 상태를 사전에 감지하는 것이 중요합니다. 또한, 쿠버네티스의 오토스케일링(Auto-Scaling) 기능과 연계된 모니터링 솔루션을 통해 파드가 실시간 트래픽 변화에 맞춰 자동으로 확장 또는 축소될 수 있도록 설정하는 것이 자원 효율성 측면에서도 유리합니다. 이와 같은 종합적인 모니터링 솔루션은 파드와 컨테이너의 상태 변화에 대한 정확한 정보를 제공하고, 문제가 발생하기 전에 이를 사전에 탐지하고 대응할 수 있는 능력을 제공합니다. [2] 클러스터와 노드 상태 모니터링 쿠버네티스 클러스터는 다수의 노드로 구성된 분산 시스템으로, 각 노드는 파드(Pod)를 실행하는 주체로서 클러스터 전반의 성능과 안정성에 중요한 영향을 미칩니다. 각 노드의 CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 주요 리소스 사용량을 실시간으로 모니터링함으로써 리소스 과부하나 잠재적 장애를 사전에 감지하고 예방할 수 있습니다. 특히, 노드 간 리소스 사용의 불균형은 클러스터 전체 성능에 부정적인 영향을 미칠 수 있으며, 특정 노드에서 발생하는 비정상적인 리소스 소모는 장애의 전조로 볼 수 있습니다. 예를 들어, CPU나 메모리 자원의 지속적인 고갈, 네트워크 트래픽의 급격한 증가 등은 장애를 유발할 수 있는 주요 지표로, 이를 사전에 감지하고 신속하게 대응하는 것이 중요합니다. 이를 위해 각 노드의 메트릭 데이터를 분석하고, 비정상적인 패턴을 자동으로 탐지할 수 있는 쿠버네티스 모니터링 솔루션을 도입하는 것이 필요합니다. 이러한 솔루션은 클러스터 내 모든 노드의 상태를 실시간으로 모니터링하고, 비정상적인 리소스 사용을 빠르게 인식할 수 있게 해줍니다. 또한, 자동화된 경고 시스템을 통해 잠재적인 문제가 발생하기 전에 관리자에게 즉시 알림을 제공하며, 리소스 사용 추세를 기반으로 한 예측 분석 기능을 통해 향후 발생할 수 있는 문제를 미리 방지할 수 있도록 지원합니다. [3] 네트워크 모니터링 쿠버네티스는 내부 네트워크와 외부 네트워크 간 통신이 빈번하게 이루어지는 복잡한 분산 시스템입니다. 파드 간의 통신 오류나 클러스터 외부와의 연결 문제는 애플리케이션 성능 저하로 이어질 수 있기에, 네트워크 상태를 정밀하게 모니터링해야 합니다. 주요 모니터링 지표로는 네트워크 지연(latency), 패킷 손실(packet loss), 네트워크 인터페이스 속도와 대역폭 등이 있으며, 이러한 지표들은 애플리케이션 가용성과 성능에 직접적인 영향을 미칠 수 있습니다. 특히 서비스 메시(Service Mesh)와 같은 고급 네트워크 구성 요소를 도입한 환경에서는 네트워크 복잡성이 더욱 증가하므로, 네트워크 트래픽 경로를 시각화하고 트래픽 흐름을 분석할 수 있는 고도화된 모니터링 솔루션이 필요합니다. 이러한 시스템을 통해 비정상적인 트래픽 패턴이나 병목 현상을 사전에 감지하고, 네트워크 문제를 신속하게 해결할 수 있는 역량을 확보하는 것이 중요합니다. 특히, 네트워크 모니터링은 전체 클러스터의 안정성과 애플리케이션 성능을 보장하는 데 중요한 역할을 합니다. [4] 로그 및 메트릭 수집과 분석 모니터링의 핵심은 적절한 로그와 메트릭 데이터를 수집하고 이를 분석하여 시스템 상태를 지속적으로 파악하는 데 있습니다. 쿠버네티스는 클러스터 내에서 발생하는 다양한 이벤트를 로그로 기록하고, 각 파드, 컨테이너, 노드에서 발생하는 자원 사용량과 성능 관련 데이터를 메트릭으로 제공합니다. 이러한 로그와 메트릭을 실시간으로 수집하고 분석함으로써, 문제가 발생했을 때 그 원인을 빠르게 파악하고 대응할 수 있습니다. 예를 들어, 특정 파드에서 반복적으로 발생하는 에러 로그는 애플리케이션의 특정 기능이 문제가 있음을 시사하며, 이를 통해 운영자는 그 원인을 정확히 파악할 수 있습니다. 또한, 성능 저하가 발생할 때 메트릭 데이터를 분석하여 CPU, 메모리, 네트워크 등 리소스 부족이 원인인지 식별할 수 있습니다. 이러한 정보가 실시간으로 제공되기 때문에, 운영자는 문제를 조기에 발견하고 빠르게 대응할 수 있으며, 그 결과 시스템 장애나 성능 저하를 미연에 방지할 수 있습니다. 또한, 실시간으로 로그와 메트릭 변화를 추적하고 모니터링 솔루션의 경고 알림 기능 등을 활용하면, 문제를 사전에 예측하고 조치를 취할 수 있습니다. [5] 자동화 기능과의 긴밀한 연동 쿠버네티스의 주요 기능 중 하나는 자동화된 확장과 자가 치유(Self-Healing) 기능으로, 이를 통해 클러스터의 안정성과 가용성을 유지할 수 있습니다. 자동화된 확장은 클러스터 상태를 실시간으로 모니터링하여 자원이 부족할 때 자동으로 새로운 파드를 생성하고, 부하를 분산함으로써 성능 저하를 방지합니다. 또한 자가 치유 기능은 장애가 발생한 파드나 노드를 감지하여, 파드를 자동으로 재시작하거나 장애가 발생한 파드들을 다른 건강한 노드로 이동시키는 역할을 합니다. 이러한 기능이 원활하게 작동하려면, 모니터링 솔루션이 클러스터의 상태를 정확하게 파악하고, 자원 사용 현황 및 노드 상태에 대한 신뢰할 수 있는 데이터를 제공해야 합니다. 이를 위해 모니터링 솔루션은 높은 확장성과 안정성을 보장할 수 있는 설정이 필수적입니다. 예를 들어, 파드의 자원 부족이 발생하면 이를 실시간으로 감지하여 적절한 확장 작업이 즉시 이루어질 수 있도록 지원해야 합니다. 결과적으로, 쿠버네티스의 자동화 기능이 성공적으로 활용되려면 쿠버네티스 모니터링 솔루션과의 긴밀한 연동이 반드시 필요합니다. [6] 보안 및 규정 준수 분산 아키텍처를 기반으로 하는 쿠버네티스 클러스터는 외부 공격에 더욱 취약할 수 있으며, 다양한 보안 위협에 노출될 가능성이 존재합니다. 이러한 위협을 효과적으로 방어하기 위해서는 네트워크 트래픽 모니터링을 통해 비정상적인 활동이나 의심스러운 트래픽 패턴을 신속히 감지하고, 보안 정책 위반, 의도치 않은 구성 변경, 혹은 취약점 발견 시 자동으로 경고를 발송하는 보안 모니터링 체계가 필요합니다. 이와 함께, 컨테이너 이미지의 보안 취약점 분석을 사전에 실시하여 악성 코드나 알려진 취약점으로부터 클러스터를 보호하고, 이를 기반으로 하는 보안 스캔 자동화가 중요합니다. 또한, 클러스터 전반에서 발생하는 모든 활동을 실시간으로 감사(Audit) 및 기록하여 컴플라이언스 요구사항을 충족시키는 중앙 집중형 로그 관리 시스템이 필요합니다. 이러한 감사 로그는 규정 준수를 위한 기본적인 요소일 뿐만 아니라, 보안 사고 발생 시 원인 분석 및 대응을 위한 핵심 자료로 활용될 수 있습니다. 쿠버네티스와 같은 분산 시스템을 성공적으로 운영하기 위해서는 그 안에서 발생하는 다양한 이벤트를 실시간으로 모니터링하는 것이 매우 중요합니다. 6가지 고려사항을 통해 클러스터의 상태를 세밀하게 추적하고 분석함으로써, 예상치 못한 문제를 미리 발견하고 대비할 수 있습니다. 특히, 노드나 파드의 자원 소모가 비정상적으로 급증할 때 이를 빠르게 인식하고 조치를 취함으로써, 시스템의 성능 저하를 방지할 수 있습니다. 또한, 네트워크 상태와 보안 위협에 대한 철저한 모니터링은 전체 서비스의 가용성을 높이는 데 큰 도움이 됩니다. 이처럼 체계적인 모니터링 전략을 통해 쿠버네티스 환경에서의 안정성을 확보할 수 있으며, 서비스 중단 없이 원활한 운영을 이어갈 수 있습니다.
2024.10.24
서버 모니터링의 두 가지 방식
서버 모니터링의 두 가지 방식
이번 블로그에서는 일반적으로 서버 모니터링 소프트웨어들이 널리 쓰고 있는 서버 모니터링의 두 가지 방식에 대해서 논의하고 그 차이점을 알아보겠습니다. 지난 블로그에서 언급했듯이, 서버 모니터링은 컴퓨터 서버의 성능을 관찰하고 분석해 최적의 상태로 실행되고 있는지 확인하는 작업입니다. 이 프로세스에는 일반적으로 CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 및 응용 프로그램 성능과 같은 다양한 메트릭에 대한 데이터를 수집하는 소프트웨어 도구의 사용이 포함됩니다. 서버 모니터링 소프트웨어는 데이터 수집 후 추세, 패턴 및 이상 현상을 식별하기 위해 데이터를 분석합니다. 분석을 통해 잠재적인 문제가 심각해지기 전에 식별하고 서버 관리자가 시정 조치를 취할 수 있도록 합니다. 예를 들어, CPU 사용률이 지속적으로 높은 경우 서버의 성능이 부족해 더 많은 리소스를 할당해야 할 수 있음을 나타낼 수 있습니다. 또는 디스크 I/O가 느린 경우 서버의 저장소가 과부하됐거나 최적화가 필요함을 나타낼 수 있습니다. 서버 모니터링 소프트웨어에는 관리자가 서버 성능을 파악하는데 도움이 되는 대시보드, 경고 및 보고 기능이 포함되는 경우가 많습니다. 대시보드는 핵심 성과 지표의 실시간 보기를 제공하는 동시에 특정 임계값을 초과하거나 문제가 감지되면 관리자에게 알림을 보냅니다. 서버 관리자는 보고 기능을 통해 시간 경과에 따른 성능 추세 및 문제에 대한 보고서를 생성할 수 있으며, 이를 통해 용량 계획 및 리소스 할당 결정을 알리는데 사용할 수 있습니다. 서버 모니터링은 일반적으로 에이전트 없는 서버 모니터링과 에이전트 기반 서버 모니터링, 이 두 가지 주요 접근 방식이 있습니다. 두 가지 모두 장단점이 있으며 어떤 것을 선택하느냐는 특정 요구 사항과 선호도에 따라 달라집니다. 에이전트 기반 서버 모니터링 에이전트 기반 서버 모니터링에는 모니터링하려는 각 서버에 ‘에이전트’라고 하는 별도의 서버용 모니터링 소프트웨어를 설치해 데이터를 수집하는 방식을 말합니다. 에이전트는 서버에서 다양한 성능 메트릭에 대한 데이터를 수집해 모니터링 시스템으로 다시 보냅니다. 이 접근 방식은 에이전트 없는 모니터링보다 더 상세하고 세분화된 데이터와 기능을 제공합니다. 또, 데이터를 암호화하고 보안 채널을 사용해 데이터를 전송하므로 일반적으로 에이전트 없는 모니터링보다 더 안전합니다. 에이전트 기반 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 성능 모니터링: 에이전트는 CPU, 메모리, 디스크 사용률, 네트워크 트래픽 등의 정보를 수집할 수 있습니다. 이를 이용해 서버의 성능을 모니터링하고, 부하가 높아지면 적시에 대처할 수 있습니다. ∙ 로그 모니터링: 에이전트는 서버에서 발생하는 로그를 수집할 수 있습니다. 이를 이용해 서버에서 발생한 이벤트의 원인 파악에 도움을 줄 수 있습니다. ∙ 보안 모니터링: 에이전트는 서버 내부의 보안 상태를 모니터링할 수 있습니다. 예를 들어, 악성 코드 감지, 사용자 로그인 상태, 파일 권한 등을 체크해 보안 위협을 조기에 감지할 수 있습니다. ∙ 애플리케이션 모니터링: 에이전트는 서버에 설치된 애플리케이션의 상태를 모니터링할 수 있습니다. 예를 들어, 웹 서버에서는 HTTP 요청, 응답 코드, 응답 속도 등을 모니터링해 애플리케이션의 상태를 파악할 수 있습니다. ∙ 자동화된 조치: 에이전트는 모니터링 데이터를 기반으로 자동화된 조치를 수행할 수 있습니다. 예를 들면, CPU 부하가 높아지면 자동으로 스케일 업 또는 스케일 아웃을 수행할 수 있습니다. 에이전트 리스 서버 모니터링 에이전트가 없는 서버 모니터링은 서버 자체에 소프트웨어를 설치할 필요가 없습니다. 대신 모니터링 소프트웨어가 별도의 서버나 워크스테이션에 설치되고, SNMP 또는 WMI와 같은 네트워크 프로토콜을 사용해 대상 서버에서 데이터를 원격으로 수집합니다. 이 접근 방식은 각 서버에 소프트웨어 에이전트를 설치하고 관리할 필요가 없어 일반적으로 설정 및 유지 관리가 더 쉽고 빠릅니다. 또, 에이전트 기반보다 같은 자원을 이용해서 더 많은 수의 서버를 모니터링할 수 있어 경제적입니다. 대신 기능이 제한적이고 프로토콜이 의존해 데이터를 수집하기 때문에 보안 문제가 발생할 수 있습니다. 에이전트 리스 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 원격 모니터링: 에이전트 없는 모니터링 도구는 원격 데이터 센터, 지사 또는 클라우드 환경에 있는 서버를 포함해 모든 곳에 있는 서버를 원격으로 모니터링할 수 있습니다. 이러한 유연성을 통해 조직의 전체 서버 인프라를 중앙집중식으로 모니터링하고 관리할 수 있습니다. ∙ 확장성: 에이전트 없는 모니터링은 서버 인프라 또는 워크로드 요구사항의 변화를 수용하기 위해 쉽게 확장 또는 축소할 수 있습니다. 추가 에이전트 소프트웨어 설치 또는 구성 없이 모니터링 시스템에 추가 서버를 추가할 수 있습니다. ∙ 포괄적인 모니터링: 에이전트 없는 모니터링은 서버 성능 메트릭을 추적하고 문제를 식별하며, 실시간 경고를 제공함으로써 관리자가 서버 인프라의 상태를 유지하고 중요한 애플리케이션과 서비스가 원활하게 실행되도록 합니다. ∙ 손쉬운 유지 관리 및 업데이트: 에이전트 없는 모니터링을 사용하면 모니터링 되는 각 시스템에서 에이전트 소프트웨어를 관리하고 업데이트할 필요가 없습니다. 이는 유지보수를 단순화하고 모니터링 시스템을 항상 최신 상태로 유지합니다. Zenius(제니우스)의 서버 모니터링 브레인즈컴퍼니의 지능형 IT 인프라 통합관리 소프트웨어 ‘Zenius(제니우스)’는 고객의 시스템 상황에 따라 에이전트 기반 및 리스 방식 모두 가능합니다. 에이전트 기반의 통합 모니터링 소프트웨어 ‘Zenius SMS’는 HTML5 기반 Web UI와 토폴로지 맵을 통해 서버 성능과 상태 및 서버 간 연관관계를 직관적으로 파악합니다. 특히, Zenius SMS는 애플리케이션 단위에 성능이나 로그를 세밀하게 모니터링 및 분석이 가능합니다. Zenius SMS의 주요 기능은 아래와 같습니다. Zenius SMS의 주요 서버 모니터링 기능 1. 프로세스: 프로세스 상태(Up/Down) 및 성능 모니터링(CPU/MEM) 2. 로그: 프로세스나 시스템 로그와 같은 각종 로그 모니터링 3. GPU: GPU의 상태 및 성능 모니터링 4. 보안: 서버의 보안 취약점 점검 5. 자동화: 모니터링 데이터를 기반으로 자동화된 조치 수행 6. 기타: 코어별 온도 모니터링, 서비스 포트별 네트워크 상태, S/W 목록, 환경변수, 계정, 그룹, 스케쥴링, 공유폴더 현황 등 ‘Zenius SMS’ 도입을 통해 체계화된 서버 통합관리를 할 수 있습니다. 반복적이고 수동적인 업무는 자동화돼 업무 효율성을 향상시키며, 객관적인 데이터를 기반으로 정확한 성능 현황 및 비교분석이 가능합니다. 이는 곧 서비스 연속성 확보로 이어지며, 향후 고객 만족도 향상을 기대할 수 있습니다. 반면, 고객 서버에 에이전트 탑재가 불가능한 경우에는 에이전트 리스 방식으로도 사용 가능합니다. 브레인즈컴퍼니의 에이전트 리스 제품으로는 ‘Zenius VMS’가 있습니다. ‘Zenius VMS’는 VMware, Citrix Xen Server, Hyper-V와 같은 서버 가상화 환경에서 호스트 서버와 게스트 서버의 리소스 할당 및 사용 현황, 관계 등을 통합적으로 관제합니다. ‘Zenius VMS’는 프라이빗 클라우드 환경을 모니터링하는데 효과적입니다. Open API로 프라이빗 클라우드 인프라와 통신해, 가상머신의 상태 및 성능, 스토리지 활용도 및 네트워크 트래픽과 같은 환경의 다양한 측면에 대한 데이터를 수집합니다. 수집된 데이터를 분석해 잠재적 문제를 나타낼 수 있는 경향, 패턴 및 이상 현상을 식별하고, 크게 CPU, 메모리, 디스크, MIB 이 4가지 정보를 기본적으로 제공합니다. ‘Zenius VMS’는 VM 상세 관리를 위해 SMS 추가 확장이 용이한 제품입니다. VMS를 통해 호스트-게스트 간 연관관계 기반의 모니터링을 시행하고, 별도로 가상화 서버에 SMS 모듈을 추가해 보다 다양한 모니터링 항목으로 정밀하게 관리함으로써 효과적인 통합관리 환경을 조성할 수 있습니다.
2023.05.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
다음 슬라이드 보기
