Advertising:

X: Difference between revisions

From Zabbix-ES
Jump to navigation Jump to search
(Created page with "=LLDs y LLD Overrides= ==Que es y para que se utiliza el LLD== Con los LLDs podemos realizar discoverys y automatizar la creacion de Items, triggers, Graph y Host Prototypes...")
 
Line 8: Line 8:
  pero si el /var se llena, no podremos escribir logs pero la maquina seguirá operativa. Por este motivo podemos decidir que un FS puede tener una criticidad mayor que otro, con un umbral diferente, etc.
  pero si el /var se llena, no podremos escribir logs pero la maquina seguirá operativa. Por este motivo podemos decidir que un FS puede tener una criticidad mayor que otro, con un umbral diferente, etc.
   
   
===Links a videos interesantes===
[https://www.youtube.com/watch?v=1zLrZJZ1CZY Termplates - Practica Lab 2: Low-Level Discovery - Mariano Obarrio curso Zabbix de 0 a 100]
[https://www.youtube.com/watch?v=rufZHXGl0yE Zabbix 5.0 Monitoring Tutorials - LLD Overrides Explained - Dmitry Lambert]
===Formato pre 4.2===
===Formato pre 4.2===
  {
  {

Revision as of 08:03, 23 October 2020

LLDs y LLD Overrides

Que es y para que se utiliza el LLD

 Con los LLDs podemos realizar discoverys y automatizar la creacion de Items, triggers, Graph y Host Prototypes que son para decirlo de una forma facil, elementos genéricos que se aplicaran al dato que recuperemos en el discovery.

El ejemplo mas simple es el de un discovery de FS, no sabemos cuantos FS podemos tener en una maquina, pero si podemos verlos con el comando DF si fuera un linux, el LLD nos permite descubrir los FS y crear Items y triggers que los monitoricen

Pero también podemos tener la necesidad de que algunos de los items no sigan el patrón que nosotros queremos tener para todo lo que auto descubrimos, como puede ser un FS / no es igual que un /var o /home, ya que si el / se nos llena la maquina deja de funcionar,
pero si el /var se llena, no podremos escribir logs pero la maquina seguirá operativa. Por este motivo podemos decidir que un FS puede tener una criticidad mayor que otro, con un umbral diferente, etc.

Links a videos interesantes

Termplates - Practica Lab 2: Low-Level Discovery - Mariano Obarrio curso Zabbix de 0 a 100
Zabbix 5.0 Monitoring Tutorials - LLD Overrides Explained - Dmitry Lambert

Formato pre 4.2

{
  data: [
    { "{#CLAVE1}": "VALOR1", "{#CLAVE2}": "VALOR1" },
    { "{#CLAVE1}": "VALOR2", "{#CLAVE2}": "VALOR2" },
    { "{#CLAVE1}": "VALOR3", "{#CLAVE2}": "VALOR3" }
  ]
}

Formato Post 4.2

[
  { "{#CLAVE1}": "VALOR1", "{#CLAVE2}": "VALOR1" },
  { "{#CLAVE1}": "VALOR2", "{#CLAVE2}": "VALOR2" },
  { "{#CLAVE1}": "VALOR3", "{#CLAVE2}": "VALOR3" }
]

LLD Override (sobreescritura)

Con la relativamente nueva opcion de Override, vamos a sobreescribir algunas propiedades de los itemas, triggers , graficos o hosts en el momento del discovery.


Para los ejemplos utilizaremos los siguientes scripts

Script: nodos.sh 
#!/usr/bin/bash

cat <<EOF
[
  { "{#HOST}": "OSMaster01", "{#PATH}":"/OS/Master01", "{#DESC}": "OpenShift Nodo Master 1" },
  { "{#HOST}": "OSMaster02", "{#PATH}":"/OS/Master02", "{#DESC}": "OpenShift Nodo Master 2" },
  { "{#HOST}": "OSMaster03", "{#PATH}":"/OS/Master03", "{#DESC}": "OpenShift Nodo Master 3" },
  { "{#HOST}": "OSWorker01", "{#PATH}":"/OS/Worker01", "{#DESC}": "OpenShift Nodo Worker 1" },
  { "{#HOST}": "OSWorker02", "{#PATH}":"/OS/Worker02", "{#DESC}": "OpenShift Nodo Worker 2" },
  { "{#HOST}": "OSWorker03", "{#PATH}":"/OS/Worker03", "{#DESC}": "OpenShift Nodo Worker 3" },
  { "{#HOST}": "OSWorker04", "{#PATH}":"/OS/Worker04", "{#DESC}": "OpenShift Nodo Worker 4" },
  { "{#HOST}": "OSWorker05", "{#PATH}":"/OS/Worker05", "{#DESC}": "OpenShift Nodo Worker 5" }
]
EOF
Script: nodos-2.sh 
#!/usr/bin/bash

cat <<EOF
[
  { "{#HOST}": "OSMaster01", "{#PATH}":"/OS/Master01", "{#DESC}": "OpenShift Nodo Master 1" },
  { "{#HOST}": "OSMaster02", "{#PATH}":"/OS/Master02", "{#DESC}": "OpenShift Nodo Master 2" },
  { "{#HOST}": "OSMaster03", "{#PATH}":"/OS/Master03", "{#DESC}": "OpenShift Nodo Master 3" },
  { "{#HOST}": "OSWorker01", "{#PATH}":"/OS/Worker01", "{#DESC}": "OpenShift Nodo Worker 1" },
  { "{#HOST}": "OSWorker02", "{#PATH}":"/OS/Worker02", "{#DESC}": "OpenShift Nodo Worker 2" },
  { "{#HOST}": "OSWorker03", "{#PATH}":"/OS/Worker03", "{#DESC}": "OpenShift Nodo Worker 3" },
  { "{#HOST}": "OSWorker04", "{#PATH}":"/OS/Worker04", "{#DESC}": "OpenShift Nodo Worker 4" },
  { "{#HOST}": "OSWorker05", "{#PATH}":"/OS/Worker05", "{#DESC}": "OpenShift Nodo Worker 5" },
  { "{#HOST}": "OSWorker06", "{#PATH}":"/OS/Worker06", "{#DESC}": "OpenShift Nodo Worker 6" },
  { "{#HOST}": "OSWorker07", "{#PATH}":"/OS/Worker07", "{#DESC}": "OpenShift Nodo Worker 7" },
  { "{#HOST}": "OSWorker08", "{#PATH}":"/OS/Worker08", "{#DESC}": "OpenShift Nodo Worker 8" },
  { "{#HOST}": "OSWorker09", "{#PATH}":"/OS/Worker09", "{#DESC}": "OpenShift Nodo Worker 9" },
  { "{#HOST}": "OSWorker10", "{#PATH}":"/OS/Worker10", "{#DESC}": "OpenShift Nodo Worker 10" }
]
EOF
Script: getStatus.sh 
#!/usr/bin/bash

export PUSAGE=$(/usr/bin/shuf -i 0-100 -n 1)
export STATUS=$([ -f $1/down ] && echo 0 || echo 1;)

echo '{"status":'$STATUS', "pusage": '$PUSAGE'}'


Script: /etc/zabbix/zabbix_agent2.d/ldd_overrides.conf
UserParameter=cluster.discovery,/OS/nodos.sh
UserParameter=cluster.status[*],/OS/getStatus.sh $1

Esctructura de directorios

/OS
├── nodos.sh       <---- LLD que muestra los Nodos del Cluster.
├── nodos-2.sh     <---- LLD que crea nuevos Workers al Cluster.
├── getStatus.sh   <---- Script que simula estado de un nodo UP/DOWN  y el Porcentage de Utilizacion del mismo.  Ej. Respuesta: {"status": 1,"pusage": 35}
├── /OS/Master01
├── /OS/Master02
│   └── /OS/Master02/down       <---- Flag que indica el estado del nodo (DOWN). Si no dice nada esta UP 
├── /OS/Master03
├── /OS/Worker01
├── /OS/Worker02
├── /OS/Worker03
├── /OS/Worker04
├── /OS/Worker05
├── /OS/Worker06
├── /OS/Worker07
├── /OS/Worker08
├── /OS/Worker09
└── /OS/Worker10

Pruebas desde linea de comando

Vamos a verificar que todo este correctamente configurado.

# zabbix_agent2 -t cluster.discovery
# zabbix_agent2 -t cluster.status["/OS/Master01"]
# zabbix_agent2 -t cluster.status["/OS/Master02"]


- Vamos a ver lo mismo pero formateada la salida
# zabbix_get -s 127.0.0.1 -k cluster.discovery | jq
# zabbix_get -s 127.0.0.1 -k cluster.status["/OS/Master01"] | jq
# zabbix_get -s 127.0.0.1 -k cluster.status["/OS/Master02"] | jq