UptimeLens 모니터링은(는) 무엇을 하나요?

UptimeLens MCP 서버를 통해 고객의 자체 리소스에서 UptimeLens 가동 시간 모니터링을 설정하고 실행합니다. 이 스킬은 모니터링 요청("이 URL 모니터링", "이 배포 후 무엇을 확인해야 하나요?", "무엇이 다운됐나요?", "인시던트 열기")을 올바른 MCP 도구 호출 시퀀스로 변환합니다.

이 스킬을 사용해야 하는 경우

제품의 모니터링 설정 및 인시던트 기록 관리 측면에 사용하세요.

HTTP/HTTPS 모니터 생성, 배포 후 또는 새 서비스에 대한 적용 범위 추천.
현재 다운된 항목 확인 및 간단한 조사(상태 기록, 프로브별 근본 원인, 응답 시간/가용성).
배포 또는 계획된 작업이 누구도 페이지를 울리지 않도록 유지 관리 기간 예약.
하위 검사가 상위 항목이 이미 다운되었을 때 알리지 않도록 모니터 종속성 모델링.
인시던트 열기, 업데이트 또는 해결.

요청이 모니터링이 아닌 페이지 응답에 관한 것인 경우(예: 활성 에스컬레이션 확인 또는 일시 중지, 교대 근무 커버, 에스컬레이션 실행 검사)에는 uptimelens-on-call 스킬을 사용하세요. 인시던트에 대한 심층적이고 안내된 근본 원인 조사의 경우에는 전체 분석을 스크립팅하기보다는 읽기 전용 triage_incident MCP 프롬프트(및 get_root_cause 도구)를 선호하세요.

전제 조건

UptimeLens MCP 서버가 이 클라이언트에 연결되어 있습니다. 읽기 도구는 모든 요금제에서 작동합니다.
쓰기 작업(create_monitor, update_monitor, pause_monitor, resume_monitor, register_monitor_dependency, delete_monitor_dependency, create_incident, post_incident_update, resolve_incident, cancel_incident, reopen_incident, save_postmortem, add_incident_action_item, create_maintenance, delete_maintenance)에는 읽기-쓰기 API 토큰과 Pro 요금제 이상이 필요합니다. 읽기 전용 토큰을 사용하면 쓰기 도구가 나열되지 않습니다. Free 요금제에서는 FeatureNotAvailable을 반환합니다.
일부 읽기 도구는 요금제에 따라 제한됩니다. get_root_cause(유료) 및 get_incident_analytics(Pro+)는 하드 게이트입니다. 요금제 미만에서는 FeatureNotAvailable 오류를 반환합니다. 아래 쓰기 도구 전제 조건과 동일하게 처리하세요(사용자에게 요금제가 충족되지 않았다고 알리고 재시도하지 마세요). query_metrics 백분위수는 소프트 게이트입니다. 백분위수 필드는 Team 미만에서는 오류가 아닌 null을 반환합니다.

쓰기 도구가 누락되었거나 FeatureNotAvailable을 반환하는 경우 재시도하는 대신 어떤 전제 조건이 충족되지 않았는지 사용자에게 알리세요.

도구

이 도구들은 UptimeLens MCP 서버에서 제공됩니다. 정규화된 이름인 UptimeLens:<tool>로 참조하세요. — 이 클라이언트에서 커넥터에 지정된 이름으로 UptimeLens를 바꾸세요. 그렇지 않으면 도구를 찾을 수 없습니다.

읽기(검색 및 컨텍스트):

UptimeLens:get_overview — "지금 무엇이 고장났나요?"에 대한 시작점: 상태별 모니터 수, 24시간 가동 시간, 열린 인시던트, 함께 그룹화된 고유 장애 — 같은 방식으로 같은 대상을 향해 고장난 40개의 모니터는 40개 행 대신 하나의 중단으로 표시됩니다. 인벤토리 자체(이름, 태그, ID)가 필요할 때는 list_monitors를 대신 사용하세요.
UptimeLens:list_monitors — 현재 상태와 함께 모니터를 표시합니다. status(up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance), 이름 또는 태그로 필터링할 수 있습니다. 거의 모든 다른 작업을 위한 monitorId의 출처이며 "무엇이 다운됐나요?"에 대한 답변입니다.
UptimeLens:get_monitor — 하나의 모니터 구성 및 현재 상태(자격 증명 없음).
UptimeLens:list_status_changes — 모니터의 up/down/degraded 기록(지속 시간 포함). get_root_cause에 필요한 statusChangeId의 출처입니다.
UptimeLens:get_status_change — 컨텍스트(이전 및 다음 변경, 이를 포함하는 인시던트 및 에스컬레이션 실행)와 주변 검사에 대한 위치별 요약(실패한 검사 수, firstDownAt, 가장 빈번한 errorCategory)을 포함한 하나의 상태 변경입니다. 중단이 시작된 위치와 확인 방법을 알려주는 데 사용합니다. 모든 요금제에서 사용 가능합니다.
UptimeLens:get_root_cause — 하나의 상태 변경에 대한 프로브별 네트워크 진단(DNS/연결/TLS 타이밍, traceroute, TLS 버전, SSL 만료일, 오류 범주). "왜 다운되었는지"에 대한 가장 풍부한 정보 소스입니다(유료 요금제).
UptimeLens:query_metrics — 특정 기간 동안 하나의 모니터에 대한 응답 시간 및 가동 시간 통계(기간 요약, 전체 시계열 아님; 백분위수는 Team+).
UptimeLens:get_monitor_availability — 하나의 모니터에 대한 SLA 보기: 가동 시간 %, 다운타임, 인시던트 수, MTTR, MTBF, 응답 시간 통계. 읽을 때 주의: uptimePct가 없으면 해당 기간에 측정치가 없음을 의미합니다. 100%가 아니므로 모니터가 측정되지 않았다고 말하세요. longestIncidentSec는 인시던트의 벽시계 시간이며 측정된 totalDowntimeSec를 초과할 수 있습니다. 이는 정상적인 현상이며 데이터 오류가 아닙니다. uptimePct는 소수점 둘째 자리에서 반올림되므로 매우 짧은 중단이 긍정적인 다운타임 옆에 100.00으로 표시될 수 있습니다. mtbfSec/mttrSec가 없으면 0이 아닙니다.
UptimeLens:get_uptime_report — 특정 기간 동안 전체 계정에 대한 동일한 질문: 시간 가중 가동 시간, 다운타임, SLA 목표에 대한 오류 예산, 고장난 항목(causes) 및 확인된 위치(locations). 사전 설정(last_month, last_30d, …) 또는 명시적 날짜로 기간을 선택하세요. "지난 달은 어땠나요?"에 사용하고, 하나의 모니터에 대해서는 get_monitor_availability를 사용하세요.
UptimeLens:list_monitor_dependencies — 모니터가 의존하는 상위 모니터(알림이 실행되기 위해 반드시 작동 중이어야 하는 모니터).
UptimeLens:list_monitor_dependents — 역방향: 이 모니터에 의존하는 모니터(즉, 이 모니터의 블래스트 반경). 근본 원인과 증상을 구별하는 데 사용합니다.
UptimeLens:list_incidents — 가장 최신순으로 인시던트를 표시합니다. startDate/endDate를 전달하지 않으면 기본적으로 지난 7일 동안의 인시던트를 표시합니다. status, monitorId 또는 source로 필터링할 수 있습니다.
UptimeLens:get_incident — 하나의 인시던트 상세 정보와 업데이트 타임라인 및 영향을 받은 모니터를 표시합니다.
UptimeLens:get_incident_analytics — 전체 인시던트 메트릭(MTTR, 볼륨/추세, 심각도/소스 분석, 상위 모니터)을 날짜 범위에 대해 표시합니다. (Pro+).
UptimeLens:list_maintenance — 유지 관리 기간; status=active는 "지금 유지 관리 중인 것이 있나요?"에 대한 답변입니다.
UptimeLens:list_status_pages / UptimeLens:get_status_page — 고객에게 게시된 내용과 페이지에 표시되는 모니터(적용 범위 결정 시 유용).

쓰기(상태 변경 — "확인 후 쓰기" 참조):

UptimeLens:create_monitor — URL에서 HTTP/HTTPS 모니터를 생성합니다. "create_monitor가 할 수 있는 것과 없는 것"을 참조하세요.
UptimeLens:update_monitor — 기존 모니터의 이름 및/또는 확인 간격을 편집합니다(id + name 및/또는 intervalSeconds, 하나 이상). 다른 모든 설정(URL, 유형, 인증, 헤더, 임계값, 리전)은 변경되지 않고 유지되며 MCP를 통해 변경할 수 없습니다. 되돌릴 수 있고 멱등적입니다.
UptimeLens:pause_monitor / UptimeLens:resume_monitor — 하나의 모니터에 대한 활성 모니터링을 중지하거나 다시 시작합니다. 입력: id. 되돌릴 수 있고 멱등적입니다.
UptimeLens:register_monitor_dependency — 하위→상위 종속성을 선언합니다. 상위가 다운된 동안 하위의 다운 알림이 억제됩니다. 입력: monitorId(하위), parentId. 직접 상위만 허용되며, 순환/자기 참조는 거부됩니다.
UptimeLens:delete_monitor_dependency — 레코드 id로 종속성 에지를 제거합니다(list_monitor_dependencies에서 가져옴). 모니터를 삭제하지 않습니다.
UptimeLens:create_incident — 인시던트를 엽니다. "인시던트는 초안으로 열림"을 참조하세요.
UptimeLens:post_incident_update — 메시지와 함께 타임라인 업데이트(조사 중/식별됨/모니터링 중)를 추가합니다. notifySubscribers=true를 전달하지 않는 한(그리고 인시던트가 이미 게시된 경우에만) 구독자에게 이메일이 전송되지 않습니다.
UptimeLens:resolve_incident — 인시던트를 해결됨으로 표시합니다. notifySubscribers=true를 전달하지 않는 한(그리고 게시된 경우에만) 구독자에게 이메일이 전송되지 않습니다. reopen_incident를 통해 되돌릴 수 있습니다.
UptimeLens:cancel_incident — false_alarm/duplicate/test로 취소합니다. 종결형(다시 열 수 없음)이며 분석에서 제외됩니다. 기본적으로 자동입니다.
UptimeLens:reopen_incident — 이전에 해결된 인시던트를 다시 엽니다(취소된 인시던트는 다시 열 수 없습니다).
UptimeLens:save_postmortem — 인시던트의 포스트모템 본문을 마크다운으로 작성(또는 덮어씁니다). 선택적 status는 draft 또는 in_review입니다. postmortem_draft 프롬프트의 출력이 저장되는 곳입니다. 이것 없이는 초안이 채팅에만 존재합니다. 게시는 대시보드에서 사람이 수행하는 단계로 유지됩니다.
UptimeLens:add_incident_action_item — 인시던트에 후속 조치 항목을 추가합니다(제목, 선택적 유형, 우선순위 및 기한). 실제로 무언가를 변경하는 포스트모템의 절반입니다.
UptimeLens:create_maintenance / UptimeLens:delete_maintenance — 유지 관리 기간(해당 기간 동안 모니터에 대한 알림을 억제함)을 예약하거나 취소합니다.

핵심 워크플로우: 모니터링 설정(특히 배포 후)

발견이 먼저입니다. 거의 모든 쓰기 작업에는 ID 또는 현재 인벤토리만이 알 수 있는 결정이 필요합니다. 이 체크리스트를 복사하여 진행하세요.

모니터링 설정:
- [ ] 1. 현재 적용 범위 확인(list_monitors) — 무엇이 존재하는지, 무엇이 누락되었는지, 이미 무엇이 다운되었는지 확인
- [ ] 2. 새 URL/서비스의 경우: list_monitors에서 중복 확인(create_monitor는 멱등적이지 않음)
- [ ] 3. 사용자와 URL 확인 후 create_monitor(HTTP/HTTPS만 해당)
- [ ] 4. 해당되는 경우 토폴로지 연결(register_monitor_dependency: 상위 아래 새 검사)
- [ ] 5. 배포/유지보수 진행 중인 경우 노이즈 차단(create_maintenance for the window)

1단계 — 인벤토리. list_monitors를 호출하세요. "무엇이 다운됐나요?"에 답하려면 status=["down"]을 전달하세요(사용자가 "비정상"을 의미하는 경우 degraded/unconfirmed-down 추가). 이것은 또한 사용자가 방금 배포했지만 일치하는 모니터가 없는 서비스와 같은 격차를 찾는 방법입니다.

2-3단계 — 신중하게 생성. create_monitor는 멱등적이지 않습니다. 동일한 URL에 대해 두 번 호출하면 두 개의 모니터가 생성됩니다. 먼저 list_monitors에서 기존 모니터를 확인하고, 생성하기 전에 사용자와 정확한 URL을 확인하세요. 아래 제약 조건을 참조하세요.

4단계 — 토폴로지(선택 사항). 새 모니터가 이미 모니터링 중인 항목(게이트웨이 뒤의 앱, 데이터베이스 뒤의 서비스)의 다운스트림에 있는 경우, 새 모니터를 monitorId로, 업스트림을 parentId로 register_monitor_dependency를 사용하여 하위가 업스트림이 실제 문제일 때 페이지를 울리지 않도록 하세요.

5단계 — 배포 노이즈 차단(선택 사항). 사용자가 배포하거나 계획된 작업을 수행하는 경우, 영향을 받는 모니터에 대해 create_maintenance를 사용하여 작업 자체가 페이지를 울리지 않도록 하세요.

create_monitor가 할 수 있는 것과 없는 것

create_monitor는 빠른 추가 기능입니다. URL을 제공하면 HTTP/HTTPS 모니터를 생성하고(스키마가 제공되지 않으면 https가 가정됨), 이름은 기본적으로 호스트로 설정되며, 확인 간격 및 알림 그룹은 테넌트 기본값을 사용합니다.

MCP를 통해 create_monitor는 할 수 없습니다: 비HTTP 모니터(TCP/UDP, DNS, ping/ICMP, SSH, SMTP 등)를 생성하거나 인증, 사용자 정의 헤더, 키워드/본문 어설션, 특정 간격 또는 알림 그룹을 설정할 수 없습니다. 이러한 경우 사용자에게 대시보드에서 설정을 완료하도록 알리세요. MCP가 구성할 수 있다고 가장하지 마세요. 생성 후 update_monitor는 모니터의 이름과 확인 간격만 변경할 수 있습니다(이 두 가지만 변경 가능하며 다른 모든 것은 대시보드에 남아 있습니다). delete_monitor 도구는 없습니다. 모니터를 제거하려면 사용자를 대시보드로 안내하세요.

인시던트는 초안으로 열림

create_incident는 항상 게시되지 않은 초안을 엽니다. 상태 페이지에 표시되지 않으며 구독자에게 알림이 전송되지 않습니다. 사람이 대시보드에서 게시합니다. 인시던트를 생성할 때 이 점을 말하여 사용자가 아직 공개되지 않았음을 알 수 있도록 하세요. post_incident_update, resolve_incident, cancel_incident 및 reopen_incident는 명시적으로 notifySubscribers=true를 전달하는 경우에만 구독자에게 이메일을 보냅니다. MCP 기본값은 자동입니다. 고객의 고객에게 보내는 메일은 되돌릴 수 없기 때문입니다. (대시보드는 반대로 동작합니다. 대시보드에서는 사람이 버튼을 누릅니다.) cancel_incident는 종결형(false_alarm/duplicate/test)이며 다시 열 수 없습니다. resolve_incident는 reopen_incident를 통해 되돌릴 수 있습니다. "실제가 아닌 경우"에는 cancel을 사용하고, "종료된 경우"에는 resolve를 사용하세요.

확인 후 쓰기

자유롭게 읽고 추천하세요. 쓰기 전에 수행할 작업을 설명하고 사용자의 승인을 받으세요. 이러한 작업은 모니터링 대상, 페이지 울림 대상 또는 기록 대상을 변경합니다.

모니터 생성: 정확한 URL을 지정하세요. 멱등적이지 않으므로 이미 모니터가 없는지 확인하세요(list_monitors를 확인했습니다).
일시 중지/재개: 일시 중지는 모니터링을 중지하므로 실제 중단이 발생해도 일시 중지된 동안에는 페이지가 울리지 않습니다. 사용자가 이를 음소거하려는 것인지 확인하세요.
유지 관리: 모니터와 정확한 기간(RFC3339; 기본값 UTC 또는 Europe/Istanbul과 같은 IANA timezone 전달 가능 — 반복 기간은 DST를 인식함)을 지정하세요. 기간 동안 알림이 억제됩니다.
인시던트 열기/업데이트/해결/취소: 인시던트 이름을 지정하고, 해결/취소의 경우 구독자 이메일 전송 여부(notifySubscribers=true)를 물으세요. 기본적으로 메일은 전송되지 않습니다.

가장 덜 놀라운 작업을 선호하고, 대규모로 생성하기보다는 추천하세요. 인시던트별 확인 없이 인시던트를 일괄적으로 열거나 해결하지 마세요.

일반적인 시나리오

"https://api.example.com을 모니터링하세요." list_monitors(이미 모니터링 중인지 확인) → URL 확인 → create_monitor(url). 사용자가 인증, 키워드 검사 또는 비HTTP 프로토콜을 원하는 경우 기본 HTTP 모니터를 생성하고 대시보드에서 해당 설정을 완료하도록 알리세요.

"방금 결제 서비스를 배포했습니다. 무엇을 모니터링해야 하나요?" list_monitors로 현재 적용 범위 확인 → 격차 식별(모니터가 없는 새 공개 엔드포인트/상태 확인)하고 자동으로 생성하지 말고 사용자에게 추천 → 확인 후 각각에 대해 create_monitor → 새 모니터가 이미 감시 중인 항목 뒤에 있는 경우 register_monitor_dependency로 해당 업스트림 아래에 배치 → 자동 생성할 수 없는 항목(비HTTP, 인증, 키워드)을 기록하고 대시보드로 안내.

"지금 무엇이 다운됐나요?" get_overview를 먼저 호출하세요. 이는 "무엇이 고장났나요?"에 대한 가장 빠른 답변을 제공합니다. 모니터링되지 않는 URL에 대해 사용자가 질문하는 경우(예: "example.com이 다운됐나요?") list_monitors로 귀하의 계정에 모니터가 있는지 확인하고, 없으면 "해당 URL에 대한 모니터가 설정되어 있지 않습니다"라고 말하고 생성을 제안하세요.

"api 서버가 다운된 것 같습니다." list_status_changes로 최근 상태 변경 확인 → get_status_change로 세부 정보 확인(어디서 실패했는지, 어떤 오류 범주인지) → 인시던트가 열려 있는 경우 get_incident로 타임라인 및 메모 확인 → get_root_cause(유료 요금제)가 활성화된 경우 사용하여 DNS/연결/TLS 문제 진단 → 근본 원인을 알고 있는 경우 post_incident_update로 타임라인 업데이트 게시 → 해결되면 resolve_incident → 나중에 save_postmortem으로 포스트모템 작성 및 add_incident_action_item으로 후속 조치 항목 추가.

"다음 2시간 동안 유지 관리를 예약하세요. 결제 및 API 모니터를 음소거하세요." list_monitors로 관련 모니터 ID 확인 → list_maintenance로 기존 유지 관리 기간과 충돌하지 않는지 확인 → 사용자와 정확한 기간 및 모니터 확인 → create_maintenance 호출(모니터 ID 배열 및 RFC3339 시간 사용).

"인시던트 #12345에 대한 포스트모템을 작성하세요." get_incident로 세부 정보 검색 → list_status_changes로 타임라인 확인 → 분석 작성 → save_postmortem으로 마크다운 본문 저장 → add_incident_action_item으로 후속 조치 항목 추가(예: "모든 서비스에 오류율 알림 추가" 또는 "데이터베이스 장애 조치 테스트").

오류 처리

도구를 찾을 수 없음 (MCPError: tool not found): 클라이언트가 다른 이름으로 커넥터를 구성했을 수 있습니다. 사용자에게 UptimeLens MCP 커넥터가 이 클라이언트에 추가된 이름을 물어보고 그 이름을 접두사로 사용하세요.
FeatureNotAvailable: 요금제 부족을 의미합니다(쓰기 도구의 경우 읽기-쓰기 토큰 부족일 수도 있음). 재시도하지 말고 사용자에게 "이 작업에는 [X] 요금제가 필요합니다. 업그레이드하거나 대시보드에서 완료하세요."라고 말하세요.
속도 제한 (429): 30초 동안 기다렸다가 재시도하세요. 그래도 실패하면 사용자에게 나중에 다시 시도하라고 말하세요.
일시적인 오류(5xx, 네트워크 시간 초과): 최대 2회 재시도하고 지수 백오프(2초, 5초)를 적용하세요. 그 후에는 사용자에게 UptimeLens 상태를 확인하라고 말하세요.

그 외 알아야 할 사항

URL 검증: create_monitor는 https://가 없는 URL을 가정합니다. 예: example.com → https://example.com. 유효하지 않은 URL의 경우 자체 검증(정규식)을 추가하세요.
타임존: RFC3339 타임스탬프는 기본적으로 UTC로 가정됩니다. IANA 타임존 문자열을 전달하여 재정의하세요(예: timezone: "America/New_York"). 유지 관리 기간(create_maintenance) 및 쿼리 간격(query_metrics 등)에 적용됩니다.
되돌리기: resolve_incident(reopen_incident를 통해) 및 pause_monitor(resume_monitor를 통해)는 되돌릴 수 있습니다. cancel_incident는 종결형입니다. create_monitor는 되돌릴 수 없습니다. 삭제하려면 대시보드가 필요합니다. create_maintenance는 해당 시간이 지나기 전에 delete_maintenance로 취소할 수 있습니다.
멱등성: list_*, get_*, query_metrics는 멱등적입니다. update_monitor, pause_monitor, resume_monitor, delete_maintenance는 동일한 입력으로 다시 호출해도 안전합니다. create_monitor, create_incident, create_maintenance, register_monitor_dependency, post_incident_update, save_postmortem, add_incident_action_item은 확인이 필요합니다(또는 create_monitor의 경우 중복 검사).
모니터 ID 가져오기: 항상 도구 출력에서 모니터 ID를 추출하세요. 모니터 ID는 대부분의 쓰기 작업에 필요합니다.

UptimeLens 모니터링