|

[Aruba DevNet 4강] Central Webhook과 Slack의 만남

⏱️ 예상 읽기 시간: 약 16분 (16 min read)

네트워크 엔지니어의 숙명은 ‘장애와의 싸움’입니다.
하지만 새벽에 걸려오는 전화를 받고 나서야 장애를 인지한다면 이미 늦은 것이겠죠.

오늘은 Aruba Central의 Webhook 기능을 활용해, 특정 이벤트(AP Down, 스위치 포트 에러 등)가 발생하면 즉시 슬랙(Slack)으로 알림을 쏴주는 지능형 관제 시스템을 구축해 보겠습니다.


Webhook(웹훅)이란 무엇인가?

많은 분이 API와 Webhook을 혼동하시곤 합니다. 가장 쉬운 차이는 “누가 먼저 말을 거는가”입니다.
쉽게 비유하자면, API가 우리가 정보를 물어보는 ‘질문’이라면, Webhook은 장비가 우리에게 알려주는 ‘속보‘입니다.

[Aruba DevNet 4강] Central Webhook과 Slack의 만남 - image 54
  • API: “야, 1번 AP 지금 살아있니?” (주기적으로 계속 물어봐야 함 – Polling)
  • Webhook: (장애 발생 시) “관리자님! 1번 AP가 방금 죽었습니다!” (이벤트 발생 시 즉시 전송)

준비물: 슬랙(Slack) 앱 생성과 Webhook URL

먼저 알림을 받을 슬랙 채널에서 ‘Incoming Webhook’ 설정을 통해 고유 URL을 발급받아야 합니다.

  1. Slack API 포털 접속 > Create New App
  2. Incoming Webhooks 활성화 및 Add New Webhook to Workspace 클릭
  3. 알림을 받을 채널 선택 후 생성된 Webhook URL 복사

실전! Central과 Slack을 이어주는 ‘가교’ 스크립트

Central에서 보낸 Webhook 데이터를 슬랙이 이해할 수 있는 형식으로 변환해주는 간단한 파이썬 서버가 필요합니다.
(회사 보안망 환경을 고려해 윈도우 파이썬에서도 잘 도는 Flask를 활용합니다.)

[webhook_receiver.py]

Python
from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

# ==========================================
# 1. 설정 정보 입력
# ==========================================
# [보안 설정] New Central Webhook 설정 시 입력한 API Key와 동일해야 합니다.
MY_SECRET_API_KEY = "Rubaruba_Secret_999!"

# [슬랙 설정] 발급받은 Slack Webhook URL을 입력하세요.
SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/XXXX/XXXX/XXXX"

@app.route('/central_webhook', methods=['POST'])
def handle_webhook():
    # ==========================================
    # 2. API Key 인증 검증 (보안 로직)
    # ==========================================
    # New Central은 보통 'Authorization' 헤더나 'X-API-Key'에 키를 담아 보냅니다.
    # (환경에 따라 헤더 이름이 다를 수 있으니 필요시 수정하세요)
    received_key = request.headers.get('Authorization')
    
    if received_key != MY_SECRET_API_KEY:
        print(f"❌ 보안 경고: 잘못된 API Key 접근 (입력된 키: {received_key})")
        return jsonify({"error": "Unauthorized"}), 401

    print("✅ 인증 성공! New Central로부터 데이터를 수신했습니다.")

    # ==========================================
    # 3. New Central 페이로드(JSON) 데이터 파싱
    # ==========================================
    payload = request.json
    
    # 전달받은 실제 JSON 구조에 맞춰 필요한 값을 추출합니다.
    alert_name = payload.get("name", "알 수 없는 이벤트")
    severity = payload.get("severity", "Info")
    state = payload.get("state", "Unknown")
    summary = payload.get("summary", "상세 내용 없음")
    device_type = payload.get("deviceType", "Unknown")
    alert_time = payload.get("time", "")

    # 장애 발생 장비의 시리얼 넘버 추출 (리스트 형태이므로 첫 번째 값 추출)
    impacted_entities = payload.get("impactedEntities", {})
    device_serials = impacted_entities.get("deviceSerial", [])
    serial_num = device_serials[0] if device_serials else "N/A"

    # ==========================================
    # 4. 슬랙 알림 메시지 디자인 (Block Kit & Attachments)
    # ==========================================
    # 심각도(Severity)에 따라 슬랙 메시지 왼쪽 띠의 색상을 다르게 지정합니다.
    if severity == "Critical":
        color = "#FF0000"  # 빨강
    elif severity == "Warning":
        color = "#FFA500"  # 주황
    else:
        color = "#36A64F"  # 초록 (정상/기타)
        
    slack_msg = {
        "attachments": [
            {
                "fallback": f"New Central Alert: {alert_name}",
                "color": color,
                "title": f"🚨 [New Central 장애 알림] {alert_name}",
                "fields": [
                    {"title": "심각도 (Severity)", "value": severity, "short": True},
                    {"title": "상태 (State)", "value": state, "short": True},
                    {"title": "장비 유형", "value": device_type, "short": True},
                    {"title": "장비 시리얼", "value": serial_num, "short": True},
                    {"title": "상세 내용 (Summary)", "value": summary, "short": False},
                    {"title": "발생 시간", "value": alert_time, "short": False}
                ],
                "footer": "Rubaruba DevNet Monitoring | egstory.net"
            }
        ]
    }

    # ==========================================
    # 5. 슬랙으로 메시지 전송
    # ==========================================
    response = requests.post(SLACK_WEBHOOK_URL, json=slack_msg)
    
    if response.status_code == 200:
        print("🚀 슬랙으로 알림 전송 완료!")
    else:
        print(f"❌ 슬랙 전송 실패: Code {response.status_code}")

    return jsonify({"status": "success"}), 200

if __name__ == '__main__':
    # 5000번 포트로 서버를 실행합니다.
    app.run(host='0.0.0.0', port=5000)

New Central에서 Webhook 설정하기

이제 Central에게 “장애 나면 저 파이썬 서버 주소로 알려줘!”라고 설정해야 합니다.

  1. Central 접속 > 좌측 메뉴 아이콘 클릭 > API Gateway (API 게이트웨이) 카드 선택
[Aruba DevNet 4강] Central Webhook과 Slack의 만남 - image 55
  1. Webhooks 클릭 > Create Webhook 클릭
  2. 다음 항목들을 입력
  • Name: Webhook 식별 이름 (예: Slack_Alert_Prod)
  • Target URL: 수신 서버 주소 (예: http://your-server-ip:5000/endpoint)
  • Authentication Method: 보안 방식 선택
    – API Key: 시스템 간 간편하고 안전한 인증을 위한 고유 키 사용
    – OIDC: OAuth 2.0 기반의 고수준 보안 인증 (Client ID/Secret 필요)
  1. 다시 좌측 메뉴 아이콘 클릭 > Notification Rules (알람 규칙) 카드 선택
  2. Create Rule (규칙 만들기) 클릭 후, 슬랙으로 알람 받을 이벤트를 선택
[Aruba DevNet 4강] Central Webhook과 Slack의 만남 - image 56
  1. 위에서 생성한 Webhook(Slack_Alert_Prod)을 선택

New Central에서 달라진 Webhook 포인트

New Central로 진화하면서 Webhook은 더욱 강력하고 안전해졌습니다.

항목기존 CentralNew Central (AOS 10)
관리 메뉴Organization > WebhooksAPI Gateway 카드 내 통합 관리
인증 보안단순 Header 토큰API Key 및 OIDC(OpenID Connect) 지원
유연성제한된 이벤트 알림Streaming API 연동 및 서비스 단위 구독 가능
UI/UX리스트 형태의 나열카드 기반의 직관적인 워크플로우

특히 OIDC 인증을 지원하게 된 점은 보안이 까다로운 금융권이나 엔터프라이즈 환경에서도 안심하고 자동화 파이프라인을 구축할 수 있는 기반이 됩니다.


마치며: ‘관제’에서 ‘대응’으로

New Central에서 API Gateway를 통해 Webhook을 관리하게 된 것은 매우 중요한 변화입니다.
이는 네트워크 자동화가 단순한 ‘부가 기능’이 아니라, 인프라 운영의 ‘표준 인터페이스’가 되었음을 의미합니다.

많은 엔지니어가 알람을 받는 것만으로 만족합니다. 하지만 진정한 엔지니어라면 그 다음을 생각해야 합니다.

슬랙 알림 메시지에 ‘장비 재부팅 버튼’을 추가하거나, 알림과 동시에 2강에서 만든 엑셀 리포트를 자동으로 생성해 첨부하게 만든다면 어떨까요? New Central API와 Webhook의 결합은 단순한 모니터링을 넘어 자동화된 운영 시스템의 시작점입니다.

유사 게시물

  • [ACSA 교육#10] 네트워크 장치

    ⏱️ 예상 읽기 시간: 약 9분 (9 min read) 기업 네트워크 환경에는 수백 또는 수천대의 컴퓨터 기기가 각각 다른 네트워크 요소를 사용하여 디지털 통신을 실현합니다. 여기서 오늘 우리는 일반적으로 LAN Campus 네트워크에 배포되는 네트워크 장치를 얘기해볼까 합니다. Layer 2 스위치 Layer 3 라우터 멀티-레이어 스위치…

  • [APSC 교육#2] Aruba Central 기능

    ⏱️ 예상 읽기 시간: 약 6분 (6 min read) 지난 포스팅에서는 Aruba Central에 대한 간단한 소개와 함께 그 기반이 되는 Aruba ESP에 대해 알아보았습니다. 이번 포스팅은 Aruba Central이 제공하는 각각의 기능들은 좀 더 자세히 다뤄보도록 하겠습니다. 엔드-투-엔드 자동화 및 오케스트레이션 수년 동안 네트워킹은 수동적인 방식으로…

  • [ACSA 교육#33] 라우팅

    ⏱️ 예상 읽기 시간: 약 10분 (10 min read) 스위치는 Layer 2 장치이기 때문에 스위치의 포트는 각 VLAN의 구성원(멤버 포트)가 되거나 프레임을 전송하는 등 Layer 2 기능 및 프로토콜만 실행할 수 있습니다. Layer 2 인터페이스로 사용되는 포트에 엔드포인트 단말을 연결하면, 목적지 Layer 2 MAC주소를 기반으로…

  • [Aruba DevNet 1강] 네트워크 엔지니어를 위한 자동화와 IaC 입문

    ⏱️ 예상 읽기 시간: 약 4분 (4 min read) 오늘부터 조금 특별하고, 아주 강력한 기술 연재를 시작해보려 합니다. 바로 ‘Aruba 네트워크 자동화(Network Automation)’ 시리즈입니다. 네트워크 엔지니어들은 현장에서 이런 경험 한 번씩 있지 않으신가요? “50대 스위치 VLAN 설정을 바꿔야 하는데, Putty 창 50개 띄워 놓고 Ctrl+C,…

  • [ACSA 교육#5] TCP/IP Stack

    ⏱️ 예상 읽기 시간: 약 3분 (3 min read) 인터넷 프로토콜 스위트(Suite)은 인터넷과 컴퓨팅 네트워크에서 사용되는 개념적 모델이면서 통신 프로토콜입니다. 이 스위트의 기본 프로토콜이 TCP와 IP이기 때문에 일반적으로 TCP/IP Stack으로 알려져 있습니다. 이 모델은 엔드-투-엔드 데이터 통신을 제공합니다. 데이터 패킷화, 주소 지정, 전송, 라우팅 및…

  • [ACSA 교육#14] AOS-CX 아키텍처

    ⏱️ 예상 읽기 시간: 약 7분 (7 min read) 지난 Aruba 스위치 포트폴리오를 설명하면서 AOS-CX 스위치에 대해 설명한 적이 있습니다. 오늘은 AOS-CX 운영체제 및 스위치에 대한 아키텍처 설명을 드리고자 합니다. AOS-CX 소프트웨어 아키텍처 AOS-CX 스위치는 클라우드 네이티브 운영체제를 탑재하고 있다고 말씀드렸는데요. 이는 많은 중요하고 복잡한…