Uno de las principales desventajas de VMware ESXi es su difícil monitorización.
A través del cliente vSphere podemos hacer un seguimiento de distintos parámetros de la
máquina (CPU, memoria, disco, etc.) durante la última hora, situación que generalmente
es insuficiente si se necesita mantener registrados dichos valores de cara a la posible resolución
de una incidencia. Además a través de dicho cliente, tampoco podemos generar ningún
tipo de alerta.
Una de las posibles alternativas que se tienen consiste combinar la herramienta resxtop
con uno de los mejores softwares open source existentes para la monitorización
de equipos: Zabbix.
La idea va a consistir en lanzar resxtop en modo batch, con el objetivo de recopilar los parámetros
que nosotros le indiquemos a través del fichero de configuración de resxtop. Esta operación
devolverá como resultado un fichero CSV. La aplicación resxtop será gestionada a través
de un script en bash, el cual recibirá como parámetro a través de la línea de órdenes el nombre
o dirección IP del VMware ESXi del cual queramos obtener su informe CSV.
A través de Zabbix podremos generar posteriormente un item que tenga asociado este script,
y el cual se encargue de obtener el informe CSV de forma periódica.
A continuación y a través de otro script en bash (el cual recibirá como argumentos el nombre
o dirección IP del VMware ESXi y el parámetro que se desee obtener - consumo de CPU,
memoria libre, etc.), podremos obtener el valor asociado a un argumento concreto. De esta
forma y posteriormente en Zabbix, podremos generar varios items que se encarguen de
obtener dichos valores utilizando el script.
Para hacer las pruebas vamos a emplear Zabbix 1.8.1 instalado sobre un CentOS 5.4 de 64 bits.
Primero vamos a crear un script en bash denominado resxtop_esxi.sh, el cual reciba por la
línea de órdenes el nombre del VMware ESXi (o dirección IP) que se desee monitorizar a través
de resxtop (habría que sustituir xxxxxx por la password de root del ESXi).
El script anterior depositará los resultados dentro del directorio reports.
Para instalar resxtop en la máquina CentOS, he descargado la versión de esta aplicación
para 64 bits y la he descomprimido directamente dentro del
directorio /etc/zabbix/externalscripts/resxtop_esxi. Al intentar instalarla utilizando el script
que trae consigo (vmware-install.pl) me ha dado varios problemas, así que he
optado por instalarla manualmente.
Éstos son los pasos que he seguido:
Si tenemos activado SELinux, tendremos que ejecutar las dos siguientes órdenes:
El fichero de configuración de resxtop tendrá el siguiente contenido:
De esta forma diremos a resxtop que obtenga los parámetros generales de CPU
y memoria (dos primeras líneas en blanco) y los datos concretos para cada una
de las unidades de disco e interfaces de red (líneas cuarta y sexta).
Si echamos un vistazo al fichero CSV que crea resxtop, podremos ver que se trata
de una tabla con dos filas y múltiples columnas, una por cada uno de los datos registrados.
Por lo tanto lo que vamos a hacer será un script en AWK que se encargue de
obtener el valor del campo concreto que le indiquemos.
Y por último, vamos a hacer un script llamado get_esxi_field.sh que recibirá dos argumentos
por la línea de órdenes: el primero será el nombre o dirección IP del ESXi del cual se quiera
obtener un cierto parámetro (CPU, memoria, etc.) y el segundo argumento será la cadena
de texto que indique dicho argumento (Por ejemplo "Memory Overcommit (1 Minute Avg)").
El árbol de ficheros y directorios de la estructura de monitorización que acabamos de crear quedaría de la siguiente forma:
A través del cliente vSphere podemos hacer un seguimiento de distintos parámetros de la
máquina (CPU, memoria, disco, etc.) durante la última hora, situación que generalmente
es insuficiente si se necesita mantener registrados dichos valores de cara a la posible resolución
de una incidencia. Además a través de dicho cliente, tampoco podemos generar ningún
tipo de alerta.
Una de las posibles alternativas que se tienen consiste combinar la herramienta resxtop
con uno de los mejores softwares open source existentes para la monitorización
de equipos: Zabbix.
La idea va a consistir en lanzar resxtop en modo batch, con el objetivo de recopilar los parámetros
que nosotros le indiquemos a través del fichero de configuración de resxtop. Esta operación
devolverá como resultado un fichero CSV. La aplicación resxtop será gestionada a través
de un script en bash, el cual recibirá como parámetro a través de la línea de órdenes el nombre
o dirección IP del VMware ESXi del cual queramos obtener su informe CSV.
A través de Zabbix podremos generar posteriormente un item que tenga asociado este script,
y el cual se encargue de obtener el informe CSV de forma periódica.
A continuación y a través de otro script en bash (el cual recibirá como argumentos el nombre
o dirección IP del VMware ESXi y el parámetro que se desee obtener - consumo de CPU,
memoria libre, etc.), podremos obtener el valor asociado a un argumento concreto. De esta
forma y posteriormente en Zabbix, podremos generar varios items que se encarguen de
obtener dichos valores utilizando el script.
Para hacer las pruebas vamos a emplear Zabbix 1.8.1 instalado sobre un CentOS 5.4 de 64 bits.
Primero vamos a crear un script en bash denominado resxtop_esxi.sh, el cual reciba por la
línea de órdenes el nombre del VMware ESXi (o dirección IP) que se desee monitorizar a través
de resxtop (habría que sustituir xxxxxx por la password de root del ESXi).
[root@centos ~]# mkdir -p /etc/zabbix/externalscripts/resxtop_esxi/reports
[root@centos ~]# cd /etc/zabbix/externalscripts
[root@centos externalscripts]# cat resxtop_esxi.sh
#!/bin/bash
PATH_RESXTOP="/etc/zabbix/externalscripts/resxtop_esxi"
if [ "$2" == "" ]; then
echo 1 ; exit 1
fi
mv $PATH_RESXTOP/reports/$2.csv.tmp $PATH_RESXTOP/reports/$2.csv
echo 0
$PATH_RESXTOP/resxtop -b -n 1 -c $PATH_RESXTOP/esxtop4rc --server $2 --username root > $PATH_RESXTOP/reports/$2.csv.tmp << eof
xxxxxx
eof
[root@centos externalscripts]# chmod 700 resxtop_esxi.shEl script anterior depositará los resultados dentro del directorio reports.
Para instalar resxtop en la máquina CentOS, he descargado la versión de esta aplicación
para 64 bits y la he descomprimido directamente dentro del
directorio /etc/zabbix/externalscripts/resxtop_esxi. Al intentar instalarla utilizando el script
que trae consigo (vmware-install.pl) me ha dado varios problemas, así que he
optado por instalarla manualmente.
Éstos son los pasos que he seguido:
[root@centos resxtop_esxi]# tar xvzf VMware-vSphere-CLI-4.0.0-198790.x86_64.tar.gz
[root@centos resxtop_esxi]# mkdir -p /etc/vmware-vcli/
[root@centos resxtop_esxi]# cat /etc/vmware-vcli/locations
answer LIBDIR /usr/lib/vmware-vcli
[root@centos resxtop_esxi]# mkdir -p /usr/lib/vmware-vcli/lib
[root@centos resxtop_esxi]# cp -a vmware-vsphere-cli-distrib/lib/lib64/wrapper-gtk24.sh /usr/lib/vmware-vcli/lib/
[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/bin /usr/lib/vmware-vcli/
[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/lib64 /usr/lib/vmware-vcli/
[root@centos resxtop_esxi]# cp -ar vmware-vsphere-cli-distrib/lib/lib32 /usr/lib/vmware-vcli/
[root@centos resxtop_esxi]# cp -a vmware-vsphere-cli-distrib/bin/resxtop .
[root@centos resxtop_esxi]# rm -rf vmware-vsphere-cli-distrib/Si tenemos activado SELinux, tendremos que ejecutar las dos siguientes órdenes:
[root@centos resxtop_esxi]# chcon -t textrel_shlib_t '/usr/lib/vmware-vcli/lib32/libvmacore.so.1.0/libvmacore.so.1.0'
[root@centos resxtop_esxi]# semanage fcontext -a -t textrel_shlib_t '/usr/lib/vmware-vcli/lib32/libvmacore.so.1.0/libvmacore.so.1.0'El fichero de configuración de resxtop tendrá el siguiente contenido:
[root@centos resxtop_esxi]# cat esxtop4rc
AG
DHIJK
5cDe esta forma diremos a resxtop que obtenga los parámetros generales de CPU
y memoria (dos primeras líneas en blanco) y los datos concretos para cada una
de las unidades de disco e interfaces de red (líneas cuarta y sexta).
Si echamos un vistazo al fichero CSV que crea resxtop, podremos ver que se trata
de una tabla con dos filas y múltiples columnas, una por cada uno de los datos registrados.
[root@centos resxtop_esxi]# resxtop -b -n 1 -c esxtop4rc --server esxi.local --username root > esxi.local.csv
[root@centos resxtop_esxi]# cat esxi.local.csv
"(PDH-CSV 4.0) (CET)(0)","\\esxi.local\Memory\Memory Overcommit (1 Minute Avg)","\\esxi.local\Memory\Memory Overcommit (5 Minute Avg)"...
...
[root@centos resxtop_esxi]# cat esxi.local.csv | cut -d',' -f 2
"\\esxi.local\Memory\Memory Overcommit (1 Minute Avg)"
"0.00"Por lo tanto lo que vamos a hacer será un script en AWK que se encargue de
obtener el valor del campo concreto que le indiquemos.
[root@centos resxtop_esxi]# cat parser_resxtop.awk
BEGIN {
FS = "," ; RS = ""
}
{
for (i = 1; i <= NF/2; i++)
if ( index($i, field) != 0 )
{
gsub("\"","",$(i + NF/2))
print $(i + NF/2)
break
}
}
[root@centos resxtop_esxi]# awk -v field="Memory Overcommit (1 Minute Avg)" -f parser_resxtop.awk reports/esxi.local.csv
0.00Y por último, vamos a hacer un script llamado get_esxi_field.sh que recibirá dos argumentos
por la línea de órdenes: el primero será el nombre o dirección IP del ESXi del cual se quiera
obtener un cierto parámetro (CPU, memoria, etc.) y el segundo argumento será la cadena
de texto que indique dicho argumento (Por ejemplo "Memory Overcommit (1 Minute Avg)").
[root@centos resxtop_esxi]# cd ..
[root@centos externalscripts]# cat get_esxi_field.sh
#!/bin/bash
PATH_SCRIPTS="/etc/zabbix/externalscripts/resxtop_esxi"
if [ "$2" == "" -o "$3" == "" ]; then
echo 1 ; exit 1
fi
echo "$(awk -v field="$3" -f $PATH_SCRIPTS/parser_resxtop.awk $PATH_SCRIPTS/reports/$2.csv)"
[root@centos externalscripts]# chmod +x get_esxi_field.sh
[root@centos externalscripts]# chown -R zabbix:zabbix /etc/zabbix/externalscriptsEl árbol de ficheros y directorios de la estructura de monitorización que acabamos de crear quedaría de la siguiente forma:
[root@centos ~]# tree /etc/zabbix/externalscripts
/etc/zabbix/externalscripts
|-- get_esxi_field.sh
|-- resxtop_esxi
| |-- esxtop4rc
| |-- parser_resxtop.awk
| |-- reports
| `-- resxtop
`-- resxtop_esxi.sh
2 directories, 5 filesMAR 23, 2010
¿Estamos ante el fin de Microsoft Office en la Administración Pública?
Probablemente lo que voy a contar a continuación sea lo único bueno que he visto hacer a lo largo de los seis años de gobierno socialista que nos ha tocado (padecer) vivir a los españoles.
El 8 de Enero de 2010 se aprobó el Real Decreto 4/2010, donde se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, por el que se obliga a los organismos públicos a la utilización de estándares abiertos (artículo 11):
"1. Las Administraciones públicas usarán estándares abiertos, así como, en su caso y de forma complementaria, estándares que sean de uso generalizado por los ciudadanos, al objeto de garantizar la independencia en la elección de alternativas tecnológicas por los ciudadanos y las Administraciones públicas y la adaptabilidad al progreso de la tecnología y, de forma que:
a) Los documentos y servicios de administración electrónica que los órganos o Entidades de Derecho Público emisores pongan a disposición de los ciudadanos o de otras Administraciones públicas se encontrarán, como mínimo, disponibles mediante estándares abiertos.
...
2. En las relaciones con los ciudadanos y con otras Administraciones públicas, el uso en exclusiva de un estándar no abierto sin que se ofrezca una alternativa basada en un estándar abierto se limitará a aquellas circunstancias en las que no se disponga de un estándar abierto que satisfaga la funcionalidad satisfecha por el estándar no abierto en cuestión y sólo mientras dicha disponibilidad no se produzca."
Si ahora nos vamos al Glosario de términos, contenido en el ANEXO del documento, podemos ver la definición que el Real Decreto hace de "estándar abierto":
“Estándar abierto: Aquél que reúne las siguientes condiciones:
a) Que sea público y su utilización sea disponible de manera gratuita o a un coste que no suponga una dificultad de acceso,
b) Que su uso y aplicación no esté condicionado al pago de un derecho de propiedad intelectual o industrial.”
En base a la afirmación anterior podemos concluir que los formato utilizados por Microsoft no cumplen en ningún caso lo establecido por el Real Decreto 4/2010.
Microsoft Office nunca ha empleado un formato estándar hasta su versión 2007, ya que a partir de este producto empezó a utilizar como formato por defecto el OOXML (Office Open XML), el cual fue declarado como estándar ISO/IEC 29500 en el año 2008, después de diferentes procesos sospechosos y duras controversias.
En cambio OpenOffice emplea como formato para sus archivos el ODF (OpenDocument Format), desarrollado inicialmente por Sun Microsystems y aprobado como estándar ISO/IEC 26300 en el año 2005.
Los criterios de diseño para ODF fueron totalmente independientes de los vendedores, compatibles con la suite Office, accesibles para desarrolladores, se utilizaron estándares abiertos ya existentes y se implementó una estructura clara y extendible.
Si en la Administración Pública se consiguiera pasar completamente a OpenOffice, supondría alcanzar la antesala de una hipotética migración de todos los equipos de los usuarios a GNU Linux, ya que hoy en día el principal escollo que obliga a seguir utilizando Microsoft Windows como sistema operativo de trabajo es el empleo de Microsoft Office como suite ofimática.
El 8 de Enero de 2010 se aprobó el Real Decreto 4/2010, donde se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, por el que se obliga a los organismos públicos a la utilización de estándares abiertos (artículo 11):
"1. Las Administraciones públicas usarán estándares abiertos, así como, en su caso y de forma complementaria, estándares que sean de uso generalizado por los ciudadanos, al objeto de garantizar la independencia en la elección de alternativas tecnológicas por los ciudadanos y las Administraciones públicas y la adaptabilidad al progreso de la tecnología y, de forma que:
a) Los documentos y servicios de administración electrónica que los órganos o Entidades de Derecho Público emisores pongan a disposición de los ciudadanos o de otras Administraciones públicas se encontrarán, como mínimo, disponibles mediante estándares abiertos.
...
2. En las relaciones con los ciudadanos y con otras Administraciones públicas, el uso en exclusiva de un estándar no abierto sin que se ofrezca una alternativa basada en un estándar abierto se limitará a aquellas circunstancias en las que no se disponga de un estándar abierto que satisfaga la funcionalidad satisfecha por el estándar no abierto en cuestión y sólo mientras dicha disponibilidad no se produzca."
Si ahora nos vamos al Glosario de términos, contenido en el ANEXO del documento, podemos ver la definición que el Real Decreto hace de "estándar abierto":
“Estándar abierto: Aquél que reúne las siguientes condiciones:
a) Que sea público y su utilización sea disponible de manera gratuita o a un coste que no suponga una dificultad de acceso,
b) Que su uso y aplicación no esté condicionado al pago de un derecho de propiedad intelectual o industrial.”
En base a la afirmación anterior podemos concluir que los formato utilizados por Microsoft no cumplen en ningún caso lo establecido por el Real Decreto 4/2010.
Microsoft Office nunca ha empleado un formato estándar hasta su versión 2007, ya que a partir de este producto empezó a utilizar como formato por defecto el OOXML (Office Open XML), el cual fue declarado como estándar ISO/IEC 29500 en el año 2008, después de diferentes procesos sospechosos y duras controversias.
En cambio OpenOffice emplea como formato para sus archivos el ODF (OpenDocument Format), desarrollado inicialmente por Sun Microsystems y aprobado como estándar ISO/IEC 26300 en el año 2005.
Los criterios de diseño para ODF fueron totalmente independientes de los vendedores, compatibles con la suite Office, accesibles para desarrolladores, se utilizaron estándares abiertos ya existentes y se implementó una estructura clara y extendible.
Si en la Administración Pública se consiguiera pasar completamente a OpenOffice, supondría alcanzar la antesala de una hipotética migración de todos los equipos de los usuarios a GNU Linux, ya que hoy en día el principal escollo que obliga a seguir utilizando Microsoft Windows como sistema operativo de trabajo es el empleo de Microsoft Office como suite ofimática.
MAR 17, 2010
Scripts externos en Zabbix
Zabbix trae de serie numerosas plantillas, también conocidas como templates, que permiten monitorizar diversas aplicaciones y sistemas.
Puede ocurrir que con esas plantillas no tengamos los suficientes recursos para monitorizar un determinado servicio. Ante esta situación podríamos crear un script personalizado que cumpla los requisitos solicitados, utilizar algún tipo de script que ya haya sido implementado por otra persona o utilizar por ejemplo plugins de Nagios, los cuales pueden ser llamados desde Zabbix encapsulándolos a través de un wrapper.
Un wrapper no es más que un envoltorio de un determinado plugin de Nagios, el cual se encarga de ejecutar dicho script y parsear sus resultados al formato de Zabbix.
Para poder utilizar scripts externos en Zabbix, lo primero que hay que hacer es definir en el fichero de configuración del servidor el directorio donde residirán los scripts.
A la hora de crear un item que utilice un script externo, tendremos que seleccionar como tipo (Type), External check.
Vamos a ver todo esto con un sencillo ejemplo: se va a crear un script externo en bash que monitorice el número de procesos Apache que hay levantados. El script se va a llamar check_status.sh y va a recibir como único argumento el nombre del proceso del cual debe obtenerse el número total de procesos existentes.
Como versión de Zabbix se va a emplear una 1.8.1 en un CentOS 5.4 de 64 bits.
Para ejecutar el script desde Zabbix utilizaremos la siguiente llamada como key: check_process.sh[httpd]. El tipo de dato que devolverá la función será un número entero decimal sin signo.
Para devolver un valor a Zabbix desde un script externo en bash, utilizaremos el comando echo. Por lo tanto, el script quedará de la siguiente forma:
Como argumento recibido a través de la línea de órdenes se tiene que empezar a utilizar a partir de $2, ya que $1 se corresponde siempre con la dirección IP de la máquina que ejecuta el script.
Si se necesitan pasar más parámetros, éstos deben estar separados por espacios en blanco (por ejemplo check_process.sh[httpd "memory limit"]).
Puede ocurrir que con esas plantillas no tengamos los suficientes recursos para monitorizar un determinado servicio. Ante esta situación podríamos crear un script personalizado que cumpla los requisitos solicitados, utilizar algún tipo de script que ya haya sido implementado por otra persona o utilizar por ejemplo plugins de Nagios, los cuales pueden ser llamados desde Zabbix encapsulándolos a través de un wrapper.
Un wrapper no es más que un envoltorio de un determinado plugin de Nagios, el cual se encarga de ejecutar dicho script y parsear sus resultados al formato de Zabbix.
Para poder utilizar scripts externos en Zabbix, lo primero que hay que hacer es definir en el fichero de configuración del servidor el directorio donde residirán los scripts.
[root@centos ~]# cat /etc/zabbix/zabbix_server.conf
...
ExternalScripts=/etc/zabbix/externalscripts
[root@centos ~]# chown zabbix:zabbix /etc/zabbix/externalscriptsA la hora de crear un item que utilice un script externo, tendremos que seleccionar como tipo (Type), External check.
Vamos a ver todo esto con un sencillo ejemplo: se va a crear un script externo en bash que monitorice el número de procesos Apache que hay levantados. El script se va a llamar check_status.sh y va a recibir como único argumento el nombre del proceso del cual debe obtenerse el número total de procesos existentes.
Como versión de Zabbix se va a emplear una 1.8.1 en un CentOS 5.4 de 64 bits.
Para ejecutar el script desde Zabbix utilizaremos la siguiente llamada como key: check_process.sh[httpd]. El tipo de dato que devolverá la función será un número entero decimal sin signo.
Para devolver un valor a Zabbix desde un script externo en bash, utilizaremos el comando echo. Por lo tanto, el script quedará de la siguiente forma:
[root@centos ~]# cat /etc/zabbix/externalscripts/check_process.sh
#!/bin/bash
echo $(pgrep $2 | wc -l)
[root@centos ~]# chmod +x /etc/zabbix/externalscripts/check_process.shComo argumento recibido a través de la línea de órdenes se tiene que empezar a utilizar a partir de $2, ya que $1 se corresponde siempre con la dirección IP de la máquina que ejecuta el script.
Si se necesitan pasar más parámetros, éstos deben estar separados por espacios en blanco (por ejemplo check_process.sh[httpd "memory limit"]).
MAR 8, 2010
Monitorización de VMware ESXi con resxtop/esxtop
VMware ESXi proporciona una herramienta similar al top de Linux denominada esxtop, la cual permite obtener en tiempo real, datos relativos al uso de CPU, memoria, disco, estado de los procesos, etc.
Para poder ejecutar esxtop hay que tener acceso a la service console (SSH) del VMware ESXi. La forma básica de ejecución de esxtop es la siguiente:
La pantalla interactiva que nos ofrece esta orden nos permite ver los datos relativos al porcentaje de utilización de la CPU, tanto de los distintos cores físicos como el consumo de los procesos. A esta pantalla podremos regresar siempre que queramos pulsando la tecla 'c'.
En la pantalla anterior puede verse que el ESXi en cuestión dispone de ocho cores, ya que en el campo correspondiente al porcentaje de uso de cada una de las CPUs físicas (PCPU USED) se muestran ocho valores. El último campo (AVG) corresponde a la media de todos los cores físicos.
La línea que aparece debajo (PCPU UTIL) representa el porcentaje útil de uso de cada una de las CPUs. Este campo representa el porcentaje real de utilización de la CPU, ya que no se tiene en cuenta el tiempo idle. En cambio PCPU USED sí que tiene en cuenta este valor.
En la primera línea hay que destacar también el campo load average, que indica el número medio de procesos del sistema que durante los últimos 1, 5 y 15 minutos han estado esperando por algún recurso del sistema (CPU, acceso a disco, red, etc.).
La lista de datos que se muestra debajo de la cabecera inicial se corresponde con el estado de los distintos procesos del sistema. Los principales son: %USED es el porcentaje de utilización de las CPUs físicas (suma de de los porcentajes de todos los cores - %USED = %RUN + %SYS - %OVRLP). %RUN es el porcentaje empleado en la planificación. %SYS es el porcentaje de utilización de CPU por parte del VMKernel. %OVRLP es el porcentaje de uso de CPU por parte de los servicios del sistema.
Dentro de esta pantalla, si pulsamos la tecla 'm' accederemos al estado de la memoria (todos los valores representan MB, exceptuando los campos que comienzan por %).
En la primera línea de la pantalla anterior, MEM overcommit avg representa el exceso de memoria (media aritmética) durante los últimos 15, 5 y 1 minuto. Lo habitual es que estos valores sean siempre cero. Si son superiores significa que las máquinas virtuales están solicitando más memoria (física) de la disponible.
La línea PMEM hace referencia a la memoria física. total es la memoria física total disponible. vmk es la cantidad de memoria utilizada por el VMKernel. other es la memoria total empleada por las máquinas virtuales y free es la memoria que queda libre.
La línea VMKMEM hace referencia a la memoria administrada por el VMKernel. minfree es la cantidad de memoria que el VMKernel preferiría tener libre. rsvd es la cantidad de memoria actualmente reservada por el VMKernel y ursvd es la cantidad de memoria que no se encuentra reservada.
La línea PSHARE hace referencia a la memoria compartida. shared es la cantidad de memoria física que está siendo compartida.common es la cantidad de memoria común para todas las máquinas virtuales y saving es la cantidad de memoria guardada debido al intercambio (shared = common + saving).
Y la línea SWAP hace referencia a la memoria swap.
La lista de datos que se muestra debajo de la cabecera inicial se corresponde con la utilización de memoria por parte de los distintos procesos del sistema (o máquinas virtuales). MEMSZ es la cantidad de memoria reservada. GRANT es la cantidad de memoria concedida, SZTGT es la cantidad de memoria utilizada y TCHD es la cantidad de memoria recientemente empleada.
Dentro de esta pantalla, si pulsamos la tecla 'd' accederemos al estado de los distintos adaptadores del sistema. Para el caso del VMware ESXi utilizado, el adaptador vmhba0 se corresponde con un controlador IDE empleado por un CD-ROM. vmhba1 hace referencia al disco duro y vmhba32 no se está utilizando.
Dentro de esta pantalla destacaremos los siguientes valores: READS/s (número de comandos de lectura lanzados por segundo),WRITES/s (número de comandos de escritura lanzados por segundo), MBREAD/s (MB leídos por segundo) y MBWRTN/s (MB escritos por segundo).
Si se pulsa la tecla 'u' accederemos al estado de las diferentes unidades de almacenamiento. mpx.vmhba0:CO:T es la unidad de CD-ROM y mpx.vmhba1:CO:T el disco duro.
Los valores más importantes son los mismos que los mostrados para los adaptadores del sistema.
Y por último, dentro de esta pantalla si pulsamos la tecla 'n' accederemos al estado de los diferentes interfaces de red. Management es un puerto interno. vnmnic0 se corresponde con el único interfaz físico de red (tarjeta) que dispone este VMware ESXi. vmk0 es un interfaz virtual utilizado por el VMKernel para realizar sus propias tareas (actualizaciones, operaciones de vmotion, etc.).
Y el resto de interfaces virtuales (CENTOS01.LOCAL y CENTOS02.local) se corresponden con las tarjetas virtuales que tienen configuradas esas dos máquinas virtuales.
Como puede observarse, los interfaces virtuales están enlazados con el interfaz físico vmnic0. A su vez, todos ellos están conectados a un switch virtual denominado vSwitch0.
PKTTX/s es el número de paquetes transmitidos por segundo. MbTX/s es el número de MB transmitidos por segundo. PKTRX/s es el número de paquetes recibidos por segundo. MbRX/s es el número de MB recibidos por segundo. %DRPTX es el porcentaje de paquetes transmitidos que han sido descartados y %DRPRX es el porcentaje de paquetes recibidos que han sido descartados.
Si al comando esxtop le añadimos el argumentos -a, ampliaremos las estadísticas mostradas.
Otra opción interesante es -b, que permite ejecutar el comando en modo batch. De esta forma podremos volcar los resultados a un fichero. Con la opción -n indicamos el número de iteraciones y con -d el retardo entre dichas iteraciones.
Si no disponemos de acceso SSH al VMware ESXi, podemos utilizar la versión remota de este comando: resxtop. Este comando se encuentra disponible instalando en un PC cliente (Linux o Windows) el vSphere CLI (Command-Line Interface).
Otra utilidad bastante interesante de estas herramientas es la posibilidad de utilizar un fichero de configuración a través de la opción -c. Cuando se lanza resxtop/esxtop, la utilidad trata de buscar siempre el fichero de configuración ~/.esxtop4rc. Si no existe, desplegará todos los campos, y si existe, mostrará sólo los campos que estén definidos dentro de dicho fichero. Para que no utilice por defecto dicho archivo, indicaremos con el parámetro -c la ruta al fichero que queremos utilizar.
Este fichero está formado por ocho líneas. Las siete primeras se corresponden a las pantallas de CPU (c), memoria (m), adaptadores (d), unidades de almacenamiento (u), discos virtuales (v) e interrupciones (i). La última indica la frecuencia de muestreo en segundo y la primera pantalla que se mostrará al ejecutar la herramienta (CPU, memoria, ...).
En cada una de las líneas se establecen las columnas a mostrar mediante letras mayúsculas.
Otra posibilidad de crear este fichero sería una vez que esteviésemos dentro de la pantalla de monitorización, configuraríamos los campos que quisiéramos visualizar y a continuación pulsaríamos la tecla 'W', para que la aplicación generase el fichero esxtop4rc.
Si queremos ampliar la información sobre los datos obtenidos por estos comandos, podemos recurrir al artículo Interpreting esxtop Statistics.
Para poder ejecutar esxtop hay que tener acceso a la service console (SSH) del VMware ESXi. La forma básica de ejecución de esxtop es la siguiente:
~# esxtop
3:25:30pm up 7 days 1:21, 172 worlds; CPU load average: 0.01, 0.01, 0.01
PCPU USED(%): 1.1 0.9 0.5 0.6 0.7 1.1 0.9 1.1 AVG: 0.9
PCPU UTIL(%): 1.6 1.3 0.8 1.0 1.1 1.5 1.4 1.6 AVG: 1.3
ID GID NAME NWLD %USED %RUN %SYS %WAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
1 1 idle 8 798.81 799.22 0.00 0.00 7.58 0.00 0.02 0.00 0.00 0.00
2 2 system 6 0.02 0.02 0.00 600.00 0.00 0.00 0.00 0.00 0.00 0.00
3 3 vim 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 0.00
6 6 helper 55 0.05 0.06 0.00 5500.00 0.01 0.00 0.00 0.00 0.00 0.00
...La pantalla interactiva que nos ofrece esta orden nos permite ver los datos relativos al porcentaje de utilización de la CPU, tanto de los distintos cores físicos como el consumo de los procesos. A esta pantalla podremos regresar siempre que queramos pulsando la tecla 'c'.
En la pantalla anterior puede verse que el ESXi en cuestión dispone de ocho cores, ya que en el campo correspondiente al porcentaje de uso de cada una de las CPUs físicas (PCPU USED) se muestran ocho valores. El último campo (AVG) corresponde a la media de todos los cores físicos.
La línea que aparece debajo (PCPU UTIL) representa el porcentaje útil de uso de cada una de las CPUs. Este campo representa el porcentaje real de utilización de la CPU, ya que no se tiene en cuenta el tiempo idle. En cambio PCPU USED sí que tiene en cuenta este valor.
En la primera línea hay que destacar también el campo load average, que indica el número medio de procesos del sistema que durante los últimos 1, 5 y 15 minutos han estado esperando por algún recurso del sistema (CPU, acceso a disco, red, etc.).
La lista de datos que se muestra debajo de la cabecera inicial se corresponde con el estado de los distintos procesos del sistema. Los principales son: %USED es el porcentaje de utilización de las CPUs físicas (suma de de los porcentajes de todos los cores - %USED = %RUN + %SYS - %OVRLP). %RUN es el porcentaje empleado en la planificación. %SYS es el porcentaje de utilización de CPU por parte del VMKernel. %OVRLP es el porcentaje de uso de CPU por parte de los servicios del sistema.
Dentro de esta pantalla, si pulsamos la tecla 'm' accederemos al estado de la memoria (todos los valores representan MB, exceptuando los campos que comienzan por %).
~# esxtop
3:51:58pm up 7 days 1:47, 174 worlds; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM /MB: 8187 total: 716 vmk, 4091 other, 3379 free
VMKMEM/MB: 7790 managed: 467 minfree, 1285 rsvd, 6136 ursvd, high state
PSHARE/MB: 3794 shared, 1314 common: 2480 saving
SWAP /MB: 0 curr, 0 target: 0.00 r/s, 0.00 w/s
MEMCTL/MB: 0 curr, 0 target, 3992 max
GID NAME MEMSZ GRANT SZTGT TCHD %ACTV %ACTVS %ACTVF %ACTVN OVHDUW OVHD OVHDMAX
16 init.4189 2.40 0.11 2.40 0.11 0 0 0 0 0.00 0.00 0.00
159 busybox.4338 2.40 0.11 2.40 0.11 0 0 0 0 0.00 0.00 0.00
163 vmklogger.4342 2.45 0.09 2.45 0.09 0 0 0 0 0.00 0.00 0.00
...En la primera línea de la pantalla anterior, MEM overcommit avg representa el exceso de memoria (media aritmética) durante los últimos 15, 5 y 1 minuto. Lo habitual es que estos valores sean siempre cero. Si son superiores significa que las máquinas virtuales están solicitando más memoria (física) de la disponible.
La línea PMEM hace referencia a la memoria física. total es la memoria física total disponible. vmk es la cantidad de memoria utilizada por el VMKernel. other es la memoria total empleada por las máquinas virtuales y free es la memoria que queda libre.
La línea VMKMEM hace referencia a la memoria administrada por el VMKernel. minfree es la cantidad de memoria que el VMKernel preferiría tener libre. rsvd es la cantidad de memoria actualmente reservada por el VMKernel y ursvd es la cantidad de memoria que no se encuentra reservada.
La línea PSHARE hace referencia a la memoria compartida. shared es la cantidad de memoria física que está siendo compartida.common es la cantidad de memoria común para todas las máquinas virtuales y saving es la cantidad de memoria guardada debido al intercambio (shared = common + saving).
Y la línea SWAP hace referencia a la memoria swap.
La lista de datos que se muestra debajo de la cabecera inicial se corresponde con la utilización de memoria por parte de los distintos procesos del sistema (o máquinas virtuales). MEMSZ es la cantidad de memoria reservada. GRANT es la cantidad de memoria concedida, SZTGT es la cantidad de memoria utilizada y TCHD es la cantidad de memoria recientemente empleada.
Dentro de esta pantalla, si pulsamos la tecla 'd' accederemos al estado de los distintos adaptadores del sistema. Para el caso del VMware ESXi utilizado, el adaptador vmhba0 se corresponde con un controlador IDE empleado por un CD-ROM. vmhba1 hace referencia al disco duro y vmhba32 no se está utilizando.
~# esxtop
4:37:30pm up 7 days 2:33, 176 worlds; CPU load average: 0.01, 0.01, 0.01
4:42:28pm up 7 days 2:38, 176 worlds; CPU load average: 0.01, 0.01, 0.01
ADAPTR CID TID LID NCHNS NTGTS NLUNS CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
vmhba0 - - - 2 1 1 1.98 0.00 0.00 0.00 0.00 1.01 0.01 1.03 0.00
vmhba1 - - - 1 1 1 8.32 2.77 5.55 0.08 0.07 0.25 0.01 0.26 0.00
vmhba32 - - - 2 0 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00Dentro de esta pantalla destacaremos los siguientes valores: READS/s (número de comandos de lectura lanzados por segundo),WRITES/s (número de comandos de escritura lanzados por segundo), MBREAD/s (MB leídos por segundo) y MBWRTN/s (MB escritos por segundo).
Si se pulsa la tecla 'u' accederemos al estado de las diferentes unidades de almacenamiento. mpx.vmhba0:CO:T es la unidad de CD-ROM y mpx.vmhba1:CO:T el disco duro.
~# esxtop
10:54:40am up 7 days 19:50, 173 worlds; CPU load average: 0.01, 0.01, 0.01
DEVICE PATH/WORLD/PARTITION DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
mpx.vmhba0:C0:T - 16 - 0 0 0 0.00 1.95 0.00 0.00 0.00 0.00 1.00 0.02 1.02 0.01
mpx.vmhba1:C0:T - 32 - 0 0 0 0.00 14.42 10.91 3.51 0.32 0.12 0.32 0.01 0.32 0.00Los valores más importantes son los mismos que los mostrados para los adaptadores del sistema.
Y por último, dentro de esta pantalla si pulsamos la tecla 'n' accederemos al estado de los diferentes interfaces de red. Management es un puerto interno. vnmnic0 se corresponde con el único interfaz físico de red (tarjeta) que dispone este VMware ESXi. vmk0 es un interfaz virtual utilizado por el VMKernel para realizar sus propias tareas (actualizaciones, operaciones de vmotion, etc.).
Y el resto de interfaces virtuales (CENTOS01.LOCAL y CENTOS02.local) se corresponden con las tarjetas virtuales que tienen configuradas esas dos máquinas virtuales.
Como puede observarse, los interfaces virtuales están enlazados con el interfaz físico vmnic0. A su vez, todos ellos están conectados a un switch virtual denominado vSwitch0.
~# esxtop
5:03:02pm up 7 days 2:58, 175 worlds; CPU load average: 0.01, 0.01, 0.01
PORT-ID USED-BY TEAM-PNIC DNAME PKTTX/s MbTX/s PKTRX/s MbRX/s %DRPTX %DRPRX
16777217 Management n/a vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00
16777218 vmnic0 - vSwitch0 1.98 0.00 15.06 0.02 0.00 0.00
16777219 vmk0 vmnic0 vSwitch0 0.40 0.00 6.94 0.01 0.00 0.00
16777220 10059:CENTOS01.LOCAL vmnic0 vSwitch0 1.59 0.00 8.12 0.01 0.00 0.00
16777221 11419:CENTOS02.LOCAL vmnic0 vSwitch0 0.00 0.00 6.54 0.01 0.00 0.00PKTTX/s es el número de paquetes transmitidos por segundo. MbTX/s es el número de MB transmitidos por segundo. PKTRX/s es el número de paquetes recibidos por segundo. MbRX/s es el número de MB recibidos por segundo. %DRPTX es el porcentaje de paquetes transmitidos que han sido descartados y %DRPRX es el porcentaje de paquetes recibidos que han sido descartados.
Si al comando esxtop le añadimos el argumentos -a, ampliaremos las estadísticas mostradas.
Otra opción interesante es -b, que permite ejecutar el comando en modo batch. De esta forma podremos volcar los resultados a un fichero. Con la opción -n indicamos el número de iteraciones y con -d el retardo entre dichas iteraciones.
~# esxtop -b -n 2 -d 5 > file.csvSi no disponemos de acceso SSH al VMware ESXi, podemos utilizar la versión remota de este comando: resxtop. Este comando se encuentra disponible instalando en un PC cliente (Linux o Windows) el vSphere CLI (Command-Line Interface).
[root@centos ~]# resxtop --server 192.168.1.10 --username root
...Otra utilidad bastante interesante de estas herramientas es la posibilidad de utilizar un fichero de configuración a través de la opción -c. Cuando se lanza resxtop/esxtop, la utilidad trata de buscar siempre el fichero de configuración ~/.esxtop4rc. Si no existe, desplegará todos los campos, y si existe, mostrará sólo los campos que estén definidos dentro de dicho fichero. Para que no utilice por defecto dicho archivo, indicaremos con el parámetro -c la ruta al fichero que queremos utilizar.
Este fichero está formado por ocho líneas. Las siete primeras se corresponden a las pantallas de CPU (c), memoria (m), adaptadores (d), unidades de almacenamiento (u), discos virtuales (v) e interrupciones (i). La última indica la frecuencia de muestreo en segundo y la primera pantalla que se mostrará al ejecutar la herramienta (CPU, memoria, ...).
En cada una de las líneas se establecen las columnas a mostrar mediante letras mayúsculas.
[root@centos ~]# cat .esxtop4rc
AG
DHIJK
5c
...Otra posibilidad de crear este fichero sería una vez que esteviésemos dentro de la pantalla de monitorización, configuraríamos los campos que quisiéramos visualizar y a continuación pulsaríamos la tecla 'W', para que la aplicación generase el fichero esxtop4rc.
Si queremos ampliar la información sobre los datos obtenidos por estos comandos, podemos recurrir al artículo Interpreting esxtop Statistics.
