Quartz 4

프로메테우스-슬랙 연동 핵심 개념

8 min read

🎯 프로메테우스-슬랙 연동 핵심 개념

📑 목차

1. 핵심 개념 요약

한 문장 정리

“쿠버네티스라는 ‘폐쇄된 섬(Internal)‘에 있는 Alertmanager가, 바다 건너 ‘육지(External)‘에 있는 Slack에게 편지를 보내기 위해서는 ‘지도(DNS)‘와 ‘배(Network)‘가 모두 필요하다.”

💡 외부 API 연동의 3대 조건

조건역할실패 시 증상
DNS 해결외부 도메인을 IP로 변환server misbehaving, lookup failed
Network 연결실제 HTTP 요청 전송connection refused, timeout
Pod 상태요청을 보낼 주체가 살아있어야함.Pending, CrashLoopBackOff

2. DNS 문제 (가장 빈번)

🚨 문제 상황

# 전형적인 DNS 오류 로그
level=ERROR source=dispatch.go:363 msg="Notify for alerts failed" 
err="dial tcp: lookup hooks.slack.com on 10.96.0.10:53: server misbehaving"

🔍 원인 분석

  • CoreDNS 설정 문제: 상위 DNS 서버(회사 DNS 등)가 응답하지 않음
  • DNS 캐시 문제: Pod가 잘못된 DNS 정보를 기억하고 있음
  • 네트워크 정책: DNS 쿼리 자체가 차단됨

✅ 해결 방법

A. CoreDNS 설정을 구글 DNS로 변경

# CoreDNS ConfigMap 수정
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        # ... 기존 설정 ...
        forward . 8.8.8.8 1.1.1.1  # 핵심: 신뢰할 수 있는 DNS 서버 지정
        # ... 기존 설정 ...
    }

B. 즉시 적용 명령어

# 1. CoreDNS 설정 강제 업데이트
kubectl apply -f - <<EOF
[위의 YAML 내용]
EOF
 
# 2. CoreDNS 재시작
kubectl rollout restart deployment coredns -n kube-system
 
# 3. 문제 Pod도 재시작 (DNS 캐시 초기화)
kubectl delete pod -l app=prometheus-alertmanager -n monitoring

C. DNS 테스트 방법

# 클러스터 내부에서 DNS 테스트
kubectl run -it --rm --restart=Never dns-test --image=busybox:1.28 \
  -- nslookup hooks.slack.com
 
# 성공 시: Address: 3.10.15.20 (IP 주소 출력)
# 실패 시: can't resolve 'hooks.slack.com'

3. 네트워크 연결성

📋 쿠버네티스 외부 통신 경로

Pod → Service → Node → Internet Gateway → External API

🛡️ 잠재적 차단 지점

  1. NetworkPolicy: Pod 간 통신 제한
  2. 노드 방화벽: 특정 포트/도메인 차단
  3. 클라우드 보안 그룹: AWS/GCP/Azure 레벨 제한
  4. 회사 프록시: 기업 환경에서 HTTP/HTTPS 프록시 필요

✅ 네트워크 테스트 방법

# 1. 기본 연결 테스트
kubectl run -it --rm --restart=Never net-test --image=curlimages/curl \
  -- curl -v https://hooks.slack.com/services/YOUR/WEBHOOK/URL
 
# 2. Alertmanager Pod에서 직접 테스트  
kubectl exec -it prometheus-alertmanager-0 -n monitoring \
  -- wget -qO- --timeout=10 https://hooks.slack.com
 
# 성공 시: HTML 응답 또는 "Bad Request" (정상 - Webhook 형식 아니므로)
# 실패 시: timeout, connection refused

4. Pod 상태 및 스토리지

🏥 Pod 건강 상태 체크

A. 기본 상태 확인

kubectl get pods -n monitoring
# 모든 Pod가 Running 상태여야 함

B. 문제 Pod 상세 진단

kubectl describe pod [POD_NAME] -n monitoring
# Events 섹션에서 오류 원인 확인:
# - FailedMount: 스토리지 문제
# - FailedScheduling: 자원 부족
# - ImagePullBackOff: 이미지 다운로드 실패

C. 스토리지(PVC) 문제 해결

# 1. PVC 상태 확인
kubectl get pvc -n monitoring
 
# 2. 문제 PVC 삭제 및 재생성
kubectl delete pvc storage-prometheus-alertmanager-0 -n monitoring
kubectl delete pod prometheus-alertmanager-0 -n monitoring
 
# Pod가 재시작되면서 새 PVC 자동 생성

5. 실무 체크리스트

🔧 외부 API 연동 시 순서별 점검

1단계: 기본 상태 점검

  • 모든 관련 Pod가 Running 상태인가?
  • PVC가 정상적으로 Bound 되어 있는가?
  • Service와 Endpoint가 제대로 연결되어 있는가?

2단계: DNS 해결 테스트

  • 클러스터 내부에서 외부 도메인 nslookup 성공하는가?
  • CoreDNS 로그에 에러가 있는가?
  • 필요시 DNS를 8.8.8.8로 변경했는가?

3단계: 네트워크 연결 테스트

  • curl/wget으로 외부 API 직접 호출 되는가?
  • 방화벽이나 보안 그룹에서 차단하지 않는가?
  • 회사 프록시 설정이 필요한가?

4단계: 애플리케이션 로그 분석

  • 애플리케이션 로그에서 구체적인 에러 메시지 확인
  • 재시도 횟수와 타임아웃 설정 적절한가?
  • API 키나 인증 정보가 올바른가?

🚀 빠른 해결 템플릿

DNS 문제일 때

# 원라이너로 CoreDNS를 구글 DNS로 변경
kubectl get cm coredns -n kube-system -o yaml | \
  sed 's|forward . /etc/resolv.conf|forward . 8.8.8.8 1.1.1.1|g' | \
  kubectl apply -f -
kubectl rollout restart deployment coredns -n kube-system

스토리지 문제일 때

# 해당 워크로드의 PVC 재생성
kubectl delete pvc $(kubectl get pvc -n monitoring -o name)
kubectl delete pod -l app=prometheus-alertmanager -n monitoring

설정 문제일 때

# Helm으로 전체 재배포 (가장 확실한 방법)
helm uninstall prometheus -n monitoring
helm install prometheus prometheus-community/prometheus -n monitoring -f values.yaml

📝 경험에서 얻은 교훈

✨ 핵심 인사이트

DNS가 80% 이상의 원인

외부 연동이 안 될 때는 DNS 문제부터 의심하자. 특히 VM 환경이나 온프레미스에서는 DNS 설정이 자주 꼬인다.

Pod 재시작의 힘

설정을 바꾸고도 안 되면 관련 Pod를 재시작하자. DNS 캐시나 연결 풀 문제를 단번에 해결할 수 있다.

테스트 순서가 중요

  1. Manual curl/wget 테스트 → 2. DNS 해결 → 3. 애플리케이션 설정 순서로 접근하면 시간을 절약할 수 있다.

💪 실무 적용 포인트

A. 모니터링 환경에서

  • Grafana, Prometheus, Alertmanager 등은 외부 API를 많이 사용
  • 각 컴포넌트별로 별도의 DNS/Network 설정이 필요할 수 있음
  • 보안을 위해 NetworkPolicy 적용 시 외부 통신 예외 규칙 필요

B. 마이크로서비스 환경에서

  • Service Mesh(Istio 등) 사용 시 사이드카 프록시 설정 확인
  • 서비스 간 mTLS 활성화되어 있다면 외부 API 예외 처리
  • API Gateway를 통한 외부 연동이 더 안전할 수 있음

C. 클라우드 환경에서

  • AWS: VPC Endpoint, Security Group, NACL 확인
  • GCP: Private Google Access, 방화벽 규칙 확인
  • Azure: Service Endpoint, NSG 규칙 확인

�

그래프 뷰