Arquitectura
Una instalación autoalojada de Status200 es un puñado de contenedores: un ingress por el que entra cada petición, una imagen de aplicación que hace el trabajo, sondas que ejecutan las comprobaciones de tus monitores y tres almacenes de datos. Esta página muestra cómo encajan, qué hace cada uno y qué conexiones atraviesan tu red.
Una instalación autoalojada de Status200
Qué muestra
- Las personas llegan a Status200 a través del ingress, que termina TLS y dirige cada petición a la aplicación: el Dashboard, las páginas de estado, la API y cada endpoint de ingesta al que se envía telemetría.
- La aplicación lee y escribe su estado en PostgreSQL, guarda la telemetría en ClickHouse y usa Valkey (el fork con licencia BSD de Redis 7.2) como caché y para las colas que procesan sus trabajos en segundo plano.
- Las sondas pueden ejecutarse dentro de tu clúster (recomendado) y/o en otro punto de tu red. Pueden monitorizar:
- Servicios internos/privados detrás de tu cortafuegos.
- Recursos externos/públicos en internet.
- Los resultados de las sondas se envían a la aplicación, se encolan en Valkey y los trabajos en segundo plano los procesan hacia tus almacenes de datos. Una sonda situada en otro punto de tu red llega a la aplicación a través del ingress, en tu URL de Status200.
- La telemetría (métricas, trazas, logs y más) la ingiere la misma aplicación y se guarda en ClickHouse.
Si usas PostgreSQL, Valkey (o Redis) o ClickHouse externos en lugar de los incluidos, la aplicación se conecta a tus endpoints externos. El flujo lógico sigue siendo el mismo.
Los componentes
| Componente | Servicio de Docker Compose | Chart de Helm | Qué hace |
|---|---|---|---|
| Ingress | ingress | nginx | Termina TLS, sirve tu nombre de host y los dominios de tus páginas de estado, y dirige cada petición a la aplicación. |
| Aplicación | app | app | El Dashboard, las páginas de estado, los endpoints de API e ingesta y, salvo que los separes, los trabajos en segundo plano. |
| Worker | Parte de app | worker (desactivado por defecto) | Los trabajos en segundo plano, en sus propios pods, para que el procesamiento intenso de colas nunca compita con las peticiones a la API. |
| Telemetry writer | Parte de app | telemetryWriter (desactivado por defecto) | Un nivel de tamaño fijo que hace cada inserción en ClickHouse, para que las inserciones se mantengan acotadas por mucho que escalen los workers. |
| Sonda | probe-1 | probes | Ejecuta las comprobaciones de los monitores y devuelve los resultados. Cada sonda incluida es una sonda global que pueden usar todos los proyectos. |
| Runner | runner | runner | El Runner propio de la instancia, que puede ejecutar correcciones de código con IA para cada proyecto. Los pasos de los runbooks se ejecutan en Runners que instalas donde deban ejecutarse. |
| Runner global | global-runner | globalRunner | Un Runner global: ejecuta los pasos JavaScript de todos los proyectos que no eligen un Runner propio, cada uno en un sandbox que solo llega a internet. Tiene su propia clave y nada más del servidor. |
| PostgreSQL | postgres | postgresql, o postgresOperator.cnpg | Proyectos, monitores, incidentes, usuarios y todos los demás ajustes y estados. |
| ClickHouse | clickhouse | clickhouse, o clickhouseOperator.altinity | Logs, métricas, trazas, excepciones, perfiles y logs de monitores. |
| Valkey | valkey | valkey | La caché, las colas de trabajos y el estado de corta duración, como los acuses de push pendientes. |
Todos los roles de la aplicación son la misma imagen: Docker Compose los ejecuta en un solo contenedor app, y el chart de Helm puede ejecutar el worker y el telemetry writer como despliegues propios. Para dimensionar cada nivel, consulta Dimensionamiento y planificación de capacidad.
Conexiones que salen de tu red
Se hacen tres conexiones a menos que cambies un ajuste:
- Una vez al día, la aplicación pregunta a la API de GitHub (
api.github.com) si hay una versión más reciente. Para desactivarlo, estableceupdateCheck.disabled: trueen el chart de Helm, oDISABLE_UPDATE_CHECK=trueenconfig.envcon Docker Compose. - Registrarse con «Notificarme sobre parches de seguridad y nuevas versiones» marcado, como está al principio, envía a
status200.ruel nombre y el correo de la persona, la empresa y el teléfono que haya indicado, y la dirección y la versión de tu instalación. Desmárcalo en una red sin acceso a internet. - En Kubernetes, las sondas recurren a los resolutores públicos
8.8.8.8y1.1.1.1después del DNS de tu propio clúster. EstablecednsConfig.nameserversen[]para que todas las consultas se queden en tu propio DNS.
Todo lo demás solo se conecta hacia fuera cuando lo activas, y cada conexión tiene una página que indica las direcciones exactas que hay que permitir:
| Conexión saliente | Se usa para | Dónde leer más |
|---|---|---|
| Correo (SMTP, o la API de SendGrid) | Notificaciones e invitaciones | SMTP |
| Twilio | SMS y llamadas telefónicas | Integración con Twilio |
| El relé de push de Status200, o Expo | Notificaciones push móviles | Notificaciones push |
| Slack y Microsoft Teams | Notificaciones y acciones en el espacio de trabajo | Integración con Slack |
| Un proveedor de LLM, como OpenAI, Anthropic, Microsoft Foundry o un modelo que ejecutas tú mismo | Status200 AI | Proveedores de LLM |
status200.ru | Activar una licencia Enterprise en línea | Edición Enterprise |
Las conexiones en sentido contrario – SendGrid entregando correo entrante, Slack y Microsoft Teams devolviendo llamadas – necesitan que el ingress sea accesible desde internet. Qué direcciones privadas pueden alcanzar la aplicación y las sondas lo decides tú: consulta Acceso a red privada.
El logotipo de Status200 va dentro de cada correo que envía Status200, así que se ve incluso en una red sin acceso a internet, y abrir un correo no le pide nada a ningún otro host. Las imágenes que subes tú, como tu propio logotipo o el de una página de estado, se muestran desde tu URL de Status200, a la que deben poder acceder quienes lean esos correos.