기술이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 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
기술이야기 좋은 대시보드(Dashboard) 설계를 위한 4가지 핵심 가이드 기술이야기 좋은 대시보드(Dashboard) 설계를 위한 4가지 핵심 가이드 급변하는 IT 환경에서 우리는 많은 데이터를 접하고 있습니다. 이러한 방대한 데이터를 효율적으로 관리하고 시각화하기 위해 '대시보드'가 등장한 후 널리 활용되고 있습니다. 대시보드(Dashboard)는 필요한 데이터를 통합하여 시각화하는 화면으로, 사용자에게 중요한 정보를 한눈에 보여주는 도구입니다. 2023년 가트너(Gartner) 연구에 따르면, 전 세계 기업 72%가 데이터 시각화 도구를 사용하고 있기도 합니다. 데이터 시각화 도구를 활용한 기업이 비활용 기업에 비해 의사 결정 속도가 5배 빠르다는 연구 결과도 나왔죠. 그렇다면 기업운영에 있어 대시보드가 왜 중요한지, 좀 더 자세히 살펴보겠습니다. │대시보드(Dashboard), 왜 중요할까요? 대시보드가 중요한 이유는 여러 가지 있지만, 그중에서도 가장 핵심적인 이유는 다음과 같습니다. 첫째, 대시보드는 빠르고 정확한 의사 결정을 가능하게 합니다. 대시보드는 실시간으로 데이터를 시각화하고 중요한 정보를 즉각적으로 제공하여, 빠르고 정확한 의사 결정을 가능하게 합니다. 예를 들어 서버의 성능 문제나 네트워크 장애를 실시간으로 감지하고 즉각적으로 대응할 수 있습니다. 이는 기업이 비즈니스 연속성을 유지하고, 예기치 않은 문제로 인한 손실을 최소화할 수 있게 도와주죠. 둘째, 대시보드는 전체적인 상황을 한눈에 파악할 수 있게 합니다. 여러 출처에서 수집된 데이터를 하나의 화면에 통합하여 보여주기 때문에, 전체적인 상황을 한눈에 파악할 수 있습니다. 이를 통해 데이터 간의 관계를 쉽게 분석하고, 복잡한 문제를 효율적으로 해결할 수 있죠. 이는 전략적 계획 수립과 운영 효율성을 높이는 데 매우 중요한 역할을 합니다. 위에서 살펴본 두 가지 핵심 이유로 인해서 대시보드는, 기업의 비즈니스 경쟁력 확보를 위한 핵심 도구로 자리 잡고 있습니다. │어떤 종류의 대시보드가 있을까요? 대시보드 종류는 매우 다양한데요. IT 인프라 통합 관리 대시보드 기준에서, 대표적으로 세 가지 대시보드 유형을 살펴보겠습니다. 서비스형 대시보드 [그림] Zenius 서비스형 대시보드 일반적으로 많이 사용하는 서비스형 대시보드는 IT 서비스 성능 상태를 실시간으로 모니터링할 수 있게 도와줍니다. CPU, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등을 한눈에 확인할 수 있죠. 이를 통해 성능 저하나 장애가 발생하면 즉각 알림을 받아 빠르게 대응할 수 있습니다. 또한 클라우드와 온 프레미스 환경 모두 사용 가능해 유연성이 뛰어납니다. 지도형 대시보드 [그림] Zenius 지도형 대시보드 지도형 대시보드는 여러 지역에 분산된 IT 인프라를 한 지도에서 통합적으로 보여줍니다. 서버, 데이터 센터, 네트워크 장비 위치와 상태를 지도 위에 표시해 한눈에 파악할 수 있죠. 이때 특정 지역에서 문제가 발생하면 즉시 감지하고 대응할 수 있습니다. 또한 지리적 데이터를 바탕으로 장애 패턴을 분석하여 효율적인 관리가 가능하며, 실제 지리 정보 시스템(GIS)와 연동해 정교한 위치 기반 관리도 가능합니다. 이러한 기능 덕분에 이 대시보드는, 특히 글로벌 기업이나 여러 지사와 데이터 센터를 운영하는 조직에서 유용하게 사용됩니다. 구성도형 대시보드 [그림] Zenius 구성형 대시보드 구성도형 대시보드는 네트워크 자원의 상태와 관계를 시각적으로 표현해 줍니다. 이를 통해 네트워크 장비 간의 트래픽 흐름을 실시간으로 모니터링하고, 병목 지점이나 장애 발생 지점을 쉽게 찾아낼 수 있습니다. 또한 각 장비의 상태, 성능 지표, 로그 데이터를 시각적으로 제공해 문제를 조기에 발견하고 해결할 수 있도록 도와줍니다. 더 나아가 네트워크 트래픽을 분석해 최적화 방안을 도출할 수 있으며, 다양한 네트워크 인프라를 지원해 유연한 관리가 가능합니다. 하지만 이러한 대시보드는 '어떻게 구현하고 설계했느냐'에 따라서 좋은 대시보드가 될 수도, 그렇지 못할 수도 있는데요. 그렇다면 좋은 대시보드를 만들기 위해 어떤 점을 고려해야 할까요? 다음 내용을 통해 자세히 살펴보겠습니다. │좋은 대시보드를 만들기 위한 고려사항 핵심 데이터 우선 제공 우선 좋은 대시보드를 만들기 위해 가장 먼저 고려해야 할 점은, 시각화할 대상과 데이터를 명확히 파악해야 한다는 것입니다. 어떤 데이터가 가장 중요한지, 결정하는 것이 우선이죠. 반대로 너무 많은 데이터를 시각화하지 않도록 주의해야 합니다. 과도한 데이터 시각화는 사용자가 중요한 정보를 파악하는 데 어려울 수 있습니다. 따라서 핵심 데이터를 선별하여 우선적으로 표시해야 합니다. 좀 더 구체적인 사례를 통해 살펴볼게요. 대시보드는 서버, 네트워크, DB 등 기본 인프라 데이터를 수집하고 시각화해야 하는데요. 이 데이터는 CPU, 메모리, bps, 스토리지, 데이터 파일 등과 같이 시스템 성능과 운영 상태를 파악하는 필수적인 핵심 지표들입니다. 이러한 핵심 데이터를 명확하게 정의하고 제공하는 것은 대시보드 설계의 첫 번째 단계에서 중요한 요소이죠. [그림] Zenius 서비스형 대시보드 Zenius 대시보드는 이러한 기본 인프라 데이터를 우선적으로 수집하고 시각화하여, 사용자가 가장 중요한 정보를 빠르게 파악할 수 있도록 합니다. 사용자가 어떤 데이터를 가장 먼저 확인해야 하는지, 즉 우선순위를 명확히 하여 중요한 정보를 놓치지 않도록 도와주죠. 효율적이고 직관적인 정보 전달 좋은 대시보드를 만들기 위해 두 번째로 고려해야 할 점은, 사용자가 필요한 정보를 쉽고 빠르게 확인할 수 있도록 설계되어야 합니다. 데이터의 가독성을 높이는 색상과 그래픽 요소를 적절히 사용하여, 사용자 인터페이스가 직관적이고 사용하기 쉬워야 합니다. 여기서 유의할 점은 시각적 요소에 너무 몰두하지 않도록 주의해야 합니다. 디자인에만 집중하면 필요한 정보가 제대로 전달되지 않을 위험이 있기 때문이죠. 따라서 실용성과 사용성을 중시하여 사용자 중심의 인터페이스를 설계해야 합니다. 이번에도 대시보드 사례를 통해 구체적으로 살펴볼게요. Zenius는 '사용자 맞춤형 대시보드'를 제공하고 있는데요. 사용자의 모니터링 환경에 맞게 자유롭게 편집할 수 있습니다. 관리 대상이 많아지거나, 관리 목표를 변경해도 컴포넌트와 디스플레이 항목을 손쉽게 편집할 수 있습니다. 또한 Zenius의 직관적이고 유연한 편집 기능을 통해, 사용자에게 필요에 따라 색상이나 차트 유형을 쉽게 변경할 수 있도록 설계했습니다. 데이터를 가독성 있게 시각화하여 사용자가 인터페이스 직관적이고 사용하기 쉽도록 구성했죠. 외부 데이터 통합 좋은 대시보드를 만들기 위해 세 번째로 고려해야 할 점은, 기업 내 여러 솔루션의 핵심 지표를 한 화면에서 확인할 수 있도록 구성해야 합니다. 외부 데이터와의 연동으로 여러 시스템의 데이터를 통합하면, 전체 상황을 한눈에 파악할 수 있는데요. 이를 통해 분석과 의사결정을 용이하게 해줍니다. Zenius 사례를 통해 다시 한번 살펴보겠습니다. Zenius 대시보드는 3rd Party 시스템 연동을 통해, 외부 데이터를 통합하여 한 화면에서 핵심 지표를 확인할 수 있도록 설계했습니다. 이를 통해 사용자가 기업 내 다양한 솔루션 지표를 한눈에 파악할 수 있죠. 비즈니스 전반의 통합 관제 좋은 대시보드를 만들기 위해 네 번째로 고려해야 할 점은, 비즈니스 관점에서 모니터링과 이상 상황을 감지할 수 있도록 설계되어야 합니다. 조직의 전반적인 운영 상태를 실시간으로 파악하고, 문제 발생 시 신속하게 대응해야 하기 때문이죠. 또한 서비스 단위로 인프라를 구성하여, 비즈니스 문제 여부를 즉각적으로 파악할 수 있도록 해야 합니다. 다시 Zenius 사례를 통해 살펴볼게요. Zenius 대시보드는 수집된 다양한 정보를 바탕으로, 최상위 레벨에서 비즈니스 관점 모니터링과 이상 상황을 감지할 수 있는 화면을 제공합니다. 다양한 컴포넌트와 차트, 다이나믹한 요소들을 적용하여 시각적인 효과를 극대화할 수 있죠. 이번 시간에는 대시보드가 왜 필요한지, 좋은 대시보드를 구현하기 위해서는 어떠한 점들을 고려해야 하는지 알아보았습니다. 하지만 이러한 좋은 대시보드를 성공적으로 구현하기 위해서는, 전문가의 도움이 필요합니다. 데이터를 시각화하여 구성하는 것은 보는 이에 따라 관점이 다르고 다양하여, 하나부터 열까지 구성하는 것이 어려울 수 있기 때문이죠. 또한 조직 상황이나 사용자 관점마다 중요한 데이터가 다르고 시각화해야 하는 방식도 다를 수 있습니다. 따라서 제니우스(Zenius)와 같이 수많은 구축 노하우를 보유하고 있고, 고객의 상황에 따라 최적화된 대시보드 구현이 가능한 솔루션 활용을 통해 비즈니스 경쟁력을 확보하시기 바랍니다. ?더보기 Zenius Dashboard 더 자세히 보기 2024.07.26
기술이야기 ICMP와 SNMP를 비롯한 NMS의 구성요소와 주요 기능은? 기술이야기 ICMP와 SNMP를 비롯한 NMS의 구성요소와 주요 기능은? 지난 포스팅을 통해서 NMS의 기본 개념과 시대별 변화, 그리고 활용 사례 등을 살펴보았는데요. 오늘은 ICMP와 SNMP를 비롯한 NMS의 구성 요소와 주요 기능에 대해서 자세히 알아보겠습니다. 。。。。。。。。。。。。 │ NMS(네트워크 관리 시스템)의 구성 요소와 역할 NMS의 구성 요소와 역할은 크게 다섯 가지로 나눌 수 있습니다. NMS Manager NMS Manager는 Managed Device를 모니터링하고 제어하는 역할을 합니다. SNMP, ICMP, RMON 등의 망 관리 프로토콜을 이용하여 Managed Device 정보를 수집하며 User Interface도 제공합니다. Management Agent (SNMP Agent) 독자적으로 트래픽을 모니터링하고, 통계 정보를 자신의 MIB에 저장해 두었다가 트래픽 정보 요구나 특정 동작 요청에 응답합니다. 또한 망 관리 프로토콜을 활용하여 Manager에게 관리 정보를 전달합니다. Managed Device 백본, 스위치, 라우터, 허브와 같은 네트워크 장비를 말하며 Management Information을 수집하여 MIB에 보관합니다. MIB (Management Information Base) Managed Device의 정보를 포함한 Database 역할을 수행합니다. 관리되는 정보들을 계층적 트리 구조로 구성되고, 망 관리용 프로토콜인 SNMP 등에 의해서 읽힙니다. SNMP Protocol 네트워크 장치로부터 정보를 수집하여 작업을 수행하는 응용 계층의 프로토콜입니다. MIB에 정의되어 있는 객체들의 OID 값을 전달받아 해당 장비의 상태를 나타냅니다. │ NMS 구성 요소의 상호작용 NMS 구성 요소의 상호 작용을 자세히 살펴보면 각각의 네트워크 장비에는 SNMP Agent가 내장되어 있고, MIB를 이용해 네트워크의 상태 및 구성에 대한 정보를 요청하고 응답받습니다. Agent는 관리 정보를 수집하며, SNMP 프로토콜을 이용하여 NMS Manager와 통신을 합니다. NMS Manager의 Server 단에서는 SNMP가 수집한 데이터를 기반으로 분석, 가공, 성능, 구성, 장애, 보안, 운영 등의 관리 작업을 수행합니다. 또한 DB 단에서는 이벤트 및 로그를 기록하여 문제 해결 및 보고에 사용하는데요. 최종적으로는 User Interface를 통해 운영자가 네트워크 장비들을 효율적으로 모니터링하고 관리하기 위한 가시적인 화면을 제공합니다. │ NMS의 데이터 수집 방식 (관련 프로토콜) NMS는 여러 가지 성능 정보를 수집하여 모니터링하기 위해 다양한 프로토콜을 사용합니다. ① SNMP(Simple Network Management Protocol) 네트워크 장비를 관리하고 모니터링하기 위해 사용되는 인터넷 표준 프로토콜입니다. 네트워크 관리자가 네트워크에 연결된 상태를 확인하고 필요한 경우 설정을 변경할 수 있도록 설계되었고, 대부분 NMS 상에 구현되어 이용되고 있습니다. TCP/IP 기반에서 망관리를 위한 프로토콜이며, 관리 대상과 시스템 간 관리 정보(MIB)를 주고받기 위한 규정입니다. Manager(NMS), Agent, MIB(Management Information Base), Managed Device 등으로 구성됩니다. SNMP의 처리 단계는 Get/Set/Trap의 단순 명령 구조로 구성됩니다. SNMP의 메시지 타입은 Get/Set/Trap의 단순 명령 구조로 구성되는데요, 메세지 타입별 역할은 아래와 같습니다. ② ICMP (Internet Control Message Protocol) IP(Internet Protocol) 네트워크의 기기들이 서로 통신 상태 정보와 오류 메시지를 교환하기 위해 사용하는 네트워크 레벨 프로토콜로, 주로 네트워크 장비와 서버 간의 연결 문제를 진단하고 보고하는 데 사용됩니다. ICMP의 주요 기능은 크게 두 가지입니다. ◾ 오류보고(Error Reporting): 네트워크에서 데이터를 전송하는 동안 발생할 수 있는 여러 종류의 오류를 감지하고, 이에 대한 정보를 송신자에게 알리는 기능 ◾ 진단도구(Diagnostic Functions): 네트워크 연결 문제를 진단하는 데 사용되는 유틸리티(예: ping, traceroute)는 ICMP 메시지를 활용하여 네트워크의 상태를 확인합니다. 이를 통해 네트워크의 연결 상태, 지연 시간, 패킷 손실 등을 평가할 수 있습니다. 먼저 SNMP와 ICMP를 살펴보았는데요, 잠깐 두 가지 방식을 자세히 비교해 보면 SNMP는 장치 모니터링, 구성 변경, 이벤트 알림을 제공하며 주로 관리자 중심의 기능을 수행합니다. 반면 ICMP는 네트워크 통신의 에러 및 상태를 보고하고 호스트 간의 연결성을 테스트하는 데 사용되며, 주로 이벤트 기반 및 연결성 확인을 위한 메시지를 전송하는 데 중점을 둡니다. NMS의 데이터 수집 방식에 대해서 계속 살펴보겠습니다. ③ RMON (Remote Network Monitering) SNMP의 확장 형태로 개발된 RMON은, 분산되어 있는 망에 대한 트래픽을 측정하여 망을 감시하고 분석을 제공하는 프로토콜입니다. 원격에 위치한 Probe에서 망자원의 상태 정보를 수집하여 에러를 방지하고 효율적으로 이용하는 것을 목적으로 합니다. NMS의 대표적인 수집 방식을 살펴보았는데요, 이 외에도 다양한 방식이 있기 때문에 NMS 솔루션은 다양한 방식을 지원하는 것이 중요합니다. (*브레인즈컴퍼니의 Zenius-NMS는 SNMP와 ICMP 외에도 RMON, CDP, LLDP 프로토콜 등 다양한 수집 방식을 지원하고 있습니다.) │ NMS의 경보 알림 연계 방식 네트워크 내의 장애나 이상 상태를 감지했을 때 관리자나 담당자에게 이를 알리는 방법으로, NMS의 핵심이라고 할 수 있습니다. 다양한 경보 알림 방식이 있으며, 각 방식은 특정 상황이나 니즈에 맞게 선택되고 있는데요 가장 대표적인 방식들을 알아보겠습니다. 이메일(E-mail) 알림 네트워크 성능이 저하되는 등의 문제가 발생하면, 이메일 시스템과 연계하여 설정된 이메일 주소로 자동으로 알림을 발송합니다. 문제 발생 시 기록을 남기기 쉽다는 장점이 있지만, 긴급한 문제에는 이메일을 확인하는데 지연이 발생할 수 있습니다. 문자 메시지(SMS) 알림 네트워크의 문제 감지 시, NMS는 사전에 등록된 휴대전화 번호로 경보의 성격과 간단한 설명을 포함한 SMS 메시지를 보냅니다. 신속한 알림이 가능하다는 장점은 있지만, 메시지 길이에 제한이 있다는 단점도 있습니다. 메신저 및 협업 툴을 사용한 알림 최근 많이 사용되는 슬랙, 텔레그램, 팀스, 카카오톡을 통해 네트워크의 이상을 알리는 방식입니다. 문자 메시지와 같이 신속한 알림이 가능하면서 메시지 길이에 크게 제한이 없다는 장점도 있습니다. Dashboard를 통한 이벤트 관제 특정 경보가 발생하면, 웹 기반의 대시보드에 경보 메시지를 포함하여 관리자가 시각적으로 확인할 수 있도록 알립니다. 직관적으로 실시간 네트워크 상태를 모니터링할 수 있는 것이 가장 큰 장점입니다. 서버, 네트워크, 부대설비 모듈을 포함한 Zenius-Dashboard 예시 화면 위와 같이 다양한 알림 연계 방식을 통해, 담당자에게 즉시 장애 처리를 할 수 있도록 지원하는 기능도 중요합니다. NMS에서 즉각적인 장애를 처리하기 위해 제공하는 기능은 다음과 같습니다. ◾ 다중 수신자 지원: 여러 관리자나 담당자에게 동시에 경보를 전송하여 여러 관리자가 신속하게 대응할 수 있게 합니다. ◾ 알림 임계값 설정: 관리자는 경보 발생을 위한 임계값을 설정할 수 있습니다. (예: 특정 장치의 성능이 일정 수준 이하로 떨어질 때 알림을 발생시키도록 설정) ◾ 장애 관리 자동화: 특정 이벤트에 대해 미리 정의된 복구 스크립트 및 시나리오를 통해 장애 감지부터 처리까지의 장애 관리 업무를 자동화할 수 있습니다. NMS의 경보 알림 방식을 살펴보았는데요, 이제 NMS의 주요 기능을 자세하게 알아보겠습니다. │ NMS의 주요 기능 자세히 보기 NMS는 네트워크의 효율성, 가용성, 보안 등을 관리하고 감시하기 위한 다양한 기능을 제공합니다. 보편적으로 NMS에서 제공하는 상세 기능들은 아래와 같이 정리할 수 있습니다. NMS는 장애 관리, 구성 관리, 성능 관리를 중심으로 다양한 세부 기능을 가지고 있습니다. NMS의 많은 기능 중에서도 특히 네트워크 장비들을 실시간으로 모니터링할 수 있는 '성능 관리' 기능과, 성능 저하 또는 병목 현상을 빠르게 식별하여 해결할 수 있는 '장애 관리' 기능이 중요합니다. │ NMS의 발전 방향 NMS는 복잡하고 빠르게 변화하는 기술 트렌드에 맞춰 지속적으로 발전하고 있습니다. 클라우드, 가상화, 5G, IoT와 같은 기술의 발전에 따라서 사용자에게 높은 품질의 서비스를 제공하기 위한 방향으로 진화하고 있습니다. 온 프레미스와 클라우드의 조화 온 프레미스 환경은 보안, 규정 준수, 네트워크 제어와 같은 니즈 때문에 여전히 중요한 역할을 하고 있습니다. 반면 클라우드 기반 NMS 솔루션은 비용 효율성, 안정성, 용이한 배포와 같은 이점을 제공하는데요. 따라서 NMS도 온 프레미스와 클라우드의 장점을 조화롭게 포함하며 발전하고 있습니다. 클라우드 네이티브 환경으로의 진화 기업과 기관들이 클라우드 서비스를 적극적으로 채택함에 따라 NMS는 클라우드의 유연성, 확장성, 효율성을 극대화하는 등 클라우드 환경에 더욱 적합한 구조로 발전하고 있습니다. 분산형 아키텍처와 기술 혁신 최근의 NMS는 중앙 집중식에서 벗어나 더욱 분산된 아키텍처를 채택하고 있습니다. 마이크로 서비스 아키텍처(MSA)를 통해 모듈화되고 유연한 시스템 구조를 도입하여, 필요한 기능을 쉽게 추가하거나 변경할 수 있습니다. 또한 AI 기반의 NMS는 네트워크 데이터를 분석하고, 문제의 예측 및 해결 능력 향상에 기여하고 있습니다. 이 밖에도 NMS는 5G와 IoT 등의 신기술에 효과적으로 대응하기 위해 지속적으로 발전하고 있습니다. 。。。。。。。。。。。。 NMS의 구성 요소와 주요 기능 그리고 발전 방향에 대해서 살펴봤습니다. NMS 솔루션을 선택할 때는 기본적인 기능을 잘 갖추고 있을 뿐 아니라, 혁신적인 기술과 트렌드를 적극적으로 채택하고 지속적인 연구와 개선을 지속하는 기업의 솔루션을 선택해야 합니다. 안정적인 네트워크 운영은 이제 비즈니스의 필수 요소입니다. 성공적인 NMS 솔루션 선택을 통해 네트워크 성능을 극대화하여 비즈니스의 경쟁력을 확보하시기 바랍니다! 2024.02.08

1