Monitor de página de status externa

Um monitor de página de status externa acompanha a página de status pública de um serviço do qual você depende (AWS, GCP, Azure, GitHub, OpenAI, Anthropic e muitos outros) e alerta você quando esse provedor informa uma interrupção ou desempenho degradado. Use-o para saber de problemas nos seus provedores assim que eles os informam, e para separá-los dos seus.

Ele também lê páginas de status criadas com o Status200, recurso por recurso, e distingue manutenção planejada de uma interrupção: acompanhe o projeto de outra equipe, ou um provedor cuja página de status roda no Status200.

Como funciona#

A cada verificação, uma sonda baixa a página de status, descobre o formato dela e lê o status geral, os componentes e os incidentes ativos. Se você limitou o monitor a um grupo de componentes ou a um componente, só eles contam. Depois, os critérios decidem se o monitor está online ou offline.

Você pode usá-lo para:

• Monitorar a disponibilidade dos serviços de terceiros dos quais seu aplicativo depende
• Ser alertado quando provedores externos sofrem interrupções
• Acompanhar o status de cada componente
• Limitar o monitoramento a um único grupo de componentes (por exemplo, só as "APIs" da OpenAI), para que incidentes sem relação em outras partes da página não disparem seu monitor
• Detectar desempenho degradado antes que ele afete seus usuários
• Relacionar seus próprios incidentes com problemas dos provedores externos

Provedores compatíveis#

Detecção automática#

Com Auto, o Status200 detecta automaticamente o formato da página de status, nesta ordem:

1. Primeiro, tenta a API de páginas de status do incident.io (/proxy/<host>).
2. Depois, tenta a API JSON do Atlassian Statuspage (/api/v2/status.json, /api/v2/components.json e /api/v2/incidents/unresolved.json).
3. Em seguida, pede o resumo de uma página de status do Status200 (/status-page-api/summary/<page>).
4. Se essas falharem, tenta ler a página como um feed RSS ou Atom.
5. Como último recurso, faz uma verificação básica de acessibilidade HTTP.

A verificação de acessibilidade também é o último recurso quando um provedor escolhido explicitamente falha. Ela só diz se a página responde (online com uma resposta 2xx ou 3xx) e não informa componentes nem incidentes.

Criar um monitor de página de status externa#

1. Começar um novo monitor#

   Vá para Monitores e clique em Criar monitor. Em Tipo de monitor, clique em Mais tipos de monitor e escolha External Status Page em Basic Monitoring, ou digite statuspage na caixa de pesquisa. Digite um Nome e clique em Próximo.

2. Informar a URL da página de status#

   Informe a URL da Página de Status. Deixe o Provedor em Auto, a menos que você conheça o formato.

3. Delimitar o escopo, se precisar#

   Abra Mais campos para informar um Component Group Filter, como APIs, e um Filtro de nome de componente para acompanhar um único componente (dentro do grupo, se houver um grupo definido).

4. Testar#

   Clique em Testar monitor para baixar a página uma vez, e confira o provedor, os componentes e os incidentes encontrados.

5. Revisar os critérios#

   A etapa de critérios começa com os critérios padrão, que marcam o monitor como offline quando o provedor informa um incidente ativo ou uma interrupção dentro do escopo. Altere-os se precisar e clique em Próximo.

6. Escolher as sondas e criar#

   Selecione as Sondas e um Intervalo de monitoramento (começa em A cada 5 minutos) e clique em Criar monitor.

Opções de configuração#

Component Group Filter#

Se a página de status organiza seus componentes em grupos, você pode limitar o monitor a um único grupo. Por exemplo, em https://status.openai.com, informar APIs limita o monitor aos serviços de API da OpenAI.

Quando um grupo de componentes está definido, o número de incidentes ativos e o status geral são calculados só com os componentes desse grupo: um incidente que afeta um grupo sem relação (por exemplo, o ChatGPT) não vai disparar um monitor limitado ao grupo "APIs".

A filtragem por grupo de componentes é compatível com os provedores Atlassian Statuspage, incident.io e Status200 Status Page. Feeds RSS e Atom não expõem grupos de componentes.

Filtro de nome de componente#

Se a página de status informa vários componentes, você pode indicar o nome de um componente para monitorar só ele. O filtro corresponde a qualquer componente cujo nome contenha o que você digitar, sem diferenciar maiúsculas de minúsculas: actions corresponde a um componente chamado "Actions".

Quando um grupo de componentes também está definido, o filtro de nome de componente é aplicado dentro desse grupo, permitindo mirar em um único componente dentro de um grupo maior. Quando nenhum filtro é informado, todos os componentes do escopo são monitorados. Em um feed RSS ou Atom, o filtro de nome é comparado com os títulos dos itens do feed.

Critérios de monitoramento#

Você pode configurar critérios para decidir quando o serviço externo é considerado online ou offline, com base em:

O status geral é o que a página diz, então os valores dele variam conforme o provedor: uma Atlassian Statuspage informa a própria descrição, como All Systems Operational; uma página de status do Status200, o pior status entre os componentes no escopo, como under_maintenance; um feed informa operational ou degraded_performance; a verificação de acessibilidade informa reachable ou unreachable. Essas comparações diferenciam maiúsculas de minúsculas. Para alertar sobre interrupções, External Status Page Active Incidents e External Status Page Component Status costumam ser mais confiáveis.

Em um feed RSS ou Atom, os itens das últimas 24 horas contam como incidentes ativos: um item RSS pela data de publicação, uma entrada Atom pela data de atualização. Um item com data no futuro só conta a partir dessa data.

Critérios padrão#

Por padrão, o Status200 cria critérios baseados no que realmente importa em uma página de status (os incidentes ativos e a saúde dos componentes) e não na simples acessibilidade:

Como o número de incidentes ativos e os status dos componentes respeitam os filtros de grupo e de nome de componente, esses critérios padrão miram automaticamente só nos componentes que interessam a você.

Páginas de status do Status200#

Escolha Status200 Status Page como provedor, ou deixe Auto, para acompanhar uma página de status criada com o Status200: o projeto de outra equipe, ou a página de um provedor no Status200 Cloud ou num Status200 auto-hospedado. Informe o endereço da própria página em URL da Página de Status: o domínio dela, como https://status.example.com, ou https://status200.ru/status-page/<status-page-id> para uma página sem domínio próprio.

O monitor lê o resumo da página, /status-page-api/summary/<page> (veja Ler o resumo): só o que a página mostra aos visitantes, e nada mais do outro projeto. Cada recurso da página, um monitor ou um grupo de monitores, é um componente, com o nome que a página dá a ele, no grupo da página; um grupo dentro de outro fica Core / Databases. Acompanhe um recurso com Filtro de nome de componente, ou um grupo com Component Group Filter.

O status de um componente é o valor que o status dele na página representa, então os critérios de status de componente funcionam como em qualquer página de status:

Enquanto um evento de manutenção programada em andamento afeta um recurso, porque nomeia um dos monitores dele ou um monitor do grupo de monitores dele, o componente fica under_maintenance, seja qual for o status dos monitores: um monitor não é verificado enquanto um evento o segura. Um evento que ainda vai acontecer, ou que já terminou, não muda nada. Os incidentes ativos da página contam para os recursos que eles afetam.

Os critérios padrão nunca tomam uma manutenção por uma interrupção: o monitor continua online durante o trabalho planejado do outro projeto.

Mostrar no seu monitor a manutenção do outro projeto#

1. Adicionar o critério#

   Nos critérios do monitor, clique em Adicionar critérios. Dê a ele o filtro External Status Page Component Status, Igual a, Under Maintenance, e escolha o seu status de manutenção em Alterar status do monitor para.

2. Levá-lo para o topo#

   Arraste o novo critério para cima dos outros: vence o primeiro critério que corresponde.

3. Conferir com Testar monitor#

   Clique em Testar monitor enquanto o outro projeto tem uma manutenção em andamento: o componente afetado mostra Under Maintenance.

O que uma página de status do Status200 deixa o monitor ler#

Uma página que qualquer pessoa pode abrir é lida como os visitantes a veem. Uma página privada, que pede login, SSO ou uma senha, não pode ser lida: com Status200 Status Page escolhido, a verificação falha e diz por quê. Uma página com uma lista de IPs permitidos precisa liberar o endereço da sonda: acompanhe-a a partir de uma sonda dentro dessa rede.

Variáveis de modelo#

Ao criar incidentes ou alertas a partir de monitores de página de status externa, você pode usar estas variáveis em títulos, descrições e notas de correção (veja Modelos de incidentes e alertas):

URLs de páginas de status populares#

Aqui está uma lista de páginas de status de serviços populares. Muitas usam o Atlassian Statuspage ou o incident.io, então o provedor Auto as detecta automaticamente. Uma página que não é baseada em nenhum dos dois, e que não é um feed, só recebe a verificação de acessibilidade: nesses casos, monitore o feed RSS ou Atom do provedor, se ele publicar um.

Boas práticas#

• Use o provedor Auto, a menos que você saiba o formato exato: a detecção automática funciona bem na maioria das páginas de status.
• Limite a um grupo de componentes se você só depende de uma parte de um provedor (por exemplo, só das "APIs" da OpenAI), para que incidentes sem relação não façam barulho.
• Monitore componentes específicos se você só depende de certos serviços.
• Combine com seus próprios monitores: junte os monitores de página de status externa aos seus monitores de API e de site. Quando os dois caem ao mesmo tempo, a página de status do provedor leva você mais rápido à causa raiz.

Solução de problemas#

Próximos passos#