Monitoreo de VMware vSpheresin tocar una sola VM

Un agente Glouton, en una máquina Linux o Windows, habla con tu API de vSphere mediante una cuenta de solo lectura y descubre todo el parque: clústeres, hosts ESXi, máquinas virtuales y datastores. No se instala nada dentro de las VMs — que suele ser la razón por la que un equipo VMware dice que no a la monitorización de entrada.

vCenter o ESXi standalone • Cuenta vSphere de solo lectura • Objetos descubiertos facturados desde 3,99 €/mes cada uno

4
Tipos de objeto descubiertos
0
Agentes en las VM
13 meses
Retención de métricas

Visión general

La objeción nunca son las métricas

Nadie discute que haya que monitorizar los hosts ESXi. Lo que se discute es lo que cuesta llegar ahí: un paquete en trescientas VM, una excepción en la imagen dorada, una petición de cambio por VM, y un parque donde la mitad de las máquinas son appliances que de todos modos no puedes tocar.

Bleemeo lee vSphere como vSphere espera ser leído. Instalas un agente Glouton en cualquier máquina Linux o Windows que alcance vCenter, le das una cuenta de vSphere de solo lectura y recorre el inventario: cada clúster, cada host, cada VM, cada datastore. Los objetos nuevos aparecen a los pocos minutos de crearse, porque el descubrimiento corre de forma continua y no en una sincronización nocturna.

Donde quieras detalle interno — CPU por proceso, servicios descubiertos, logs — instalas el agente en esa VM y aterriza en la misma cuenta y los mismos paneles. Es una adición, no un requisito previo.

Cobertura

Qué se descubre

Cuatro tipos de objeto, recorridos desde el inventario de vCenter. Los hosts ESXi standalone funcionan igual, sin el clúster. Clústeres, hosts y VMs son cada uno un recurso facturado; los datastores no.

Clústeres

CPU y memoria agregadas de todos los hosts del clúster, para ver la presión al nivel en el que realmente planificas capacidad.

  • CPU usada en todo el clúster
  • Memoria usada, en porcentaje
  • Recalculado cuando un host entra o sale

Hosts ESXi

Once métricas por host, incluidos los dos contadores que importan para el ratio de consolidación y que es fácil perder de vista: cuántas VMs están arrancadas y cuántas no.

  • CPU, memoria total y usada
  • Swap in y swap out
  • Rendimiento de disco en lectura y escritura
  • Red enviada y recibida
  • Recuento de VMs arrancadas y paradas

Máquinas virtuales

Nueve métricas por VM sin agente dentro — incluida la latencia de CPU, que es cómo distingues una VM lenta de un host sobresuscrito.

  • CPU usada y latencia de CPU
  • Memoria usada y swap
  • Rendimiento de disco en lectura y escritura
  • Red enviada y recibida
  • Uso de sistemas de archivos

Datastores

Capacidad y E/S por datastore: un datastore que se llena se convierte en una fecha del informe semanal, no en una sorpresa al hacer un snapshot.

  • Espacio usado y total
  • Rendimiento de lectura y escritura
  • Alimenta la previsión de capacidad

Puesta en marcha

Tres pasos, una máquina

El agente puede correr en cualquier sitio que alcance vCenter — una VM de administración, un bastión, un contenedor. Se pueden listar varios vCenter y hosts ESXi uno al lado del otro.

1

Crear una cuenta de vSphere de solo lectura

La cuenta necesita acceso de lectura a los objetos a monitorizar: datacenter, clúster, hosts, VMs, datastores. Con solo lectura basta, y ahí acaba la historia de permisos — no hay nada más que conceder.

2

Instalar un agente Glouton

En cualquier máquina Linux o Windows que alcance la API de vSphere. Un comando en Linux, un instalador en Windows. Esa máquina es un recolector, no un objetivo: no tiene que estar dentro del clúster.

3

Añadir la conexión a su configuración

Unas líneas en un fichero drop-in con la URL del vCenter o del ESXi y la cuenta. Añade más entradas para más vCenter. El descubrimiento arranca de inmediato y los paneles se llenan a medida que se recorre el inventario.

Migración

¿Dejáis VMware? Vais a tener los dos durante un tiempo

Los cambios de licenciamiento han puesto a muchos equipos en camino a Proxmox, Nutanix o KVM a secas. Esas migraciones duran de seis a dieciocho meses, y durante todo ese tiempo operas dos hipervisores, dos consolas y una sola guardia que tiene que cubrir ambos.

Bleemeo abarca los dos lados sin cambiar de herramienta a mitad de camino. vSphere se lee por su API, y un host Proxmox VE es una máquina Debian: el mismo agente que monitoriza tu parque Linux monitoriza el nuevo hipervisor — misma cuenta, mismos paneles, mismas reglas de alerta, mismo informe semanal. Migrar de hipervisor ya es bastante disruptivo sin migrar además la monitorización.

Los dos lados, un panel

Una aplicación repartida entre VMs de ESXi y VMs de Proxmox durante una migración puede vivir tras una sola etiqueta de aplicación, de modo que la vista de salud no se fragmenta por la frontera de la migración.

Proxmox VE y Backup Server

Ambos están basados en Debian, así que el agente se instala desde nuestro repositorio APT con un comando — Proxmox VE 7, 8 y 9, y todas las versiones de Proxmox Backup Server. Obtienes CPU, memoria, disco, red y sistemas de archivos del host, más los servicios que corren en él.

Cada VM conserva su detalle

Del lado VMware, el detalle por VM es opcional porque lo aporta la API. Del lado Proxmox, las métricas por VM vienen de instalar el agente en las VM que te importan — el mismo agente, así que nada nuevo que aprender.

La comparación sigue siendo honesta

Antes y después de una migración miras los mismos nombres de métricas en los mismos gráficos con la misma retención. Eso es lo que convierte «¿es realmente mejor la nueva plataforma?» en una pregunta que se responde con datos.

Comparativa

vCenter solo frente a vCenter con Bleemeo

FeaturevCenter soloBleemeo
Métricas del inventario vSphere
Completas, nativas
Leídas por la API de vSphere, misma fuente
Agentes dentro de las VM
No necesarios
No necesarios
Infraestructura fuera de VMware
Fuera de alcance
Bare metal, cloud, contenedores, Kubernetes
Histórico
Agregado agresivamente pasados unos días
13 meses a resolución completa
Alertas
Alarmas de vCenter, por objeto
Valores por defecto, Slack, PagerDuty, SMS
Previsión de capacidad
Manual, o producto aparte
Una fecha por datastore y por disco
Durante una migración de hipervisor
Cubre el lado que abandonas
Cubre los dos lados a la vez
Acceso requerido
Administrador, en la práctica
Una cuenta de vSphere de solo lectura

Preguntas frecuentes

La monitorización de vSphere con Bleemeo, en la práctica

¿Necesito instalar un agente dentro de mis máquinas virtuales?

No. Un agente Glouton, en una máquina que alcance vCenter, basta para descubrir y monitorizar cada clúster, host, VM y datastore. Instalar el agente dentro de una VM es opcional y te da lo que solo la VM sabe: CPU y memoria por proceso, servicios descubiertos como MySQL o Nginx, y logs.

¿Qué permisos de vSphere necesita Bleemeo?

Permisos de solo lectura sobre los objetos a monitorizar — datacenter, clúster, hosts, VMs, datastores. Ese es todo el requisito. El agente lee el inventario y los contadores de rendimiento; no puede encender, migrar, reconfigurar ni eliminar nada.

¿Funciona sin vCenter?

Sí. Glouton se conecta a un host ESXi standalone igual que a vCenter. Pierdes el objeto clúster, porque no hay clúster, y todo lo demás funciona. También puedes listar varios vCenter y varios hosts standalone en la misma configuración.

¿Con qué rapidez se detectan las VMs nuevas?

En pocos minutos. El descubrimiento corre de forma continua en lugar de como sincronización nocturna, así que una VM creada esta mañana está en un panel esta mañana — lo que importa cuando el parque se mueve.

¿Qué es la latencia de CPU y por qué importa?

Es la fracción de tiempo en que una VM estaba lista para ejecutarse pero esperaba CPU físico. Una VM puede mostrar un consumo de CPU modesto y aun así ir lenta porque el host está sobresuscrito, y la latencia de CPU es lo que distingue ambos casos. Bleemeo la recoge por VM, y «la app va lenta» deja de ser una discusión entre el equipo de aplicación y el de plataforma.

Estamos migrando de VMware a Proxmox. ¿Funciona?

Sí, y es una buena razón para migrar antes la monitorización. vSphere se lee por su API; un host Proxmox VE es Debian, así que el mismo agente se instala desde nuestro repositorio APT — Proxmox VE 7, 8 y 9, y Proxmox Backup Server. Durante la migración ambos lados reportan a una sola cuenta con los mismos paneles y alertas, así que no cambias de monitorización mientras cambias de hipervisor.

¿Cómo se factura la monitorización de vSphere?

Cada clúster, host y máquina virtual descubierto es un recurso monitorizado, con el mismo precio que los demás: 4,99 € al mes en Professional y 3,99 € en Starter. Los datastores no se facturan.

En un parque grande eso suma, y el agente trae la palanca: con skip_monitor_vms, Glouton monitoriza solo clústeres, hosts y datastores. Conservas el recuento de VMs arrancadas y paradas a nivel de host, y dejas de pagar por VM. Consulta los precios para la tabla completa.

¿Qué planes incluyen el monitoreo de VMware?

La monitorización de vSphere está disponible en los planes Starter y Professional. Consulta los precios para el detalle.

Monitoriza vSphere sin negociar con trescientas VM

Un agente, una cuenta de solo lectura y todo tu parque en un panel en una tarde. Quince días, sin tarjeta.