UptimeLens - Monitoramento Uptime

Monitoramento UptimeLens

Configure e execute o monitoramento de uptime do UptimeLens nos próprios recursos do cliente, através do servidor MCP UptimeLens. Esta skill transforma uma solicitação de monitoramento ("monitore esta URL", "o que devo observar após este deploy?", "o que está fora do ar?", "abra um incidente") na sequência correta de chamadas de ferramentas MCP.

Quando usar esta skill

Use-a para o lado de configuração de monitoramento e manutenção de incidentes do produto:

• Criando monitores HTTP/HTTPS e recomendando cobertura após um deploy ou para um novo serviço.
• Verificando o que está atualmente fora do ar e fazendo uma investigação leve (histórico de status, causa raiz por probe, tempo de resposta/disponibilidade).
• Agendando uma janela de manutenção para que um deploy ou trabalho planejado não notifique ninguém.
• Modelando dependências de monitores para que uma verificação downstream não alerte quando seu upstream já está fora do ar.
• Abrindo, atualizando ou resolvendo incidentes.

Passe adiante quando a solicitação for sobre responder a um alerta em vez de monitorar: para reconhecer ou adiar uma escalada ativa, cobrir um turno ou inspecionar execuções de escalada, use a skill uptimelens-on-call. Para uma investigação profunda e guiada de causa raiz de um incidente, prefira o prompt MCP triage_incident (somente leitura) e a ferramenta get_root_cause em vez de roteirizar toda a análise aqui.

Pré-requisitos

1. O servidor MCP UptimeLens está conectado a este cliente. Ferramentas de leitura funcionam em todos os planos.
2. Ações de escrita (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) exigem um token de API de leitura e escrita e um plano Pro ou superior. Com um token somente leitura, as ferramentas de escrita nem são listadas; no plano Gratuito, elas retornam FeatureNotAvailable.
3. Algumas ferramentas de leitura são limitadas por plano. get_root_cause (pago) e get_incident_analytics (Pro+) são rigidamente limitadas — abaixo do plano, retornam um erro FeatureNotAvailable; lide com isso como os pré-requisitos de ferramentas de escrita abaixo (informe ao usuário que o plano não é atendido, não tente novamente). Os percentis de query_metrics são flexivelmente limitados — os campos de percentil retornam nulos abaixo do plano Team, não um erro.

Se uma ferramenta de escrita estiver ausente ou retornar FeatureNotAvailable, informe ao usuário qual pré-requisito não foi atendido em vez de tentar novamente.

Ferramentas

Essas ferramentas vêm do servidor MCP UptimeLens. Consulte-as totalmente qualificadas como UptimeLens:<ferramenta> — substitua UptimeLens pelo nome que o conector recebeu neste cliente; caso contrário, a ferramenta pode não ser encontrada.

Leitura (descoberta e contexto):

• UptimeLens:get_overview — comece aqui para "o que está quebrado agora?": contagens de monitores por status, uptime de 24 horas, incidentes abertos e as falhas distintas agrupadas — quarenta monitores que quebraram da mesma forma no mesmo destino retornam como UMA interrupção em vez de quarenta linhas. Use list_monitors em vez disso quando precisar do inventário em si (nomes, tags, ids).
• UptimeLens:list_monitors — monitores com integridade atual; filtre por status (up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance), nome ou tags. A fonte de monitorId para quase tudo o mais e a resposta para "o que está fora do ar?".
• UptimeLens:get_monitor — configuração e integridade atual de um monitor (sem credenciais).
• UptimeLens:list_status_changes — histórico de up/down/degraded de um monitor com durações; a fonte do statusChangeId que get_root_cause precisa.
• UptimeLens:get_status_change — uma alteração de status com seu contexto (alteração anterior e seguinte, o incidente e as execuções de escalada que a cobrem) e um resumo por localização das verificações ao redor: quantas falharam, firstDownAt e o errorCategory mais frequente. Use para saber onde uma interrupção começou e como foi confirmada; disponível em todos os planos.
• UptimeLens:get_root_cause — diagnósticos de rede por probe para uma alteração de status: tempo de DNS/conexão/TLS, traceroute, versão TLS, dias restantes do SSL, categoria de erro. A fonte mais rica de "por que estava fora do ar" (plano pago).
• UptimeLens:query_metrics — estatísticas de tempo de resposta e uptime para um monitor em um período (resumo do período, não uma série completa; percentis são Team+).
• UptimeLens:get_monitor_availability — visão de SLA para um monitor: % de uptime, downtime, contagem de incidentes, MTTR, MTBF, estatísticas de tempo de resposta. Ao ler: um uptimePct ausente significa que o período NÃO teve medições — NÃO é 100, então diga que o monitor não foi medido; longestIncidentSec é o tempo de parede de um incidente e PODE exceder o medido totalDowntimeSec — isso é esperado, não um erro de dados; uptimePct é arredondado para duas casas decimais, então uma interrupção muito curta pode mostrar 100,00 ao lado de um downtime positivo; um mtbfSec/mttrSec ausente NÃO é zero.
• UptimeLens:get_uptime_report — a mesma pergunta para a conta inteira em um período: uptime ponderado pelo tempo, downtime, orçamento de erros em relação a uma meta de SLA, além do que quebrou (causes) e onde foi confirmado (locations). Escolha um período com um predefinido (last_month, last_30d, …) ou datas explícitas. Use para "como foi o último mês?"; get_monitor_availability para um monitor.
• UptimeLens:list_monitor_dependencies — os monitores pai dos quais um monitor depende (o que deve estar ativo para que seus alertas disparem).
• UptimeLens:list_monitor_dependents — o inverso: monitores que dependem deste — seu raio de explosão, para distinguir causa raiz de sintoma.
• UptimeLens:list_incidents — incidentes, do mais novo ao mais antigo; o padrão são os últimos 7 dias, a menos que você passe startDate/endDate. Filtre por status, monitorId ou source.
• UptimeLens:get_incident — detalhes de um incidente mais sua linha do tempo de atualizações e monitores afetados.
• UptimeLens:get_incident_analytics — métricas de incidentes em nível de frota em um intervalo de datas (MTTR, volume/tendência, detalhamento por gravidade/fonte, principais monitores) — Pro+.
• UptimeLens:list_maintenance — janelas de manutenção; status=active responde "há algo em manutenção agora?".
• UptimeLens:list_status_pages / UptimeLens:get_status_page — o que é publicado para os clientes e quais monitores aparecem em uma página (útil ao decidir a cobertura).

Escrita (mudam estado — veja "Confirme antes de escrever"):

• UptimeLens:create_monitor — cria um monitor HTTP/HTTPS a partir de uma URL. Veja "O que create_monitor pode e não pode fazer".
• UptimeLens:update_monitor — edita o nome e/ou intervalo de verificação de um monitor existente (id + name e/ou intervalSeconds, pelo menos um). Todas as outras configurações (URL, tipo, autenticação, cabeçalhos, limites, regiões) são preservadas intactas e não podem ser alteradas via MCP. Reversível e idempotente.
• UptimeLens:pause_monitor / UptimeLens:resume_monitor — para ou reinicia o monitoramento ativo de um monitor. Entrada: id. Reversível e idempotente.
• UptimeLens:register_monitor_dependency — declara uma dependência filho→pai: enquanto o pai estiver fora do ar, os alertas de down do filho são suprimidos. Entrada: monitorId (filho), parentId. Somente pai direto; ciclos/auto-referência são rejeitados.
• UptimeLens:delete_monitor_dependency — remove uma aresta de dependência pelo seu id de registro (de list_monitor_dependencies); não exclui nenhum monitor.
• UptimeLens:create_incident — abre um incidente. Veja "Incidentes abrem como rascunhos".
• UptimeLens:post_incident_update — adiciona uma atualização na linha do tempo (investigating/identified/monitoring) com uma mensagem. Os assinantes não são notificados por email a menos que você passe notifySubscribers=true (e apenas se o incidente já estiver publicado).
• UptimeLens:resolve_incident — marca um incidente como resolvido. Os assinantes não são notificados por email a menos que você passe notifySubscribers=true (e apenas se publicado). Reversível via reopen_incident.
• UptimeLens:cancel_incident — cancela como false_alarm/duplicate/test; terminal (não pode ser reaberto), excluído da análise. Silencioso por padrão.
• UptimeLens:reopen_incident — reabre um incidente previamente resolvido (um incidente cancelado não pode ser reaberto).
• UptimeLens:save_postmortem — escreve (ou sobrescreve) o corpo do postmortem de um incidente como markdown; status opcional de draft ou in_review. É aqui que a saída do prompt postmortem_draft vai — sem ele, o rascunho existe apenas no chat. A publicação continua sendo uma etapa humana no dashboard.
• UptimeLens:add_incident_action_item — adiciona um item de ação de acompanhamento a um incidente (título, mais tipo, prioridade e data de vencimento opcionais). A metade de um postmortem que realmente muda algo.
• UptimeLens:create_maintenance / UptimeLens:delete_maintenance — agenda ou cancela uma janela de manutenção que suprime alertas para seus monitores durante a janela.

Fluxo de trabalho principal: configurar monitoramento (especialmente após um deploy)

Descoberta vem primeiro: quase toda escrita precisa de um ID, ou de uma decisão que apenas o inventário atual pode informar. Copie esta lista de verificação e siga-a:

Configurar monitoramento:
- [ ] 1. Veja a cobertura atual (list_monitors) — o que existe, o que está faltando, o que já está fora do ar
- [ ] 2. Para uma nova URL/serviço: verifique list_monitors por duplicatas (create_monitor NÃO é idempotente)
- [ ] 3. Confirme a(s) URL(s) com o usuário, depois create_monitor (apenas HTTP/HTTPS)
- [ ] 4. Conecte a topologia se relevante (register_monitor_dependency: a nova verificação sob seu upstream)
- [ ] 5. Se um deploy/manutenção estiver ocorrendo, silencie o ruído (create_maintenance para a janela)

Etapa 1 — inventário. Chame list_monitors. Para responder "o que está fora do ar?", passe status=["down"] (adicione degraded/unconfirmed-down se o usuário se referir a "não saudável"). Isto também é como você identifica lacunas: um serviço que o usuário acabou de implantar sem um monitor correspondente.

Etapas 2-3 — crie com cuidado. create_monitor não é idempotente — chamá-lo duas vezes para a mesma URL cria dois monitores. Verifique list_monitors por um existente primeiro e confirme a URL exata com o usuário antes de criar. Veja as restrições abaixo.

Etapa 4 — topologia (opcional). Se o novo monitor estiver a jusante de algo que você já monitora (um aplicativo atrás de um gateway, um serviço atrás de seu banco de dados), use register_monitor_dependency com o novo monitor como monitorId e o upstream como parentId para que o filho não alerte quando o upstream for o problema real.

Etapa 5 — silenciar ruído de deploy (opcional). Se o usuário estiver implantando ou fazendo trabalho planejado, use create_maintenance para os monitores afetados durante a janela, para que o trabalho em si não alerte ninguém.

O que create_monitor pode e não pode fazer

create_monitor é uma adição rápida: forneça uma URL, ele cria um monitor HTTP/HTTPS (https é assumido quando nenhum esquema é fornecido), o nome padrão é o host, e o intervalo de verificação e o grupo de alerta usam os padrões do locatário.

Ele não pode, via MCP: criar monitores não-HTTP (TCP/UDP, DNS, ping/ICMP, SSH, SMTP, etc.), ou definir autenticação, cabeçalhos personalizados, asserções de palavra-chave/corpo, um intervalo específico ou grupos de alerta. Para qualquer um desses, diga ao usuário para finalizar a configuração no dashboard — não finja que o MCP pode configurá-los. Após a criação, update_monitor pode alterar o nome e o intervalo de verificação de um monitor (apenas esses dois — todo o resto permanece no dashboard). Não há ferramenta delete_monitor: para remover um monitor, direcione o usuário para o dashboard.

Incidentes abrem como rascunhos

create_incident sempre abre um rascunho não publicado: ele não é exibido em nenhuma página de status e os assinantes não são notificados. Um humano o publica a partir do dashboard. Diga isso ao criar um, para que o usuário saiba que ainda não é público. post_incident_update, resolve_incident, cancel_incident e reopen_incident notificam assinantes por email apenas quando você passar explicitamente notifySubscribers=true — o padrão do MCP é silencioso, porque o email para os próprios clientes do cliente não pode ser desfeito. (O dashboard se comporta de forma oposta: lá um humano está apertando o botão.) cancel_incident é terminal (false_alarm/duplicate/test) e não pode ser reaberto; resolve_incident é reversível via reopen_incident. Use cancel para "isto não era real", resolve para "isto acabou".

Confirme antes de escrever

Leia e recomende livremente. Antes de qualquer escrita, declare o que você está prestes a fazer e obtenha a aprovação do usuário — estas alteram o que é monitorado, o que alerta ou o que é registrado:

• Criar monitor: nomeie a URL exata. Como não é idempotente, confirme que já não existe um monitor para ela (você verificou list_monitors).
• Pausar/retomar: pausar interrompe o monitoramento, portanto uma interrupção real não alertará enquanto estiver pausado — confirme que o usuário pretende silenciá-lo.
• Manutenção: nomeie os monitores e a janela exata (RFC3339; padrão UTC, ou passe um timezone IANA como Europe/Istanbul — janelas recorrentes são compatíveis com horário de verão); durante ela, os alertas são suprimidos.
• Abrir/atualizar/resolver/cancelar incidente: nomeie o incidente e, para resolver/cancelar, diga se você está solicitando um email para assinantes (notifySubscribers=true) — por padrão, nenhum email é enviado.

Prefira a ação menos surpreendente, recomende em vez de criar em escala, e nunca abra ou resolva incidentes em lote sem confirmação por incidente.

Cenários comuns

"Monitore https://api.example.com." list_monitors (verifique se já não está sendo monitorado) → confirme a URL → create_monitor(url). Se o usuário quisesse autenticação, uma verificação de palavra-chave ou um protocolo não HTTP, crie o monitor HTTP básico e diga para finalizar essas configurações no dashboard.

"Acabei de implantar o serviço de cobrança — o que devo monitorar?" list_monitors para ver a cobertura atual → identifique as lacunas (os novos endpoints públicos / verificações de integridade sem monitor) e recomende-as ao usuário, em vez de criar silenciosamente → após confirmação, create_monitor para cada → se o novo monitor estiver atrás de algo que você já monitora, register_monitor_dependency para colocá-lo sob esse upstream. Observe o que não pode ser criado automaticamente (não HTTP, autenticação, palavras-chave) e direcione para o dashboard.

"O que está fora do ar agora?" get_overview primeiro — ele responde "o que está quebrado agora?" com contagens de monitores por status, uptime de 24 horas, incidentes abertos e as falhas distintas agrupadas — quarenta monitores que quebraram da mesma forma no mesmo destino retornam como UMA interrupção em vez de quarenta linhas. Para uma lista de monitores individuais, use list_monitors.

"Abra um incidente para o gateway de pagamento — ele está fora do ar." get_monitor (confirme que está fora do ar) → create_incident com o monitorId → diga que é um rascunho e não foi publicado → se o usuário quiser notificar assinantes, eles precisam publicar no dashboard. Poste atualizações com post_incident_update e, quando terminar, resolve_incident.

"Houve um incidente na semana passada com o banco de dados de usuários. Escreva o postmortem." list_incidents filtrando por nome/período → get_incident para detalhes → list_status_changes e opcionalmente get_root_cause para contexto sobre por que caiu → get_monitor_availability ou query_metrics para métricas do período → escreva o postmortem (o conteúdo é seu julgamento) → save_postmortem para salvá-lo como rascunho → recomende adicionar itens de ação com add_incident_action_item.

"Vou implantar a nova fila de mensagens à meia-noite de sábado." list_monitors (encontre os monitores que verificarão a fila) → create_maintenance(monitorIds, window) → diga ao usuário que os alertas serão suprimidos durante esse período.

"Atualize o incidente #42 — diga que identificamos a causa." Use get_incident para verificar que o incidente existe e obter seu estado atual. Então post_incident_update com status="identified" e uma breve mensagem explicando a causa. A menos que o usuário peça explicitamente notifySubscribers=true, nenhum email é enviado. Após a resolução, resolve_incident e, em seguida, escreva o postmortem com save_postmortem e adicione itens de ação com add_incident_action_item.

"Temos um incidente antigo #15 que foi encerrado, mas acabou de acontecer novamente. Reabra-o." get_incident(id=15) para confirmar que está resolvido → reopen_incident(id=15) → diga ao usuário que foi reaberto, mas ainda é um rascunho; publique no dashboard para notificar assinantes. Não passe notifySubscribers=true a menos que explicitamente solicitado.

"Quero que o monitor de API espere que o balanceador de carga esteja funcionando antes de alertar." list_monitors para obter ambos os IDs → register_monitor_dependency(monitorId=<API>, parentId=<load-balancer>) → confirme a dependência. Durante uma interrupção do balanceador de carga, o monitor de API não alertará por estar downstream.

"Este alerta foi um alarme falso — um pico de latência durante um pico de tráfego, não uma falha real." list_incidents para encontrar o incidente → cancel_incident com reason=false_alarm. Lembre-se de que isso é terminal e o incidente não pode ser reaberto; use resolve_incident se a causa foi corrigida. cancel também exclui o incidente da análise.

Notas sobre limites de plano

• get_root_cause e get_incident_analytics retornam FeatureNotAvailable quando o plano atual não os inclui. Informe o usuário qual recurso não está disponível e pare. Não tente novamente.
• query_metrics retorna percentis como null no plano Gratuito. Trate percentis nulos como "não disponível no seu plano" e use a média/mediana onde disponível.
• get_monitor_availability: um uptimePct ausente significa que não houve medições durante o período, não 100%.