 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Los plugins de check que funcionan con SNMP se desarrollan de forma similar a sus parientes basados en agentes. La diferencia radica tanto en el proceso de descubrimiento de servicios como en el propio check. Con los plugins de check basados en agentes, el plugin de agente se utiliza para determinar qué datos se envían al site de Checkmk, y el prefiltrado (pero no la evaluación) a menudo ya tiene lugar en el host. En cambio, con SNMP debes especificar exactamente qué campos de datos necesitas y solicitarlos explícitamente. Con SNMP, estas áreas (ramas de un árbol) o campos de datos individuales (hojas) se identifican mediante OID (identificadores de objetos).
En teoría, sería posible una transferencia completa de todos los datos (mediante el llamado paseo SNMP), pero incluso con dispositivos rápidos esto lleva minutos, y con conmutadores complejos puede llevar más de una hora. Por tanto, esto ya es un problema durante un descubrimiento y aún más durante el propio check. Aquí Checkmk adopta un enfoque más específico. No obstante, los paseos SNMP están disponibles en Checkmk para depurar los checks existentes y desarrollar tus propios checks.
Si aún no tienes experiencia con SNMP, te recomendamos que leas el artículo sobre monitorización mediante SNMP.
1.1. ¿Qué funciona de forma diferente en SNMP?
En comparación con un check plugin para el agente Checkmk, hay algunas características especiales a tener en cuenta con SNMP. Con un check plugin para SNMP, el descubrimiento de servicios se divide en dos fases.
En un primer paso, se utiliza la función de detección SNMP para detectar el dispositivo. Esto sirve para determinar si el check plugin tiene algún interés para el dispositivo correspondiente y se lleva a cabo para cada dispositivo que se monitoriza mediante SNMP. Para ello, se recuperan algunos OID -individuales, sin camino SNMP-. El más importante de ellos es el sysDescr (OID: 1.3.6.1.2.1.1.1.0). Bajo este OID, cada dispositivo SNMP proporciona una descripción de sí mismo, por ejemplo Flintstones, Inc. Fred Router rev23.
En el segundo paso, se recuperan los datos de monitorización necesarios para cada uno de estos candidatos mediante paseos SNMP. A continuación, se resumen en una tabla y se proporcionan a la función de descubrimiento del check plugin en el argumento section, que determina entonces los items que hay que monitorizar. Entonces se genera un servicio para cada uno de estos items.
Durante el check ya se sabe si el Plugin debe ejecutarse para el dispositivo y, por tanto, no es necesaria una nueva detección SNMP. Los datos de monitorización actuales necesarios para el Plugin se recuperan aquí mediante paseos SNMP.
Entonces, ¿qué tienes que hacer diferente con un check plugin para SNMP en comparación con uno basado en agente?
1.2. ¡No tengas miedo de las MIB!
En esta breve introducción nos gustaría hablar de las tristemente célebres MIB de SNMP, sobre las que existen muchos prejuicios. La buena noticia: Checkmk no necesita las MIB. Sin embargo, pueden ser una ayuda importante a la hora de desarrollar un check plugin o de solucionar problemas de los check plugins existentes.
¿Qué son las MIB? MIB significa literalmente Base de Información de Gestión, que contiene poca más información que la propia abreviatura. Básicamente, una MIB es un archivo de texto legible por humanos que describe las ramas y hojas de un árbol de datos SNMP.
Los OID pueden identificar ramas u hojas. La descripción de la rama contiene información sobre la información del sistema y del subsistema que proporciona la rama. Si un OID hace referencia a una hoja, la información de la MIB contiene información sobre el tipo de datos (cadena de caracteres, número de coma fija, cadena hexadecimal, ...), el rango de valores y la representación. Por ejemplo, las temperaturas pueden almacenarse como un número de coma fija con signo en la escala Celsius con una resolución de 0,1º o sin signo en pasos de 1,0º en la escala Kelvin.
Checkmk proporciona una serie de archivos MIB de libre acceso. Éstos describen campos muy generales del árbol OID global, pero no contienen ningún campo específico del fabricante, por lo que no son de mucha ayuda para los plugins de check plugin de desarrollo propio.
Así que intenta encontrar los archivos MIB relevantes para tu dispositivo concreto en algún lugar del sitio web del fabricante o incluso en la interfaz de gestión del dispositivo. Instala estos archivos en el sitio web de Checkmk, en el directorio ~/local/share/snmp/mibs/. Así podrás traducir los números OID a nombres mediante paseos SNMP y encontrar más rápidamente los datos de interés para la monitorización. Como ya se ha dicho, las MIB bien mantenidas también contienen información interesante en sus comentarios. Puedes ver fácilmente un archivo MIB con un editor de texto o con el localizador less.
2. Encontrar los OID correctos
El requisito previo crucial para desarrollar un check plugin basado en SNMP es que sepas qué OID contienen la información relevante. Para el escenario de ejemplo presentado, hemos supuesto que acabas de encargar un lote de routers del tipo Picapiedra, Inc. Fred Router rev23. A menudo te encontrarás con este dispositivo ficticio en la documentación del fabricante y en los comentarios de la MIB. Sin embargo, te has olvidado de introducir la información de contacto y ubicación de algunos dispositivos. Ahora, un check plugin autoescrito para Checkmk debería ayudarte a identificar estos dispositivos.
 |
El Plugin de ejemplo que hemos preparado está escrito de tal forma que puedes ejecutarlo con casi cualquier dispositivo con capacidad SNMP. Sólo tienes que adaptar la cadena de caracteres a comparar. Si no tienes ningún dispositivo a mano, encontrarás varias opciones de simulación en el capítulo Solución de problemas. |
El primer paso es realizar un recorrido SNMP completo. Esto implica recuperar todos los datos disponibles a través de SNMP. Puedes hacerlo muy fácilmente con Checkmk. Primero incluye en la monitorización el dispositivo para el que quieres desarrollar un check plugin. Asegúrate de que se puede monitorizar en las funciones básicas. Como mínimo, hay que encontrar los servicios SNMP Info y Uptime y probablemente también al menos un Interface.. Esto garantizará que el acceso SNMP funciona correctamente.
A continuación, pasa a la línea de comandos del site Checkmk. Aquí puedes ejecutar un recorrido completo con el siguiente comando -en el siguiente ejemplo para el dispositivo con el nombre del host mydevice01. Te recomendamos que utilices también la opción -v (para verbosidad):
OMD[mysite]:~$ cmk -v --snmpwalk mydevice01
mydevice01:
Walk on ".1.3.6.1.2.1"...3898 variables.
Walk on ".1.3.6.1.4.1"...6025 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/mydevice01.Como ya se ha mencionado, un walk SNMP completo puede tardar minutos o incluso horas (aunque esto último es poco frecuente), así que no te pongas nervioso si tarda un rato en completarse. Los resultados del walk se guardan en el archivo ~/var/check_mk/snmpwalks/mydevice01. Se trata de un archivo de texto fácil de leer que empieza así:
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3
.1.3.6.1.2.1.1.3.0 546522419
.1.3.6.1.2.1.1.4.0 barney@example.com
.1.3.6.1.2.1.1.5.0 big-router-01
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich
.1.3.6.1.2.1.1.7.0 72
.1.3.6.1.2.1.1.8.0 0Cada línea contiene un OID y, a continuación, su valor. Encontrarás el más importante en la primera línea, a saber, sysDescr. Debería ser un identificador único para un modelo de hardware.
La segunda línea también es interesante: por debajo de 1.3.6.1.4.1 hay ramas que los fabricantes de hardware pueden asignarse a sí mismos, aquí Picapiedra, Inc. tiene el identificador de fabricante ficticio 424242. Por debajo, la empresa ha asignado 2 para los routers y 3 para el mismo modelo. A continuación, encontrarás OID específicos de cada dispositivo dentro de esta rama.
Sin embargo, estos OID no son muy significativos. Si tienes instaladas las MIB correctas, puedes traducirlas a nombres en un segundo paso. Lo mejor es redirigir la salida del siguiente comando, que de otro modo se mostraría en el terminal, a un archivo:
OMD[mysite]:~$ cmk --snmptranslate mydevice01 > /tmp/translatedUna vez que este archivo ha sido translated se lee como el paseo original, pero además muestra el nombre de la OID en cada línea después del -->:
.1.3.6.1.2.1.1.1.0 Flintstones, Inc. Fred Router rev23 --> SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.424242.2.3 --> SNMPv2-MIB::sysObjectID.0
.1.3.6.1.2.1.1.3.0 546522419 --> DISMAN-EVENT-MIB::sysUpTimeInstance
.1.3.6.1.2.1.1.4.0 barney@example.com --> SNMPv2-MIB::sysContact.0
.1.3.6.1.2.1.1.5.0 big-router-01 --> SNMPv2-MIB::sysName.0
.1.3.6.1.2.1.1.6.0 Server room 23, Stonestreet 52, Munich --> SNMPv2-MIB::sysLocation.0
.1.3.6.1.2.1.1.7.0 42 --> SNMPv2-MIB::sysServices.0
.1.3.6.1.2.1.1.8.0 27 --> SNMPv2-MIB::sysORLastChange.0En la salida anterior, por ejemplo, el OID 1.3.6.1.2.1.1.4.0 tiene el valor barney@example.com y el nombre SNMPv2-MIB::sysContact.0. La información adicional que muestra los nombres de los OID proporciona información importante para identificar los OID de interés. Para el ejemplo presentado, los OID 1.3.6.1.2.1.1.4.0 a 1.3.6.1.2.1.1.6.0 son suficientes.
3. Escribir un simple plugin de check
Ya has completado el trabajo preparatorio: ahora tienes una lista de los OID que quieres leer y evaluar. La tarea ahora consiste en utilizar estas notas para enseñar a Checkmk qué servicios se generan y cuándo deben pasar a WARN o CRIT. La programación de un check plugin en Python utilizada para esto tiene muchos paralelismos con un check plugin basado en agentes. Como hay que tener en cuenta algunas sutilezas, mostraremos la estructura completa con todas las funciones que se utilizan.
3.1. Preparar el archivo
Para tus propios plugins de check, encontrarás el directorio base ya preparado en la jerarquía local del directorio del site. Se trata de ~/local/lib/python3/cmk_addons/plugins/. El directorio pertenece al usuario del site y, por tanto, puedes escribir en él.
En este directorio, los Plugin están organizados en familias de Plugin, cuyos nombres de directorio puedes elegir libremente. Por ejemplo, todos los Plugin relacionados con dispositivos Cisco se almacenan en la carpeta cisco - o todos los Plugin relacionados con routers del fabricante Flintstones, Inc. se almacenan en la carpeta flintstone.
En este subdirectorio <plug-in_family>, se crean otros subdirectorios con nombres predefinidos según sea necesario para las distintas APIs, por ejemplo agent_based para la API Check de los plugins basados en agentes, incluidos los plugins check basados en SNMP.
Crea los dos subdirectorios para el nuevo check plugin y, a continuación, pásate a ellos para trabajar:
OMD[mysite]:~$ mkdir -p local/lib/python3/cmk_addons/plugins/flintstone/agent_based
OMD[mysite]:~$ cd local/lib/python3/cmk_addons/plugins/flintstone/agent_basedCrea aquí el archivo flintstone_setup_check.py para el check plugin. La convención es que el nombre del archivo refleje el nombre del check plugin tal y como se define cuando se crea el check plugin como una instancia de la clase CheckPlugin. Es obligatorio que el archivo termine con .py, porque a partir de la versión de Checkmk 2.0.0 los check plugins son siempre módulos reales de Python.
Un marco básico ejecutable(Descargar en GitHub), que ampliarás paso a paso a continuación, tiene el siguiente aspecto:
#!/usr/bin/env python3
from cmk.agent_based.v2 import (
CheckPlugin,
CheckResult,
startswith,
DiscoveryResult,
Result,
Service,
SimpleSNMPSection,
SNMPTree,
State,
StringTable,
)
def parse_flintstone(string_table):
return {}
def discover_flintstone(section):
yield Service()
def check_flintstone(section):
yield Result(state=State.OK, summary="Everything is fine")
snmp_section_flintstone_setup = SimpleSNMPSection(
name = "flintstone_base_config",
parse_function = parse_flintstone,
detect = startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"),
fetch = SNMPTree(base='.1.3.6.1.2.1.1', oids=['4.0']),
)
check_plugin__flintstone_setup = CheckPlugin(
name = "flintstone_setup_check",
sections = [ "flintstone_base_config" ],
service_name = "Flintstone setup check",
discovery_function = discover_flintstone,
check_function = check_flintstone,
)Primero tendrás que importar las funciones y clases necesarias para los check plugin desde los módulos de Python. Te desaconsejamos el uso ocasional de import *, ya que hace un uso innecesario de la memoria y oscurece qué namespaces están realmente disponibles. Para nuestro ejemplo, sólo importaremos lo que será necesario o pueda ser útil en el resto de este artículo:
from cmk.agent_based.v2 import (
CheckPlugin,
CheckResult,
startswith,
DiscoveryResult,
Result,
Service,
SimpleSNMPSection,
SNMPTree,
State,
StringTable,
)En comparación con el plugin de check plugin de agente, destacan las nuevas funciones y clases específicas de SNMP: SNMPTree, SimpleSNMPSection y startswith. Se explica por sí misma SNMPTree, que es una clase para visualizar árboles SNMP. La clase SimpleSNMPSection se utiliza para crear una sección SNMP. La función startswith() compara el contenido de una hoja SNMP con una cadena de caracteres. Más adelante hablaremos de ello.
3.2. Crear la sección SNMP
Después de haber identificado los OID correctos, es hora de desarrollar realmente el check plugin. Al crear la sección SNMP, especifica dos cosas:
Identificas los dispositivos para los que se va a ejecutar el check plugin.
En el siguiente ejemplo, esto se hace con la funciónstartswith(), que compara una cadena de caracteres con el inicio del contenido de una hoja OID. A continuación se muestran otras opciones de asignación.Declara qué ramas u hojas OID se van a recuperar para la monitorización.
Esto se hace con el constructor de la claseSNMPTree.
Amplía el archivo de ejemplo preparado para que el Plugin sólo se ejecute para un número reducido de dispositivos, en este caso los modelos Flintstones, Inc. Fred Router. A continuación, se recuperan para estos dispositivos los OID de contacto, nombre de dispositivo y ubicación. Cada dispositivo proporciona estos tres OID. Por tanto, si quieres probar el ejemplo con dispositivos reales con capacidad SNMP, basta con personalizar el nombre del modelo a reconocer.
snmp_section_flintstone_setup_check = SimpleSNMPSection(
name = "flintstone_base_config",
parse_function = parse_flintstone,
detect = startswith(
".1.3.6.1.2.1.1.1.0",
"Flintstones, Inc. Fred Router",
),
fetch = SNMPTree(
base = '.1.3.6.1.2.1.1',
oids = ['4.0', '5.0', '6.0'],
),
)El ejemplo también contiene el parámetro name con el que se identifica la sección SNMP generada y una función de análisis sintáctico, de la que hablaremos más adelante.
La detección SNMP
Utiliza el parámetro detect para especificar las condiciones en las que debe ejecutarse la función de descubrimiento. En nuestro ejemplo, éste es el caso si el valor del OID 1.3.6.1.2.1.1.1.0 (es decir, el sysDescr) empieza por el texto Flintstones, Inc. Fred Router (no distingue mayúsculas de minúsculas). Además de startswith, hay toda una serie de otras funciones posibles para la identificación. También existe una forma negada de cada una, que empieza por not_. Ten en cuenta que cada función debe especificarse por separado en la declaración import.
| Atributo | Función | Negación |
|---|---|---|
|
El valor del OID coincide con el texto |
|
|
El valor del OID contiene el texto |
|
|
El valor del OID comienza con el texto |
|
|
El valor del OID termina con el texto |
|
|
El valor del OID corresponde a la expresión regular |
|
|
El OID está disponible en el dispositivo. Su valor puede estar vacío. |
|
También existe la opción de vincular varios atributos con all_of o any_of.
all_of El siguiente ejemplo asigna tu check plugin a un dispositivo si el texto de sysDescr empieza por foo (o FOO o Foo) yel OID 1.3.6.1.2.1.1.2.0 contiene el texto .4.1.11863.:
detect = all_of(
startswith(".1.3.6.1.2.1.1.1.0", "foo"),
contains(".1.3.6.1.2.1.1.2.0", ".4.1.11863.")
)En cambio, any_of se satisface si sólo se cumple uno de los criterios. He aquí un ejemplo en el que se permiten distintos valores para el sysDescr:
detect = any_of(
startswith(".1.3.6.1.2.1.1.1.0", "foo version 3 system"),
startswith(".1.3.6.1.2.1.1.1.0", "foo version 4 system"),
startswith(".1.3.6.1.2.1.1.1.0", "foo version 4.1 system"),
)Por cierto: ¿Estás familiarizado con las expresiones regulares? Si es así, probablemente podrías simplificar este ejemplo y arreglártelas con una sola línea:
detect = matches(".1.3.6.1.2.1.1.1.0", "FOO Version (3|4|4.1) .*")Y otra nota importante: Los OID que pasas a la detección SNMP para un check plugin se recuperan de cada dispositivo que se monitoriza mediante SNMP. Sólo así Checkmk puede determinar a qué dispositivos debe aplicarse el check plugin.
Por lo tanto, debes tener mucho cuidado cuando utilices OID específicos del fabricante. Intenta diseñar tu detección SNMP para dar prioridad a que se compruebe primero el sysDescr (1.3.6.1.2.1.1.1.0) y el sysObjectID (1.3.6.1.2.1.1.2.0).
Si aún así necesitas un OID diferente para una identificación exacta, utiliza all_of() y procede como sigue:
Primero chequea
sysDescrosysObjectID.En otros argumentos, puedes restringir aún más el grupo de dispositivos para los que se ejecutará tu Plugin.
detect = all_of(
startswith(".1.3.6.1.2.1.1.1.0", "Flintstone"), # first check sysDescr
contains(".1.3.6.1.4.1.424242.2.3.37.0", "foo"), # fetch vendor specific OID
)Esto funciona gracias al principio de evaluación perezosa: en cuanto falle uno de los anteriores checks, no se realizará ningún otro. En el ejemplo anterior, el OID 1.3.6.1.4.1.424242.2.3.37.0 sólo se recupera de los dispositivos que también tienen Flintstone en su sysDescr.
3.3. Escribir la función de análisis sintáctico
Al igual que con los plugins de agente, la función de análisis sintáctico del check plugin basado en SNMP también tiene la tarea de convertir los datos de agente recibidos en una forma que se pueda procesar fácilmente y, sobre todo, con un alto rendimiento.
Aquí también recibes los datos en forma de lista. Sin embargo, hay que tener en cuenta algunas sutilezas, ya que supone una diferencia si estás consultando hojas o ramas. Como recordatorio: en nuestro ejemplo anterior, se solicitan hojas:
fetch = SNMPTree(
base = '.1.3.6.1.2.1.1',
oids = ['4.0', '5.0', '6.0'],
)Si amplías temporalmente la función parse con la función print(), puedes mostrar los datos que Checkmk proporciona a partir de esta consulta cuando pruebes el Plugin check:
def parse_flintstone(string_table):
print(string_table)
return {}Recibirás una lista anidada que sólo contiene un elemento en su primer nivel, a saber, una lista de los valores recuperados:
[
['barney@example.com', 'big-router-01', 'Server room 23, Stonestreet 52, Munich']
]El resultado es un poco diferente si recuperas ramas que contienen varias hojas. Supongamos que el router puede estar equipado con un número variable de tarjetas de red cuyo nombre, estado de conexión y velocidad pueden leerse a continuación 1.3.6.1.4.1.424242.2.3.23...
fetch = SNMPTree(
base = '.1.3.6.1.4.1.424242.2.3.23',
oids = [
'6', # all names
'7', # all states
'8', # all speeds
],
)... entonces la lista bidimensional podría tener el siguiente aspecto:
[
# Name, State, Speed
['net0', '1', '1000'],
['net1', '0', '100'],
['net2', '1', '10000'],
['net3', '1', '1000'],
]Todas las hojas disponibles bajo un OID se escriben en una columna de la tabla. Por tanto, debería ser obvio que, a efectos de visualización de los datos, sólo se pueden consultar los OID que coincidan.
|
El último ejemplo mostrado para recuperar ramas OID también forma parte de nuestro paseo SNMP proporcionado en GitHub, que puedes utilizar para simulaciones. |
Pero ahora volvamos al ejemplo en el que se consultan las hojas OID de contacto, nombre de dispositivo y ubicación: La siguiente función de análisis sintáctico simplemente copia cada elemento de la lista interior en un par clave-valor en el diccionario devuelto:
def parse_flintstone(string_table):
# print(string_table)
result = {}
result["contact"] = string_table[0][0]
result["name"] = string_table[0][1]
result["location"] = string_table[0][2]
# print(result)
return resultEl resultado de la función parse tendrá entonces este aspecto:
{
'contact': 'barney@example.com',
'name': 'big-router-01',
'location': 'Server room 23, Stonestreet 52, Munich'
}3.4. Crear el plugin check
Un plugin de check se crea exactamente como se describe en los plugins de agente.
Como en la mayoría de los casos consultarás varias ramas SNMP y esto dará lugar a varias secciones SNMP, suele ser necesario el parámetro sections con la lista de secciones que se van a evaluar:
check_plugin__flintstone_setup = CheckPlugin(
name = "flintstone_setup_check",
sections = [ "flintstone_base_config" ],
service_name = "Flintstone setup check",
discovery_function = discover_flintstone,
check_function = check_flintstone,
)3.5. Escribir la función de descubrimiento
La función de descubrimiento también se corresponde con el ejemplo de los plugins de agente para check. Para los plugins de check que sólo generan un servicio por host, basta con un único yield():
def discover_flintstone(section):
yield Service()3.6. Escribir la función check
En el ejemplo, queremos comprobar si el contacto, el nombre del dispositivo y la información de localización están disponibles. Por lo tanto, basta con comprobar qué campos están vacíos en la función de comprobación y, en consecuencia, establecer el estado en CRIT (si falta algo) o en OK (si todo está disponible):
def check_flintstone(section):
missing = 0
for e in ["contact", "name", "location"]:
if section[e] == "":
missing += 1
yield Result(state=State.CRIT, summary=f"Missing information: {e}!")
if missing > 0:
yield Result(state=State.CRIT, summary=f"Missing fields: {missing}!")
else:
yield Result(state=State.OK, summary="All required information is available.")Una vez creada la función check, el Plugin check estará listo para su uso.
Hemos puesto este completo check plugin a tu disposición en GitHub.
3.7. Prueba y activación del plugin check
Las pruebas y la activación se llevan a cabo del mismo modo que con un plugin de agente para check plugin.
El primer paso es el descubrimiento de servicios para el Plugin:
OMD[mysite]:~$ cmk -vI --detect-plugins=flintstone_setup_check mydevice01
Discovering services and host labels on: mydevice01
mydevice01:
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
+ ANALYSE DISCOVERED HOST LABELS
SUCCESS - Found no new host labels
+ ANALYSE DISCOVERED SERVICES
+ EXECUTING DISCOVERY PLUGINS (1)
1 flintstone_setup_check
SUCCESS - Found 1 services
Como era de esperar, el descubrimiento de servicios se ha realizado correctamente. Ahora puedes probar el check contenido en el check plugin:
OMD[mysite]:~$ cmk -v --detect-plugins=flintstone_setup_check mydevice01
+ FETCHING DATA
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
Get piggybacked data
Flintstone setup check All required information is available.
No piggyback files for 'mydevice01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[snmp] Success, [piggyback] Success ...Tras reiniciar el núcleo de monitorización ...
OMD[mysite]:~$ cmk -R
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Validating Nagios configuration...OK
Restarting monitoring core...OK... el nuevo servicio será visible en la monitorización:
4. Solución de problemas
Como la resolución de problemas en los plugins de agente también se aplica esencialmente a los plugins de check plugin basados en SNMP, aquí sólo trataremos los aspectos específicos de SNMP.
4.1. Opciones de simulación
Uso de recorridos SNMP guardados en Checkmk
En el artículo sobre monitorización a través de SNMP mostramos en detalle cómo puedes crear recorridos SNMP desde la GUI y cómo puedes utilizarlos para la simulación. Esto también hace posible desarrollar check plugins en sistemas de prueba que no pueden acceder a los host SNMP para los que estás desarrollando un plugin. En nuestro repositorio de GitHub encontrarás un ejemplo de recorrido SNMP, que utilizamos en este artículo y que puedes usar para desarrollar y probar el check plugin.
El daemon SNMP ficticio
Si quieres asegurarte de que determinados OID cambian unos en función de otros, puede ser útil programar un daemon SNMP ficticio que proporcione datos coherentes. El módulo de Python snmp-agent puede ser una ayuda a la hora de programar un daemon de este tipo.
4.2. Hardware no cooperativo
Antes de poder monitorizar un dispositivo con un nuevo check plugin basado en SNMP, primero debe poder monitorizarse a través de SNMP. Por ello, puedes encontrar una visión general de los problemas conocidos con sugerencias de solución en el artículo sobre Monitorización a través de SNMP.
5. Archivos y directorios
| Ruta del archivo | Descripción |
|---|---|
|
Directorio base para almacenar archivos de Plugin. |
|
Ubicación de almacenamiento para los Plugin de check escritos según la API de check V2. |
|
Almacena aquí los archivos SNMP MIB que deban cargarse automáticamente. |