OpenNMS Horizon with RRDtool

As described in the previous article we have built and installed an OpenNMS Horizon Core component from the source. It comes with a Java implementation of RRDTool called JRobin. The portability of Java applications allowed users to run OpenNMS platforms where RRDTool wasn’t easily available. It was threadsafe and allowed more threads writing data. RRDTool implemented that functionality and surpassed JRobin performance and feature wise.

💁‍♀️ If you just don’t care in a dev or testing environment, you can use JRobin for simplicity, because it’s just there and works out of the box. For any production environment, I highly recommend to use RRDTool. It gives you much better support for tools, performance and features. Migrating later is doable but painful.

Demystifying iplike in OpenNMS Horizon

As described in the previous article we have built and installed an OpenNMS Horizon Core component from the source.

With setting up the database schema with ${OPENNMS_HOME}/bin/install -dis a function IPLIKE is created for the OpenNMS database.

It allows us to get IP address matches for IPv4 and IPv6 addresses with filters used in all IP filters in the tool, e.g. IPADDR IPLIKE 192.168.0-3.0-255.

By default, the function is implemented in a SQL procedural language (PL/pgSQL). As OpenNMS had to deal with larger IP address inventories, an optimized version in C was created which is available as the IPLIKE package. The C version of this stored procedure has to be built against header files from specific PostgreSQL major versions. This is the reason you see iplike-pgsql{12,13,14,15} packages in the OpenNMS repositories.

JniPing vs. JnaPing

As described in the previous article we have build an OpenNMS Horizon Core component from source. If you don’t do anything else, it will uses an ICMP implementation using Java Native Access (JNA). The big benefit here, it’s all Java and supports IPv4 and IPv6. You also don’t need additional permissions on your Linux system such as net.ipv4.ping_group_range and SELinux. It makes it perfect for local development and also if you want to run OpenNMS on exotic architectures where you can’t easily compile or build the JNI equivalent written in C from the source code. The downside it comes with some overhead for each ICMP service test. You can see the effect on the latency measurements, especially on very fast responding IP addresses, such as the local loopack interface.

OpenNMS - Auf die harte Tour

I asked many questions in 2004 on IRC when I tried to get my first OpenNMS instance up and running. People in the community held my hand when I was struggling. They helped me to get to my personal “Aha!” moments. If you have time and patience, this is great, because this is a great learning opportunity. In the world of User Experience Design, this is called “friction”. How can you determine friction? My background is that of someone who cut his hands on sharp metal changing network equipment and operating IT gear for others – I have empathy for people running OpenNMS. I like to run user empathy sessions with someone in your target group and figure out where and how they struggle. If you have no one, the next best option is to put yourself in the shoes and get your hands dirty.