New post
Question
· Nov 15, 2023

Testing MIB file with a Rest API

#API #Docker #Monitoring #InterSystems IRIS for Health #Other

Hello,

In response to the infrastructure needs of our company's service, I've created a small API that sends SNMP queries to InterSystems to visualize relevant data for retrieval when the infrastructure implements monitoring.

However, I'm experiencing a timeout issue when attempting to collect information using an SNMP walk. Here is the code for my API's SNMP service:

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" ];

export const 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()
    });
};

I do have the 'session created' console.log, so I am able to successfully create the SNMP session. However, I encounter this error: 'error: RequestTimedOutError: Request timed out.' The OID corresponds to retrieving irisProdStatus (Current status of all existing productions, of which I have around ten).

I have tried both udp4 and udp6 transport methods. For session creation, I've attempted using localhost as well as 127.0.0.1.

I have InterSystems running in a local Docker container (with the network configured to be on the same 'local network' as my API). Here is my docker-compose file so that you can verify that the correct ports are open :

version: '3.8'
services:
  iris:
    build:
      context: .
      dockerfile: Dockerfile
      target: final
    restart: always
    command: --check-caps false --ISCAgent false
    ports:
      - 161:161/udp
      - 162:162/udp
      - 705:705
      - 1972:1972
      - 52773:52773
      - 53773:53773
    volumes:
      - ./:/home/irisowner/dev
    network_mode: bridge

On the InterSystems portal, I have enabled the %Service_Monitor service and checked the 'Start SNMP agent at system startup' checkbox.

 

I noticed after some research that Net-SNMP on Linux does not enable TCP port 705 by default, hence this error:

I followed these points from the documentation:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

However, I still can't start the snmpd service in the Docker container.

 

Did I miss anything? Is the SNMP library I'm using functioning correctly?

Thanks in advance for your feedback!

 

Best regards,

Cyril

Product version: IRIS 2023.1
$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.1.1 (Build 380U) Fri Jul 7 2023 23:53:46 EDT [Health:5.1.0-1.m1]
Discussion (1)1
Log in or sign up to continue
Guillaume Rongier · Nov 20, 2023

Hello Cyril,

I have finished this exercise, I will share my experience on this subject with you:

Have you checked that the snmpd deamon is installed and configured on your docker instance?

By default, it is not installed, so you have to install and configure it.

Example of a dockerfile to install 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}

Example of a 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

From this neat article : https://community.intersystems.com/post/intersystems-data-platforms-and-...

Then, you have to start the snmpd deamon:

sudo service snmpd start

On iris, you have to configure the snmp agent:

%SYS> w $$start^SNMP()

With all these steps, you should be able to retrieve information via snmp.

snmpwalk -m ALL -v 2c -c public localhost .iso.3.6.1.4.1.16563.4.1.1.1.5.4.73.82.73.83

Result :

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"

Now that the snmpd service is running and functional as well as the snmp agent.

I encourage you to have a look at OpenTelemetry, it's a new standard for monitoring and tracing.

https://opentelemetry.io/

And our implementation of OpenTelemetry for IRIS :

https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=GCM...

0 0