스킬 observability-monitoring-monitor-setup
📦

observability-monitoring-monitor-setup

안전

종합 모니터링 및 관찰 가능성 설정

처음부터 모니터링을 구현하는 것은 복잡하고 오류가 발생하기 쉽습니다. 이 스킬은 MTTR을 줄이고 전체 시스템 가시성을 제공하는 메트릭, 추적, 로깅을 위한 검증된 패턴을 제공합니다.

지원: Claude Codex Code(CC)
📊 71 적절함
1

스킬 ZIP 다운로드

2

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

3

토글을 켜고 사용 시작

테스트해 보기

"observability-monitoring-monitor-setup" 사용 중입니다. 자동 포드 발견으로 Kubernetes 클러스터에 대한 Prometheus 스크래핑 설정

예상 결과:

  • 자동 발견을 위한 kubernetes_sd_configs가 포함된 Prometheus 구성
  • 스크래핑 대상 지정에 필요한 ��드 주석
  • 발견된 대상을 필터링하고 태그 지정하는 재라벨링 규칙
  • 스크래핑 작동 확인을 위한 검증 단계

"observability-monitoring-monitor-setup" 사용 중입니다. 메모리 사용량이 90% 초과 시 알림 생성

예상 결과:

  • container_memory_working_set_bytes를 사용하는 PromQL 표현식
  • 적절한 임계값 및 지속 시간이 포함된 알림 규칙
  • 메모리 압력 조사를 위한 Runbook 단계
  • 메모리 트렌드 시각화를 위한 Grafana 패널 쿼리

보안 감사

안전
v1 • 2/24/2026

This skill contains documentation and code samples for monitoring setup. All static analysis findings are false positives - backticks are markdown code block delimiters, not shell execution. URLs are internal service endpoints. Environment variable usage follows standard configuration patterns. No malicious patterns detected.

2
스캔된 파일
557
분석된 줄 수
0
발견 사항
1
총 감사 수
보안 문제를 찾지 못했습니다
감사자: claude

품질 점수

38
아키텍처
100
유지보수성
87
콘텐츠
31
커뮤니티
100
보안
91
사양 준수

만들 수 있는 것

신규 서비스 모니터링

메트릭, 추적, 로깅을 포함하여 새 마이크로서비스를 위한 완전한 관찰 ��능성 스택을 첫날부터 설정합니다.

프로덕션 인시던트 대응

MTTR을 줄이고 사전 예방적 문제 감지를 가능하게 하는 실행 가능한 대시보드 및 알림을 만듭니다.

SLO 정의 및 추적

오류 버젯으로 서비스 수준 목표를 정의하고 안정성 엔지니어링을 위한 소진률 모니터링을 ��현합니다.

이 프롬프트를 사용해 보세요

기본 메트릭 설정
Node.js API에 Prometheus 메트릭을 추가하는 도움이 필요합니다. 요청 수, 오류율, 대기 시간 추적이 필���합니다. prom-client 설정 및 /metrics 엔드포인트 노출 방법을 보여주세요.
Grafana 대시보드 생성
4개의 골든 시그널을 표시하는 결제 서비스용 Grafana 대시보드 JSON을 만드세요. 요청율, 오류율, p95/p99 대기 시간, 포화 메트릭에 대��� 패널을 포함하세요.
알림 구성
높은 오류율(5분 동안 >5%) 및 느린 응답 시간(10분 동안 p95 >1초)에 대한 알림 규칙이 필요���니다. 중요한 알림은 PagerDuty로, 경고는 Slack으로 라우팅하도록 Alertmanager를 구성하세요.
SLO 구현
30일 동안 99.9% 가용성 목표로 API에 대한 SLO를 정의하세요. 오류 버젯 계산 방법, 다중 윈도우 소진률 알림 설정 ���법, SLO 추적을 위한 Grafana 패널 만드는 방법을 보여주세요.

모범 사례

  • 정확한 백분위수 계산을 위해 SLO 목표에 맞춘 히스토그램 버킷 사용
  • 효과적인 필터링을 위해 모든 메트릭에 일관된 라벨(service, environment, version) 추가
  • 알림을 활성���하기 전에 거짓 긍정을 최소화하기 위해 역사 데이터로 알림 테스트

피하기

  • 명확한 소유권 없이 모든 ��을 모니터링하면 알림 피��� 및 무시된 페이지 발생
  • 백분위수 대신 평균 대기 시간을 사용하면 사용자에게 영향을 미치는 꼬리 대기 시간 문제가 숨겨짐
  • 대시보드가 답해야 할 질문을 정의하기 전에 대시보드를 설정하면 노력 낭비

자주 묻는 질문

메트릭에 적절한 스크래이프 간격을 어떻게 선택하나요?
대부분의 서비스에서는 15초로 시작하세요. 대기 시간에 민감한 시스템이나 디버깅 시에는 5초를 사용��세요. 5초 미만 간격은 비례하는 혜택 없이 Prometheus 부하를 증가시키므로 피하세요.
모든 요청을 추적해야 하나요 아니면 샘플링해야 하나요?
프로덕션에서 샘플링하세요. 트래픽이 많은 서비스에는 헤드 기반 샘플링(예: 요청의 10%)을 사용하세요. 스테이���에서는 100% 추적하세요. 샘플링율에 관계없이 항상 오류를 추적하세요.
RED 및 USE 모니터링의 차이점은 ��엇인가요?
RED(Rate, Errors, Duration)는 ��용자 대면 서비스용입니다. USE(Utilization, Saturation, Errors)는 인프라 리소스용입니다. 애플리케이션 모니터링에는 RED를, 노드 및 데이터베이스에는 USE를 사용하세요.
의미 있는 SLO 목표를 어떻게 설정하나요?
목표를 현재 성능이 아닌 사용자 기대치 및 비즈니스 요구사항에 기반하세요. 보수적으로(99%) 시작하고 안정성이 개선됨에 따라 강화하세요. 28-30일 윈도우로 측정하세요.
첫날부터 세 가지 핵심 ��소(메트릭, 로그, 추��)가 모두 필요한가요?
가장 저렴하고 '무엇이 고장났는지'를 답해주는 메트릭으로 시작하세요. '왜 고장났는지'를 위해 로깅을 추가하세요. 서비스 간 문제 디버깅이 어려워지면 분산 시스템을 위해 추적을 추가하세요.
모니터링 데이터를 얼마나 오래 보관해야 하나요?
디버깅을 위해 고해상도 메트릭(원본 샘플)을 15-30일 동안 보관하세요. 장기 트렌드에는 다운샘플링 또는 레코딩 규칙을 사용하세요. 일반적으로 최소 90일 기준, 준수 요구사항에 따라 로그를 저장하세요.

개발자 세부 정보

파일 구조