Monitorización de flota por mTLS

Cada servidor de tu flota, una vista verde de control.

Un agente ligero transmite métricas y señales de seguridad por TLS mutuo. Servers Sentinel puntúa cada host, alerta en los canales que ya usas y marca la fuerza bruta en cuanto empieza.

Primer servidor gratis. Sin tarjeta, instalación en una línea.

Pensado para flotas mixtas Windows y Linux

systemd + servicio de Windowsamd64 · arm64 · 386ingesta mTLSautoalojado o gestionado
01Por qué

Entre reportes, la flota se queda a ciegas

Para cuando el panel se refresca, el incidente ya tiene una hora. Servers Sentinel cierra esa brecha.

Puntos ciegos

Un host deja de reportar y nadie lo nota hasta que lo hace un usuario. La cobertura no debería depender de quién mira la pantalla.

Fatiga de alertas

Cada herramienta tiene su bandeja. Las señales se dispersan entre correo, chat y webhooks hasta que todas se ignoran.

Fuerza bruta silenciosa

El adivinado de contraseñas por RDP y SSH corre horas antes de aparecer en la revisión de logs. Debería surgir en segundos.

Deriva de configuración

Umbrales fijados por servidor se desincronizan con el tiempo. Un valor por defecto debería cascadear, con anulaciones por host encima.

Un agente, una consola, una puntuación por host

Servers Sentinel recoge métricas localmente, las transmite por TLS mutuo y las condensa en una puntuación de salud y una alerta clara. Las plantillas globales cascadean a cada servidor; cualquier host anula una clave sin romper el valor por defecto.

02Cómo funciona

De la instalación a la alerta en cuatro pasos

Nada que compilar, ningún puerto entrante que abrir. Todo sale saliente por TLS.

  1. 01

    Añade un servidor

    Registra un host en el panel y obtén un comando de instalación de una línea con un token de alta efímero.

  2. 02

    Ejecuta el instalador

    El script detecta SO y arquitectura, instala el agente como servicio y lo da de alta por mTLS.

  3. 03

    Míralo reportar

    CPU, memoria, disco y red llegan según un ritmo. Cada host recibe una puntuación de salud en vivo.

  4. 04

    Enruta las alertas

    Las reglas disparan a correo, Telegram, Slack o webhook. La fuerza bruta se detecta en el agente y se marca al instante.

03Funciones

Todo lo que hace la consola

El bucle central hoy, con seguridad, discos y bases diseñados como módulos enchufables.

01

Métricas en vivo

CPU, memoria, disco y red por host, guardadas como series temporales y dibujadas en sparklines legibles de un vistazo.

02

Config de dos niveles

Las plantillas globales fijan los valores por defecto; cada servidor anula solo las claves necesarias. Las anulaciones cascadean, nunca bifurcan.

03

Ingesta mTLS

Cada agente tiene un certificado de cliente. La ingesta está autenticada mutuamente: un token filtrado por sí solo no abre nada.

04

Detección de fuerza bruta

El agente vigila la autenticación RDP y SSH localmente y reporta un ataque activo con las IP de origen principales.

05

Puntuación de salud

Cada host se reduce a una única puntuación 0-100, así una flota de cientos se ordena por lo que necesita atención.

06

Alertas multicanal

Correo, Telegram, Slack y webhooks. Añade un canal, envía una prueba y enruta reglas hacia él.

07

Equipos multiinquilino

Usuarios, equipos y roles (lector, operador, admin) aíslan la flota de cada cliente tras un único acceso.

08

Agentes multiplataforma

Un protocolo para una unidad systemd en Linux y un servicio de Windows, en amd64, arm64 y 386.

04Precios

Precios que escalan con la flota

Empieza gratis en un servidor. Paga por número de hosts, al mes o al año.

Free

0 €/mes
1 servidor
Para un solo host o un primer vistazo a la consola.
  • 1 servidor monitorizado
  • Métricas + puntuación
  • Alertas por correo
  • Detección de fuerza bruta
  • Roles de equipo

Solo

9 €/mes
por servidor / mes
Para un puñado de hosts de producción.
  • Hasta 5 servidores
  • Todas las series
  • Correo + Telegram
  • Detección de fuerza bruta
  • Roles de equipo

Team

El más elegido
29 €/mes
al mes
Para una flota con más de un operador.
  • Hasta 50 servidores
  • Todos los canales de alerta
  • Detección de fuerza bruta
  • Equipos + roles
  • Plantillas de config

Business

99 €/mes
al mes
Para flotas gestionadas y operadores multiinquilino.
  • Servidores ilimitados
  • Aislamiento multiinquilino
  • Soporte prioritario
  • Opción autoalojada
  • Registro de auditoría

14 días de Pro gratis, sin tarjeta

Regístrate y vigila toda tu flota: historial de métricas, comprobaciones de disponibilidad y de API, alertas de Telegram e informes. Al terminar no se cobra nada: la cuenta vuelve a Free y la monitorización de un servidor sigue funcionando.

Empezar la prueba gratuita
05Casos

Cuándo un parque de servidores tiene que vigilarse de verdad

Quince situaciones en las que no saber qué está haciendo un servidor deja de ser un riesgo aceptable. Si reconoce su propio parque en alguna de ellas, el hueco ya está ahí: sencillamente todavía no le ha costado nada.

fleetlast seen04:12nobody was told17 up1 unknown

Cuándo se vuelve necesario monitorizar un parque de servidores

El primer grupo trata de lo que pasa desapercibido. Ninguna de estas situaciones es negligencia: aparecen en cuanto el número de máquinas supera al que una persona puede tener en la cabeza, que en la mayoría de los equipos son unas cuatro.

  1. 01

    Un host se queda callado y nadie se entera hasta que llama un usuario

    Una máquina deja de reportar. Puede haberla reiniciado un hipervisor, puede haber perdido la ruta, haberse quedado sin memoria, o simplemente haberla apagado alguien que ordenaba un bastidor. Nada lo anuncia: un servidor ausente no genera ningún error, y el silencio es exactamente lo que produce también uno sano.

    Todo el problema está en el hueco entre el fallo y la llamada. Suele medirse en horas, siempre lo descubre la peor persona posible, y para entonces la pregunta ya no es qué se rompió, sino por qué no lo sabía nadie.

    • Una máquina virtual que nunca volvió de una migración de anfitrión
    • Un agente o servicio que murió en silencio tras actualizar un paquete
    • Una delegación cuyo enlace se cayó de madrugada
    • Una máquina que todos daban por supuesto que vigilaba otro
  2. 02

    Un disco se llena a las tres de la madrugada y se lleva una base de datos por delante

    Quedarse sin disco es la caída más previsible que existe. Los registros crecen, una copia se escribe dos veces, una tabla temporal no se limpia nunca, y la curva de espacio libre lleva quince días apuntando al mismo día.

    Es además la caída cuya recuperación sale más cara, porque una base de datos que se queda sin espacio a mitad de una escritura no se detiene con educación. La diferencia entre un aviso al 80 % y una llamada al 100 % es la diferencia entre dos minutos de limpieza y una restauración desde la copia de anoche.

  3. 03

    Algo se degrada durante semanas antes de fallar del todo

    Fugas de memoria, agotamiento del grupo de conexiones, una cola que se vacía un poco más despacio cada día, un certificado a un mes de caducar: nada de eso es un evento. Son pendientes, y una pendiente es invisible para quien solo mira el valor actual.

    Sin histórico no hay nada con lo que comparar. «¿Un 70 % de memoria es normal en este host?» no tiene respuesta si nada registró qué era lo normal, y ese registro tenía que estar funcionando antes de que a nadie se le ocurriera preguntar.

  4. 04

    El parque es Windows y Linux y nadie tiene una vista única

    La mayoría de los parques reales son mixtos: un par de servidores Windows para la contabilidad y el recurso compartido, un puñado de máquinas Linux para la web y la base de datos, quizá algo en ARM en una sede remota. Cada plataforma tiene sus propias herramientas nativas y ninguna habla con la otra.

    Así que el cuadro se monta a mano, en la cabeza de quien esté de turno, a partir de una consola de servicios, una sesión SSH y el panel del proveedor. Y se monta solo cuando alguien va a mirar, es decir, cuando algo ya ha salido mal.

    • El visor de eventos por un lado, journalctl por otro, sin línea de tiempo común
    • Los mismos umbrales significando cosas distintas en cada plataforma
    • Una arquitectura que nadie normalizó, porque creció en vez de diseñarse
  5. 05

    Las máquinas están en varios sitios a la vez

    Un servidor en la oficina, dos en un proveedor, tres en una nube, uno en otra por una migración que nadie terminó, y una caja en una delegación instalada antes de que llegara el equipo actual. Cada uno tiene su espacio de direcciones, su vía de acceso y su responsable.

    No hay una consola única que los abarque, porque nunca se compraron como una sola cosa. Lo que hace falta es un sitio que los trate como un solo parque, independientemente de dónde esté físicamente cada uno.

db-01disk 96%email34chat61webhook88sms115four inboxes · one incidentalerts / week1 240read: few

Cuando la señal existe pero nunca llega a una persona

El segundo grupo trata de la distancia entre «era detectable» y «alguien hizo algo». La mayoría de los incidentes que duelen estuvieron visibles en un registro todo el tiempo; el fallo ocurrió en los últimos metros, entre la máquina y un ser humano.

  1. 06

    Cada herramienta tiene su propia bandeja y las señales se dispersan

    Un sistema manda correos, otro publica en un canal de chat, un tercero dispara un webhook, el proveedor envía SMS, y el software de copias deja un informe en una carpeta que nadie ha abierto desde que se configuró.

    Nada se correlaciona. El mismo incidente produce cuatro notificaciones con cuatro nombres distintos en cuatro sitios, y el trabajo de darse cuenta de que son el mismo incidente le toca a quien casualmente estaba mirando la ventana correcta.

  2. 07

    Fatiga de alertas: todo avisa, así que nada avisa

    Una monitorización sin ajustar alerta sin parar: un pico de CPU durante una tarea nocturna, un disco que cruza un umbral que cruza todas las semanas, un servicio que se reinicia tal y como está previsto. La gente aprende muy rápido que eso se puede ignorar, y tiene razón hasta el día en que no la tiene.

    Una vez que un canal ha enseñado a sus lectores a saltárselo, añadir más alertas empeora las cosas en lugar de mejorarlas. La medida útil no es cuánto se detecta, sino cuánto llega a alguien que después hace algo.

    • Un canal de chat silenciado por media plantilla
    • Una regla de correo que archiva las alertas en una carpeta que nadie lee
    • Un incidente real encontrado más tarde, en un canal donde llevaba todo el tiempo
  3. 08

    Nadie está de guardia de noche, en fin de semana ni en agosto

    Los equipos pequeños y medianos no llevan turnos. La persona que conoce los sistemas está durmiendo, en un avión o de vacaciones, y al incidente le da igual. Por eso todo tiene que ser comprensible para quien esté realmente disponible, incluida una persona que no construyó nada de esto.

    Eso impone un requisito duro a lo que una alerta debe decir. «db-01 CPU 96 %» no significa nada a las tres de la madrugada para alguien que nunca ha entrado en db-01; qué ocurrió alrededor y a qué se parece lo normal marcan la diferencia entre arreglarlo y encadenar llamadas.

  4. 09

    Los umbrales puestos máquina a máquina acaban desalineados

    Cada servidor se configuró a mano, en un momento distinto, por una persona distinta, con una idea distinta de qué justifica despertar a alguien. Dos años después no hay dos máquinas que coincidan, nadie recuerda por qué una está al 85 % y otra al 95 %, y cambiarlas todas significa visitarlas todas.

    Lo que un parque necesita es otra cosa: un valor por defecto que se propague a todas partes y excepciones por host visibles como excepciones, para que una desviación sea una decisión deliberada y revisable, y no un accidente de la historia.

  5. 10

    La adivinación de contraseñas aparece en una revisión de registros semanas después

    Un puerto RDP o SSH expuesto está bajo ataque de forma continua, y una contraseña acertada se parece, en el registro, casi exactamente a un acceso normal. Las pruebas están ahí -una subida de fallos, un origen desconocido, un primer acceso con éxito desde un país nuevo-, pero solo como líneas en un fichero que nadie lee a diario.

    La detección, por tanto, tiene que ser algo que hace la máquina y no algo que hace una persona una vez al trimestre. La ventana que importa es la que va del primer intento al primer acierto, y suele medirse en horas.

    • Un pico de accesos fallidos que nadie representó en una gráfica
    • Un acceso con éxito a una hora a la que esa cuenta no entra nunca
    • La misma dirección de origen apareciendo a la vez en varios servidores
30 days2 incidents · both reportedthis month99.7%availabilityexported · signed

Cuando el contrato, la auditoría o el cliente piden el registro

El tercer grupo trata del momento en que alguien de fuera del equipo técnico necesita una respuesta. La disponibilidad, el historial de incidentes y la prueba de que se estaba vigilando existen como registro o no existen en absoluto: no se reconstruyen después de memoria.

  1. 11

    Un SLA o un contrato con un cliente exige prueba de disponibilidad

    En cuanto la disponibilidad se escribe en un acuerdo, deja de ser una sensación y pasa a ser una cifra que hay que presentar cada mes, defender si se discute y calcular igual todas las veces. «Que sepamos, estuvo funcionando» no es una medición.

    El registro también protege en el sentido contrario. La mayoría de las discusiones sobre disponibilidad van sobre de quién fue la culpa de una caída, y una cronología que muestra que el host estaba sano mientras el enlace del propio cliente estaba caído zanja la conversación más rápido que cualquier argumento.

    • Una cifra mensual de disponibilidad que se le debe a un cliente
    • Una cláusula de penalización activada por un umbral que nadie mide
    • Un incidente cuyo inicio y fin hacen falta al minuto
  2. 12

    Un auditor o una aseguradora pregunta cómo se supervisan los sistemas

    Las solicitudes de ciberseguro, las revisiones de proveedores y los marcos regulatorios de datos de pago y personales preguntan todos una variante de lo mismo: cómo sabe usted que sus sistemas funcionan como deben, y cómo se enteraría de que han dejado de hacerlo.

    Lo que se pide no es el nombre de una herramienta. Es prueba de que la supervisión fue continua durante el periodo revisado, de que las alertas fueron a un sitio donde una persona las leía, y de que los incidentes quedaron registrados en lugar de recordados.

  3. 13

    Un solo administrador vigila servidores de muchos clientes

    Los proveedores de servicios gestionados, los administradores de sistemas autónomos y las pequeñas empresas de informática llevan decenas de máquinas repartidas entre empresas, proveedores y arquitecturas de red distintas. Cada cliente tiene su horario, su tolerancia a la interrupción y su propia idea de qué es urgente.

    Configurarlas de una en una a mano no escala, ni tampoco enterarse de un problema solo cuando llama el cliente. Un parque así necesita una base común aplicada en todas partes, excepciones por cliente allí donde uno realmente difiere, y un único muro donde se vea todo a la vez.

  4. 14

    Todo lo que se sabe del parque vive en la cabeza de una persona

    Qué máquina importa, cómo es una carga normal en ella, qué alerta se puede ignorar sin riesgo, por qué aquel umbral se subió en marzo: nada de eso está escrito en ninguna parte. Lo lleva encima quien lo montó todo, y se va con esa persona.

    Un relevo se convierte entonces en un proyecto de arqueología, y los primeros meses en manos nuevas se van en redescubrir lo que un año antes se sabía perfectamente. Un histórico y una configuración que viven fuera de una persona son la única defensa contra eso.

    • Un compañero que se va llevándose el motivo de cada ajuste
    • Unas vacaciones durante las cuales nadie puede decir si una cifra es rara
    • Un parque entregado a un proveedor nuevo sin una referencia con la que compararlo
  5. 15

    Lo que vigila el parque obtiene acceso privilegiado a todo él

    Supervisar no está libre de riesgo. Cualquier cosa que lea métricas de todas sus máquinas tiene, por definición, un punto de apoyo en todas sus máquinas, y además es alcanzable desde fuera, porque de eso se trata.

    Así que la pregunta de cómo se vigila el parque es también una pregunta sobre ese canal: quién puede hablar con él, qué identidad demuestra cada parte, qué ocurre con los datos en tránsito y si una consola comprometida entregaría el parque entero. Es una pregunta legítima antes de instalar nada en ningún sitio.

06FAQ

Preguntas, respondidas

¿Es seguro en un servidor de producción?

¿Es seguro en un servidor de producción?

Sí. El agente solo lee métricas locales y sus propios logs de autenticación, y se conecta saliente por TLS. No abre puertos entrantes ni tiene capacidad ofensiva.

¿Funciona en Windows y Linux?

¿Funciona en Windows y Linux?

Sí. Un protocolo maneja una unidad systemd en Linux y un servicio de Windows, en amd64, arm64 y 386. El instalador detecta la plataforma por ti.

¿Cómo se asegura la ingesta?

¿Cómo se asegura la ingesta?

Cada agente se da de alta con un certificado de cliente y transmite por TLS mutuo. Un token de alta robado es efímero y no puede suplantar a un host ya dado de alta.

¿Cómo funciona la config de dos niveles?

¿Cómo funciona la config de dos niveles?

Defines las plantillas globales una vez. Cada servidor anula claves individuales; las anulaciones cascadean sobre los valores por defecto en vez de reemplazarlos, así un cambio de plantilla llega a cada host.

¿Puedo autoalojarlo?

¿Puedo autoalojarlo?

Sí. El panel se entrega como stack docker-compose tras Traefik con Postgres (TimescaleDB opcional). Consulta la guía de despliegue en el repositorio.

¿Qué cubre la detección de fuerza bruta?

¿Qué cubre la detección de fuerza bruta?

El agente vigila la autenticación RDP y SSH localmente, así que marca un ataque activo y sus IP de origen principales en segundos, incluso antes de que el panel se refresque.

Detectar un servidor no disponible antes de que el usuario llame

Solo sé que una máquina virtual, un servicio o un enlace de sucursal se detuvo cuando el usuario llama. El host puede dejar de transmitir datos durante la noche, después de una migración o actualización, y no tengo ni un solo latido ni un propietario responsable. ¿Cómo puedo configurar el monitoreo de la disponibilidad del servidor y recibir una señal inmediatamente después de que un host desaparece?

Con los Servers Sentinel, instalo el agente como una unidad systemd o un servicio de Windows, lo conecto con un canal de salida mTLS y veo la telemetría más reciente y la puntuación del estado del host. Establezco una regla para los datos faltantes, envío una notificación por correo, Telegram, Slack o webhook y verifico la brecha de la prueba; Puedo mantener un servidor en un plan gratuito con notificaciones por correo electrónico.

Gratis sin Servers Sentinel Ejecuto blackbox_exporter/Prometheus o una verificación cron de ping/TCP desde otro sitio, almaceno last_seen y envío una alerta a través de Alertmanager. Compruebo por separado el monitoreo en sí con un interruptor de hombre muerto externo, configuro el retraso para un reinicio normal y documento al propietario del host; de lo contrario, la pérdida del sistema de seguimiento aparece como un estado verde.

Advertencia de que el disco está lleno antes de que falle la base

En mi servidor, los registros, las tablas temporales y de respaldo están creciendo, y el espacio libre se acerca a cero por la noche. La base puede detenerse en medio de un récord, aunque la tendencia es visible desde hace varias semanas; un umbral único del 90% no es suficiente para volúmenes pequeños y grandes. ¿Cómo puedo configurar la supervisión del disco y la previsión de capacidad?

Con los Servers Sentinel, recopilo el espacio libre y usado de cada sistema de archivos como una serie de tiempo, establezco un umbral general y una anulación separada para un volumen específico, y envío una notificación antes del valor crítico. Miro la tasa de crecimiento junto al porcentaje actual, verifico el inodo en Linux y dejo suficiente margen para WAL/log y operación de emergencia.

De forma gratuita, instalo node_exporter/windows_exporter con Prometheus y Alertmanager o ejecuto df/Get-Volume mediante cron/Task Scheduler. Advierto por porcentaje y gigabytes absolutos al mismo tiempo, agrego rate/predict_linear para un horizonte de 24 a 72 horas, configuro logrotate/retention y pruebo la alerta llenando artificialmente un volumen no crítico.

Identificar la degradación lenta del servidor según las tendencias

Veo un 70% de memoria o una cola en crecimiento, pero no sé si esto es normal para un host en particular: la pérdida de memoria, la agrupación de conexiones y el certificado TLS que vence se deterioran durante semanas sin un evento claro. Cuando un servicio falla, no existe una línea de base. ¿Cómo puedo monitorear las tendencias y detectar la degradación temprana?

Con los Servers Sentinel almaceno una serie de CPU, memoria, disco y red, comparo el host con su propio historial y acumulo el estado actual en una puntuación de 0 a 100. Establezco la duración de la condición para no reaccionar ante un pico de un minuto y creo comprobaciones separadas de tiempo de actividad/TLS/API donde la duración del certificado o la respuesta de la aplicación son importantes.

Implemento Prometheus, exportadores y Grafana de forma gratuita, establezco reglas de registro para la línea de base y alertas para el crecimiento sostenible, y verifico los certificados con blackbox_exporter. Almaceno al menos algunas semanas de datos, marco la implementación/mantenimiento en los gráficos y uso la tasa/derivación solo para métricas relevantes; Apoyo TSDB y me gobierno yo mismo.

Monitoreo unificado de servidores Windows y Linux

Mi flota incluye Windows Server, Linux de varias distribuciones y hosts ARM. Ahora miro el Visor de eventos, el journalctl y los paneles de hoster por separado, por lo que no hay una escala de tiempo común, el mismo estado y una lista única de problemas. ¿Cómo puedo organizar la monitorización de servidores multiplataforma en un solo panel?

Con los Servers Sentinel uso un protocolo para el servicio de Windows y el agente systemd en amd64, arm64 y 386, obtengo las mismas métricas base y el mismo puntaje de salud. Mantengo las diferencias de plataforma en las anulaciones, pero clasifico toda la flota por riesgo y paso la telemetría a mTLS sin abrir el puerto de entrada del agente.

De forma gratuita, combino windows_exporter y node_exporter en un Prometheus, normalizo las etiquetas de host/cliente/os y construyo un panel de Grafana común. Asigno el reenvío de eventos de Windows y syslog/Loki por UTC, describo los diferentes umbrales para el sistema operativo como código y verifico que la actualización del exportador no cambie los nombres de las métricas sin migrar las reglas.

Monitoreo de servidores en la oficina, nubes y sucursales.

Mis servidores están distribuidos entre la oficina, dos nubes, un hosting y una sucursal, están detrás de NAT y no tienen un direccionamiento común. No quiero abrir puertos entrantes en cada host, pero sí quiero una vista única de la disponibilidad y los recursos independientemente del sitio. ¿Cómo puedo centralizar el monitoreo de servidores distribuidos?

Con Servers Sentinel instalo un agente en cada host; inicia la conexión saliente por sí mismo y está autenticado mediante el certificado de cliente mTLS. Asigno etiquetas de sitio y de propietario, veo todos los hosts en una consola y establezco reglas globalmente con anulaciones punto por punto, sin crear una ruta entrante a cada máquina.

De forma gratuita, conecto sitios de WireGuard y exportadores de encuestas con Prometheus central o uso Remote_write/agents que envían métricas externamente. Limito la ACL solo a la dirección del recopilador, la protejo con certificados TLS, almaceno los datos cuando se rompen y superviso la propia VPN; Yo mismo hago el diseño de la red y la rotación de claves.

Consolidar canales de notificación dispares

Un sistema envía un correo electrónico, otro escribe en Telegram, el tercero llama a un webhook y el proveedor de alojamiento envía un SMS; Un incidente aparece con diferentes nombres y nadie entiende cuál es el mensaje principal. ¿Cómo puedo centralizar las notificaciones de monitoreo y asociar una alarma a un servidor y regla específicos?

Con los Servers Sentinel creo canales de correo electrónico, Telegram, Slack o webhook en una consola, les envío una prueba y les envío reglas de acuerdo con los hosts requeridos. Utilizo nombres únicos y contexto de host para que el operador vea la métrica, el umbral y el tiempo, en lugar de recopilar un incidente a partir de cuatro letras independientes.

De forma gratuita, dirijo Prometheus Alertmanager a una puerta de enlace de notificación, configuro group_by, group_wait, repetir_interval e inhibición, y dejo a las fuentes un enlace a un runbook. Normalizo las etiquetas de gravedad/servicio/propietario y reviso rutas con alertas de prueba; Los SMS y los proveedores externos pueden seguir cobrando incluso con software gratuito.

Reducir la fatiga de alerta

Mi monitoreo me alerta sobre cada breve pico de CPU, reinicio programado y unidad que cruza el mismo umbral todas las noches. El equipo ha desactivado el canal, por lo que el incidente real tampoco se lee. ¿Cómo puedo reducir la fatiga de las alertas y dejar solo alertas procesables?

Con los Servers Sentinel, establezco umbrales globales, duraciones de condiciones y excepciones puntuales para hosts donde la norma es diferente, y luego dirijo los niveles de gravedad a diferentes canales. Utilizo la puntuación de estado para priorizar, probar la regla y revisar las alertas sobre las que no se ha actuado.

De forma gratuita, mantengo un catálogo de alertas con un propietario y un runbook, uso for en Prometheus, agrupación e inhibición en Alertmanager y cierro el trabajo programado con silencio y finalización automática. Mido la cantidad de notificaciones, reconocimientos y reintentos, elimino señales no procesables y no enmascaro el ruido simplemente elevando todos los umbrales.

Alertas nocturnas sin servicio completo

Tengo un equipo pequeño sin guardia 24 horas al día, 7 días a la semana: por la noche hay una persona disponible que no construyó un servidor y no sabe lo que significa “db-01 CPU 96%”. Necesito que la señal crítica llegue con contexto y una acción comprensible, y que la señal no crítica espere hasta la mañana. ¿Cómo configuro alertas de monitoreo nocturno?

Con los Servers Sentinel, separo la gravedad y los canales, agrego una función/cliente al nombre de host y solo configuro la regla después de una infracción persistente. Reviso el mensaje con una prueba, dejo un enlace al runbook en el webhook del destinatario y uso un gráfico de métricas/evaluación de salud para que la persona de turno pueda distinguir un pico único de la degradación.

De forma gratuita, creo un cronograma de enrutamiento de Alertmanager, envío eventos críticos a una llamada o chat a través de una puerta de enlace disponible y el resto a la cola diaria. Escribo un runbook de tres acciones, un propietario y un criterio de escalamiento, agrego un enlace al panel y emito alertas de capacitación periódicamente; El canal de llamada gratuita depende del servicio seleccionado.

Umbrales de monitoreo unificados con excepciones por host

Mis servidores fueron configurados por diferentes personas: la advertencia del disco está en 80, 85 o 95% y los motivos no están escritos en ninguna parte. Quiero cambiar el umbral base una vez, pero mantener excepciones conscientes para la base de datos, el servidor de archivos y la pequeña partición del sistema. ¿Cómo puedo gestionar los patrones de seguimiento sin desvíos?

Con Servers Sentinel configuro una plantilla de configuración global y en un servidor específico anulo solo la clave deseada; la anulación se aplica en cascada sobre el valor predeterminado en lugar de copiar toda la configuración. Veo la desviación como una excepción, cambio el umbral general una vez y verifico qué hosts permanecieron deliberadamente en un valor diferente.

De forma gratuita, almaceno reglas de Prometheus y parámetros de inventario en Git, genero reglas Jsonnet/Ansible y solicito una revisión con el motivo y la fecha límite de la excepción. Ejecuto una verificación de sintaxis de CI, una diferencia de la configuración implementada y un informe sobre anulaciones; Sin esa disciplina, incluso una pila libre rápidamente vuelve a la deriva manual.

Detección instantánea de fuerza bruta vía RDP y SSH

Solo encuentro adivinanzas de contraseñas cuando miro el registro de eventos de seguridad y auth.log semanalmente. En ese momento, habían pasado horas entre la primera serie de fallas y el eventual inicio de sesión exitoso, y una IP podía atacar múltiples servidores. ¿Cómo puedo recibir una notificación sobre una fuerza bruta RDP/SSH cuando comienza un ataque?

Con los Servers Sentinel habilito la detección de autenticación local: un agente en Windows o Linux lee eventos RDP/SSH y transmite un ataque activo con una fuente de IP superior. Dirijo la regla al canal en vivo y hago coincidir una fuente entre los hosts; La función de detección está disponible en un plan de prueba o pago elegible.

De forma gratuita recopilo Windows 4625 y sshd Contraseña fallida en Wazuh/Elastic o Loki, creo una correlación mediante source_ip para una ventana deslizante y una alerta para el posterior 4624/Aceptado exitoso. Sincronizo la hora a través de NTP, normalizo IPv4/IPv6 y excluyo los escáneres de prueba; la ruta gratuita requiere un recopilador independiente y soporte de reglas.

Cálculo de disponibilidad y SLA por dimensiones

En el contrato con el cliente tengo anotado un SLA, por ejemplo, del 99,9% mensual, pero ahora la disponibilidad se evalúa por sensaciones y llamadas. Para un conflicto necesitamos un principio, un final y un motivo para cada parada, la exclusión del trabajo acordado y una fórmula única. ¿Cómo puedo organizar el monitoreo del tiempo de actividad y los informes de SLA?

Con los Servers Sentinel creo comprobaciones TCP/TLS/API desde un punto externo, almaceno un historial de resultados y separo la indisponibilidad de la aplicación de la telemetría del agente faltante. Establezco un SLO, registro el mantenimiento y genero un informe periódico con límites de tiempo; Antes de firmar, acuerdo con el cliente el intervalo, las regiones de inspección y las reglas de exclusión.

De forma gratuita, implemento blackbox_exporter y Prometheus fuera del sitio controlado, considero la disponibilidad como sondas exitosas/sondas esperadas y almaceno eventos de Alertmanager. Anoto el mantenimiento en un registro separado, sincronizo UTC y genero un informe de Grafana; un punto de verificación no prueba la disponibilidad global, por lo que si es necesario agrego una sonda independiente.

Evidencia de seguimiento continuo para auditoría.

El auditor, asegurador o cliente pregunta cómo sé que los sistemas fueron monitoreados durante todo el período, quién recibió alertas y qué incidentes se cerraron. El panel verde actual por sí solo no es suficiente porque no confirma el mes anterior. ¿Cómo puedo preparar evidencia de monitoreo continuo del servidor?

Con los Servers Sentinel guardo el historial de métricas, comprobaciones de tiempo de actividad, configuración de reglas, canales y eventos, y uso el registro de auditoría para cambios de propietario y políticas en el plan apropiado. Subo un informe para el período exacto, adjunto una prueba de entrega y explico la identidad mTLS de los agentes; Observo la ausencia de datos como una laguna en la observación y no como la norma.

De forma gratuita almaceno Prometheus/Loki/Wazuh en un servidor seguro con respaldo, configuración y aprobaciones en Git, e incidencias en un sistema de tickets. Registro mensualmente coberturas, lagunas, prueba de alertas y lista de excepciones, firmo el informe y limito el acceso; el instrumento en sí, sin un procedimiento de cierre, no es prueba de control.

Monitoreo de servidores de varios clientes por un administrador

Como MSP o administrador entrante, monitorizo los servidores de diferentes empresas, proveedores y redes. Los clientes tienen diferentes horarios, umbrales y contactos, pero quiero una cola de problemas sin mezclar datos y derechos de acceso. ¿Cómo puedo organizar la supervisión del servidor multiinquilino?

Con los Servers Sentinel divido la flota por equipo/inquilino, asigno roles de espectador, operador y administrador y aplico plantillas básicas con excepciones de clientes. Clasifico todos los hosts por puntuación de estado, envío notificaciones al propietario y uso la opción Business/autohospedado cuando se necesita aislamiento y una flota ilimitada.

De forma gratuita, implemento arrendamientos/instancias de Prometheus separados o aíslo datos con etiquetas estrictas y ACL en Grafana, almacenando secretos del cliente en diferentes bóvedas. Genero una configuración a partir del inventario, dirijo Alertmanager por inquilino/propietario y pruebo el bloqueo del acceso cruzado; La tenencia múltiple segura requiere más trabajo que un panel compartido.

Mantener el conocimiento sobre la norma y la configuración del parque.

Toda la información sobre qué servidor es importante, qué carga es normal y por qué se cambió el umbral está en la cabeza de un administrador. Cuando se producen unas vacaciones o un despido, una persona nueva ve números sin contexto y no sabe qué desviación es peligrosa. ¿Cómo puedo convertir mi historial de seguimiento en documentación operativa transferible?

Con Servers Sentinel firmo hosts por rol y propietario, almaceno series de métricas, plantillas globales y anulaciones explícitas, y asocio canales con propietarios. Utilizo el historial como base, documento el motivo del umbral no estándar junto al proceso de cambio y le doy al nuevo operador una función de solo visualización antes de transferir autoridad.

De forma gratuita, mantengo inventario y runbooks en Git, agrego enlaces al panel, propietario, dependencias y fundamentos para cada anulación, y acepto cambios mediante solicitud de extracción. Almaceno el aprovisionamiento de Grafana/Prometheus como código, marco la implementación/mantenimiento y transfiero el incidente a otro empleado una vez por trimestre; Sin práctica organizacional, los gráficos en sí no retendrán el conocimiento.

Agente de monitoreo seguro con privilegios mínimos

Entiendo que un agente de monitoreo se ubica en cada servidor y pasa a formar parte de la cadena de confianza. No quiero abrir puertos entrantes, pasar un token de inscripción persistente ni darle al panel de la nube la capacidad de ejecutar comandos arbitrarios en toda la flota. ¿Cómo evalúo e implemento de forma segura un agente de monitoreo?

Con los Servers Sentinel utilizo una conexión saliente TLS mutua: cada agente recibe un certificado de cliente y el token de conexión de corta duración no reemplaza la identidad ya emitida. Verifico los derechos del servicio, la lista de métricas y registros recopilados, desactivo acciones innecesarias, implemento el piloto en un host y controlo la revocación del certificado cuando se elimina el servidor.

De forma gratuita, instalo node_exporter/windows_exporter en una cuenta separada sin privilegios, escucho solo localhost/VPN y limito el conjunto de recopiladores. Protejo el scrape con TLS/mTLS o ACL de red, firmo paquetes, confirmo versiones, busco actualizaciones y no habilito secuencias de comandos de archivos de texto que escriben desde fuentes que no son de confianza; Separo la gestión de la configuración del seguimiento.

07Confianza

Quién lo desarrolla, a quién le paga y qué puede hacer el agente en su parque

Tres preguntas que merecen respuesta antes de desplegar nada con permisos de administrador en un parque en producción.

01

Quién lo desarrolla

Servers Sentinel lo escribe Victor G. Bobrov, especialista principal en seguridad de servidores en Recovery Toolbox: más de 20 años en ingeniería de sistemas y seguridad y certificaciones Microsoft MCSD/MCDBA. La puntuación de salud, las reglas de alerta y la documentación de este sitio son su trabajo, publicados con su nombre y no bajo una marca anónima. Documentación →

02

A quién le paga

El proveedor es File Master LLC, empresa registrada en Bulgaria (UE): Bulstat/IVA 180842207, oficina en Varna, localizable por teléfono y correo. Los pagos los gestiona PayPro Global como comerciante registrado; los términos, la política de privacidad y el acuerdo de tratamiento de datos están publicados íntegros, no resumidos. Términos del servicio · Privacidad · DPA

03

Qué puede y qué no puede hacer el agente

El agente lee métricas locales y el registro de autenticación de su propio host y los envía hacia fuera por TLS mutuo. No abre ningún puerto entrante ni tiene canal de comandos remotos: desde fuera no se le puede ordenar que ejecute nada en su servidor. Cada agente se inscribe con un certificado de cliente y el token de inscripción es de vida corta: uno robado no puede suplantar a un host ya inscrito. El propio panel se despliega como una pila docker-compose en su propio hardware. Instalar el agente →

08Recursos

Recursos: la monitorización, las plataformas vigiladas y las normas que las rodean

La monitorización de un parque no es un tema en sí mismo: está entre las plataformas que observa, las herramientas que la precedieron y las normas con las que se mide un servidor. Estas son las fuentes que definen cada uno de ellos.

Recovery Toolbox / File Master LLC

Contactar con Recovery Toolbox

Datos de contacto de Recovery Toolbox y File Master LLC, además del perfil de Victor G. Bobrov, especialista principal en seguridad de la empresa.

Oficina de la empresa

File Master LLC es la entidad jurídica detrás de los servicios en línea y los productos de software de Recovery Toolbox.

File Master LLC
Serena app., office C13
Golden Sands, Varna, 9007
Bulgaria, Unión Europea
Bulstat/IVA
180842207

Acerca de Recovery Toolbox

File Master LLC desarrolla y mantiene los servicios en línea y los productos de software de Recovery Toolbox para reparar archivos, bases de datos y formatos de correo dañados. La empresa se centra en herramientas de recuperación prácticas para usuarios, especialistas de TI y empresas que necesitan restaurar el acceso a datos dañados.

Sus comentarios y sugerencias son bienvenidos. Envíenos su opinión sobre el sitio web por correo electrónico: webmaster@recoverytoolbox.com

Victor G. Bobrov, server security specialist and author of Servers Sentinel
Especialista en seguridad

Victor G. Bobrov

Especialista en seguridad de servidores · más de 20 años en ingeniería de sistemas y seguridad

Victor G. Bobrov dirige la ingeniería de seguridad en File Master LLC / Recovery Toolbox. Define qué vigila Servers Sentinel en un parque de servidores: la puntuación de salud detrás de las métricas de un host, la actividad de fuerza bruta en sus registros de autenticación, la desviación de configuración respecto a los CIS y las alertas que deben dispararse antes de que un administrador note nada.

  • Monitorización de parque
  • Fortificación de servidores y CIS
  • Alertas y respuesta a incidentes
  • MCSD
  • MCDBA

Certificaciones de Microsoft

Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.

MCSD MCDBA

Apunta Servers Sentinel a tu primer servidor

Añade un host, ejecuta una línea y míralo reportar en un minuto. El primer servidor es gratis.