Mostrando entradas con la etiqueta zabbix-api. Mostrar todas las entradas
Mostrando entradas con la etiqueta zabbix-api. Mostrar todas las entradas

Zabbix-API y tiempo de ejecución

En la entrada de hoy voy a comentar una cosa curiosa que me sucedió y a la que le sigo dando vueltas. El software empleado es Zabbix con algunas pequeñas modificaciones que le había aplicado, para tener unos mapas con un poco más de información.
Pongámonos en situación. Zabbix, desde la versión 1.8 trae un API de consulta bastante potente y de la que ya hablamos en otras ocasiones aquí. El propio interfaz gráfico hace uso de ella para obtener sus datos. Especialmente en la versión 2.0 de Zabbix, el uso del API es cada vez más extendido en el frontend. El problema es saber cómo trabajar con un API. No el API de Zabbix, sino cualquier API. ¿Debemos hacer muchas consultas pequeñas? ¿Sólo una y más grande? Mi conclusión, cuando menos para Zabbix, es más óptimo sacar los datos en cuantas menos consultas mejor.
Veamos un ejemplo del fallo.
...
$options = array(
   'nodeids' => get_current_nodeid(true),
   'hostids' => $hostids,
   'output' => array('status'),
   'nopermissions' => true,
   'preservekeys' => true,
   'selectScreens' => API_OUTPUT_COUNT,
);
$hosts = API::Host()->get($options);
foreach ($hosts as $db_element) {
 ...
 if ($db_element['elementtype'] == SYSMAP_ELEMENT_TYPE_HOST) {
  $options = array(
     'hostids' => $db_element["elementid"],
     'output' => array('value', 'description'),
     'nopermissions' => true,
     'filter' => array('value_flags' => null),
     'monitored' => true,
     'skipDependent' => true,
     'only_true' => 1
  );
  $triggers = API::Trigger()->get($options);
  if(count($triggers) > 0) {
   ...
  }
 ...
 }
...
Esta es la parte del código original de Zabbix, en el fichero include/maps.inc.php. Aunque aquí se presenta de forma simplificada, la idea es que se hace una consulta al API (API::Host()) de la que se obtienen los datos de estado de un listado de equipos. Esos equipos son los que pertenecen a un mapa. Después de trabajar con ellos, para un añadido propio, se hace una nueva llamada al API, en la que para cada elemento de tipo HOST se hace una nueva llamada al API de la que se sacan los trigger's que tenga activo el host en cuestión.
Hasta aquí todo correcto y funciona a la perfección. Con un mapa de 10 elementos, por ejemplo, todo es correcto. El problema viene cuando el mapa comienza a tener más de 20 elementos de tipo HOST.  Si el número de elementos (hablando siempre de tipo HOST) es de 7, las llamadas al API será 7, si son 12, 12 y así siempre. Esto es lógico, ¿no?
La lógica también dice que si una llamada tarda en ejecutarse 0.1 segundos, 10 llamadas tardarán 1 segundo. Que yo sepa, el API de Zabbix no hace ningún tipo de filtrado por llamadas excesivas ni nos bloquea por demasiadas peticiones, por lo tanto, lo que me pasó es algo muy curioso.
Si el número de equipos de tipo HOST que tenía en un mapa pasaba de 15, en sacar los datos tardaba entorno a ~20 segundos. Lo normal sería que tardase 2 segundos, podemos asumir incluso 5 segundos, pero si los mapas tenían entorno a 20 equipos, el tiempo no era proporcional al número de llamadas, sino que se disparaba. Esto no entraba dentro de lo esperado, para nada.
Por suerte, la solución fue sencilla y mucho más óptima en cuando a número de llamadas, pero siempre quedará ahí patente el por qué de la tardanza en la ejecución. La base de datos no tenía problema, al servidor web no le subía la carga. Es y quizás seguirá siendo un misterio.

Puede que la informática no siempre sea determinista o que los algoritmos de basen, no siempre sean así.

La entrada Zabbix-API y tiempo de ejecución la puedes leer en Puppet Linux.
Leer más

Zabbix 2.0 API - host.create

Aunque ya hace tiempo que no hablaba acerca de cómo emplear el API de Zabbix, eso no quiere decir que no la estuviese usando, más bien todo el contrario. Durante este tiempo hice numerosas cosas con ella, y la más especial, emplear la versión escrita en Python para interactuar con ella. Puesto que tuve que escribir código en Python, aproveché para recordar y ver cómo evolucionó este lenguaje de programación.
Por si alguien lo necesita, voy a hacer una serie/mini-tutorial acerca de cómo manejar el API de Zabbix (en su versión 2.0), esta vez desde Python.
Lo primero que necesitamos para ello es obtener el código para hablar con el API de Zabbix. Existen varios port's a Pyhton, yo personalmente opté por éste, que es el port a Python de la librería Ruby oficial. Para comenzar a trabajar, lo que necesitamos es crear una carpeta y descargar el código Python necesario (un único fichero). En dicha carpeta también crearemos los script's que vayamos haciendo, para así evitar problemas con las rutas (por simplificar).
shell> mkdir scripts_zabbix
shell> cd scripts_zabbix
shell> wget https://raw.github.com/gescheit/scripts/master/zabbix/zabbix_api.py
Ahora que ya tenemos todo listo, sólo nos queda escribir el pequeño código necesario para crear/actualizar host's en Zabbix. Puesto que deseamos ser ordenados, crearemos un primer fichero de conexión y configuración. Luego un segundo fichero que hará los cálculos y las llamadas. El primer fichero, zabbix_conf.py tendrá el siguiente código.
#!/usr/bin/env python
from zabbix_api import ZabbixAPI

user = 'admin'
password = 'zabbix'
url = 'http://localhost/'
zabbix = ZabbixAPI(server = url)
zabbix.login(user = user, password = password)

templatesList = {
  'windows': '1', # id del template Windows
  'linux': '2',   # id del template Linux
}
soList = {
  'windows': '1', # id del hostgroup Windows
  'linux': '2',   # id del hostgroup Linux
}
Lógicamente, cada uno que adapte la URL, el nombre de usuario y la contraseña a la de su sistema. Acordaros que el usuario que empleéis debe tener acceso a la API. Ahora creamos el segundo fichero, zabbix_host.py que tendrá la siguiente forma,
#!/usr/bin/env python
from zabbix_conf import *
import sys
import getopt
import traceback
import csv
from optparse import OptionParser

use = "Usage: %prog [options]"
parser = OptionParser(usage = use)

parser.add_option("-a", "--add", dest="add", action="store_true", default=False, help="Insert host.")

options, args = parser.parse_args()

if options.add:
  file = csv.reader(open('hosts.list', 'r'), delimiter=' ')
  for index, row in enumerate(file):
    try:
      temporal = {
        "name": row[0].strip(),
        "dns": row[0].strip() + "your_network.net",
        "pais": row[1].strip().upper(),
        "so": row[2].strip()
      }
      groups = [{"groupid": soList[temporal["so"]]}]
      templates = [{"templateid": templatesList[temporal["so"]}]
      profile = {
        "site_country": temporal["pais"],
        "os_full": temporal["so"]
      }
      print str(index + 1) + ":", temporal["name"]
      print "\tGrupos:", groups
      print "\tTemplates:", templates
      print "\tPerfil:", profile

    except:
      print "\tFallo:", data
      continue

    hosts = zabbix.host.get({'filter': {'name': temporal["name"]}, 'output': "extend"})
    if hosts:
      host = {
        'hostid': hosts[0]["hostid"], # línea importante para actualizar
        'host': temporal["name"],
        'groups': groups,
        'templates': templates,
        'inventory': profile,
        'inventory_mode': 0
      }
      r = zabbix.host.update(host);
      if r:
        print "Actualizado correctamente"
      else:
        print "Fallo al actualizar"

    else:
      host = {
        'host': temporal["name"],
        'interfaces': [{'type': 1, 'ip': "0.0.0.0", 'port': 10050, 'useip': 0, 'main': 1, 'dns': temporal["dns"]}],
        'groups': groups,
        'templates': templates,
        'inventory': profile,
        'inventory_mode': 0
      }
      r = zabbix.host.create(host);
      if r:
        print "Añadido correctamente"
      else:
        print "Fallo al crear"
Pues que la idea es automatizar la creación de host's, como podéis observar, al principio del script se lee un fichero, hosts.list, que contiene la siguiente información,
host_1 España Windows
host_2 España Linux
host_3 EE.UU. Linux
Modificar el comportamiento del script no es muy complejo y espero que a alguien le sirva como referencia para comenzar a emplear el API de Zabbix de manera útil.

PD: Recordar que en Python la identación es MUY importante!

La entrada Zabbix 2.0 API - host.create la puedes leer el Puppet Linux.
Leer más

Agregando información extra a los mapas de Zabbix

Aunque lo fuerte de Zabbix no es exactamente el diseño de mapas, sí es cierto que éstos permiten poner de forma visible una gran cantidad de información. Sin mucho esfuerzo podemos crear un mapa con un equipo y que muestre información en tiempo real del mismo. El mapa permite una mejor visualización y la información importante allí mostrada, facilita y de qué forma, saber el estado del mismo. A mayores, si el equipo tiene un fallo, éste también estará presente en el mapa, lo cual ya nos da más información.
Sin embargo, una de las cosas que faltaba en los mapas de Zabbix era que sobre equipos con algún fallo se nos mostrase dicho fallo al pasar por encima con el ratón, por ejemplo. De esta forma los errores se pueden visualizar, pero sólo si nos interesa. En caso contrario no se mostrarán. Con un ejemplo gráfico que se entenderá mejor.

En la parte izquierda tenemos un equipo con información, siempre en tiempo real y con dos errores. La forma de saber cuales son esos errores, tal como está ahí en el mapa es ir a la pestaña trigger's de ese equipo y ver cuales están disparados. Sin embargo, tras la modificación que veremos a continuación, tenemos la imagen de la derecha. En ella se observa un pequeño popup que aparece al pasar el ratón por encima de la imagen y que nos muestra la descripción de los trigger's disparados con el color que le corresponde. Esta información no es molesta, puesto que sólo aparece cuando pasamos el ratón por encima del equipo, sino permanece oculta.
Si te interesa aplicar esta pequeña mejora, simplemente debes de editar el fichero include/maps.inc.php y agregar las siguientes líneas (en negrita) al final de la función getActionMapBySysmap.
...
if (!empty($menus)) {
 $r_area->addAction('onclick', 'javascript: '.$menus);
}

if ($db_element['elementtype'] == SYSMAP_ELEMENT_TYPE_HOST) {
 $options = array(
    'hostids' => $db_element["elementid"],
    'output' => array('value', 'description'),
    'nopermissions' => true,
    'filter' => array('value_flags' => null),
    'monitored' => true,
    'skipDependent' => true,
    'only_true' => 1,
 );
 $triggers = API::Trigger()->get($options);
 if(count($triggers) > 0) {
  $text = "";
  $isTable = false;
  foreach($triggers as $t) {
   if($t["value"] == 1) {
    $isTable = true;
    switch ($t['priority']) {
     case 0: $class="normal"; break;
     case 1: $class="information"; break;
     case 2: $class="warning"; break;
     case 3: $class="average"; break;
     case 4: $class="high"; break;
     case 5: $class="disaster"; break;
     }
    $text .= "<tr><td class='".$class."'>".$t['description']."</td></tr>";
   }
  }
  if($isTable) {
   $text = "<div class='nowrap ui-corner-all ui-widget-header header move'>Triggers</div><table class='tableinfo'>".$text."</table>";
   $r_area->addAction('onmouseover', 'hintBox.HintWraper(event, this, '.zbx_jsvalue($text).', \'\', \'\');');
  }
 }
}
$action_map->addItem($r_area);
...
La idea desarrollada es muy simple. Crear una nueva área oculta con javascript y que ante el evento onmouseover aparezca y contenga la información que no interesa. Lo mismo que el popup que salta al pinchar sobre un equipo y que permite ejecutar comandos, pero con otra información.

La entrada Agregando información extra a los mapas de Zabbix la puedes leer en Puppet Linux.
Leer más

Zabbix trigger report

Supongo que no seré el único que muchas veces está trabajando con Zabbix y necesita tener rápidamente un listado de todos los equipos afectados por un determinado trigger. Recientemente desarrollé un pequeño módulo que se agrega a la pestaña Reports de Zabbix y que ofrece un listado de todos aquellos triggers que están activos y una dirección de correo a la que enviar el listado. Si estás trabajando y alguien te pregunta ¿qué equipos tienen la carga alta? Ahora la respuesta será muy sencilla: "Te lo paso por mail".
Si te interesa lo puedes descargar desde aquí y tras copiarlo a tu directorio raíz con el nombre trigger_report.php ya sólo necesitas editar el fichero include/menu.inc.php y agregar estas líneas dentro del array de reports.
array(
   'url' => 'trigger_report.php',
   'label' => _('Trigger reports'),
   'user_type' => USER_TYPE_SUPER_ADMIN
)
El resultado es el que se muestra en la imagen lateral, en la que sólo salen aquellos trigger's que están activos. A continuación nos pide un mail al que enviar los resultados. Tras darle a enviar, haciendo uso de la API de zabbix, se enviará el listado de los equipos afectados por el trigger que se ha seleccionado.




Leer más

zabbix, no dashboard

zabbix usa un sistema de permisos un poco especial para mostrar los menús. Por defecto tiene creados tres tipos de grupos de usuarios diferentes. Un usuario únicamente puede pertenecer a uno de los grupos y en función de éste, tendrá acceso a unas pestañas u otras. Los datos a los que tengan acceso, están definidos por los grupos de usuarios + grupos de host's. Los 3 tipos de grupos de permisos que hay son:


  • USER_TYPE_ZABBIX_USER
    Definido con el ID 1 y de nombre "Zabbix User" establece los permisos para todas las pestañas a las que puede tener acceso un usuario normal, sin privilegios.
  • USER_TYPE_ZABBIX_ADMIN
    Definido con el ID 2 y con nombre "Zabbix Admin" contiene los permisos para aquellas pestañas a las que un usuario puede tener acceso, pero con algo más de privilegios. Por ejemplo a las pestañas de creación y configuración de host's, mapas, etc.
  • USER_TYPE_SUPER_ADMIN
    Definido con el ID 3 representa al "Zabbix Super Admin" y es el usuario que tiene acceso a todas las pestañas.
En el fichero include/menu.inc.php es donde se usan estas variables para definir si un usuario puede o no puede ver una pestaña. Por ejemplo,
array(
   'url'=>'maps.php',
   'label'=>S_MAPS,
   'sub_pages'=>array('map.php'),
   'user_type'=>USER_TYPE_ZABBIX_USER
),
Aquí de define que la pestaña "maps" es visible para los usuarios con permisos mayor o igual a 'USER_TYPE_ZABBIX_USER'. Prácticamente todas las pestañas o grupos de pestañas tienen estos permisos y siempre se define el de menor permiso que lo puede ver. Saber si un usuario puede o no ver una pestaña por lo tanto es muy simple de calcular.
Vamos a definir ahora el caso que nos atañe, tenemos un grupo de usuarios al que no nos interesa que pueda ver la pestaña dashboard (o cualquier otra). Por defecto esto zabbix no lo permite hacer, por lo que vamos a crear un pequeño parche para ofrecer esta funcionalidad extra.
Primeramente creamos un grupo de usuarios llamado "No dashboard". Todos los usuarios que pertenezcan a este grupo no verán dicha pestaña. Una vez lo tengamos creado, simplemente agregamos ahí a los usuarios que nos interesen. Luego, editamos el fichero include/menu.inc.php y lo dejamos tal que así,
global $ZBX_MENU;
global $USER_DETAILS;

$users = CUser::get(array('filter' => array(
  'userid' => USER_DETAILS['userid']),
  'output' => API_OUTPUT_EXTEND,
  'select_usrgrps' => API_OUTPUT_EXTEND));

$usrgrps = $users[0]['usrgrps'];
$show = 1;
foreach($usrgrps as $ugnum => $usrgrp){
   if(strtolower($usrgrp['name']) == strtolower("No dashboard")) {
      $show = 0;
   }
}

if($show) {
   $dash = array(
      'url'=>'dashboard.php',
      'label'=>S_DASHBOARD,
      'sub_pages'=>array('dashconf.php')
   );
} else {
   $dash = array(
      'url'=>'dashboard.php',
      'label'=>S_DASHBOARD,
      'sub_pages'=>array('dashconf.php'),
      'user_type'=>USER_TYPE_SUPER_ADMIN
   );
}

$ZBX_MENU = array(
   'view'=>array(
   'label'           => S_MONITORING,
   'user_type'       => USER_TYPE_ZABBIX_USER,
   'node_perm'       => PERM_READ_LIST,
   'default_page_id' => 0,
   'pages'=>array(
      $dash,
      array(
         ...
Con este pequeño cambio se consigue una funcionalidad extra muy interesante. Dejo aquí colgado el parche, por si a alguien le interesa.
Leer más

Zabbix 1.8 API - CHost::create

Después de ver ya la función de obtención de datos, es lógico que veamos cómo crear los datos, así que vamos con CHost::create. Como su propio nombre nos hace presagiar, es la función de crear nuevo hosts. Ésta recibe un mayor número de parámetros de entrada, no sólo el nombre del host como la get. Toda la información que nos devolvió la anterior se le puede pasar a create para que la devuelva. Lo único que tenemos que tener en cuenta a la hora de pasarle la información es cómo hay que estructurarla. Es el único truco que tiene esta función. Así que vamos a verlo,
  • Información habitual, que es un array con todos los datos
    hostid, proxy_hostid, host, dns, useip, ip, port, status, disable_until, error, available, errors_from, lastaccess, inbytes, outbytes, useipmi, ipmi_port, ipmi_authtype, ipmi_privilege, ipmi_username, ipmi_password, ipmi_disable_until, ipmi_available, snmp_disable_until, snmp_available, maintenanceid, maintenance_status, maintenance_type, maintenance_from, ipmi_ip, ipmi_errors_from, snmp_errors_from, ipmi_error, snmp_error
  • Templates, es un array con el id de las plantillas a linkar
    templateid
  • Grupos, lo mismo que templates, pero con el id correspondiente al grupo
    groupid
  • profile, un array con los datos que interese
    hostid, devicetype, name, os, serialno, tag, macaddress, hardware, software, contact, location, notes
  • profile_ext, otro array
    hostid, device_alias, device_type, device_chassis, device_os, device_os_short, device_hw_arch, device_serial, device_model, device_tag, device_vendor, device_contract, device_who, device_status, device_app_01, device_app_02, device_app_03, device_app_04, device_app_05, device_url_1, device_url_2, device_url_3, device_networks, device_notes, device_hardware, device_software, ip_subnet_mask, ip_router, ip_macaddress, oob_ip, oob_subnet_mask, oob_router, date_hw_buy, date_hw_install, date_hw_expiry, date_hw_decomm, site_street_1, site_street_2, site_street_3, site_city, site_state, site_country, site_zip, site_rack, site_notes, poc_1_name, poc_1_email, poc_1_phone_1, poc_1_phone_2, poc_1_cell, poc_1_screen, poc_1_notes, poc_2_name, poc_2_email, poc_2_phone_1, poc_2_phone_2, poc_2_cell, poc_2_screen, poc_2_notes
  • maintenances, el último array
    maintenanceid
Una vez que sabemos qué información es la necesaria a pasar, podemos hacer un ejemplo sencillo.
$t = array(array("templateid" => 15),array("templateid" => 2));
$g = array(array("groupid" => 12),array("groupid" => 22));

$h = array(
   'host' => 'Equipo de prueba',
   'useip' => 0,
   'port' => 10050,
   'dns' => 'host.domain.com',
   'ip' => '0.0.0.0',
   'groups' => $g,
   'templates' => $t
);

$r = CHost::create($h);
if($r) {
   echo "Host insertado";
} else {
   echo "Host NO insertado";
}
Como se puede observar el código es sencillo y únicamente hay que declarar aquellos valores que nos interese tener para el equipo. Como dato destacado sobresaltar el valor de la variable useip, que si vale cero indica que el host se monitorizará por dns y si vale 1 que será por IP. Luego también ver que los grupos y las templates se pasan por su id y que la función CHost::create cuando inserta el equipo comprueba internamente dichos valores. Si uno de los dos no existe, el equipo no se podrá crear.
En caso de que nos interese, por ejemplo meter algún valor en el campo profile, simplemente abría que añadir un nuevo.
...
$p = array("devicetype" => 05, "tag" => 'ibm');
$h = array(
   'host' => $d["name"],
   'useip' => 0,
   'port' => 10050,
   'dns' => $d["dns"],
   'ip' => '0.0.0.0',
   'groups' => $g,
   'templates' => $t,
   'profile' => $p
);
$r = CHost::create($);
...
Leer más

Zabbix 1.8 API - CHost::get

Vamos a comenzar hablando de la función más simple que hay, que es CHost::get. Simple en cuanto que sólo devuelve los valores de un host si éste existe. Como su propio nombre indica, get. Pues bien, esta función es importante por que puede ayudar a saber si un host ya existe o no y por lo tanto, permite evitar llamadas más complejas a la API. Si un host no existe, ¿por qué lo vamos a intentar borrar? Y si existe, ¿por qué lo vamos a intentar volver a crear? A mayores, la función get nos devuelve otros valores de interés del host, ya que permite realizar un filtrado por algunos datos. La forma de emplearla es muy sencilla,
$host = CHost::get(array('filter' => array('host' => 'nombre')));
Con esto conseguiremos una salida similar a ésta, al pasarle un nombre de host que exista.
Array
(
   [0] => Array
   (
      [hostid] => 35
   )
)
Y vacío en caso contrario,
Array
(
)
Gracias a ello, podremos realizar condiciones de este tipo,
$host = CHost::get(array('filter' => array('host' => 'nombre')));
if(!empty($host)) {
}
Aunque llegados a este punto, lo que realmente no interesa no es únicamente saber el id del equipo, sino toda la información que éste tiene dentro. Para saber esto hay que realizar la llamada al get con un par de parámetros extra.
$hosts = CHost::get(array('filter' => array('host' => 'nombre'),
                          'select_profile' => true,
                          'extendoutput' => API_OUTPUT_EXTEND));
Y aquí la salida sí contiene toda la información que se espera del host.
Array
(
   [0] => Array
   (
      [profile] => Array
      (
                    [hostid] => 35
                    [devicetype] => 01
                    [name] => 
                    [os] => Linux
                    [serialno] => 
                    [tag] => 12596
                    [macaddress] => 
                    [hardware] => 
                    [software] => Apache
                    [contact] => infor@domain.com
                    [location] => 
                    [notes] => 
      )
      [profile_ext] => Array
      (
      )
      [maintenances] => Array
      (
         [0] => Array
         (
            [maintenanceid] => 0
         )
      )
      [hostid] => 35
      [proxy_hostid] => 0
      [host] => nombre
      [dns] => nombre.domain.com
      [useip] => 0
      [ip] => 0.0.0.0
      [port] => 10050
      [status] => 0
      [disable_until] => 0
      [error] => 
      [available] => 0
      [errors_from] => 0
      [lastaccess] => 0
      [inbytes] => 0
      [outbytes] => 0
      [useipmi] => 0
      [ipmi_port] => 623
      [ipmi_authtype] => 0
      [ipmi_privilege] => 0
      [ipmi_username] => 
      [ipmi_password] => 
      [ipmi_disable_until] => 0
      [ipmi_available] => 0
      [snmp_disable_until] => 0
      [snmp_available] => 0
      [maintenanceid] => 0
      [maintenance_status] => 0
      [maintenance_type] => 0
      [maintenance_from] => 0
      [ipmi_ip] => 
      [ipmi_errors_from] => 0
      [snmp_errors_from] => 0
      [ipmi_error] => 
      [snmp_error] => 
   )
)
Si no se filtran las salidas, get devolverá todos los hosts que Zabbix esté a monitorizar, de ahí que lo veamos con el filtro, ya que puede resultar más útil. Aunque por ejemplo, si lo que nos interesa es saber el número de hosts que hay en Zabbix, podríamos ejecutarlo sin filtro alguno
$hosts = CHost::get();
obteniendo en el array de salida el id de todos los equipos. Útil si luego tenemos que acceder a todos ellos para alguna tarea.
Leer más

Zabbix 1.8 API - CUser::authenticate

La verdad es que ya hacía tiempo que tenía ganas de empezar a escribir esta sería de post que hacen referencia al empleo del API de Zabbix, en su versión 1.8. Sí, la versión 2.0 ya salió, pero todavía no la empleamos en producción.
Tras una época empleando la API de Zabbix para realizar un poco de todo, empiezas a comprender qué es lo que hace y cómo hacerlo, si bien hay que decir que la documentación es un tema pendiente. Pues bien, ya metiéndonos en la materia, el empleo de la API se puede realizar desde prácticamente cualquier lenguaje de programación que soporte json, ya que Zabbix tiene un fichero (api_jsonrpc.php) al que se lanzan todas las llamadas. Si bien es cierto que se puede emplear desde cualquier lenguaje, vamos a ver aquí cómo hacerlo desde perl y desde php.
Lógicamente la API como el resto de partes de Zabbix necesita autenticación, por lo que tendremos que habilitar el empleo de la API al usuario que vayamos a dar de alta. Para hacer esto hay dos formas, a bien añadimos al usuario al grupo "API" (lo más aconsejable) o bien le damos acceso a la API a uno de los otros grupos. La mejor solución es añadir el usuario que vayamos emplear a la API, ya que precisamente para eso está.
Grupos de usuarios Zabbix
Una vez el usuario esté ya listo para poder loguearse con la API, ya sólo nos queda escribir el código necesario para hacerlo. Si deseamos emplear perl, tenemos que instalar las librerías json. Para ello antes de nada,
shell> apt-get intall libjson-perl libjson-rpc-perl libtest-json-perl
Con las librerías instaladas, ya podemos comenzar a escribir nuestro código. Lo primero será autenticarse. Así que vamos a ver cómo poder hacerlo.
  • perl
    En perl existen dos formas de poder acceder a la API de Zabbix. La primera es empleando la API escrita en perl, que permite emplear funciones de más alto nivel. Este es un proyecto independiente, por lo que la continuidad y calidad del mismo no depende en estos momentos de zabbix. La forma de emplearla,
    #!/usr/bin/env perl
    
    use strict;
    use warnings;
    use Zabbix::API;
     
    my $zabbix = Zabbix::API->new(server => 'http://localhost/api_jsonrpc.php', verbosity => 1);
     
    $zabbix->login(user => 'javier', password => 'javier');
    
    La otra forma de emplear perl para acceder a Zabbix es mediante json y acceso a la API de Zabbix directamente. Se le mandan las cadenas en formato json y es Zabbix quien las procesa. Para autenticarse por lo tanto,
    #!/usr/bin/env perl
    
    use 5.010;
    use strict;
    use warnings;
    use JSON::RPC::Client;
    use Data::Dumper;
    
    my $client = new JSON::RPC::Client; 
    my $uri = 'http://localhost/api_jsonrpc.php'; 
    
    my $json_obj = {
     jsonrpc => "2.0",
     method => "user.login",
     params => {
      user => "javier",
      password => "javier"
     },
     id => 1
    };
    
    my $response = $client->call($uri, $json_obj);  
    my $authHash;
    if ($response->content->{'result'}) { 
     $authHash = $response->content->{'result'}; 
     #print "Auth successful - ID hash: " . $authHash . "\n"; 
     print $response->jsontext;
    }
    else {
     #print "sorry, incorrect auth\n";
     exit;
    }
    
  • php
    Accede al API de Zabbix nativamente, al igual que lo hace la mayor parte del código de la web y es la forma más óptima de realizar las consultas. La forma de autenticarse,
    <?php
    include_once "include/config.inc.php";
    
    $config = select_config();
    $login = CUser::authenticate(array('user'=>"javier", \
                          'password'=>"javier", \
                          'auth_type'=>$config['authentication_type']));
    ?>
    
Lo escrito hasta aquí aunque parezca poco es esencial, ya que sin estas líneas el resto de código que escribamos no funcionará. Poco a poco iremos viendo las funciones,
  • CHost::get
  • CHost::create
  • CHost::update
  • CHost::delete
  • CHostGroup::get
  • CHostGroup::create
  • CHostGroup::update
  • CHostGroup::delete
  • CMap::get
  • CMap::create
  • CMap::update
  • CMap::delete
  • CMap::addElements
  • CMap::updateElements
  • CMap::deleteElements
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios