El hilo de la comunidad de IceWhale de 2023 sobre Uptime Kuma es más una introducción que una guía de instalación. La publicación indica que el tutorial cubre la instalación en CasaOS, mientras que las respuestas se centran en por qué las personas valoran Uptime Kuma: notificaciones de interrupciones, supervisión en producción de servicios no críticos y monitores push. El texto del foro en sí no conserva la configuración paso a paso del instalador.
Por lo tanto, una página actual debería conservar el contexto de CasaOS y los casos de uso de la comunidad, pero utilizar los requisitos de Docker mantenidos de Uptime Kuma para la implementación real.
Qué aporta Uptime Kuma a un servidor doméstico
Uptime Kuma es un panel de supervisión autohospedado. Puede comprobar si un sitio web, servicio TCP, endpoint DNS, destino de ping, servicio relacionado con Docker o tarea basada en push funciona correctamente, y enviar notificaciones cuando cambia su estado.
Las respuestas originales destacaban repetidamente las notificaciones como el valor práctico. Un panel es útil, pero el principal beneficio es enterarse de que un servicio está caído antes de que alguien de la casa lo comunique.
Usa el contenedor actual de Uptime Kuma
Las instrucciones actuales de implementación de Uptime Kuma utilizan la imagen mantenida louislam/uptime-kuma:2. La aplicación web escucha en el puerto 3001 y almacena su base de datos y configuración persistentes en /app/data.
Para una aplicación personalizada actual de CasaOS, traduce la configuración de instalación de Docker mantenida de Uptime Kuma al formulario de aplicaciones de CasaOS, en lugar de utilizar una etiqueta de imagen antigua de un vídeo de 2023.
Expón el panel en el puerto 3001
El servicio web del contenedor utiliza el puerto TCP 3001. Si ese puerto del host ya está ocupado, asigna otro puerto del host al puerto 3001 del contenedor y abre la aplicación de CasaOS mediante el puerto elegido del host.
Cambiar el puerto del host no requiere cambiar el puerto interno de Uptime Kuma, salvo que la aplicación ascendente lo admita explícitamente y necesite ese cambio.
Conserva /app/data
Asigna una carpeta del host de CasaOS o un volumen de Docker a /app/data. Este es el objetivo de copia de seguridad importante, ya que contiene la configuración de supervisión, los datos de usuario y la base de datos SQLite.
Si recreas el contenedor sin ese volumen persistente, se comportará como una instalación nueva de Uptime Kuma.
Mantén la base de datos en un sistema de archivos con bloqueo fiable
Las indicaciones actuales de Uptime Kuma advierten que la base de datos SQLite necesita un bloqueo de archivos POSIX fiable y desaconsejan específicamente sistemas de archivos como muchas configuraciones de NFS para su directorio de datos.
En un servidor doméstico, mantener /app/data en almacenamiento local es la opción más sencilla. Después puedes hacer una copia de seguridad de ese directorio local en otro disco o destino remoto.
Elige monitores que coincidan con la experiencia del usuario
Un monitor de ping solo demuestra que una máquina responde a ICMP. Si el requisito real es «Jellyfin debería cargar», un monitor HTTP para el endpoint de Jellyfin es más significativo.
Un conjunto práctico puede incluir:
- comprobaciones HTTP para aplicaciones web;
- comprobaciones TCP para servicios sin un endpoint web útil;
- comprobaciones DNS para Pi-hole o AdGuard Home;
- comprobaciones de ping para verificar la accesibilidad básica del host;
- monitores push para tareas programadas que deberían informar de su finalización.
Por qué importa el monitor push mencionado en el hilo
Un participante de la comunidad dijo específicamente que utilizaba monitores push con frecuencia. En lugar de que Uptime Kuma consulte un servicio, un script de copia de seguridad o una tarea programada llama a una URL única cuando se completa correctamente. Si ese latido no llega dentro del intervalo esperado, Uptime Kuma marca el monitor como no saludable.
Esto resulta útil para tareas en las que «el servidor está conectado» no demuestra que el trabajo se haya ejecutado realmente.
Prueba las notificaciones antes de la primera interrupción
Configura al menos un canal de notificaciones y activa deliberadamente una alerta de prueba. Un sistema de supervisión que falla silenciosamente al enviar notificaciones no es más que un panel histórico.
Para los servicios domésticos, considera también la fatiga por alertas. Supervisar cada endpoint menor con notificaciones inmediatas puede hacer que sea más fácil ignorar las interrupciones reales.
Mantén privado el panel de supervisión, a menos que el acceso remoto sea intencionado
Uptime Kuma puede revelar nombres de host internos, nombres de servicios, direcciones de red e historial de interrupciones. No lo expongas directamente a internet público simplemente porque la supervisión remota sea útil. Si necesitas acceso remoto, utiliza una VPN, una red superpuesta privada o un proxy inverso autenticado.
No trates el hilo de CasaOS de 2023 como una versión fijada actual
La discusión original elogia una aplicación bien mantenida, pero no conserva una versión de imagen. Esto es beneficioso: utiliza la versión ascendente actual en lugar de intentar recrear exactamente el contenedor que existía en septiembre de 2023.
Preguntas frecuentes sobre Uptime Kuma en CasaOS
¿Qué puerto utiliza la versión actual de Uptime Kuma?
El puerto 3001 para la interfaz web.
¿Qué directorio debe conservarse?
/app/data.
¿Por qué debería mantenerse el directorio de datos en almacenamiento local?
La base de datos SQLite necesita un bloqueo de archivos fiable, y las indicaciones actuales del proyecto desaconsejan los sistemas de archivos de red inadecuados.
¿Qué valoraba más la comunidad original?
Las notificaciones y la funcionalidad de los monitores push se destacaron repetidamente en las respuestas.
