Arquitetura
Uma instalação auto-hospedada do Status200 é um punhado de contêineres: um ingress por onde entra cada requisição, uma imagem de aplicação que faz o trabalho, sondas que executam as verificações dos seus monitores e três armazenamentos de dados. Esta página mostra como eles se encaixam, o que cada um faz e quais conexões atravessam a sua rede.
Uma instalação auto-hospedada do Status200
O que isto mostra
- As pessoas chegam ao Status200 pelo ingress, que termina o TLS e encaminha cada requisição para a aplicação: o Dashboard, as páginas de status, a API e cada endpoint de ingestão para onde a telemetria é enviada.
- A aplicação lê e grava o seu estado no PostgreSQL, guarda a telemetria no ClickHouse e usa o Valkey (o fork com licença BSD do Redis 7.2) como cache e para as filas que as suas tarefas em segundo plano processam.
- As sondas podem rodar dentro do seu cluster (recomendado) e/ou em outro ponto da sua rede. Elas podem monitorar:
- Serviços internos/privados atrás do seu firewall.
- Recursos externos/públicos na internet.
- Os resultados das sondas são enviados para a aplicação, enfileirados no Valkey e processados pelas tarefas em segundo plano para os seus armazenamentos de dados. Uma sonda em outro ponto da sua rede chega à aplicação pelo ingress, na sua URL do Status200.
- A telemetria (métricas, traces, logs e mais) é ingerida pela mesma aplicação e armazenada no ClickHouse.
Se você usa PostgreSQL, Valkey (ou Redis) ou ClickHouse externos em vez dos incluídos, a aplicação se conecta aos seus endpoints externos. O fluxo lógico continua o mesmo.
Os componentes
| Componente | Serviço do Docker Compose | Chart do Helm | O que faz |
|---|---|---|---|
| Ingress | ingress | nginx | Termina o TLS, atende o seu nome de host e os domínios das suas páginas de status e encaminha cada requisição para a aplicação. |
| Aplicação | app | app | O Dashboard, as páginas de status, os endpoints de API e de ingestão e, a menos que você os separe, as tarefas em segundo plano. |
| Worker | Parte de app | worker (desligado por padrão) | As tarefas em segundo plano, em pods próprios, para que o processamento pesado das filas nunca concorra com as requisições à API. |
| Telemetry writer | Parte de app | telemetryWriter (desligado por padrão) | Uma camada de tamanho fixo que faz cada inserção no ClickHouse, para que as inserções continuem limitadas por mais que os workers escalem. |
| Sonda | probe-1 | probes | Executa as verificações dos monitores e envia os resultados de volta. Cada sonda incluída é uma sonda global que todos os projetos podem usar. |
| Runner | runner | runner | O Runner próprio da instância, que pode executar correções de código com IA para cada projeto. Os passos dos runbooks rodam em Runners que você instala onde eles devem rodar. |
| Runner global | global-runner | globalRunner | Um Runner global: executa as etapas JavaScript de todos os projetos que não escolhem um Runner próprio, cada uma em um sandbox que só alcança a internet. Tem a sua própria chave e nada mais do servidor. |
| PostgreSQL | postgres | postgresql, ou postgresOperator.cnpg | Projetos, monitores, incidentes, usuários e todas as outras configurações e estados. |
| ClickHouse | clickhouse | clickhouse, ou clickhouseOperator.altinity | Logs, métricas, traces, exceções, perfis e logs de monitores. |
| Valkey | valkey | valkey | O cache, as filas de tarefas e o estado de curta duração, como os recibos de push pendentes. |
Todos os papéis da aplicação são a mesma imagem: o Docker Compose os executa em um único contêiner app, e o chart do Helm pode executar o worker e o telemetry writer como deployments próprios. Para dimensionar cada camada, veja Dimensionamento e planejamento de capacidade.
Conexões que saem da sua rede
Três conexões são feitas, a menos que você mude uma configuração:
- Uma vez por dia, a aplicação pergunta à API do GitHub (
api.github.com) se saiu uma versão mais nova. Para desligar isso, definaupdateCheck.disabled: trueno chart do Helm, ouDISABLE_UPDATE_CHECK=truenoconfig.envcom o Docker Compose. - Cadastrar-se com “Notifique-me sobre patches de segurança e novas versões” marcado, como vem de início, envia para
status200.ruo nome e o e-mail da pessoa, a empresa e o telefone que ela informou, e o endereço e a versão da sua instalação. Desmarque essa opção em uma rede sem acesso à internet. - No Kubernetes, as sondas recorrem aos resolvedores públicos
8.8.8.8e1.1.1.1depois do DNS do seu próprio cluster. DefinadnsConfig.nameserverscomo[]para manter todas as consultas no seu próprio DNS.
Todo o resto só se conecta para fora quando você o ativa, e cada um tem uma página que indica os endereços exatos a liberar:
| Conexão de saída | Usada para | Onde ler mais |
|---|---|---|
| E-mail (SMTP, ou a API do SendGrid) | Notificações e convites | SMTP |
| Twilio | SMS e chamadas telefônicas | Integração com o Twilio |
| O relay de push do Status200, ou o Expo | Notificações push móveis | Notificações push |
| Slack e Microsoft Teams | Notificações e ações no workspace | Integração com o Slack |
| Um provedor de LLM, como OpenAI, Anthropic, Microsoft Foundry ou um modelo que você mesmo executa | Status200 AI | Provedores de LLM |
status200.ru | Ativar uma licença Enterprise online | Edição Enterprise |
As conexões no sentido contrário – o SendGrid entregando e-mails recebidos, o Slack e o Microsoft Teams chamando de volta – exigem que o ingress seja acessível pela internet. Quais endereços privados a aplicação e as sondas podem alcançar é você quem decide: veja Acesso à rede privada.
O logotipo do Status200 vai dentro de cada e-mail que o Status200 envia, então ele aparece até em uma rede sem acesso à internet, e abrir um e-mail não pede nada a nenhum outro host. As imagens que você mesmo envia, como o seu próprio logotipo ou o de uma página de status, são mostradas a partir da sua URL do Status200, que quem lê esses e-mails precisa conseguir acessar.