Uptime, incidencias y solicitudes de soporte
Monitor public endpoints, route alerts, see incidents and raise requests to CostGlass engineers.
Uptime, incidencias y solicitudes de soporte
Vigile sus puntos finales públicos, reciba alertas cuando fallen, vea incidentes registrados y solicite ayuda a los ingenieros de CostGlass.
- Uptime envía una solicitud HTTP a cada URL pública que registra y registra el estado, el tiempo de respuesta y la caducidad del certificado. En producción, la verificación se realiza aproximadamente cada cinco minutos.
- Una verificación pasa solo con una respuesta 2xx dentro de los 5 segundos. Cualquier otra cosa marca el servicio como Degradado y activa una alerta.
- Las alertas van a Slack, PagerDuty, Microsoft Teams o al correo electrónico, por categoría de entorno o por servicio.
- La página Incidentes enumera los incidentes abiertos registrados para su organización. CostGlass no los genera automáticamente a partir de comprobaciones fallidas y la página no tiene un botón de creación.
- Support & Requests es su escritorio para los ingenieros de CostGlass: plantee una tarea, error, solicitud de función o pregunta y realice un seguimiento.
- Un plan de crecimiento, escala o empresa. El elemento del menú Tiempo de actividad está atenuado debajo de Crecimiento.
- Rol de propietario o administrador para registrar servicios, cambiar categorías o canales.
- Una URL pública HTTP o HTTPS que devuelve un estado 2xx cuando está en buen estado, como /health, /healthz o /status. Debería ser seguro llamar repetidamente.
- Para alertas: un webhook entrante de Slack, un webhook de Teams, una clave de integración de PagerDuty o una dirección de correo electrónico.
Qué puede y qué no puede monitorizar Uptime
El tiempo de actividad es una verificación sintética: CostGlass realiza un HTTP GET a la URL que usted le proporciona y juzga la respuesta. Sólo puede monitorear puntos finales HTTP/HTTPS públicos. Una función Lambda, una base de datos RDS o una carga de trabajo de Kubernetes sin URL no se pueden observar de esta manera; para el estado de aquellos, utilice Recursos Cloud. Una tarjeta de página en Uptime dice lo mismo y enlaza a las plantillas de descubrimiento.
Tiempo de actividad: reglas de notificación de categorías arriba, servicios monitoreados a continuación.
| que esta grabado | Detalle |
|---|---|
| Estado | Saludable cuando la respuesta es 2xx; Degradado de lo contrario (incluidos tiempos de espera y errores de conexión). Se siguen las redirecciones. |
| Estado latente | Tiempo de respuesta del último cheque. Se muestra como P99 en la fila de servicio. |
| SSL | Días hasta que caduque el certificado HTTPS. La fila se vuelve ámbar y luego roja a medida que se acerca. |
| % de tiempo de actividad | Una cifra continua que aumenta en 0,01 por cada verificación exitosa y cae en 0,05 por cada falla, entre 0 y 100. Es un indicador de tendencia, no un verdadero cálculo de disponibilidad de 30 días. |
Añadir un servicio
https://api.example.com/health. Sin una URL, el formulario se niega a guardarse.The service list has filter buttons for all, healthy, degraded and down, and per row: 🔔 Test, ⚙ Alert, edit and delete (with confirmation). Click a service for its detail page: Current Status, SSL Expires In, Response Latency and Service Status charts. Los nuevos servicios necesitan algunas comprobaciones antes de que se completen los cuadros.
Canales de alerta
Reglas de categoría
Service Notification Rules by Category defines default channels per environment (prod, sandbox, staging, or categories you add with + Add Category). Cada categoría se puede habilitar o deshabilitar, muestra No hay canales configurados o Silencio cuando no hay nada configurado y puede notificar sobre estados degradados y inactivos. Las categorías personalizadas se pueden eliminar.
Anulación por servicio
Click ⚙ Alert on a service and choose Select Alert Routing Behavior: inherit the category's channels, or Custom Alert Channels Override for this specific service. Agregue destinos con los botones Slack, PagerDuty, Teams y Email, y envíe una prueba a cada uno.
| Canal | tu proporcionas |
|---|---|
| Flojo | Un nombre de canal y/o una URL de webhook entrante (https://hooks.slack.com/…). |
| Servicio de buscapersonas | Una clave de integración de 32 caracteres. |
| Equipos de Microsoft | Una URL de webhook de Teams o Workflows. |
| Correo electrónico | Una o más direcciones. |
- Las URL y las claves de los webhooks son de solo escritura: después de guardar, solo verá los últimos caracteres y, al dejar el campo en blanco, se conserva el valor guardado.
- Los hosts de Webhook se comparan con una lista permitida de hosts reales de Slack y Teams; cualquier otra cosa es rechazada.
- Los correos electrónicos de prueba siempre van solo a su propia dirección, cualesquiera que sean los destinatarios configurados. Las alertas reales van a los destinatarios guardados.
- Una prueba de PagerDuty crea un incidente real en PagerDuty.
- Solo los propietarios y administradores pueden cambiar categorías y canales, y no se puede probar un servicio sin nada configurado.
LÃmites y consideraciones de las alertas
- El verificador marca las fallas como Degradadas; el filtro Inactivo existe, pero una verificación fallida no produce actualmente un estado Inactivo separado.
- Solo se realizan comprobaciones HTTP (y comprobaciones de implementación de Kubernetes para servicios vinculados a un clúster).
- Los secretos de canales guardados para servicios individuales se guardan en la base de datos; Los secretos de las reglas de anomalía se guardan en un almacén de secretos.
Incidencias
Incidents (titled Production Incident Management) shows open incidents as cards with title, description, severity P1 to P4, status and start time, or No open incidents with an All Clear badge.
| Gravedad | Color | Significado |
|---|---|---|
| P1 | Rojo | Más grave. |
| P2 | Ámbar | Grave. |
| P3 | Azul | Moderado. |
| P4 | Verde | Menor. |
La cabina de descripción general de operaciones resume los servicios en línea, los activos descubiertos, los incidentes abiertos y sus solicitudes activas.
Soporte y solicitudes
Plantee cualquier cosa que necesite de CostGlass: trabajo de DevOps/SRE, una solicitud de función, un informe de error o una pregunta. Open Support & Requests and click + New Request.
¿Qué sucede después de enviar
- El correo electrónico va a los ingenieros asignados a su organización y a los operadores de la plataforma CostGlass, vinculando a la solicitud en el Back Office de su región.
- Recibirá un correo electrónico de confirmación. Si su cuenta no tiene una dirección de correo electrónico registrada, no hay nada que enviar.
- Cuando se asigna un ingeniero, se le envía un correo electrónico. Cuando el estado cambia, se le envía un correo electrónico.
- Los problemas de correo electrónico nunca impiden que se guarde la solicitud.
Leyendo la página
The KPI strip shows Active Requests, SLA & Resolution, Assigned SRE Bench and Completed Tasks. Las pestañas filtran por Todo, En curso, Abierto y Completado; un menú desplegable de prioridad y una búsqueda reducen la lista. Los estados son Abierto, En progreso, En espera de revisión y Completado.