Monitorizar cambios en carpetas

Fijo que a muchos de vosotros alguna vez os interesó saber quién o cuando se modificaba un archivo y también que os llegase un aviso o que por lo menos quedase registrado en los log's. Aunque ya vimos una forma de hacerlo con audit, hoy os quiero presentar un servicio que se dedica sólo a eso. Se llama incron y, por definirlo, se podría decir que es un pequeño servicio que de dedica a monitorizar las carpetas que le indicamos y ejecutar acciones cuando detecta un cambio (también el que indiquemos).

incron está disponible tanto en Debian/Ubuntu como en CentOs/Red Hat en los repositorios, así que la instalación es sencilla.

shell> apt-get install incron

El fichero de configuración principal es /etc/incron.conf, pero su configuración por defecto nos sirve perfectamente. Dentro de la carpeta /etc/incron.d se colocan todos aquellos archivos de configuración que deseemos incluir con el siguiente formato.

directorio  cambio_a_monitorear  comando_a_ejecutar  parámetros

De los cuales,

• directorio
  Ruta completa al path que deseamos monitorizar
• cambio_a_monitorear
  
  Tipo de cambio sobre el que se va a alertar. Puede ser más de uno, separados por comas. Los cambios disponibles son:
• IN_ACCESS
  Se accedió a un archivo del directorio
• IN_ATTRIB
  Se cambió algunos de los atributos de algún archivo
• IN_CLOSE_WRITE
  Archivo abierto para escritura fue cerrado
• IN_CLOSE_NOWRITE
  Archivo abierto no fue cerrado
• IN_CREATE
  Se creó un nuevo fichero o directorio
• IN_DELETE
  Se borró un fichero o directorio
• IN_DELETE_SELF
  Fichero o directorio se borró a si mismo
• IN_MODIFY
  El archivo fue modificado
• IN_MOVE_SELF
  El archivo se movió a si mismo
• IN_MOVED_FROM
  Se movió un archivo a otro directorio
• IN_MOVED_TO
  Se movió un archivo a este directorio
• IN_OPEN
  El archivo fue abierto
• IN_ALL_EVENTS
  Todos los eventos
• comando_a_ejecutar
  Comando bash a ejecutar.
• parámetros
  Variables que pueden ser pasadas al comando como parámetros.
• $$
  Símbolo del dolar
• $@
  Ruta completa del directorio monitorizado
• $#
  Archivo que produjo el evento
• $%
  Nombre del evento que produce la alerta. Son de la lista anterior
• $&
  Número de evento

Un ejemplo de fichero de configuración que monitorice todo lo ocurrido en /tmp/example puede ser,

/tmp/example  IN_ALL_EVENTS  logger  "$% $#"

Y lo que hacemos es que todo lo que suceda lo envía con logger a syslog. Si ahora vemos lo ocurrido,

logger: "IN_CLOSE_NOWRITE,IN_ISDIR "
logger: "IN_OPEN,IN_ISDIR "
incrond[14571]: (system::test) CMD (logger "IN_CREATE file2")
incrond[14571]: (system::test) CMD (logger "IN_OPEN file2")
incrond[14571]: (system::test) CMD (logger "IN_ATTRIB file2")
incrond[14571]: (system::test) CMD (logger "IN_CLOSE_WRITE file2")
logger: "IN_CREATE file2"
logger: "IN_OPEN file2"
logger: "IN_CLOSE_WRITE file2"
logger: "IN_ATTRIB file2"

Y si en vez de emplear el comando logger empleamos el comando mail, se non enviaría una alerta al correo en cada evento que hayamos detectado.

La entrada Monitorizar cambios en carpetas la puedes leer en Puppet Linux.

Leer más

Control de sesiones Zimbra desde Zabbix

Zimbra ofrece muy buenas herramientas para extraer, tanto desde el interfaz gráfico como desde línea de comandos, información y estado de toda la actividad. Si deseamos tener un perfecto control de nuestros sistemas, de cuanta más información dispongamos, mejor que mejor. Aunque siempre hay que tener un balanceo entre la información recadada, la procesada y el tiempo de cada una.

Sin embargo, con información fácil de extraer siempre es útil tenerla presente y éste es el caso de las sesiones activas y las cuentas que tiene Zimbra. Con la ejecución de un simple comando, zmsoap -z -t admin DumpSessionsRequest, podemos obtener información interesante del uso de nuestro servidor Zimbra.

shell> zmsoap -z -t admin DumpSessionsRequest
<DumpSessionsResponse activeSessions="21" xmlns="urn:zimbraAdmin">
  <soap activeAccounts="4" activeSessions="8"/>
  <imap activeAccounts="7" activeSessions="13"/>
</DumpSessionsResponse>

Como podemos observar, tenenemos el número de sesiones activas en Zimbra en el momento de la ejecución, por lo que si lo ejecutamos periódicamente podemos obtener unas buenas estadísticas del uso del sistema de correo a lo largo del tiempo, lo que ayudaría a prevenir problemas o a dar respuesta a problemas encontrados. Como de lo que estamos hablando es de monitorización, estamos hablando de Zabbix! En el foro de Zabbix, stefaan dejó un script que hacía lo mismo, así que simplemente lo vamos a adaptar para nuestros intereses y propósitos.

#!/usr/bin/perl

use XML::Simple;
use Data::Dumper;

my $num_args = $#ARGV + 1;
if ($num_args != 1) {
   print "Usage: zabbix_sessions <Accounts|Sessions>\n";
   exit;
} else {
   $parm = $ARGV[0];
   $xml = new XML::Simple;
   $xmldata = `/bin/su -c 'zmsoap -z -t admin DumpSessionsRequest' \
               - zimbra`;
   $data = $xml->XMLin($xmldata);
   if ($parm eq "sessions") {
      if($data->{activeSessions} eq ""){
         print "0";
      } else {
         print $data->{activeSessions};
      }
   }
   
   if ($parm eq "soapaccounts") {
      if($data->{soap}{activeAccounts} eq ""){
         print "0";
      } else {
         print $data->{soap}{activeAccounts};
      }
   }
   
   if ($parm eq "soapsessions") {
      if($data->{soap}{activeSessions} eq ""){
         print "0";
      } else {
         print $data->{soap}{activeSessions};
      }
   }
   
   if ($parm eq "imapaccounts") {
      if($data->{imap}{activeAccounts} eq ""){
         print "0";
      } else {
         print $data->{imap}{activeAccounts};
      }
   }
   
   if ($parm eq "imapsessions") {
      if($data->{imap}{activeSessions} eq ""){
         print "0";
      } else {
         print $data->{imap}{activeSessions};
      }
   }
}

Como siempre, necesitamos darle permisos a dicho script para que el usuario zabbix lo pueda ejecutar y también modificar el fichero de configuración del agente, para crear una nueva key, en este caso zimbra.users.

zabbix ALL= NOPASSWD: /usr/local/bin/zabbix_sessions

Y en el agente, creamos la nueva key,

UserParameter=zimbra.users[*], /usr/bin/sudo /usr/local/bin/zabbix_sessions $1

Los parámetros que acepta son: sessions, soapaccounts, soapsessions, imapaccounts e imapsessions. Ya sólo nos queda crear los item's de monitorización.

Como el valor que se almacena es de tipo numérico, si es necesario crear un trigger para algún valor en concreto será muy simple de hacer.

Leer más

Zabbix, howto monitoring raid hardware

El otro día me preguntó un compañero cómo hacer para monitorizar un RAID desde zabbix. Tras las primeras pesquisas, la pregunta obvia es qué tipo de RAID se quiere monitorizar, hardware o software. Cada uno tiene sus utilidades y sus métodos de acceso y control.

En este post vamos a comentar cómo hacer para monitorizar el estado de un RAID hardware, concretamente un RAID que emplee el módulo megaraid del kernel. Aunque realmente tanto da la utilidad que empleemos, pues a nivel de zabbix realmente es lo mismo. Algo consultará el estado del RAID y nos lo devolverá y será zabbix el encargado de notificarnos si se ha producido un cambio de estado o no.
En este caso, para hacerlo más real y con datos de equipos de verdad en el que comprobar que funcionen, vamos a ver cómo emplearlo. Lo primero será comprobar que nuestra controladora RAID es compatible con el software que vamos a instalar, MegaRAID SAS, para ello el módulo megaraid* deberá estar cargado.

shell> lsmod |grep raid
megaraid_sas           45561  2

Como podemos observar lo tenemos disponible. Por lo tanto vamos a instalar el software necesario. Éste no está disponible en los repositorios oficiales de debian/ubuntu, así que tendremos que recurrir al repositorio que el propio fabricante ofrece. Creamos para ello el fichero /etc/apt/sources.list.d/megaraid.list con el siguiente contenido, según sea debian/ubuntu y la versión del mismo.

# ubuntu
deb http://hwraid.le-vert.net/ubuntu/ lucid main

#debian
deb http://hwraid.le-vert.net/debian/ squeeze main

Tras ello,

shell> apt-get update

Ahora que ya tenemos los paquetes disponibles, vamos a ver lo que hay para instalar,

shell> apt-cache search megaraid
  dellmgr - Manage DELL PERC/CERC cards based on LSI MegaRAID chip
  megacli - LSI Logic MegaRAID SAS MegaCLI
  megaclisas-status - get RAID status out of LSI MegaRAID SAS HW RAID
  megactl - LSI MegaRAID SCSI/SAS reporting tool
  megamgr - Manage LSI MegaRAID chip based cards
  megaraid-status - get RAID status out of LSI MegaRAID SCSI/SAS HW RAID

Estos son los nuevos paquetes disponibles, así que instalamos el software que nos interesa para monitorizar el estado de RAID. Aunque hay más utilidades, en este caso sólo nos interesa controlar el estado del equipamiento.

shell> apt-get install megaraid-status megaclisas-status

Cuando finalice la instalación de todo el nuevo software se iniciará un pequeño daemon, megaraidsas-statusd, que se encargará de chequear el correcto funcionamiento del RAID y en caso de que detecte alguna variación de estado, enviará un mail de advertencia. Este comportamiento es por defecto y si no nos interesa, simplemente paramos el nuevo daemon y listo.
A nosotros lo que realmente nos interesa es que nuestra herramienta de monitorización, zabbix, lea el estado del RAID en nos envíe una alerta en caso de que algo falle. Para hacerlo tendremos que ejecutar el comando megaraidsas-status (en mi caso, ya que tengo una unidad sas) o megaraid-status en cualquier otro caso. La salida que este comando nos ofrece es la siguiente,

shell> megaraidsas-status
  -- Arrays informations --
  -- ID | Type | Size | Status
  a0d0 | RAID 17 | 0B | optimal

  -- Disks informations
  -- ID | Model | Status | Warnings
  a0e64s0 | ATA ST950NS 465GiB | online
  a0e64s1 | ATA ST950NS 465GiB | online
  a0e64s2 | ATA ST950NS 465GiB | online
  a0e64s3 | ATA ST950NS 465GiB | online

Primero nos informa acerca del estado del RAID completo (en mi caso optimal) y luego del estado de cada uno de los discos (en este caso, online los 4 discos que tengo).

Si este mismo comando lo ejecutamos en un equipo que tenga el RAID con un disco fallando, la salida será,

shell> megaraidsas-status
  -- Arrays informations --
  -- ID | Type | Size | Status
  a0d0 | RAID 17 | 0B | DEGRADED

  -- Disks informations
  -- ID | Model | Status | Warnings
  a0e64s0 | ATA ST950NS 465GiB | online
  a0e64s1 | ATA ST950NS 465GiB | online
  a0e64s2 | ATA ST950NS | BAD
  a0e64s3 | ATA ST950NS 465GiB | online
  There is at least one disk/array in a NOT OPTIMAL state.

Como podemos observar nos está diciendo que el disco 3 está BAD y por lo tanto el estado general del RAID es DEGRADED. Así de fácil sabemos desde nuestro sistema GNU/Linux que un RAID ha fallado y además qué disco es el que falló.

La pregunta ahora es, cómo unir esto con zabbix. Pues simplemente creamos una nueva key como la que sigue,

zabbix: item RAID status

Las partes importantes del nuevo Item son:

• Key: system.raid.status
• Type of information: Text

La key que hemos creamos no existe, sino que 'nos la hemos inventado' y por lo tanto necesitamos crearla en el equipo. Para hacer este tipo de cosas, en el fichero de configuración del agente zabbix (zabbix_agentd.conf) tenemos los UserParameter, que son parámetros o key's que creamos nosotros directamente y hacemos que nos devuelven el valor que deseamos. Para usarlo con el software de MegaRAID debemos crear un nuevo UserParameter tal que así,

UserParameter=system.raid.status, /usr/sbin/megaraidsas-status | grep RAID | awk '{print $8}'

Si ejecutáis el comando completo podréis ver que la salida es optimal o DEGRADED, según el estado del RAID. Lo que a nosotros nos interesa es justamente eso, almacenar una única cadena ya que luego a la hora de hacer un trigger será mucho más simple.

Si lo hacéis tal que así, obtendréis un maravillo error "ZBX_NOTSUPPORTED", esto es por que el usuario zabbix no tiene permisos para ejecutar dicho comando. Lo ideal sería ahora darle permisos en el fichero /etc/sudoers para permitirle la ejecución, sin embargo esto no funciona. Tras dárselo aparecerá un nuevo fallo.

shell> sudo -u zabbix /usr/sbin/megaraidsas-status 
unable to open device /dev/megaraid_sas_ioctl_node: Permission denied

No se permite acceso al dispositivo como usuario zabbix, así que investigando un poco lo que hace el daemon, es sencillo creo un nuevo UserParameter que funcione y además así nos aseguramos de tener el daemon también ejecutándose. Este nuevo servicio crea, por defecto, bajo /var/run dos ficheros megaraidsas-statusd.[pid|status]. El segundo es el que almacena la salida y que sí puede ser leído por cualquier usuario sin problema ninguno. Así que lo vamos a emplear para tal efecto. Puesto que dicho fichero sólo existe si hay un fallo en el RAID, vamos a dejar el UserParameter así,

UserParameter=system.raid.status, if [ -e /var/run/megaraidsas-statusd.status ]; then cat /var/run/megaraidsas-statusd.status | grep RAID | awk '{print $8}'; else echo "optimal"; fi

Si existe recuperamos el valor, si no existe es el que RAID está correcto y devolvemos optimal.

Ahora que ya tenemos el Item y podemos recuperar valores, sólo queda crear un trigger que salte en caso de que el estado del RAID no sea optimal. Para ello, creamos un nuevo trigger relacionado con el Item recién creado y con estos valores:

• Name: {HOSTNAME} RAID problem
• Expression: {Template Linux RAID:system.raid.status.str("DEGRADED")}=1
• Severity: High
• Enabled: True

Con ello cualquier RAID que sufra algún problema zabbix nos alertará inmediatamente.

La entrada Zabbix, howto monitoring raid hardware la puedes leer en Puppet Linux.

Leer más

Zabbix, control de puntos de montaje

Vamos a ver cómo poder configurar en zabbix una alerta (para sistemas GNU/Linux) que compruebe y monitorice que un punto de montaje está activo. En caso contrario, que nos alerte de que no lo está.

Puesto que desde zabbix no hay un item que monitorice si un punto de montaje está o no activo, podemos simularlo. Aquí ya es trabajo de bash y la forma de hacerlo, la que cada uno prefiera. Lo vamos a realizar de forma simple, así que comencemos con un pequeño script que simule lo que nos interesa.

shell> mount |grep /var|wc -l
0
shell> mount |grep /home|wc -l
1

Como podemos observar, con un simple mount y un wc, ya sabemos si una partición está o no montada. Si devuelve 0 la partición no estará montada y si devuelve 1, ésta sí estará montada. Por lo tanto, las variaciones que zabbix tendrá que tener en cuenta son únicamente los cambios de 0 -> 1 y 1 -> 0.

Como no tenemos un item que lo realice, vamos a agregar el item al fichero de configuración de zabbix, así que al final de todo del fichero de configuración simplemente agregamos un UserParameter.

#UserParameter=,
UserParameter=system.mount.home, mount |grep /home|wc -l

Tras agregarlo, reiniciamos el servicio.

shell> service zabbix-agentd restart

Ahora lo único que falta el crear el nuevo item para el equipo o plantilla, que se encargue de monitorizarlo y el trigger correspondiente.

Vamos por lo tanto a crear un nuevo item asociado a la plantilla Linux (o al equipo que deseemos) con los siguientes datos:

Description: Mount /home
Type: Zabbix agent
Key: system.mount.home
Type of information: Numeric
Data type: Decimal
Update interval (in sec): 1800
Show value: Service state
Applications: Filesystem

Tras ello, comenzará a monitorizarse si la partición está montada o no. Puesto que lo hemos definido como en "Service state", si el valor es 0, significará que no está montada y si es 1, que sí.

Ahora sólo queda crear un pequeño trigger qué salte si el valor de la key es cero. Para ello, simplemente creamos un trigger similar al que sigue,

Name: Partición /home no montada
Expression: {Template_Linux:system.mount.home.last(10)}=0
Severity: Average
Comments: La partición /home no está montada.

Y cuando un equipo que tenga la plantilla Template_Linux no tenga la partición /home montada, saltará el trigger y por lo tanto lo podremos revisar para ver qué pasó.

Esta forma de monitorizar la partición no es 100% efectiva, ya que habría que crear muchas entradas en el fichero de configuración del agente (una para cada partición) así que veremos en otra entrada cómo poder monitorizar varias particiones con una simple entrada, es decir, pasándole parámetros.

Leer más

Agente zabbix funcionando correctamente

Muchas veces cuando se instala un nuevo agente zabbix y éste tarda en enviar información al servidor, no sabemos si es por un problema en la configuración o por que algo está fallando en la comunicación. Una forma de saber si está correctamente configurado y a la escucha es conectarnos a él desde el zabbix_server. Aunque esto no siempre tiene por que funcionar, ya que la conexión puede ser correcta pero aun así no enviar información por que algo esté fallando (por ejemplo, que el propio agente esté colgado y necesite un restart). Para comprobar todos estos detalles, nos podemos servir de telnet ;-)

Primero vamos a comprobar que la configuración del agente está correcta. En este caso hay que mirar el servidor y el puerto. Los valores, serán similares a,

Server=192.168.1.100
ListenPort=10050

Así que ahora toca lanzar un telnet desde la IP del servidor zabbix, en este caso la 192.168.1.100. Intentamos conectar con el cliente, y al conectarnos ejecutamos un item para que nos devuelva su valor.

shell> telnet 192.168.1.33 10050
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
system.cpu.load[,avg15]
ZBXD0.000000
Connection closed by foreign host.

Como se puede observar aquí, devolvió el valor, por lo tanto nuestro agente está funcionando perfectamente y es accesible desde el servidor zabbix.

Leer más

iwatch, monitorizando filesystem local

Aunque existen herramientas para monitorización en red mucho mejores, como es el caso de zabbix, del que ya hemos hablado en este blog varias veces, y que también permite controlar en tiempo real los cambios en ficheros o carpetas alertando de ello, en este caso vamos a ver una pequeña utilidad para equipos aislados. Si trabajamos o controlamos una red muy amplia es buena idea centralizar la monitorización, sin embargo si lo único que nos interesa es tener controlado un equipo, iwatch, es el software que necesitamos.

iwatch es un monitor que está chequeando y avisa, en tiempo real, de cambios en ficheros o directorios. Permite controlar cambios en los atributos, cambios en el contenido, apertura, movimiento, creación de ficheros, etc. Con todo esto envía un correo a la cuenta configurada, que puede ser distinta por recurso y también puede restaurar el contenido original. A bajo nivel, iwatch es un pequeño script escrito en perl que monitoriza los ficheros indicados y actúa según lo establecido.

Para usarlo, primero lo instalamos.

shell> apt-get install iwatch

Una vez instalado, tenemos que indicarle que se ejecute. Hay dos formas de ejecución. En modo daemon o en modo comando, que no devuelve la shell. Nos interesa dejarlo como daemon, por lo tanto, permitimos que arranque como tal.

shell> vi /etc/default/iwatch
## iwatch configuration file

# START_DAEMON:
#   should iwatch start the iwatch daemon during boot?
START_DAEMON=true

# CONFIG_FILE:
#   configuration file for iwatch daemon
#
CONFIG_FILE=/etc/iwatch/iwatch.xml

Ahora sólo queda indicar lo que deseemos monitorizar y qué hacer cuando se detecte algún cambio. El fichero a editar es /etc/iwatch/iwatch.xml. Un pequeño fichero xml muy sencillo de entender y editar. Se especifica el recurso, el mail destino de las alertas y las carpetas o ficheros a controlar.

shell> vi /etc/iwatch/iwatch.xml 
<config>
  <guard email="root@localhost" name="IWatch"/>
  <watchlist>
    <title>Operating System</title>
    <contactpoint email="root@localhost" name="Administrator"/>
    <path type="single" syslog="on">/bin</path>
    <path type="single" syslog="on">/sbin</path>
    <path type="single">/etc</path>
    <path type="recursive">/lib</path>
    <path type="exception">/lib/modules</path>
  </watchlist>
</config>

Sólo queda arrancarlo y cuando se detecte algún cambio, enviará un mail con la advertencia, según la configuración.

shell> /etc/init.d/iwatch start

Un ejemplo de email de alerta recibido se muestra a continuación,

subject: [iWatch] desktop_1: /etc/resolv.conf is changed
[14/Mar/2012 15:12:39]
IN_CLOSE_WRITE /etc/resolv.conf
* /etc/resolv.conf is closed

Leer más

Comandos interesantes: lsof

lsof es un comando incluido en las distribuciones GNU/Linux y que permite lista todos los ficheros abiertos. Se podría considerar un comando de monitorización, puesto que permite controlar los ficheros, sockets y pipes que tiene un determinado proceso abierto. La información que nos muestra es muy similar a la que se puede obtener de /proc/$PID/fd, pero mucho más fácil de consultar.

Un ejemplo de cómo funciona,

shell> lsof  /var/log/auth.log
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
syslog-ng 542 root   9w    REG  202,2    28221 1491804 /var/log/auth.log

También permite consultar los ficheros abiertos por un determinado programa (pid), lo que facilita saber qué es lo que está realizando.

shell> lsof -p 542
COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF      NODE NAME
syslog-ng 542 root  cwd    DIR      202,2     4096   1474716 /var/lib/syslog-ng
syslog-ng 542 root  mem    REG      202,2   113964   2973983 /lib/ld-2.11.2.so
syslog-ng 542 root   0r    CHR        1,3      0t0       545 /dev/null
syslog-ng 542 root   3u   unix 0xc2bfee00      0t0      2562 /dev/log
syslog-ng 542 root   4w   FIFO        0,8      0t0      2556 pipe
syslog-ng 542 root   8r    REG        0,3        0  26531988 /proc/kmsg
syslog-ng 542 root   9w    REG      202,2    28221   1491804 /var/log/auth.log
syslog-ng 542 root  11w    REG      202,2     8566   1491760 /var/log/daemon.log
syslog-ng 542 root  12w    REG      202,2        0   1492687 /var/log/kern.log
syslog-ng 542 root  13w    REG      202,2     2880   1491340 /var/log/syslog
syslog-ng 542 root  14u    REG      202,2    25703   1492016 /var/log/mail.log
syslog-ng 542 root  17w    REG      202,2     7363   1492346 /var/log/messages
syslog-ng 542 root  18w    CHR       4,10      0t0      1280 /dev/tty10
syslog-ng 542 root  19w   FIFO        0,5      0t0      2537 /dev/xconsole

lsof también permite pasarle como parámetro un puerto y ver qué proceso, ficheros o socket's lo están empleando.

Leer más

Comandos interesantes: xentop

xentop es una herramienta de monitorización de dominios cero (dom 0) que, al igual que top, permite observar en tiempo real los cambios que se van produciendo en las máquinas virtuales así como en el dom 0. Está disponible tanto para XenServer como para xen no comercial.

shell> xentop
xentop - 11:13:29   Xen 4.0.1
6 domains: 1 running, 5 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 10485140k total, 10476364k used, 8776k free    CPUs: 4 @ 1995MHz
NAME     STATE  CPU(sec) CPU(%) MEM(k)  MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS ...
apache   --b---  78413   0.1    2093312 20.0   2097152   20.0      1     1    ...
dhcp     --b---  30969   0.0     258304  2.5    262144    2.5      1     1    ...
Domain-0 -----r 260649   4.1    4625408 44.1   no limit  n/a       4     0    ...
mysql    --b---  85804   0.2    2093312 20.0   2097152   20.0      1     1    ...
puppet   -----r 171038   0.5     258304  2.5    262144    2.5      1     1    ...
win      --b---  94523   7.0    1052640 10.0   1052672   10.0      1     1    ...

Leer más

Zabbix: monitorizando log's

Zabbix nos permite obtener los log's de un determinado equipo y en función de su contenido, en base a expresiones regulares, sacar alertas. Esto puede ser algo muy útil por ejemplo, para controlar el número de accesos ssh fallidos a un determinado equipo en un tiempo X predeterminado.

Incluso si avanzamos más, se podrían escalar lo dicho anteriormente a toda la red, por lo que  si a un rango de red es atacada en el mismo momento por un acceso de ssh, puede ser que estén atacando a todos los equipos. Este tipo de avisos también los podremos controlar con zabbix.

Para comenzar a monitorizar los log's primero hay que asegurarse de que en la configuración del equipo agente esté correctamente configurado el nombre del equipo. El nombre que esté en zabbix_agentd.conf debe de coincidir con el nombre del equipo del zabbix-server. Esto es por que la monitorización de log's se realiza mediante check's activos, es el cliente el que envía los datos, no el servidor el que se los pide.

Leer más

Zabbix: trigger con valores variables

El servicio zabbix se encarga de monitorizar muchos parámetros de los equipos. La monitorización es simple, ya que se crea una plantilla y luego únicamente hay que agregar equipos a dicha plantilla para que todo lo que ésta tiene definido se extienda a los equipos. Las plantillas tienen aplicaciones, monitores, triggers y gráficos. Al agregarlo a una plantilla, automáticamente se agregan a todos los equipos.

Esto presenta un problema en los triggers, ya que no todos los equipos tienen por qué tener la misma cantidad de recursos y no es lo mismo que un equipo con 100 Gb de disco tenga el 10% libre, que un equipo con 500 Gb los tenga. Lo mismo sucede para el consumo de RAM, por ejemplo. Controlar estos parámetros variables es muy importante. Para solucionar este problema, zabbix permite tener valores variables en los triggres.

Leer más

Comandos interesantes: mytop

mytop es una utilidad basada en el comando top que permite monitorizar en tiempo real el estado de un servidor MySQL. Internamente lo que hace es conectarse cada X segundos (-s/--delay sec) al servidor en cuestión y ejecutar un 'show processlist' y un 'show status' y formatear la información para presentarsela al usuario.

shell> mytop -u USER -p USER_PASSWD -s 2
MySQL on localhost (5.1.49-3-log)         up 0+22:48:42 [16:16:40]
Queries: 51.0  qps: 0  Slow: 0.0  Se/In/Up/De(%): 6779788/15/03/19
        qps now: 3  Slow qps: 0.0  Threads: 8 (1/0) 23200/00/00/00
Key Efficiency: 99%  Bps in/out: 30.5k/12.8  Now in/out: 7.6/13.7k

Id   User    Host/IP    DB      Time  Cmd Query or State
--   ----    -------    --      ----  --- --------------
135  root    localhost          0     Query show full processlist
137  tecn    server_3  users    2     Query select user,name from
138  syadmin web       infotec  0     Sleep
139  javier  localhost          15    Connec Reading from net
106  app     intranet  web_p    2034  Sleep

Como se puede observar, la salida del comando es muy parecida a la del comando top. Una parte superior, que contiene información más estática referente al estado del servidor y que da información general del número de query's, del estado de los procesos, consumo de red, número de select/insert/update y delete.

La segunda parte es más dinámica y cambia constantemente, según las query's que se estén realizando en el servidor. Es la información 'bien colocada' del show processlist. Esta parte es la que va cambiando constantemente con el tiempo y representa el estado del servidor.

Leer más

Zabbix: envío de alertas según horarios

Zabbix nos permite controlar muchos parámetros de los equipos que monitoriza y lanzar alertas en función de los valores que detecte, según expresiones previamente definidas. Esto es muy útil, ya que si un equipo sube su carga de CPU, por ejemplo, zabbix nos alertará de ellos automáticamente. Esto es una ventaja, pero realmente a pocos usuarios les resulta útil recibir todas las alertas a todas las horas de día, ya que no estará ahí disponibles para verlas. Es por ello que zabbix permite definir rangos horarios para el envío de alertas, por usuario. Esto permite enviar alertas a usuarios en turno de mañana y esas mismas alertas a la gente de la tarde, pero nunca a ambos, ya que se presupone, no las leerán. También, y bajo circunstancias muy concretas, se permitirá el envío de sms's fuera de horario a un usuario concreto, por ejemplo.

Para realizar esto, vamos a "Configuración - Usuarios" y "Añadir medio". Aparecerá una ventana similar a ésta y ahí podremos definir el rango horario que nos interese, así como la gravedad del trigger que desate la alerta.
Un mismo usuario puede tener definidos varios tipos de medios y en cada uno una franja horaria de trabajo diferente.

• Tipo: Tipo de alerta a enviar. Puede ser email, sms, jabber, etc.
• Enviar a: Destinatario de la alerta.
• Cuando: Franja horaria de envío. Esta puede ser:
• d: Día de la semana. 1 - Lunes,..., 7 - Domingo.
• hh: Hora, 00-24.
• mm: Minutos: 00:59.
• Estado: Activado/desactivado.

Por ejemplo, el horario típico laboral, sería "1-5,09:00-18:00", de Lunes a Viernes, de 9 AM a 6 PM.

Más info en zabbix.com

Leer más

Zabbix: gráficas cortadas

Zabbix es un servicio que pide y recibe información de diversos equipos por red. La forma de funcionar es sencilla: Hay unos poller que son los que se encargan de manejar dicha información. Según el número de equipos que el zabbix-server esté monitorizando, puede que algunas de las gráficas empiecen a tener algunos cortes, especialmente si manejamos períodos muy cortos, que es cuando necesita una mayor cantidad threads que atiendan las peticiones..

En la siguiente imagen se muestra un ejemplo del fallo del que estamos hablando. Como se observa se han perdido datos y no ofrece una información muy clara al usuario, pues no se sabe si dicha pérdida es originada por un fallo en el equipo, en la red, o en el servidor.

Gráfico con falta de información

La forma de solucionar estos fallo no es otra que aumentar en número de procesos colectores de información, para que así no se pierda ningún dato. Esto se hace en el fichero de configuración del servidor, zabbix_server.conf, que tiene variables específicas para ello. En la versión actual (2.0.X) dichas variables se vieron aumentadas para facilitar una monitorización de un número mayor de equipos desde el propio servidor.

StartPollers            = 50
StartPollersUnreachable = 20
StartTrappers           = 100
StartPingers            = 20
StartDiscoverers        = 5

Cada uno de estos procesos, se encarga de obtener información específica. Se puede leer más acerca de para qué sirve cada uno de estos procesos en la documentación oficial de Zabbix. El valor que puede tomar, depende del proceso, pero está entre 0 y 1000 en la actualidad.

Una vez solucionado el problema de que no haya procesos que recojan datos, las gráficas aparecen con toda la información correcta, como la siguiente.

Gráfico con toda la información

Es importante revisar el número de procesos necesarios cada cierto tiempo, puesto que si el número de equipos controlados aumenta, el número de procesos Zabbix, también deberá de aumentar.

Leer más

Monitorizando la red: Smokeping

Vuelvo con más novedades, esta vez una herramienta que ayuda a poner gráficas que tanto suelen gustar sobre el estado de la red y la carga que esta tiene. La herramienta se llama smokeping y está disponible en los repositorios de debian testing. Es un pequeño demonio que se ejecuta y está comprobando la latencia mediante el comando fping a los equipos listados. Al mismo tiempo crea una gráficas basadas en RRDtool. La herramienta en sí es muy similar a MRTG, pero sin el componente snmp y por lo tanto mucho más simple de configurar y poner a funcionar.

Un pequeño ejemplo:

shell> apt-get install curl apache2 smokeping

A continuación hay que configurarlo.

shell> vi /etc/smokeping/config.d/General

Y luego agregar la lista de equipos a monitorizar.

shell> cat /etc/smokeping/config.d/Targets
probe = FPing
menu = Top
title = Network Latency Grapher
remark = Welcome to the SmokePing website
+ Local
menu = Local
title = Red Local
++ LocalMachine
menu = Maquina Local
title = localhost
host = localhost
+ Server
menu = Servidores
title = Servidores
++ Servidor_1
menu = Router
title = Router General
host = 192.168.1.1
++Servidor_2
menu = Mail
title = Servidor de mail
host = 192.168.1.15

Tras su sencilla configuración iniciamos el demonio.

shell> /etc/init.d/smokeping start

Y al rato se podrá ver en la web una gráfica con las latencias...

Más información: oetiker -- smokeping

Leer más