Tester le fichier MIB d'InterSystems avec une API Rest
Bonjour,
Dans le besoin de notre service infrastructure de notre entreprise, j'ai créé une petite API qui fait des requêtes SNMP sur InterSystems afin de visualiser les données intéressantes à récupérer lorsque l'infra mettra en place le monitoring.
Cependant, j'ai un timeout lorsque j'essaye de collecter des informations via un walk. Voici le code du service SNMP de mon API:
import snmp from"net-snmp";
const options = {
port: 161,
retries: 4,
timeout: 3000,
transport: "udp4", // Uniquement udp4 et udp6 possible
trapPort: 162
};
const oids = [ "1.3.6.1.4.1.16563.4.1.15.1.4" ];
exportconst testWalk = () => {
const session = snmp.createSession("localhost", "public", options);
console.log("Session created");
session.walk(oids[0], null, (error, varbinds) => {
if (error) {
console.log("error: " + error);
} else {
for (let i = 0; i < varbinds.length; i++) {
if (snmp.isVarbindError(varbinds[i])) {
console.log(snmp.varbindError(varbinds[i]));
} else {
console.log(varbinds[i].oid + " = " + varbinds[i].value);
}
}
}
session.close()
});
};J'ai bien le console.log de "session created", donc j'arrive bien à créer la session SNMP. Cependant j'ai cette erreur: "error: RequestTimedOutError: Request timed out". L'OID correspond à la récupération de irisProdStatus (Statut actuel de toutes les productions existantes, j'en ai une dizaine).
J'ai essayé les méthodes de transport udp4 et udp6. Pour la création de session j'ai essayé avec localhost mais aussi avec 127.0.0.1
J'ai InterSystems qui tourne sur un docker en local (avec le network configuré pour être sur le même "réseau local" que mon API). Voici mon docker-compose afin que vous puissiez bien vérifier que les bons ports sont bien ouverts :
version:'3.8'services: iris: build: context:. dockerfile:Dockerfile target:final restart:always command:--check-capsfalse--ISCAgentfalse ports: -161:161 -162:162 -705:705 -1972:1972 -52773:52773 -53773:53773 volumes: -./:/home/irisowner/dev network_mode:bridgeSur le portail InterSystems, j'ai bien activé le service %Service_Monitor et j'ai coché la case "démarrer l'agent SNMP au démarrage du système".
Ai-je oublié quelque chose ? Est-ce que la librairie SNMP que j'utilise marche correctement ?
Merci d'avance pour vos retours !
Cordialement,
Cyril
Comments
En poursuivant les tests, j'ai ouvert en UDP les ports 161 et 162 sur le docker d'InterSystems. Cependant j'ai toujours ce problème de timeout.
J'ai remarqué que j'avais cependant une erreur au bout d'environ 2 minutes après avoir activé le service monitor comme expliqué dans le post. Voici l'erreur :.png)
J'en déduis qu'il n'arrive pas à ouvrir en TCP le port 705, cependant ce port est précisé et est bien ouvert dans mon docker compose. Je suis donc bloqué.
J'ai suivi ces informations sur la documentation d'InterSystems :
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…
Mais il est impossible pour moi de démarrer le service snmpd.
Bonjour Cyril,
Je n'ai pas encore été au bout de l'exercice, ce pendant, je vais vous partager mon avancé sur ce sujet :
Avez-vous vérifié que le deamon snmpd etait bien installé et configuré sur votre instance docker ?
Par defaut, il n'est pas installé, il faut donc l'installer et le configurer.
Exemple d'un dockerfile pour installer snmpd :
ARG IMAGE=intersystemsdc/iris-community:latest
FROM $IMAGE
WORKDIR /irisdev/app
USER root
RUN apt-get update && apt-get install -y \
nano \
snmpd \
snmp \
sudo && \
/bin/echo -e ${ISC_PACKAGE_MGRUSER}\\tALL=\(ALL\)\\tNOPASSWD: ALL >> /etc/sudoers && \
sudo -u ${ISC_PACKAGE_MGRUSER} sudo echo enabled passwordless sudo-ing for ${ISC_PACKAGE_MGRUSER}
COPY snmpd.conf /etc/snmp/snmpd.conf
USER ${ISC_PACKAGE_MGRUSER}
Exemple d'un snmpd.conf :
###############################################################################
#
# snmpd.conf:
# An example configuration file for configuring the NET-SNMP agent with Cache.
#
# This has been used successfully on Red Hat Enterprise Linux and running
# the snmpd daemon in the foreground with the following command:
#
# /usr/sbin/snmpd -f -L -x TCP:localhost:705 -c./snmpd.conf
#
# You may want/need to change some of the information, especially the
# IP address of the trap receiver of you expect to get traps. I've also seen
# one case (on AIX) where we had to use the "-C" option on the snmpd command
# line, to make sure we were getting the correct snmpd.conf file.
#
###############################################################################
###########################################################################
# SECTION: System Information Setup
#
# This section defines some of the information reported in
# the "system" mib group in the mibII tree.
# syslocation: The [typically physical] location of the system.
# Note that setting this value here means that when trying to
# perform an snmp SET operation to the sysLocation.0 variable will make
# the agent return the "notWritable" error code. IE, including
# this token in the snmpd.conf file will disable write access to
# the variable.
# arguments: location_string
syslocation "System Location"
# syscontact: The contact information for the administrator
# Note that setting this value here means that when trying to
# perform an snmp SET operation to the sysContact.0 variable will make
# the agent return the "notWritable" error code. IE, including
# this token in the snmpd.conf file will disable write access to
# the variable.
# arguments: contact_string
syscontact "Your Name"
# sysservices: The proper value for the sysServices object.
# arguments: sysservices_number
sysservices 76
###########################################################################
# SECTION: Agent Operating Mode
#
# This section defines how the agent will operate when it
# is running.
# master: Should the agent operate as a master agent or not.
# Currently, the only supported master agent type for this token
# is "agentx".
#
# arguments: (on|yes|agentx|all|off|no)
master agentx
agentXSocket tcp:localhost:705
###########################################################################
# SECTION: Trap Destinations
#
# Here we define who the agent will send traps to.
# trapsink: A SNMPv1 trap receiver
# arguments: host [community] [portnum]
trapsink localhost public
###############################################################################
# Access Control
###############################################################################
# As shipped, the snmpd demon will only respond to queries on the
# system mib group until this file is replaced or modified for
# security purposes. Examples are shown below about how to increase the
# level of access.
#
# By far, the most common question I get about the agent is "why won't
# it work?", when really it should be "how do I configure the agent to
# allow me to access it?"
#
# By default, the agent responds to the "public" community for read
# only access, if run out of the box without any configuration file in
# place. The following examples show you other ways of configuring
# the agent so that you can change the community names, and give
# yourself write access to the mib tree as well.
#
# For more information, read the FAQ as well as the snmpd.conf(5)
# manual page.
#
####
# First, map the community name "public" into a "security name"
# sec.name source community
com2sec notConfigUser default public
####
# Second, map the security name into a group name:
# groupName securityModel securityName
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
####
# Third, create a view for us to let the group have rights to:
# Make at least snmpwalk -v 1 localhost -c public system fast again.
# name incl/excl subtree mask(optional)
# access to 'internet' subtree
view systemview included .1.3.6.1
# access to Cache MIBs Caché and Ensemble
view systemview included .1.3.6.1.4.1.16563.1
view systemview included .1.3.6.1.4.1.16563.2
####
# Finally, grant the group read-only access to the systemview view.
# group context sec.model sec.level prefix read write notif
access notConfigGroup "" any noauth exact systemview none none
Ensuite, il faut lancer le deamon snmpd :
sudo service snmpd start
Sur iris, il faut ensuite configurer le snmp agent :
%SYS> w $$start^SNMP()
Avec toutes ces étapes, vous devriez pouvoir récupérer des informations via snmp.
snmpwalk -m ALL -v 2c -c public localhost .1.3.6.1.4.1.16563.1.1.1.1
C'est là ou je bloque pour le moment, je n'arrive pas à récupérer les informations d'IRIS.
Cependant, le service snmpd est bien lancé et fonctionnel ainsi que le snmp agent.
Pour plus d'informations, je vous invite à lire les articles suivants :
Bonjour,
Merci de votre réponse, je vais essayer de faire en sorte que le fichier de config snmpd soit similaire à celui que vous avez envoyé pour voir si cela corrige le problème, car actuellement lorsque je regarde le statut du service après l'avoir normalement lancé, il est toujours considéré comme inactif.
Je reviens vers vous. Merci !
Ok, ca fonctionne de mon cote, je me suis juste trompé de oid :
snmpwalk -m ALL -v 2c -c public localhost iso.3.6.1.4.1.16563.4.1.1.1.5.4.73.82.73.83Résultat :
iso.3.6.1.4.1.16563.4.1.1.1.5.4.73.82.73.83 = STRING: "IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.1 (Build 229U) Fri Apr 14 2023 17:37:52 EDT"Maintenant que le snmpd fonctionne, je ne peux que vous recommander de vous pencher aussi sur les solutions comme OpenTelemetry, qui est un standard pour la collecte de métriques, traces et logs.
Plus d'infos ici : https://opentelemetry.io/
Et notre documentation ici : https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=GCM_rest
Merci, j'ai pas encore eu le temps d'essayer à nouveau pour le service snmpd, nous utilisons PRTG dans notre entreprise mais comme les messages en général d'InterSystems ne prennent pas en compte l'UTF-8, nous étions en train également de tester via une API pour savoir ce que l'on récupère mais aussi pour rendre plus lisible les informations.
Le statut des productions par exemple c'est: Arrêté mais depuis le SNMP, InterSystems renvoie: "ArrÃ@tÃ@"
En faisant un point en vocal, nous en avons conclu que l'utilisation du SNMP n'est pas judicieux. Il est préférable d'utiliser l'API du monitor (représentée par la route /api/monitor/metrics si l'API est activée sur IRIS).
Il est possible d'activer le monitoring des productions sur cette API.
Super :
Pour information, les métrics interop ne sont pas activés par default.
Pour les activer :
do##class(Ens.Util.Statistics).EnableSAMForNamespace()Plus d'information ici sur la doc