Planet OpenNMS

July 09, 2020

When Build Challenges Lead to Creative Solutions

A good build environment needs the right balance among complexity, speed, cost, and adaptability. With our recent move to CircleCI, OpenNMS has achieved that balance and even created two customized tools that others might find useful.

Complexity of a Large-Scale Project

At over 5 million lines of code, OpenNMS is one of the largest open source Java projects. With three flavors of OpenNMS — Horizon, Meridian, PoweredBy — there is a lot to keep track of.

In brief, our workflow sees bug fixes go into our oldest relevant branch. New features and enhancements go into the Horizon “release-NN.x” branch or “develop”. With automated continuous integration builds, we merge bug and security fixes made to older foundation branches forward:

Build Process Took Too Long

Before moving everything to CircleCI, builds were taking 20-30 minutes on a good machine, but running the test suite took an additional nine hours with the integration and smoke tests. The situation was becoming untenable: waiting for a build, then possibly adding a fix, then waiting again for a new build sometimes meant two days or more to get a green build.

Now, after migration, the entire build time, including testing, takes only 1.5 hours.

How We Did It

We took advantage of CircleCI’s parallel build feature to use multiple machines for the integration tests. This greatly speeds up the processing time, meaning that developers can build, test, fix, and rebuild within a few hours instead of days.

Tests are more self-contained. Previously, with Bamboo, creating new tests could take a week to get things set up. Now we have Dockerized our smoke tests so that they are repeatable without having to use crazy environments.

At this point, we have automated and moved anything significant that was in Bamboo into CircleCI. We will move other parts of the code base that don’t get updated very often on an as-needed basis.

Migration Challenges

The main challenge in migrating to CircleCI was the test part of the CircleCI workflow. For example, to test something that happens an hour into the process, you have to wait an hour to see if it worked. The longer into the process, the longer the wait.

Trying to figure out how to get code signing into the mix was also an issue, because you don't want to leave your private keys anywhere that automated code is accessing. The way to address this in CircleCI is to create an environment variable that contains a text-encoded version of your private key, and then when the build initializes, decode it and write it to disk.

Part of CircleCI's security setup involves making it so that these variables are not sent along to pull-request builds, so someone couldn't create a malicious pull request and extract our private keys.

To solve the code signing problem, we created an orb to sign packages.

Signing Packages with a Custom Orb

An orb is a shareable package of CircleCI configuration for use in builds. We created an orb that automates the process of turning those environment variables into Java jar-signing and GnuPG signing configs, and then also provides commands to perform the signing once you've created unsigned Debian and RPM packages.

This orb is available on the CircleCI website for anyone to use in their own CircleCI environments.

Disadvantages of the New Environment

Cost can be a disadvantage, as CircleCI server management can be expensive, as the cost of chaining multiple machines is a factor, particularly if we need to add more machines to handle the load.

But if you factor in the amount of time Ben Reed, Principal Software Developer and Build Manager at OpenNMS, spent “babysitting” the previous system, we are probably saving money.

“I feel like we are able to do just as much, if not more, with Circle than Bamboo,” Ben says. He adds that CircleCI is pretty easy to work with. “There is not a lot of figuring out how the environment works. It’s simple, but it can be built up to do other things that are more complex.”

What Does This Mean for OpenNMS Users?

Changes to the build environment may affect people like developers who do their own builds, and PoweredBy users who distribute OpenNMS under their own commercial End User’s License Agreement (EULA). PoweredBy users should read the PDF document in the PoweredBy repo that describes the steps needed to work with the new build environment.

Docker Improvements As Well

During the migration process, we also worked to cut down the size of the Horizon and Minion Docker containers. Each Docker command runs and saves snapshots of the file system. These layers build up, until we saw 500MB in Horizon and 200MB in Meridian and Sentinel that weren’t being used. We wrote a separate Docker container that runs a yum server that removes the files, so you never have the temporary files being saved.

Frustrating at Times, But in the End, Worth It

Ben estimates that the work was 50/50 between enjoyment and frustration. “It’s very gratifying when you’re done work and can see it all go through the flow,” he says. “It’s not the most enjoyable project, but finishing it delivered a great deal of satisfaction.”

by Bonnie at July 09, 2020 02:51 PM

July Updates for Meridian 2016 through 2019 and Horizon 26

OpenNMS is released on a monthly schedule, the first Tuesday of the month. The next scheduled release will be August 4th.

In July, we released updates to all Meridian versions from 2016 through 2019, as well as Horizon 26:

Horizon 26.1.2

Release 26.1.2 is the fifth release in the Horizon 26 series.

It contains a bunch of bug fixes and improvements, including docker container optimizations,
Netflow changes, documentation updates, time-series enhancements, and more.

The codename for 26.1.2 is Plague.

Bug Fixes
  • AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception (Issue NMS-7547)
  • Unable to collect SNMP through minions on a large scale (Issue NMS-10389)
  • Update examples/opennms.conf to be JDK11-compatible (Issue NMS-12468)
  • RRD-to-Newts converter only handles AVERAGE RRAs (Issue NMS-12722)
  • Parameters with dots handled incorrectly in BMP feature config (Issue NMS-12738)
  • The ReST end-point for the Flow Exporter details is returning invalid content (Issue NMS-12740)
  • Netflow 5 records in ES do not contain value for delta_switched (Issue NMS-12750)
  • dependency commons-beanutils 1.8.3 vulnerability (Issue NMS-12757)
  • Template field 'APPLICATION TAG' has illegal size (Issue NMS-12783)
  • Kafka Producer puts all events on the same partition when using donotpersist (Issue NMS-12784)
Enhancements
  • Reduce Docker container image size (Issue NMS-12284)
  • Document how to use meta-data with thresholding (Issue NMS-12735)
  • Add documentation for TcpListener (Issue NMS-12736)
  • upgrade to latest Jetty security/bug fixes (Issue NMS-12743)
  • Run a comparison: implementation before changes and after (Issue NMS-12752)
  • Optimize Performance of InfluxDb Plugin (Issue NMS-12759)
  • Be able to ignore certificate validation on all Karaf features that push data to Elasticsearch (Issue NMS-12768)
  • Evaluate and improve opennms-cortex-tss-plugin (Issue NMS-12771)
  • Provide a test harness for time series plugins (Issue NMS-12772)

Meridian 2019.1.9

Release 2019.1.9 is a small update to 2019.1.8 that fixes a few bugs and makes some Docker-related improvements.

BREAKING: This release changes the Systemd service name back from meridian to opennms to match previous releases. You may need to run systemctl disable meridian and/or systemctl enable opennms to make sure OpenNMS starts on reboot.

The codename for 2019.1.9 is Pluto.

Bug Fixes
  • AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception (Issue NMS-7547)
  • Update examples/opennms.conf to be JDK11-compatible (Issue NMS-12468)
  • RRD-to-Newts converter only handles AVERAGE RRAs (Issue NMS-12722)
  • dependency commons-beanutils 1.8.3 vulnerability (Issue NMS-12757)
  • Kafka Producer puts all events on the same partition when using donotpersist (Issue NMS-12784)
  • The Systemd service definition is called meridian not opennms (Issue LTS-239)
Enhancements
  • Reduce Docker container image size (Issue NMS-12284)
  • upgrade to latest Jetty security/bug fixes (Issue NMS-12743)

Meridian 2018.1.20

Release 2018.1.20 is a small update to 2018.1.19 that fixes a few bugs and makes some Docker-related improvements.

The codename for 2018.1.20 is Avalanche.

Bug Fixes
  • AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception (Issue NMS-7547)
  • Update examples/opennms.conf to be JDK11-compatible (Issue NMS-12468)
  • RRD-to-Newts converter only handles AVERAGE RRAs (Issue NMS-12722)
  • dependency commons-beanutils 1.8.3 vulnerability (Issue NMS-12757)
  • Kafka Producer puts all events on the same partition when using donotpersist (Issue NMS-12784)
Enhancements
  • Reduce Docker container image size (Issue NMS-12284)
  • upgrade to latest Jetty security/bug fixes (Issue NMS-12743)

Meridian 2017.1.24

Release 2017.1.24 is a small update to 2017.1.23 that fixes a few bugs and makes some Docker-related improvements.

The codename for 2017.1.24 is Kew meridian.

Bug Fixes
  • AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception (Issue NMS-7547)
  • RRD-to-Newts converter only handles AVERAGE RRAs (Issue NMS-12722)
  • dependency commons-beanutils 1.8.3 vulnerability (Issue NMS-12757)
Enhancements
  • Reduce Docker container image size (Issue NMS-12284)
  • Bump Docker base dependencies in build-env and OCI artifacts (Issue NMS-12699)
  • upgrade to latest Jetty security/bug fixes (Issue NMS-12743)

Meridian 2016.1.24

Release 2016.1.24 is a small update to 2016.1.23 that fixes a few bugs and makes some Docker-related improvements.

Meridian 2016 is technically out of support, but since there is a security fix for commons-beanutils it was deemed worth making new binaries.

The codename for 2016.1.24 is Breusing Geometric.

Bug Fixes
  • AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception (Issue NMS-7547)
  • Confd download fails silently on Docker install (Issue NMS-12642)
  • RRD-to-Newts converter only handles AVERAGE RRAs (Issue NMS-12722)
  • dependency commons-beanutils 1.8.3 vulnerability (Issue NMS-12757)
Enhancements
  • Reduce Docker container image size (Issue NMS-12284)
  • Backport CircleCI pipeline to foundation-2016 (Issue NMS-12607)
  • Bump Docker base dependencies in build-env and OCI artifacts (Issue NMS-12699)

by RangerRick at July 09, 2020 08:00 AM

July 06, 2020

OpenNMS On the Horizon – Bug Fixes, JDK Build System Updates, Encrypted SNMPv3, New Package Repositories

In the last week we did more bug fixing, worked on JDK build system updates, encrypted SNMPv3 credentials, new package repositories, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Patrick continued his work on optimizing the new time-series APIs.
  • Marcel fixed an issue with parsing APPLICATION TAG in Netflow 9 packets.
  • Chandra worked on storing SNMPv3 credentials encrypted in the key-value store.
  • Ron Roskens continued his work updating our build system to work against newer JDKs.
  • Chandra added support for ignoring certificate validation on Karaf features pushing to Elasticsearch.
  • Chandra fixed an issue with Karaf partitioning and (donotpersist) events without an event ID.
  • Christian did more work on moving the remote poller functionality to Minion.

Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Marcel Fuhrmann
  • Patrick Schweizer
  • Ronald Roskens

New Package Repositories

We are in the process of moving our package repositories from self-hosted and self-mirrored to using Cloudsmith.

They are live and active now, and CircleCI has been pushing to them for a few months, but we would like some folks to try them out and let us know if you run into any issues.

For more details on using the new repositories, see this post on our OpenNMS Discourse.

Calendar of Events

July Releases - July 7th, 2020

The next OpenNMS release day is July 7th, 2020. Currently we expect releases from all supported Meridians as well as Horizon 26, due to backported updates for the RRD Newts converter and an update to the default Java version used in Docker images.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-84: Add Graph Provider to support ALEC
  • NMS-12468: Update examples/opennms.conf to be JDK11-compatible
  • NMS-12736: Add documentation for TcpListener
  • NMS-12760: Add ReST interface for Remote Poller
  • NMS-12768: Be able to ignore certificate validation on all Karaf features that push data to Elasticsearch
  • NMS-12783: Template field 'APPLICATION TAG' has illegal size
  • NMS-12784: Kafka Producer puts all events on the same partition when using donotpersist

by RangerRick at July 06, 2020 04:58 PM

June 29, 2020

OpenNMS On the Horizon – Build and Infrastructure, Documentation, Flow and Measurements Bug Fixes, and Minion Remote Poller

In the last week we did more build and infrastructure work, documentation updates, flow and measurements bugs, and the Minion-based remote poller.

Github Project Updates

Internals, APIs, and Documentation
  • Ron Roskens worked on resurrecting his Dev Jam work to build on a JDK newer than 1.8.
  • I did more work on infrastructure updates for CI and repo serving.
  • Bonnie did more work on thresholding metadata and TCP listener documentation.
  • Chandra worked on making the Minion-based remote poller handle poller package association.
  • Ronny fixed a bunch of Asciidoc documentation warnings.
  • Sean worked on a bug where "last seen" wasn't updating with flow raw records disabled.
  • Justin Wood submitted a fix for interfaceSnmpByIfIndex when an interface has no associated physaddr.
  • Marcel worked on a fix for handling the APPLICATION TAG field from Netflow 9.
  • Ronny worked on updating us to the latest 4.x JNA.
Web, ReST, UI, and Helm
  • Christian added a ReST interface for accessing Minion remote poller data.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Justin Wood
  • Marcel Fuhrmann
  • Matthew Brooks
  • Patrick Schweizer
  • Ronald Roskens
  • Ronny Trommer
  • Sean Torres

Calendar of Events

July Releases - July 7th, 2020

The next OpenNMS release day is July 7th, 2020. Currently we expect releases from all supported Meridians as well as Horizon 26, due to backported updates for the RRD Newts converter and an update to the default Java version used in Docker images.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-85: ALEC smoke tests currently failing loading in Sentinel
  • NMS-12677: Dynamic service scheduling: Polling package association
  • NMS-12735: Document how to use meta-data with thresholding
  • NMS-12752: Run a comparison: implementation before changes and after
  • NMS-12757: dependency commons-beanutils 1.8.3 vulnerability
  • NMS-12770: Fix docs warnings for resource-types, time series config and thresholding
  • NMS-12772: Provide a test harness for time series plugins
  • NMS-12781: Migrated VMware asset data to metadata entries
  • ORG-55: http://xmlns.opennms.org content no longer available
  • ORG-87: xmlns went missing as part of our office server shutdown

by RangerRick at June 29, 2020 04:04 PM

June 23, 2020

OpenNMS On the Horizon – Time-Series API, Minion Remote Poller, CircleCI, Netflow, VMware, and Documentation

In the last 2 weeks we did a lot of infrastructure and bug fixing, as well as continuing to work on optimizing the new time-series API.

Github Project Updates

Internals, APIs, and Documentation
  • Patrick continued his work on making performance improvements to the new time-series API.
  • Christian updated the new Minion-based remote poller to support thresholding on response times.
  • Bonnie added documentation for using metadata with thresholding.
  • I did a bunch of work on CircleCI improvements, including merging the fixes to shrink our Docker images.
  • Chandra fixed the reporting of delta_switched in Netflow 5 Elasticsearch records.
  • I updated our commons-beanutils dependencies to the latest version.
  • Jeff updated the admin guide with a Minion RPC troubleshooting example.
  • Christian did an update to move the VMware asset data to node metadata.
  • Sean fixed a bug in returning Netflow aggregations when no results are returned by Elasticsearch.
  • Bonnie did a bunch of cleanups in the developer documentation.
Web, ReST, UI, and Helm
  • Bonnie worked on Helm documentation for expressions and filtering.
  • I upgraded our Jetty to the latest 9.4.29.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Jeff Gehlbach
  • Matthew Brooks
  • Patrick Schweizer
  • Sean Torres
  • Seth Leger

Calendar of Events

July Releases - July 7th, 2020

The next OpenNMS release day is July 7th, 2020. Currently we expect releases from all supported Meridians as well as Horizon 26, due to backported updates for the RRD Newts converter and an update to the default Java version used in Docker images.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-231: "How to configure the data sources in Grafana" docs are missing
  • HELM-240: Enhance HELM documentation
  • HELM-241: Add expression examples
  • HELM-242: JEXL expressions
  • NMS-7547: AbstractSnmpValue.allBytesDisplayable() IndexOutOfBound Exception
  • NMS-10389: Unable to collect SNMP through minions on a large scale
  • NMS-12284: Reduce Docker container image size
  • NMS-12682: Update collectors chapter
  • NMS-12721: Apply thresholding for remote poller response times
  • NMS-12738: Parameters with dots handled incorrectly in BMP feature config
  • NMS-12742: remove the java ("windows") installer
  • NMS-12750: Netflow 5 records in ES do not contain value for delta_switched

by RangerRick at June 23, 2020 08:46 PM

June 08, 2020

OpenNMS On the Horizon – Bug Fixes, Docker, Minion, Time-Series, Node Metadata, Documentation

In the last week we did the June releases, fixed some bugs, did more work on Docker impovements, continued to work on Minion updates, time-series enhancements, metadata improvements and documentation, flow ReST, and more.

Github Project Updates

Internals, APIs, and Documentation
  • We ressurected an old attempt to fix UTF-8 handling in SNMP values from Seth.
  • I continued to work on the changes to make docker images built from RPMs smaller.
  • Dustin did more work on updating the Remote Poller to use modern APIs and Minion.
  • Dustin fixed an issue in the RRD to Newts converter when step-size isn't 300.
  • Chandra continued his work on improving thread handling in the Minion.
  • Bonnie worked on documentation for metadata thresholding.
  • Patrick made improvements to ResourceDAO performance in the new time-series API.
  • Zoë fixed some issues in BMP telemetry when handling parameters with . in them.
  • I removed Windows-related installation references from the documentation for Horizon 27.
  • I fixed some issues with CircleCI automatic branch merging.
  • Christian worked on moving VMware asset metadata from node assets to the new node metadata API.
  • Patrick updated OIA to offer up tag names as constants in the time-series APIs.
Web, ReST, UI, and Helm
  • Sean fixed an issue with ingress/egress handling in the flow exporter ReST interface.
  • I worked on bumping our Jetty to the latest version.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Mark Mahacek
  • Patrick Schweizer
  • Sean Torres
  • Seth Leger
  • Zoë Knox

June Releases - Meridian 2019.1.8, Horizon 26.1.1

For the June releases, we put out relatively small updates to Horizon 26 and Meridian 2019.

Both contained a number of fixes and a few enhancements, including Kafka event forwarding fixes. Horizon 26.1.1 also included a couple other bug fixes, most notably a fix for a performance regression in Netflow handling.

For more details, see the June release announcement.

Calendar of Events

July Releases - July 7th, 2020

The next OpenNMS release day is July 7th, 2020. Currently we expect releases from all supported Meridians as well as Horizon 26, due to backported updates for the RRD Newts converter and an update to the default Java version used in Docker images.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-3672: Poller Packages ignores include/excludes for remote polling
  • NMS-4671: JNA ping code returns timeouts for all link-local IPv6 addresses
  • NMS-4912: JdbcCollector freeze Collectd when using Data Source Factories defined on opennms-datasources.xml instead of using their own connections.
  • NMS-5628: Requisition File is Unmarshalled for each Node as it is Scanned
  • NMS-12678: Dynamic service scheduling: Poller-Configuration change
  • NMS-12698: Use CollectionSetBuilder to persist response times
  • NMS-12722: RRD-to-Newts converter only handles AVERAGE RRAs
  • NMS-12730: Meta-data tag enhancements to Time Series Storage API
  • NMS-12740: The ReST end-point for the Flow Exporter details is returning invalid content
  • NMS-12743: upgrade to latest Jetty security/bug fixes
  • OIA-26: Expose intrinsic tag names as constants for TSS API

by RangerRick at June 08, 2020 04:03 PM

June 02, 2020

June Updates for Meridian 2019 and Horizon 26

OpenNMS is released on a monthly schedule, the first Tuesday of the month. The next scheduled release will be July 7th.

In June, we released updates to Meridian 2019 and Horizon 26:

Meridian 2019.1.8

Release 2019.1.8 is the ninth release in the Meridian 2019 series.

It contains bug and documentation fixes as well as a few small enhancements.

The codename for 2019.1.8 is Neptune.

Bug Fixes
  • SSLCertMonitor server-name parameter results in NPE (Issue NMS-12332)
  • Fix warnings during documentation build (Issue NMS-12702)
  • Images are broken in admin guide (Issue NMS-12713)
  • Cleanup removed Elasticsearch REST plugin and hint to Plugin Manager (Issue NMS-12716)
  • Events forwarded by Kafka Producer doesn't have any parameters set (Issue NMS-12723)
Enhancements
  • Bump Docker base dependencies in build-env and OCI artifacts (Issue NMS-12699)
  • Send trouble ticket id to kafka alarm topic (Issue NMS-12725)

Horizon 26.1.1

Release 26.1.1 is the fourth release in the Horizon 26 series.

It contains documentation and bug fixes including improvements to Kafka event and alarm publishing.

The codename for 26.1.1 is Hydrating.

Bug Fixes
  • SSLCertMonitor server-name parameter results in NPE (Issue NMS-12332)
  • Provisiond accepts multiple primary SNMP interfaces (Issue NMS-12605)
  • Fix warnings during documentation build (Issue NMS-12702)
  • Cleanup removed Elasticsearch REST plugin and hint to Plugin Manager (Issue NMS-12716)
  • The Alarm History feature is not working (Issue NMS-12718)
  • Events forwarded by Kafka Producer doesn't have any parameters set (Issue NMS-12723)
  • Netflow ingress performance regression (Issue NMS-12724)
Enhancements
  • Bump Docker base dependencies in build-env and OCI artifacts (Issue NMS-12699)
  • Send trouble ticket ID to Kafka alarm topic (Issue NMS-12725)

by RangerRick at June 02, 2020 08:51 PM

June 01, 2020

OpenNMS On the Horizon – CircleCI, Docker, Minion, Time-Series and Kafka Metadata, and the Remote Poller

In the last week we did more work on CI and Docker images, Minion bugfixes, time-series metadata, refactoring the remote poller, and Kafka metadata improvements.

Github Project Updates

Internals, APIs, and Documentation
  • I worked on shrinking our Docker images.
  • Chandra continued to work on improving the Minion's thread usage.
  • Christian continued to work on refactoring the remote poller to be a part of the Minion.
  • Patrick and Jesse worked on improved metadata in the new time-series API.
  • Dustin fixed some bugs in the Newts RRD converter.
  • I did more work migrating Bamboo workflows to CircleCI.
  • Chandra enhanced forwarded Kafka alarms to include trouble-ticket metadata.

Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Patrick Schweizer

Calendar of Events

June Releases - June 2nd, 2020

The next OpenNMS release day is June 2nd, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-12391: Limit RPC threads on Minion using bulkhead pattern
  • NMS-12584: Create lab for simulating and persisting large volumes of flows
  • NMS-12724: Netflow ingress performance regression
  • NMS-12725: Send trouble ticket id to kafka alarm topic

by RangerRick at June 01, 2020 03:18 PM

May 26, 2020

OpenNMS On the Horizon – CircleCI, Kafka, Time-Series API, Netflow, Minion, OIA

In the last week we kept working on CI improvements, fixed some Kafka bugs, fixed time-series and netflow issues, the new Minion-based remote poller infrastructure, OIA integration updates, and more!

Github Project Updates

Internals, APIs, and Documentation
  • I did more work cleaning up and enhancing our CircleCI builds.
  • Chandra fixed an issue with the alarm history elasticsearch feature when indexPrefix is set.
  • Dustin did more work on modernizing the remote poller infrastructure.
  • Pierre added new confd templates for Minion to make SSH, RMI registry, and RMI server configurable.
  • Patrick did more work on fixing an issue when multiple SNMP interfaces are marked "primary" on a node.
  • Chandra continued his work on improving thread-handling on the Minion.
  • Chandra fixed an issue with missing parameters when forwarding events from the Kafka producer.
  • Jesse fixed a regression in throughput processing of Netflow ingress packets in Horizon 26.
  • Jesse fixed an issue with exceptions when persisting fails in the new time-series integration layer.
  • Matt did more work on storing passwords encrypted on-disk.
  • Patrick updated the OIA to expose tag names as constants accessible by integration implementers.
  • Patrick updated the time-series integration layer to pass improved metadata tags.
  • Ronny and I worked on some CircleCI changes that would reduce image sizes.

Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Matthew Brooks
  • Patrick Schweizer
  • Pierre Bouffard
  • Ronny Trommer

Calendar of Events

June Releases - June 2nd, 2020

The next OpenNMS release day is June 2nd, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-67: Log message for situation reflects cleared state
  • ALEC-74: Kafka streams dies and does not recover from error
  • ALEC-84: Add Graph Provider to support ALEC
  • NMS-12332: SSLCertMonitor server-name parameter results in NPE
  • NMS-12605: Provisiond accepts multiple primary SNMP interfaces
  • NMS-12679: Update database and send events only on status changes
  • NMS-12687: Confd templates for Minion configuration (Karaf)
  • NMS-12699: Bump Docker base dependencies in build-env and OCI artifacts
  • NMS-12710: Create SQL index for optimizing poll result lookups
  • NMS-12718: The Alarm History feature is not working
  • NMS-12723: Events forwarded by Kafka Producer doesn't have any parameters set

by RangerRick at May 26, 2020 06:22 PM

May 21, 2020

Use Case: Monitoring Websites Using Metadata

OpenNMS’ Metadata DSL (domain specific language) allows you to use dynamic configuration in parameter values to interpolate metadata into the parameter. The syntax allows for the use of patterns in an expression, whereby the metadata is replaced with a corresponding value during the collection process.

You can use this feature with provisioning (service detectors), service assurance (pollerd), and performance management (collectd) in OpenNMS. Using metadata in these situations can streamline the configuration of things that require customization and items, such as protocol port numbers, that are unique to a node.

Ronny Trommer and Marcel Fuhrmann have written a use case that shows how to use metadata to monitor websites. The use case presents a scenario of running a blackbox test on a web server that hosts three websites, and a detailed explanation of how to configure OpenNMS to do this.

Link: Monitoring Websites Using Metadata

by Bonnie at May 21, 2020 02:26 PM

May 18, 2020

OpenNMS On the Horizon – Documentation Cleanup, CI Improvements, Bug Fixes, JDK Updates

In the last week we did more documentation cleanup, did more work on our continuous integration infrastructure, fixed some bugs, did some JDK11 build updates, and more!

Github Project Updates

Internals, APIs, and Documentation
  • I did more work on cleaning up and refactoring our CircleCI builds.
  • Ronny updated our docker builds to use a newer JDK.
  • Chandra worked on improving threading on the Minion.
  • Bonnie made some improvements to the Collectd documentation.
  • Ronny cleaned up some warnings in the documentation build.
  • Sean updated Kafka components to 2.5.0.
  • Christian did more work on refactoring the Minion to handle the remote poller's duties.
  • Chandra worked a bit more on making sure Provisiond doesn't allow multiple interfaces on a node to be marked "primary."
  • Chandra made it so OIA can be built with JDK 11.
  • Ronny cleaned up old references to plugins in the documentation.
  • I did some work on making our Docker images smaller.

Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Ronny Trommer
  • Sean Torres

Calendar of Events

June Releases - June 2nd, 2020

The next OpenNMS release day is June 2nd, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-221: Make Helm docs publicly available
  • NMS-12683: Get new remote poller running as daemon
  • NMS-12702: Fix warnings during documentation build
  • NMS-12705: Release note changes for breaking changes are missing from Meridian
  • NMS-12713: Images are broken in admin guide
  • NMS-12715: Add very basic search capabilities to our docs framework
  • NMS-12716: Cleanup removed Elasticsearch REST plugin and hint to Plugin Manager

by RangerRick at May 18, 2020 07:27 PM

May 12, 2020

Recent Security Fix and Our Security Process

The OpenNMS Group recently learned about and fixed a security vulnerability that allowed remote code execution. CVE-2020-12760 applies to OpenNMS Horizon before 26.0.1, and Meridian before 2018.1.19 and 2019 before 2019.1.7. We advise customers to review the CVE and upgrade to the latest versions.

No one wants to have a security vulnerability, particularly with network management software, where the consequences could be serious. Through careful development, robust testing, and community and corporate vigilance, The OpenNMS Group does its best to produce secure software our users can trust. When someone notifies us about a security issue, we take action quickly to determine the severity, address it, and notify users.

1. Discovery

There are several ways we might learn about a security issue: from a community user, from a customer who finds something during their own routine internal IT security scanning processes, or through security researchers who actively look for security vulnerabilities in software and hardware. Contacting us through security@opennms.com sends a message to our security team, made up of key people from our development, customer support, and executive teams.

2. Responsible Disclosure

When we receive a notification about a possible security vulnerability, we immediately reach out to the reporter, using secure messaging, including PGP when working with researchers, if they wish. We thank them for notifying us, and particularly for choosing to disclose this information responsibly.

Dealing with a security vulnerability is a race to address it before it becomes widely known and exploitable. It requires balancing the ability to fix the vulnerability before someone exploits it and the risk to customers until that vulnerability is fixed.

For this reason, we appreciate responsible disclosure, which basically means the person who discovered the vulnerability does not publicize it until we have a chance to deal with it. In return, we take action immediately, and are transparent with the person who reported the issue, to keep them aware of our progress. In the case of CVE-2020-12760, we thank Florian Hauser, who works for Code White, for notifying us of this issue.

3. Verify Proof of Concept

Reporters usually provide us with a proof of concept (PoC) of how to exploit the problem they found and the steps to reproduce it. As mentioned earlier, CVE-2020-12760 allowed remote code execution.

The engineering team validates the PoC code, to determine the nature of the vulnerability and if it is reproducible. In some cases, the reporter may have been using an old version of the software, in which case we may have seen the issue already and fixed it, and it does not impact new versions of the software. We thank the reporter, and keep a bug report of the issue. Researchers usually work against the latest version, but sometimes they might use the most widely deployed version. Regardless, we take these reports seriously and investigate them.

4. Triage and Work

Once we verify the PoC, we determine the severity of the vulnerability, and create a JIRA issue visible only to core OpenNMS contributors. This keeps the issue hidden from searches until the bug is fixed to minimize the chance of someone exploiting the vulnerability. Once fixed, we change the permissions on the JIRA issue so that it becomes public and people can see a record of how it was fixed.

In serious and wide-spread cases, we inform Support and Meridian customers who might be exposed about the vulnerability, that we are addressing it, and to be prepared to install a fix when it becomes available. In some cases, there is a temporary workaround that we tell them to deploy until a fix is ready.

We update the reporter regularly on our progress with the issue, including PDF exports of the JIRA issue history. If they have an ID on our system, we add them to the permissions so they can follow the JIRA ticket.

5. Fix and Testing

All our work is done in GitHub. When we have a fix, we test it by running the PoC attack and verifying that the issue has been addressed, iterating as necessary until we have fixed the vulnerability. The researcher has the opportunity to test the fix, and once validated, we issue a new release and announcement about the vulnerability and fix.

6. Declaration and Communicating the Fix

When the fix is ready, we roll it out as soon as possible, with the next software release, or in an off-schedule release. We include information about the vulnerability in the release notes, social media, and blog posts, as well as notifying customers who are exposed. We make the JIRA issue public, and we credit the person who discovered the issue in these communications, unless they request not to be identified.

With severe issues we may create a CVE (Common Vulnerabilities and Exposures) declaration, that appears on a publicly maintained database of known exploitable vulnerabilities. This allows people to search for and discover OpenNMS security vulnerabilities and act accordingly to secure their system if they are affected. We also inform the reporter about the CVE.

We’re Never Done with Security

The world is full of “bad guys” ready to take advantage of people and their weaknesses, and of course, the Internet is no different. We must always be vigilant to potential threats, and think like the bad guys to stay ahead of them.

Building robust security testing processes into development, and using the latest tools and technologies (like OWASP, GitHub’s Dependabot, and SonarCloud, for example) to identify dependencies and fix vulnerabilities before release, are just some of the ways we can do this. Responsible disclosure and the efforts of security researchers, customers, and the OpenNMS community, are an essential part of the effort to help keep our products—and your business—secure.

by Bonnie at May 12, 2020 02:50 PM

May 11, 2020

OpenNMS On the Horizon – Releases, Documentation, Remote Poller, RPC, Karaf

In the last week we wrapped up some stuff for the releases, improved more documentation, continued to refactor the remote poller, made some RPC and Karaf improvements, and more.

Github Project Updates

Internals, APIs, and Documentation
  • I wrapped up my work on support for a simple plaintext Graphite telemetry adapter.
  • Chandra fixed an issue with multiple nodeDown messages on Pollerd reload.
  • Bonnie added documentation on generating PDFs from Grafana dashboards.
  • Bonnie worked on docs for the Prometheus collector.
  • Jesse released a new version of OIA to be included in Horizon 26.1.0.
  • Bonnie and Ronny worked on documenting restarting subsystems and thresholding.
  • Sean worked on updates to Elasticsearch used in unit tests.
  • Chandra fixed an issue with streaming telemetry and JDK 11.
  • Pierre did more work on adding more confd options to the Minion.
  • Marcel and Ronny updated the documentation for the SystemExecuteMonitor.
  • Dustin continued to work on refactoring remote poller functionality to the Minion.
  • Sean updated the Kafka components to version 2.5.0.
  • Sean worked on making HealthCheck support doing a subset of checks.
  • Chandra updated the Minion RPC to avoid creating too many threads.
  • Matt added support for encrypting password storage in the Karaf container.
Web, ReST, UI, and Helm
  • Patrick worked on tooltip support for the legacy graph provider.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jeff Gehlbach
  • Jesse White
  • Marcel Fuhrmann
  • Matthew Brooks
  • Patrick Schweizer
  • Pierre Bouffard
  • Ronny Trommer
  • Sean Torres

May Releases

May release day was the 5th, and it brought updates to both Horizon and Meridian.

Meridian 2017.1.23, 2018.1.19, and 2019.1.7

We introduced new Meridian versions for 2017 through 2019, mostly with minor bug fixes and a few documentation enhancements in 2019.

Horizon 26.1.0

Horizon got a more substantial update, with bug fixes, a Prometheus collector, Graphite listener support, an Influx timeseries implementation, and a whole bunch of flow and other enhancements.

Calendar of Events

June Releases - June 2nd, 2020

The next OpenNMS release day is June 2nd, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-237: Flow deep dive dashboard shows interfaces which don't belong to the selected node
  • NMS-9581: Document JDBCQueryMonitor "compare_string" Action
  • NMS-9804: Documentation: Install Guide: Compatibility Matrix Outdated
  • NMS-12269: Netscaler vServer SNMP collection and graph definitions
  • NMS-12568: Add an example for SystemExecuteMonitor into the docs
  • NMS-12647: Update smoketests to support various Kafka compression codecs
  • NMS-12650: Provide written procedures on the proper way to restart
  • NMS-12681: Reloading the Pollerd daemon causes multiple nodeDown messages
  • NMS-12684: Add upgrade task to enable RemotePollerNG
  • NMS-12688: Streaming Telemetry is broken when using OpenJDK 11 and minion
  • NMS-12694: Add tooltip support to the LegacyGraphProvider
  • NMS-12695: add a telemetry adapter for the Graphite plaintext protocol

by RangerRick at May 11, 2020 05:42 PM

May 07, 2020

New: Prometheus Collector

If you are using the Prometheus toolkit to monitor your network systems, you can now integrate that performance data into OpenNMS with the new PrometheusCollector.

The OpenNMS PrometheusCollector collects performance metrics via HTTP(S) using the text-based Prometheus Exposition format. Many applications have adopted this format, which the OpenMetrics project is in the process of standardizing.

How It Works

OpenNMS collects performance data using the Collectd daemon. Collectd schedules data collection on OpenNMS entities (currently nodes and interfaces) using management agents and protocol-specific collectors to collect performance metrics. Each collector has its own associated configuration that defines the parameters for the collector. (For more details on performance data collection in OpenNMS, refer to the product documentation.)

The PrometheusCollector parses and maps Prometheus-collected performance data into OpenNMS’s collection model. Manage Prometheus collection definitions in etc/prometheus-datacollection.d/, and set collection parameters in the /etc/collectd-configuration.xml file. See the PrometheusCollector documentation for more details.

Getting Started

By default we provide a sample configuration for Prometheus Node Exporter. The Node Exporter is an agent running on a server and provides detailed host machine metrics for Prometheus. Our sample configuration provides a starting point on how to use the PrometheusCollector with OpenNMS.

by Bonnie at May 07, 2020 06:42 PM

May 06, 2020

Updates for OpenNMS Horizon 26, Meridian 2019, 2018, and 2017 Released

OpenNMS Horizon 26.1.0 (Surgical) Released

Release 26.1.0 is the third release in the Horizon 26 series.

It is an enhancement release with a number of bug fixes and improvements, including updates to telemetry, provisioning, and more.

The codename for 26.1.0 is Surgical.

Bug
  • Security vulnerability in io.netty:netty-handler < 4.1.45 (need upgrade) (Issue NMS-12541)
  • NPE in KafkaFlowForwarder (Issue NMS-12660)
  • Add more context to Response Time resources (Kafka Producer) (Issue NMS-12661)
  • BMP parse error for path attribute MP_UNREACH_NLRI (Issue NMS-12671)
  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681)
  • Streaming Telemetry is broken when using OpenJDK 11 and minion (Issue NMS-12688)
Enhancement
  • Document JDBCQueryMonitor "compare_string" Action (Issue NMS-9581)
  • Add opentracing support for Provisiond (Issue NMS-12374)
  • SystemExecuteMonitor fails with exit code 6 (Issue NMS-12564)
  • Add an example for SystemExecuteMonitor into the docs (Issue NMS-12568)
  • Prometheus collector (Issue NMS-12577)
  • Timeseries Plugin Influx 1.x (Issue NMS-12633)
  • Update smoketests to support various Kafka compression codecs (Issue NMS-12647)
  • Bump ES version used in Smoke Tests (Issue NMS-12648)
  • Provide written procedures on the proper way to restart (Issue NMS-12650)
  • Aggregate flow metrics w/ stream processing (Issue NMS-12656)
  • Provisiond: Add NodeScanStarted event for scheduled scans (Issue NMS-12658)
  • Flow aggregation - alternate indices based on duration of time range filter (Issue NMS-12663)
  • Flow aggregation - Identify minimal set of fields required for current queries (Issue NMS-12664)
  • Enable node enrichment for Topology providers comming from the Integration Api (Issue NMS-12674)
  • Add tooltip support to the LegacyGraphProvider (Issue NMS-12694)
  • add a telemetry adapter for the Graphite plaintext protocol (Issue NMS-12695)

OpenNMS Meridian 2019.1.7 (Uranus) Released

Release 2019.1.7 is the eighth release in the Meridian 2019 series.

It contains a few bug fixes as well as a number of enhancements to the documentation.

The codename for 2019.1.7 is Uranus.

Bug
  • Prevent multiple node scans from being scheduled for a single node (Issue NMS-12504)
  • Add more context to Response Time resources (Kafka Producer) (Issue NMS-12661)
  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681)
  • Streaming Telemetry is broken when using OpenJDK 11 and minion (Issue NMS-12688)
Enhancement
  • Document JDBCQueryMonitor "compare_string" Action (Issue NMS-9581)
  • SystemExecuteMonitor fails with exit code 6 (Issue NMS-12564)
  • Add an example for SystemExecuteMonitor into the docs (Issue NMS-12568)
  • Provide written procedures on the proper way to restart (Issue NMS-12650)

OpenNMS Meridian 2018.1.19 (Sinkhole) Released

Release 2018.1.19 is a small release that fixes a couple of bugs.

The codename for 2018.1.19 is Sinkhole.

Bug
  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681)
Enhancement
  • SystemExecuteMonitor fails with exit code 6 (Issue NMS-12564)
  • Add an example for SystemExecuteMonitor into the docs (Issue NMS-12568)

OpenNMS Meridian 2017.1.23 (New Naval Observatory) Released

Release 2017.1.23 is a small update to 2017.1.22 that includes some build system updates and a fix for a bug when reloading Pollerd.

The codename for 2017.1.23 is New Naval Observatory meridian.

Bug
  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681

by RangerRick at May 06, 2020 06:15 PM

May 05, 2020

OpenNMS Meridian 2019.1.7 (Uranus) Released

Release 2019.1.7 is the eighth release in the Meridian 2019 series.

It contains a few bug fixes as well as a number of enhancements to the documentation.

The codename for 2019.1.7 is Uranus.

Bug

  • Prevent multiple node scans from being scheduled for a single node (Issue NMS-12504)
  • Add more context to Response Time resources (Kafka Producer) (Issue NMS-12661)
  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681)
  • Streaming Telemetry is broken when using OpenJDK 11 and minion (Issue NMS-12688)

Enhancement

  • Document JDBCQueryMonitor "compare_string" Action (Issue NMS-9581)
  • SystemExecuteMonitor fails with exit code 6 (Issue NMS-12564)
  • Add an example for SystemExecuteMonitor into the docs (Issue NMS-12568)
  • Provide written procedures on the proper way to restart (Issue NMS-12650)

by RangerRick at May 05, 2020 08:28 PM

OpenNMS Meridian 2018.1.19 (Sinkhole) Released

Release 2018.1.19 is a small release that fixes a couple of bugs.

The codename for 2018.1.18 is Sinkhole.

Bug

  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681)

Enhancement

  • SystemExecuteMonitor fails with exit code 6 (Issue NMS-12564)
  • Add an example for SystemExecuteMonitor into the docs (Issue NMS-12568)

by RangerRick at May 05, 2020 08:26 PM

OpenNMS Meridian 2017.1.23 (New Naval Observatory) Released

Release 2017.1.23 is a small update to 2017.1.22 that includes some build system updates and a fix for a bug when reloading Pollerd.

The codename for 2017.1.23 is New Naval Observatory meridian.

Bug

  • Reloading the Pollerd daemon causes multiple nodeDown messages (Issue NMS-12681

by RangerRick at May 05, 2020 08:24 PM

DYK: Generate PDF Reports of Grafana Dashboards with OpenNMS

OpenNMS makes it easy to generate PDF reports from Grafana dashboards. You can also schedule and email these PDF reports to anyone:

  • Keep staff without access to OpenNMS informed about network performance for improved capacity planning.
  • Create a permanent, historic record of strategic information by retaining reports in your inbox and/or the OpenNMS reporting library.
  • Create reports from any Grafana dashboard whether or not it has OpenNMS data.

How It Works

All you need is OpenNMS and an instance of Grafana with at least one dashboard and panel. OpenNMS allows you to create a PDF report for ANY Grafana dashboard, not just dashboards created using OpenNMS Helm. Simply obtain the Grafana Viewer API key from your Grafana instance, plug it into the Grafana endpoint configuration in OpenNMS, and you’re ready to go.

Set It and Forget It

With three templates (layouts) to choose from, your PDF can display one panel, two panels, or four panels per page. The templates have placeholders for each panel found on a Grafana dashboard.

OpenNMS connects with Grafana through the API key, retrieves a list of available dashboards, and displays them in the Report Parameters dialog:

Select a Grafana dashboard from the drop-down list, specify the time period for the report, and create a schedule to email the report to the people who need and want to see it.

From Dashboard to PDF:

Learn More!

For detailed procedures on how to create PDF reports from Grafana dashboards with OpenNMS, see the online documentation or check out this video.

by Bonnie at May 05, 2020 07:29 PM

May 04, 2020

OpenNMS On the Horizon – May 4th, 2020 – Documentation, Provisioning, Telemetry, Topology, Prometheus, Graphite, and More!

It's time for OpenNMS On the Horizon! (Did I miss last week? Shhh! Too busy doing cool stuff. Probably.)

In the last week we did a lot of plumbing work in Provisiond, Telemetryd, and topology, as well as more documentation improvements, a Prometheus collector, and a Graphite telemetry adapter.

Github Project Updates

Internals, APIs, and Documentation
  • I did more work fixing up CircleCI workflows.
  • Bonnie did more work on beefing up core documentation.
  • Jesse fixed an issue with serialized objects and ActiveMQ.
  • Chandra worked on enhancing the metadata provided with response time resources in Kafka.
  • Chandra added a new event for when a Provisiond node scan starts.
  • Dustin did more work on replacing the remote poller.
  • Chandra and Jesse made some enhancements to flow aggregation.
  • Marcel worked on updating the JDBCQueryMonitor and SystemExecuteMonitor documentation.
  • Chandra did more work on adding OpenTracing support to Provisiond.
  • Jesse added a collector for applications instrumented with Prometheus.
  • Patrick worked on some updates to make sure only one interface is marked SNMP primary.
  • Pierre worked on additional confd options for the Minion.
  • Patrick updated node enrichment to work on OIA topology providers.
  • Patrick added tooltip support to the legacy topology provider.
  • Patrick worked on an ALEC provider for the new graph API.
Web, ReST, UI, and Helm
  • Chandra added a smoke test for the password change UI.
  • Chandra did work on restoring the universal search bar.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Marcel Fuhrmann
  • Matthew Brooks
  • Patrick Schweizer
  • Pierre Bouffard
  • Ronny Trommer

Calendar of Events

May Releases - May 5th, 2020

The next OpenNMS release day is May 5th, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-238: Circuit breaker exception in Flow Deep Dive Dashboard
  • HELM-239: Too many buckets exception in Flow Deep Dive Dashboard
  • NMS-12374: Add opentracing support for Provisiond
  • NMS-12577: Prometheus collector
  • NMS-12645: Add selenium test for password change
  • NMS-12646: Re-enable Central Search functionality
  • NMS-12647: Update smoketests to support various Kafka compression codecs
  • NMS-12648: Bump ES version used in Smoke Tests
  • NMS-12653: Remove remote-poller runtimes from the build
  • NMS-12654: Update remote-poller model to link service to locations instead of individual RPs
  • NMS-12656: Aggregate flow metrics w/ stream processing
  • NMS-12658: Provisiond: Add NodeScanStarted event for scheduled scans
  • NMS-12661: Add more context to Response Time resources (Kafka Producer)
  • NMS-12663: Flow aggregation - alternate indices based on duration of time range filter
  • NMS-12671: BMP parse error for path attribute MP_UNREACH_NLRI
  • NMS-12673: Authenticated RCE vulnerability via ActiveMQ Minion payload deserialization
  • NMS-12674: Enable node enrichment for Topology providers comming from the Integration Api

by RangerRick at May 04, 2020 06:44 PM

April 29, 2020

OpenNMS Horizon 26.0.1 (Luchador) Released

Release 26.0.1 is the second release in the Horizon 26 series.

It is an off-schedule release to fix a vulnerability in ActiveMQ and the Minion. Thanks to Florian Hauser of Code White for catching this one.

The codename for 26.0.1 is Luchador.

Bug

  • Authenticated RCE vulnerability via ActiveMQ Minion payload deserialization (Issue NMS-12673)

by RangerRick at April 29, 2020 06:30 PM

OpenNMS Meridian 2019.1.6 (Europa) Released

Release 2019.1.6 is the seventh release in the Meridian 2019 series.

It is an off-schedule release to fix a vulnerability in ActiveMQ and the Minion. Thanks to Florian Hauser of Code White for catching this one.

The codename for 2019.1.6 is Europa.

Bug

  • Authenticated RCE vulnerability via ActiveMQ Minion payload deserialization (Issue NMS-12673)

by RangerRick at April 29, 2020 06:00 PM

OpenNMS Meridian 2018.1.18 (Wildfire) Released

Release 2018.1.18 is an off-schedule release to fix a vulnerability in ActiveMQ and the Minion. Thanks to Florian Hauser of Code White for catching this one.

The codename for 2018.1.18 is Wildfire.

Bug

  • Authenticated RCE vulnerability via ActiveMQ Minion payload deserialization (Issue NMS-12673)

by RangerRick at April 29, 2020 05:30 PM

April 21, 2020

New in OpenNMS: BGP Monitoring Protocol (BMP) Functionality

With the release of version 26.0 (Balaclava), OpenNMS now offers support for the BGP Monitoring Protocol (BMP) in the Streaming Telemetry feature (telemetryd).

What Is BGP Monitoring?

The BGP Monitoring Protocol (BMP) monitors Border Gateway Protocol (BGP) sessions and provides a convenient interface to monitor BGP routing information on the routing device. The integration in OpenNMS allows you to use this information, status updates, and statistics for advanced monitoring and management, providing visibility into what BGP is doing.

OpenNMS BMP Integration

OpenNMS leverages OpenBMP, an application that was developed as a reference implementation for receiving BMP messages from network equipment and presenting the state of the BGP network to the user. (For more information on OpenBMP, check out this presentation by owner/contributor Tim Evens or the following links: OpenBMP Server Collector, OpenBMP readme.)

BGP runs on routers and high-end switches. Those routers can point to OpenNMS or an OpenNMS Minion and send BMP data to OpenNMS. To use OpenNMS BMP features, you need the OpenBMP PostgreSQL component installed and set up, and have a BMP-enabled router.

The OpenNMS BMP parser accepts BMP connections from router packets using a TCP listener. Three adapters in OpenNMS read BMP data including an inventory list of connected routers and the peers they are established with, and stats and data about what is being exchanged over those peers:

  • BMP Telemetry Adapter: handles BMP statistics received and parsed by the BMP Parser. Statistics received from the router are associated as performance data with that router. View metrics and statistics related to that peer and apply thresholding.
  • BMP Peer Status Adapter: handles BMP Peer Up and Down messages that the BMP Parser receives and parses, and converts them to OpenNMS events. Allows alarm creation based on up/down status.
  • OpenBMP Integration Adapter: integrates with an existing OpenBMP installation and handles BMP messages from the BMP Parser, and creates OpenBMP-compatible messages, which are then passed to the OpenBMP Kafka cluster.

The parser and adapters are configurable in the telemetryd-configuration.xml file. For more information on BMP functionality in OpenNMS, see the online user documentation.

Visualization

View BMP data in the OpenNMS UI by logging in and choosing Reports>Resource Graphs. Select the BMP-enabled resource for which you want to view statistics, and choose Graph All. OpenNMS displays graphs similar to the following:

Displays times when a peer withdrew an IP prefix:

Displays times when a peer withdrew an update:

You can also create dashboards in Grafana to view this OpenNMS BMP data.

Displays prefixes in violation of Resource Public Key Infrastructure (RPKI) (table and chart format), prefixes in violation of an Internet Routing Registry (IRR) (table and chart format), and the number of RPKI route origin authorizations (ROAs) and IRR entries:

Displays the number of advertised IP addresses and their IP version (in this case, IPv4), the upstream/downstream autonomous systems (ASNs), and a visualization of the originating prefix trend:

Upcoming BMP Features

This first milestone provides a high-capacity and resilient infrastructure for routing BMP messages into an SNAS/OpenBMP-compatible persistence layer.

Milestone two will incorporate all OpenBMP functionality and alarm workflows into OpenNMS workflows, the Web UI, and the Helm console. This integration will allow full support of BGP monitoring in a production environment from an holistic fault and performance monitoring system.

Our third milestone will offer a cloud-hybrid software-as-a-service (SaaS) solution where on-premise OpenNMS solutions can incorporate this feature without having to deploy the additional required infrastructure.

Sponsored Development

BMP functionality in OpenNMS is the result of a customer request through our sponsored development program. Our customers have requested and received features like SNMP version 3 support, a remote monitoring method, integration with other tools. and specific monitors for such things as SMS messaging. This collaboration between customers and open source is a great way for us to respond to customer needs while developing new product features that benefit all OpenNMS users.

by Bonnie at April 21, 2020 02:33 PM

April 20, 2020

OpenNMS On the Horizon – April 20th, 2020 – Provisiond, BMP, Documentation, Infrastructure, Response Time, OpenNMS.js, Search, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on tracing in Provisiond, BMP updates, documentation, test and build infrastructure, response time resources, OpenNMS.js, search, and other bug fixes.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra did more work on adding OpenTracing support to Provisiond
  • Chandra fixed an NPE in the Kafka flow forwarder
  • Bonnie made additional documentation updates for BMP and some other core changes
  • Dustin improved handling of unknown variants in BMP and BGP data
  • I fixed a number of issues in unit/integration/smoke testing
  • Chandra improved response time resources written to Kafka to provide more info
  • I did more work on moving Bamboo tasks over to CircleCI
Web, ReST, UI, and Helm
  • I released a new version of OpenNMS.js with a fix for newer Grafana HTTP response handling
  • Chandra worked on re-adding Markus's new central search facility (including missing smoke test coverage)
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Ronny Trommer

Calendar of Events

May Releases - May 5th, 2020

The next OpenNMS release day is May 5th, 2020. Currently we expect point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-232: Support Grafana 6.7.x for our Helm plugin
  • NMS-12552: BMP parser is too strict for unknown elements / types
  • NMS-12660: NPE in KafkaFlowForwarder

by RangerRick at April 20, 2020 09:00 PM

April 13, 2020

OpenNMS.js v2.0.2

Just a small bugfix release to facilitate OpenNMS Helm fixes.

Bug Fixes

  • rest: fix response type handling in grafana 6.7 (HELM-232) (874cd80)

by RangerRick at April 13, 2020 09:17 PM

OpenNMS On the Horizon – April 13th, 2020 – Documentation, BMP, Kafka, Provisiond, Bug Fixes, and More!

It's time for OpenNMS On the Horizon!

In the last week we fixed a bunch of bugs, did more BMP work, made build system improvements, made Provisiond improvements, and a bunch more.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra fixed an NPE that could cause startup errors in the graph service.
  • Bonnie did more updates to the thresholding documentation and PDF dashboards.
  • Ronny fixed an issue with Docker image creation when Confd download fails.
  • I made some improvements to CircleCI cache handling for builds.
  • Christian, Dustin, and Jesse fixed some issues with BMP parsing and config loading.
  • Dustin implemented some deprecated OSPF attributes in BMP handling.
  • Sean added some attributes to the RPM specs to improve compatibility.
  • Jesse updated the OIA used by OpenNMS to 0.4.0.
  • Dustin and Bonnie wrapped up adding BMP documentation.
  • Sean worked on Kafka updates to support compression and ES updates.
  • Jesse fixed some issues with DNS lookup while BMP parsing.
  • Patrick worked on an InfluxDB plugin for the new timeseries API.
  • Patrick fixed an issue with Provisiond if multiple interfaces are (incorrectly) marked primary.
  • Chandra added tracing support to Provisiond.
  • Chandra added a nodeScanStarted event for when a node scan is scheduled during provisioning or a scheduled run.
Web, ReST, UI, and Helm
  • Patrick fixed an issue with creating monitored service through the v1/v2 ReST APIs.
Contributors

Thanks to all of the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Jesse White
  • Patrick Schweizer
  • Ronny Trommer
  • Sean Torres

April OpenNMS Meridian and Horizon Releases

OpenNMS Meridian

Last week we released updates to Meridians 2017 through 2019. These are recommended updates because they include security fixes:

OpenNMS Horizon

On top of the Meridian point releases, we also put out Horizon 26, a new major version of the OpenNMS Horizon track.

The biggest change involves adding support for processing BMP (BGP Monitoring Protocol) in Telemetryd.

If you'd like to see an overview of the major changes since Horizon 25, take a look at What’s New in OpenNMS Horizon 26. For an exhaustive list of issues that have been resolved since Horizon 25, see the change log.

Calendar of Events

May Releases - May 5th, 2020

The next OpenNMS release day is May 5th, 2020. Currently we expect to point/bug fix releases of Meridian 2019 and Horizon 26.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-10597: Limit SNMP Datacollection by Table Index
  • NMS-12532: Selecting an Icon on Topology Map breaks the map
  • NMS-12585: Evaluate stream processing for Top N calculation with flows
  • NMS-12588: Create threshold documentation
  • NMS-12599: Document how to generate PDFs from dashboards using OpenNMS
  • NMS-12633: Timeseries Plugin Influx 1.x
  • NMS-12636: Can't change password using the user self service
  • NMS-12637: GraphService is throwing Error with an NPE Karaf startup
  • NMS-12638: Telemetryd with BMP adapter throws java.util.ConcurrentModificationException
  • NMS-12639: Add required dependencies to use ZSTD inside Kafka to features.xml
  • NMS-12640: Set RPM compression type and level inside RPM Spec Files
  • NMS-12649: Error parsing label information from BGP MP_REACH_NLRI attribute

by RangerRick at April 13, 2020 04:35 PM

April 09, 2020

OpenNMS Horizon 26.0.0 (Balaclava) Released

Release 26.0.0 is the first release in the Horizon 26 series.

It contains a large number of bug fixes and new features, most notably initial support for handling the BGP Monitoring Protocol in Telemetryd.

For a high-level overview of what has changed in Horizon 26, see What’s New in OpenNMS Horizon 26.

The codename for 26.0.0 is Balaclava.

by RangerRick at April 09, 2020 08:00 PM

April 07, 2020

OpenNMS Meridian 2019.1.5 (Saturn) Released

Release 2019.1.5 is the sixth release in the Meridian 2019 series.

It fixes a few more security issues, as well as a number of other bugs and a couple of enhancements. Hat tip to Johannes Moritz for the security report.

The codename for 2019.1.5 is Saturn.

Bug
  • SNMP Remove from definitions fails for definitions with profile label (Issue NMS-12413)
  • persisted defaultCalendarReport database reports are broken (Issue NMS-12438)
  • Security issue disclosures, 31 Jan 2020 (Issue NMS-12513)
  • Selecting an Icon on Topology Map breaks the map (Issue NMS-12532)
  • Description: Cannot create monitored-service with JSON via ReST (Issue NMS-12625)
  • Confd download fails silently on Docker install (Issue NMS-12642)
Enhancement
  • Event documentation is missing tokens (Issue NMS-12228)
  • Splitting Docker documentation in Horizon, Minion and Sentinel (Issue NMS-12529)
  • Improve OIA performance when mapping alarms (Issue NMS-12581)
  • Events not balanced across partitions when using opennms-kafka-producer (Issue NMS-12616)

by RangerRick at April 07, 2020 08:06 PM

OpenNMS Meridian 2018.1.17 (Pandemic) Released

Release 2018.1.17 is a small update to 2018.1.16 that fixes another security issue that affects most current OpenNMS releases. Hat tip to Johannes Moritz for reporting this.

The codename for 2018.1.17 is Pandemic.

Bug
  • Security issue disclosures, 31 Jan 2020 (Issue NMS-12513)
  • Drools working memory facts are not restored properly on engine reload (Issue NMS-12586)
  • Confd download fails silently on Docker install (Issue NMS-12642)
Story
  • Backport CircleCI pipeline to foundation-2018 (Issue NMS-12476)

by RangerRick at April 07, 2020 07:20 PM

OpenNMS Meridian 2017.1.22 (meridianu(s) Budense) Released

Release 2017.1.22 is a small update to 2017.1.21 that fixes another security issue that affects most current OpenNMS releases. Hat tip to Johannes Moritz for reporting this.

The codename for 2017.1.22 is meridianu(s) Budense.

Bug

  • Security issue disclosures, 31 Jan 2020 (Issue NMS-12513)
  • Confd download fails silently on Docker install (Issue NMS-12642)

Enhancement

  • Backport CircleCI pipeline to foundation-2017 (Issue NMS-12603)

by RangerRick at April 07, 2020 06:47 PM

April 06, 2020

OpenNMS On the Horizon – April 6th, 2020 – BMP, Kafka, Documentation, CircleCI, Provisiond, Bug Fixes, and More!

It's time for OpenNMS On the Horizon!

In the last week we did more CircleCI infrastructure work, continued to work on BMP features, did more documentation updates, and did a bunch of small feature work and bugfixing.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin, Christian, and Jesse continued their work on improvements to BMP integration.
  • Jesse fixed the minion container to not enable JMS when Kafka is enabled.
  • Bonnie continued her work on improving thresholding documentation.
  • Chandra did more work on the conversion to using protobuf instead of bson for flow payloads.
  • I implemented foundation and release branch merging in CircleCI and turned them off in Bamboo.
  • Jeff disabled logging RTC events by default in Horizon 26 and up.
  • Ronny updated the Horizon and Sentinel CircleCI config to push RC branches.
  • Ronny did more work on updating Helm documentation generation.
  • Ronny updated Minion in smoke tests to run as non-root.
  • Chandra worked on adding tracing support to Provisiond.
  • Patrick worked on a few web UI fixes.
  • Sean worked on updating RPM builds for compatibility.
  • Sean worked on making it possible to ZSTD in Kafka.
Web, ReST, UI, and Helm
  • I fixed documentation generation in OpenNMS.js.
  • I fixed a bug in d3 event handling in the Topology UI.

Calendar of Events

April Releases - April 7th, 2020

The next OpenNMS release day is April 7th, 2020.

Unless we run into major issues, we're hoping to release Horizon 26 in April, which, among other things, includes support for BMP telemetry collection.

There will also be updates to all active Meridian releases.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-8032: Describe Alarm status behavior in user documentation
  • NMS-8546: Event to Notification matching is not documented
  • NMS-9754: RTC subscription events should not be persisted to DB
  • NMS-12426: Add BMP config example and documentation
  • NMS-12513: Security issue disclosures, 31 Jan 2020
  • NMS-12521: Use protobuf instead of bson for encoding/decoding Netflow payloads
  • NMS-12559: Improve parsing of BGP extended communities attribute
  • NMS-12560: Populate path id and labels attributes in unicast prefix messages (OpenBMP integration)
  • NMS-12569: Async DNS resolution for Hostnames in BMP
  • NMS-12617: XSS security issues
  • NMS-12619: sentinel-coordination-zookeeper doesn't start due to missing dependency
  • NMS-12625: Description: Cannot create monitored-service with JSON via ReST
  • NMS-12628: auto-merge foundation branches in CircleCI
  • NMS-12630: Push Minion OCI to DockerHub for release branches
  • NMS-12631: Minion confd template should disable JMS when using Kafka
  • NMS-12635: Restore CAP_NET_RAW capabilities in Minion when running as non-root
  • NMS-12641: Support for more extended community types in BMP
  • NMS-12642: Confd download fails silently on Docker install
  • NMS-12643: Error parsing MP_UNREACH_NLRI attribute
  • NMS-12644: BMP Parser Bulkhead Config does not work

by RangerRick at April 06, 2020 09:43 PM

April 03, 2020

Happy 20th Birthday, OpenNMS!

Earlier this week, OpenNMS turned 20 years old. Although the project began in the summer of 1999, March 30, 2000, marks the day that the OpenNMS Project was registered on Sourceforge and the first time any OpenNMS code was made public. David Hustace, CEO of OpenNMS and Tarus Balog, the company’s COO, share their memories of the past and thoughts about the future.

A Radical Idea in 2000

“The term "open source" was created in 1998 on the heels of the release of the Netscape browser source code, and the OSI [Open Source Initiative] was founded,” says David. “I can't provide an insider perspective on what it was like when OpenNMS first started, but I can tell you that, from an outsider's perspective, it was an extremely radical idea.”

“In 2000, the dot com bubble was subsiding but open source was never going to be considered something to be taken seriously,” he adds. “There was an onslaught of fear, uncertainty and doubt (FUD) coming from a lot of the software industry at the time.”

Network Management Has Changed a Lot

“Back then, most enterprise-level monitoring solutions required expensive hardware from IBM, HP or Sun and the scope was very limited, mainly focused on connectivity and performance network devices such as switches and routers,” says Tarus. “Some vendors were just starting to support Windows, and Linux support was non-existent. Now network monitoring solutions flourish at all levels and on all operating systems.”

David points to virtualization, IoT, and the Cloud, as three of the most significant changes in network management, because of the complexity they add. “Virtualization means monitored entities are now completely abstracted and almost always virtual implementations of their former physical selves; yet they present themselves identically to a monitoring system,” he says. “Moving monitoring applications to the Cloud introduces many application security and networking communications hurdles to crossover, as network and computer technologies still exist in data centers and corporate offices. Monitoring applications that are running in the Cloud require access to those local, on-premise networks to reliably monitor faults and performance; especially when the Cloud applications often require traversing the public Internet. And of course, IoT has changed monitoring with respect to scale. The number of devices on the network needing to be monitored has changed by multiple orders of magnitude due to the compression of technology into almost every aspect of our lives.”

Open Source: from Fringe to Mainstream

“Open source has moved from a fringe idea from a bunch of free software advocates to mainstream acceptance,” says Tarus. “We used to have much more of an ‘evangelical sale’ of OpenNMS in an organization because no one understood it well, or they were frightened by some of the FUD spread by proprietary software vendors. We no longer have that problem, as many large companies have embraced open source from the operating system on up to the software they integrate into their solutions.”

Noteworthy OpenNMS Achievements

“For me it is the fact that we are still around,” says Tarus. “OpenNMS was started by a company called Oculan. Before they went out of business in 2004, they decided to no longer support OpenNMS in May of 2002. While I might have had the option to remain at Oculan, I saw the potential of an open source network monitoring platform that could scale and decided to take a leap of faith and keep the project alive. I was lucky in that I met people like David and was able to convince them of the potential in OpenNMS, enough so that they would quit well-paying jobs to pursue making OpenNMS awesome.”

David laughs. “Twenty years! I thought of this just today … there are potentially users of OpenNMS that are younger than the project. OMG,” he says. “I think it’s significant that we still have our first customer as a customer.”

If You Could Go Back in Time

Both men reflected on what would surprise that younger self if they could go back in time and talk to him.

“That it is worth it,” says Tarus. “Trust me, in the years I’ve worked with OpenNMS there were a lot of times I didn’t think the project was going to make it. It has been the best job I’ve ever had but also the most work.”

“I would be most surprised that this project has these incredibly smart, talented, and wonderful human beings working together and producing an application that is used in production by tens of thousands of very large corporations and most of the biggest, with a combined valuation of trillions of US dollars,” says David.

Where Will OpenNMS be in 20 Years?

In 2000, no one could predict how networking and open source would change and develop. But David and Tarus still have visions for where they want OpenNMS to be 20 years from now. For David, winning the National Medal of Technology and Innovation would be a great honour and achievement.

Tarus’ goal is for OpenNMS to be “the de facto monitoring platform for carriers and large enterprises,” he says.

Personal Stories

Beyond OpenNMS’s success and staying power, it’s the people that have had the greatest impact.

Tarus describes how the company was able to hire one of its contributors, and bring him to the US on an H1B visa. “That eventually turned into a permanent resident card for him and his wife, and his future is now only limited by his imagination,” he says.” If OpenNMS went away tomorrow it would be all worth it for just that one thing, and there are lots of other examples that make all the effort worthwhile.”

Adds David, “OpenNMS and open source has enriched my life by introducing me to, and allowing me to, collaborate and experience life with the most wonderful people in the world.”

by Bonnie at April 03, 2020 05:26 PM

March 30, 2020

It Was Twenty Years Ago Today …

On March 30th, 2000, the OpenNMS Project was registered on Sourceforge. While the project actually started sometime in the summer of 1999, this was the first time OpenNMS code had been made public so we’ve always treated this day as the birth date of the OpenNMS project.

Wow.

OpenNMS Entry on Sourceforge

Now I wasn’t around back then. I didn’t join the project until September of 2001. When I took over the project in May of 2002 I didn’t really think I could keep it alive for twenty years.

Seriously. I wasn’t then nor am I now a Java programmer. I just had a feeling that there was something of value in OpenNMS, something worth saving, and I was willing to give it a shot. Now OpenNMS is considered indispensable at some of the world’s largest companies, and we are undergoing a period of explosive growth and change that should cement the future of OpenNMS for another twenty years.

What really kept OpenNMS alive was its community. In the beginning, when I was working from home using a slow satellite connection, OpenNMS was kept alive by people on the IRC channel, people like DJ and Mike who are still involved in the project today. A year or so later I was able to convince my business partner and good friend David to join me, and together we recruited a real Java programmer in Matt. Matt is no longer involved in the project (people leaving your project is one of the hardest things to get used to in open source) but his contributions in those early days were important. Several years after that we were joined by Ben and Jeff, who are still with us today, and through slow and steady steps the company grew alongside the project. They were followed by even more amazing people that make up the team today (I really want to name every single one of them but I’m afraid I’ll miss one and they’ll be rightfully upset).

I can’t really downplay enough my lack of responsibility for the success of OpenNMS. My only talent is getting amazing people to work with me, and then I just try to remove any obstacles that get in their way. I get some recognition as “The Mouth of OpenNMS” but most of the time I just stand on the shoulders of giants and enjoy the view.

by Tarus at March 30, 2020 09:03 PM

OpenNMS On the Horizon – Minion, Sentinel, Time-Series API, Kafka, Drools, BMP, Helm, CircleCI, and More!

It's time for OpenNMS On the Horizon!

In the last week we did more work on Minion, Sentinel, Kafka, and Drools, as well as the new time-series API, BMP support, the sink API, web UI bugs, and CircleCI.

Also, Happy Birthday to the OpenNMS Project!

SourceForge project started 2000-03-30

Github Project Updates

Internals, APIs, and Documentation
  • Chandra did more work on adding Jolokia to Minion and Sentinel.
  • Patrick's new time-series API was merged to mainline for Horizon 26! (whoo!)
  • Chandra did more work on publishing enriched data to Kafka, as well as fixing some event production balancing issues.
  • Chandra continued his work on moving to protobuf 3 for the sink API.
  • I continued my work on moving Bamboo workflows into CircleCI.
  • Ronny worked on docker container documentation.
  • Chandra worked on an issue with Sentinel Zookeeper integration.
  • Chandra fixed an issue with restoring Drools facts on reload.
  • Dustin added some support for extended community attributes in BGP data.
  • Christian worked on improving unicast support in the BMP integration adapter.
Web, ReST, UI, and Helm
  • Patrick worked on a few other web UI bugs.
  • Jesse fixed an issue with the graph service and nodes without a foreign source or foreign ID.
  • I worked on fixing Helm on Grafana 6.7.

Calendar of Events

April Releases - April 7th, 2020

The next OpenNMS release day is April 7th, 2020.

Unless we run into major issues, we're hoping to release Horizon 26 in April, which includes support for BMP telemetry collection.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-9121: empty Stress Testing section in admin guide
  • NMS-11788: Add SMTP monitor documentation to the Admin Guide
  • NMS-11812: Clarify Basic Installation scenario
  • NMS-12228: Event documentation is missing tokens
  • NMS-12383: Develop Timeseries Integration Layer
  • NMS-12474: dataCollectionSucceeded does event auto-clean
  • NMS-12475: Remove obsolete entry in log4j2.xml
  • NMS-12526: Enrich content of nodeAdded event
  • NMS-12527: Migrate config-tester wiki to the docs
  • NMS-12529: Splitting Docker documentation in Horizon, Minion and Sentinel
  • NMS-12533: Add Jolokia features to Minion & Sentinel
  • NMS-12583: Write enriched flows to Kafka
  • NMS-12586: Drools working memory facts are not restored properly on engine reload
  • NMS-12602: Upgrade Sink API to Proto3
  • NMS-12612: Open Redirect security issues
  • NMS-12615: PR's fail circleci RPM build steps due to missing GPG setup
  • NMS-12616: Events not balanced across partitions when using opennms-kafka-producer
  • NMS-12619: sentinel-coordination-zookeeper doesn't start due to missing dependency
  • NMS-12626: Minion should bind to 0.0.0.0 by default for SNMP traps
  • NMS-12627: Minion Docker image for develop is tagged as 27.0.0-SNAPSHOT instead of bleeding

by RangerRick at March 30, 2020 05:38 PM

March 24, 2020

OpenNMS On the Horizon – March 24th, 2020 – ARM, CircleCI, Documentation, SNMPv3, Time-Series, Flows, and More!

It's time for OpenNMS On the Horizon!

In the last week we wondered... what is time? Does time exist? Is it Monday? Oh, crap, it's Tuesday! I totally forgot to do OOH!

Um.

Anyway... so we worked on ARM support for Docker, CircleCI updates, documentation improvements, BGP, SNMPv3, time-series, flows, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Ronny updated the Minion docker images to use JICMP and JICMP6 rather than JNA.
  • Ronny finished updating the Minion docker images to support ARM builds. Horizon 27 and higher will support x86_64, arm64, and arm/v7. 👏
  • Bonnie worked on updating the documentation to recommend CentOS 8 for Horizon 25+.
  • Sean added ZSTD compression support to our Kafka config.
  • Bonnie added thresholding documentation.
  • Christian added support for parsing BGP capabilities and adding AFI/SAFI statistics as metrics.
  • I got CircleCI builds working on the foundation branches back to foundation-2016.
  • Chandra did more fixes related to SNMPv3 and engine IDs.
  • Chandra did some work on adding Jolokia features to Minion and Sentinel.
  • Chandra worked on updating the sink API to use protobuf 3.
  • Patrick continued his work on the new timeseries API.
  • Chandra worked on writing enriched (classified and tagged) flow data to Kafka.
Web, ReST, UI, and Helm
  • Ron Roskens worked on fixing persisted calendar report display.
  • I added auto-merge support to the Helm CircleCI config.

Calendar of Events

April Releases - April 7th, 2020

The next OpenNMS release day is April 7th, 2020.

Unless we run into major issues, we're hoping to release Horizon 26 in April, which includes support for BMP telemetry collection.

OpenNMS Training - Moonachie, New Jersey - April 27th through May 1st, 2020

The OpenNMS Group still hopes to be offering training at SecureWatch 24 Fusion Center in Moonachie, New Jersey the week of April 27th. 8 seats are available, and the deadline for signing up is April 17th.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-233: auto-merge helm develop -> master in CircleCI
  • MIB-3: running mib2openNMS - Segmentation fault
  • MIB-7: mib2opennms - problem of OID in mask tag
  • MIB-9: mib2opennms : set options -6 and -w as default
  • NMS-2558: Multiple Default SNMP community Strings
  • NMS-2867: OpenNMS MIB: Converting Events to MIB
  • NMS-3045: Create Java SNMP command line utils
  • NMS-3458: Event Configuration error results in success event after reloading
  • NMS-12438: persisted defaultCalendarReport database reports are broken
  • NMS-12476: Backport CircleCI pipeline to foundation-2018
  • NMS-12481: Docker Image Improvements
  • NMS-12482: Reduce Minion docker image size
  • NMS-12483: Publish arm64 and armhf Docker images for Minion
  • NMS-12484: Use jicmp (and jicmp6) by default in Minion Docker images
  • NMS-12553: Add support for per AFI/SAFI statistics
  • NMS-12570: Add support for Local RIB
  • NMS-12571: Parse BGP Capabilities
  • NMS-12574: Apply more sensible defaults to OpenBMP kafka producer
  • NMS-12603: Backport CircleCI pipeline to foundation-2017
  • NMS-12604: Update installation requirements re: CentOS 8
  • NMS-12607: Backport CircleCI pipeline to foundation-2016
  • NMS-12615: PR's fail circleci RPM build steps due to missing GPG setup

by RangerRick at March 24, 2020 03:55 PM

March 19, 2020

I Didn’t Know OpenNMS Could Do That!

Join us April 27 to May 1 for five days of OpenNMS training in Moonachie, New Jersey, with Tarus Balog, COO of The OpenNMS Group.

For 15 years, Tarus has shared his unique perspective and expert tips during an intensive, hands-on training course to help people get the most from OpenNMS and their networks.

Principles Based

Tarus not only covers the basics like installation, events, notifications, alarms, SNMP, data collection, and thresholds, he also discusses the philosophy behind OpenNMS and network management in general.

Students also have the opportunity for hands-on exercises, such as learning how to use the OpenNMS Event Translator to transform and enrich data for custom monitoring. The main course material spans four days with the final, fifth day devoted to real-world use cases from students.

“My students won’t know everything about OpenNMS — we can’t do that in a week,” Tarus says. “But they will understand the capabilities and can figure out from there how to do what they want to do.”

While It’s Magical, It Isn’t Magic

Tarus wants students to understand why OpenNMS works the way it does, and how it can help them with their own unique needs. He cites recent training with one organization, where the group set up an OpenNMS Minion on a device that manages variable message signs (VMS). (You know, those electronic highway signs that display messages like “reduce speed,” “don’t text and drive”, or “zombies ahead”.) In a short time all 80 VMSs were discovered and students could see what had previously been inaccessible to them.

“I love teaching, because it reminds me of how cool OpenNMS is,” says Tarus. “Not just from the ‘aha’ student moments, but from reflecting on how well it does what it does, the full range of its capabilities, and the unique way it solves their issues.”

Register Now

When: April 27 to May 1, 2020, 9 a.m. to 5 p.m.

Where: Fusion Center
70 Moonachie Avenue
Moonachie, NJ 07074

Cost: $2500 per student, lunch included

Only eight spots are available, so register soon. Deadline for registration: April 17, 2020.

Training is sponsored by Securewatch24 and The OpenNMS Group.

by Bonnie at March 19, 2020 02:34 PM

March 16, 2020

OpenNMS On the Horizon – March 16th, 2020 – CircleCI, Time-Series API, Minion and Sentinel, Classification Rules, Prometheus, Docker Updates, Documentation, and More!

It's time for OpenNMS On the Horizon!

Sorry for the delay in getting this out, I was hiding in the Caribbean away from all the toilet paper hoarders.

In the last couple of weeks we worked on CircleCI workflow updates, the new time-series API, improvements to Minion configuration, normalizing our Karaf command-names, CIDR support for classification rules, a Prometheus collector, a bunch of Docker updates, and documentation improvements.

Github Project Updates

Internals, APIs, and Documentation
  • I worked on backporting our CircleCI workflow to foundation-2018 as part of our continuing process to stop using Bamboo internally.
  • Patrick continued his work to create a new API for time-series data.
  • Jesse did more work on the project to normalize all Karaf commands under an opennms: namespace.
  • Matt worked on adding support for using Confd to configure Minions with a yaml file.
  • Dustin continued his work on BMP support.
  • Matt fixed a race condition in Telemetryd logging.
  • Chandra did more work on converting to using protobuf rather than BSON for transporting flow data.
  • Jesse worked on a collector for Prometheus-formatted data.
  • Markus wrapped up adding support for CIDR in classification rule expressions.
  • Chandra worked on fixing a bug in the Karaf command when attempting to remove something from SNMP definitions.
  • Jesse worked on performance improvements to OIA's use of cached alarms.
  • Ronny worked on adding support for publishing arm64/armhf Docker images for Minion.
  • Bonnie did a bunch of updates to the thresholding docs in Horizon, as well as info on making PDF reports from Grafana dashboards.
  • Sean updated our Kafka components dependency to 2.4.0.
  • Chandra made improvements to the node cache used by flow enrichment.
  • Alejandro fixed a bug in the health-check script for Minion and Sentinel Docker images.
Web, ReST, UI, and Helm
  • Ronny and Bonnie did more work on wrapping up CircleCI publishing, building, and documentation for Helm.

Calendar of Events

April Releases - April 7th, 2020

The next OpenNMS release day is April 7th, 2020.

Unless we run into major issues, we're hoping to release Horizon 26 in April, which includes support for BMP telemetry collection.

OpenNMS Training - Moonachie, New Jersey - April 27th through May 1st, 2020

The OpenNMS Group will be offering training at SecureWatch 24 Fusion Center in Moonachie, New Jersey the week of April 27th. 8 seats are available, and the deadline for signing up is April 17th.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-83: Deadlock in ALEC causes OpenNMS to hung
  • HELM-206: Document how to use the filter panel
  • HELM-207: Document how to use the entity data-source
  • HELM-214: Publish build artifacts with CircleCI to Cloudsmith
  • HELM-218: Integrate Antora documentation into CircleCI
  • HELM-222: Sign RPM and DEB packages with GPG key
  • HELM-223: Archive old AsciiBinder documentation
  • HELM-227: Some filter could be documented
  • JICMP-24: create CircleCI build for JICMP6
  • NMS-10413: Prefix all shell commands with "opennms"
  • NMS-12413: SNMP Remove from definitions fails for definitions with profile label
  • NMS-12423: Allow CIDR notation in our IP filter implementation
  • NMS-12424: Create BMP Adapter forwarding to OpenBMP
  • NMS-12436: Use Router Id (and maybe AS) to associate node with exporting router's data
  • NMS-12534: Evaluate flow-related Elasticsearch query performance
  • NMS-12565: "No future found for message" warnings in telemetryd log
  • NMS-12573: Refine parameter handling in Adapters
  • NMS-12578: Confd templates for Minion configuration
  • NMS-12580: Improve node cache in flow document enrichment
  • NMS-12581: Improve OIA performance when mapping alarms
  • NMS-12582: Upgrade Kafka components to 2.4.0
  • NMS-12600: The health check script for Minion and Sentinel on Docker Images stopped working

by RangerRick at March 16, 2020 08:23 PM

March 12, 2020

COVID-19

The number of people and countries affected by COVID-19 continues to increase as the disease spreads internationally. Each new reported case presents challenges to the person diagnosed, the surrounding community, and the region reporting the case. We extend our concern and sympathy to those who have been impacted.

Public Health Guidelines

By now, most of us are aware of the guidelines to help prevent the spread of this disease – indeed, things we should always do to minimize illness:

  • Frequently wash hands with soap and water
  • Avoid touching your face
  • Cover coughs and sneezes
  • Clean frequently touched surfaces
  • Stay home when sick

Each affected jurisdiction has its own protocols depending on the state of the outbreak and local public health policies. If you haven’t already, we encourage you to understand and follow those in your area.

The OpenNMS Group Status UPDATE (March 16)

For its part, The OpenNMS Group has implemented travel restrictions for all non-critical business travel (domestic and international). We regret having to postpone our March 23–27, 2020, training in New Jersey, which will be rescheduled at a later date. Current registrants will receive a full refund and notification of the new course when it becomes available.

At this point our employees are not required to work from home, As of March 16, our employees will be working from home, and practicing social distancing when required to be in the office. We at The OpenNMS Group want to assure our customers that the OpenNMS team will continue to provide uninterrupted, high quality service and support.

by Bonnie at March 12, 2020 02:57 PM

March 04, 2020

OpenNMS Horizon 25.2.1 (Gyōza) Released

Release 25.2.1 is the sixth release in the Horizon 25 series.

It contains a number of small improvements as well as a few bug fixes and a security
fix for an HQL injection bug. Hat tip to Johannes Moritz for the security report.

The codename for 25.2.1 is Gyōza.

Bug
  • NMS-12473 - Cannot process SNMPv3 Informs due to random Engine ID associated with users
  • NMS-12505 - api/v2/ifservices endpoint does not expose ID and IpInterface in JSON results
  • NMS-12520 - Downtime model change was not updated in the docs
  • NMS-12531 - Topology Map does not show Geocoordinates anymore
  • NMS-12572 - HQL Injection
Enhancement
  • NMS-12279 - Cleanup Interfaces Tagged for Flows
  • NMS-12422 - Allow multiple IP rules for discontinuous IP ranges for flow classification
  • NMS-12557 - Support signing code in CircleCI

by RangerRick at March 04, 2020 03:53 PM

March 03, 2020

OpenNMS Meridian 2019.1.4 Released

Release 2019.1.4 is the fifth release in the Meridian 2019 series.

It fixes an HQL injection bug, as well as a few other issues. Hat tip to Johannes Moritz for the security report.

The codename for 2019.1.4 is Jupiter.

Bug

  • Cannot process SNMPv3 Informs due to random Engine ID associated with users (Issue NMS-12473)
  • Downtime model change was not updated in the docs (Issue NMS-12520)
  • HQL Injection (Issue NMS-12572)

Enhancement

  • Support signing code in CircleCI (Issue NMS-12557)

by RangerRick at March 03, 2020 10:00 PM

OpenNMS Meridian 2018.1.16 Released

Release 2018.1.16 is a small update to 2018.1.15 that fixes an HQL injection bug, as well as a few other issues. Hat tip to Johannes Moritz for the security report.

The codename for 2018.1.16 is Hurricane.
Bug

  • The Karaf poller:test command is not location aware (Issue NMS-12460)
  • NPE while compiling a MIB (Issue NMS-12472)
  • Cannot process SNMPv3 Informs due to random Engine ID associated with users (Issue NMS-12473)
  • Backport date/time format fixes to Meridian 2018 (Issue NMS-12514)
  • HQL Injection (Issue NMS-12572)

by RangerRick at March 03, 2020 09:40 PM

OpenNMS Meridian 2017.1.21 Released

Release 2017.1.21 is a small update to 2017.1.20 that fixes an HQL injection issue that affects most current OpenNMS releases. Hat tip to Johannes Moritz for reporting this.

The codename for 2017.1.21 is Capitol meridian.

Bug

by RangerRick at March 03, 2020 09:12 PM

OpenNMS On the Horizon – March 3rd, 2020 – Netflow, BMP, Time-Series, Karaf, Helm Docs, Topology, ReST, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on netflow payload processing improvements, BMP support, time-series persistence, Helm documentation, Karaf shell commands, topology UI providers, and new ReST APIs.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra continued his work on using protobuf rather than BSON for netflow payloads.
  • Christian, Dustin, and Jesse did more work on adding BMP support.
  • Patrick continued his work on a new time-series persistence API.
  • Bonnie documented forecast filters for Helm.
  • Chandra added a Karaf shell command for displaying the local SNMP engine ID.
  • Matt fixed a logging race condition in Telemetryd.
Web, ReST, and UI
  • Markus updated the VMware and Enlinkd topology providers to use OIA-enriched vertex metadata.
  • I added /api/v2/ipinterfaces and /api/v2/snmpinterfaces endpoints to the ReST API.

Calendar of Events

March Releases - March 3rd, 2020

The next OpenNMS release day is March 3rd, 2020.

It is expected we'll put out releases on all supported:

  • Horizon 25.2.1
  • Meridian 2017.1.21
  • Meridian 2018.1.16
  • Meridian 2019.1.4
OpenNMS Training - Moonachie, New Jersey - March 23rd through 27th, 2020

The OpenNMS Group will be offering training at SecureWatch 24 Fusion Center in Moonachie, New Jersey the week of March 23rd. 8 seats are available, and the deadline for signing up is March 16th.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • JICMP-23: create CircleCI build for JICMP
  • NMS-11868: WS-Man Integration
  • NMS-12314: Discovery enhancements
  • NMS-12415: Create BMP Adapter for Peer Up / Down Events
  • NMS-12492: Investigate persisting route prefixes learned from BMP in Elasticsearch
  • NMS-12519: Add Netflow 9 generation support to udpgen
  • NMS-12538: Expose OnmsIpInterface, OnmsSnmpInterface, others as top-level resources in REST API
  • NMS-12539: The OpenNMS web UI has encountered an error that it does not know how to handle.
  • NMS-12540: Enable Status Enrichment for existing graph providers
  • NMS-12547: Use ProtoBuf to transport parsed BMP messages
  • NMS-12552: BMP parser is to strict for unknown elements / types
  • NMS-12554: Add basic system test for BMP processing
  • NMS-12557: Support signing code in CircleCI
  • NMS-12564: SystemExecutiveMonitor fails with exit code 6
  • NMS-12572: HQL Injection

by RangerRick at March 03, 2020 05:45 PM

February 27, 2020

Become an OpenNMS Expert: Register Now for Training

POSTPONED

Take your network management to the next level with five days of intensive, interactive, hands-on training. From the basics to advanced topics — including student-specific questions and use cases — Tarus Balog, COO of The OpenNMS Group will teach you how to get the most from OpenNMS and your network. Learn about

  • Installing OpenNMS

  • Setting up notifications, monitoring, and visualizations

  • Advanced topics, troubleshooting, and more

When: March 23–27, 2020, 9 a.m. to 5 p.m.

Where: Fusion Center
70 Moonachie Avenue
Moonachie, NJ 07074

Cost: $2500 per student, lunch included

Only eight spots are available, so register soon. Deadline for registration: March 16, 2020.

Training is sponsored by Securewatch24 and The OpenNMS Group.

by Bonnie at February 27, 2020 04:40 PM

February 24, 2020

OpenNMS On the Horizon – February 24th, 2020 – Time-Series, gRPC, CIDR Rules, Documentation Updates, SNMP Informs, Karaf CLI, Topology UI, ReST Improvements, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on the time-series API, the Karaf CLI, gRPC, CIDR classification rules, SNMP informs, the topology UI, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Patrick continued his work on a new time-series API.
  • Chandra did more work on cleaning up gRPC RPC/sink support.
  • Ronny updated the Docker and config-tester documentation.
  • Markus worked on adding CIDR notation format support to the filter classification rule engine.
  • Bonnie did more cleanup and improvements to documentation formatting.
  • Chandra fixed SNMP inform handling to use a persistent engine ID.
  • Jesse continued to work on refactoring our Karaf CLI commands into a unified opennms: namespace.
  • Chandra worked on switching netflow serialization to use protobuf instead of BSON for performance reasons.
Web, ReST, and UI
  • Markus fixed display of the geolocation info panel in the topology UI.
  • I worked on adding /ipinterfaces and /snmpinterfaces ReST endpoints.

Calendar of Events

March Releases - March 3rd, 2020

The next OpenNMS release day is March 3rd, 2020.

There will be more details as we continue to work on issues, but currently it is expected we'll put out releases on all supported:

  • Horizon 25.2.1
  • Meridian 2016.1.24
  • Meridian 2017.1.21
  • Meridian 2018.1.16
  • Meridian 2019.1.4
OpenNMS Training - Moonachie, New Jersey - March 23rd through 27th, 2020

The OpenNMS Group will be offering training at SecureWatch 24 Fusion Center in Moonachie, New Jersey the week of March 23rd. 8 seats are available, and the deadline for signing up is March 16th.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-83: Deadlock in ALEC causes OpenNMS to hung
  • NMS-11840: Docker artifact from build system
  • NMS-11917: Prepare build environment with docker enabled build agent
  • NMS-11926: Name convention for Docker name tag
  • NMS-11931: Develop docker built environment
  • NMS-11956: Docker image build from YUM for CentOS 6.6
  • NMS-11997: Deploy docker image to DockerHub
  • NMS-12024: Trigger docker build from Bamboo develop branch as build stage
  • NMS-12029: Docker image build from YUM for CentOS 6.6 including Postgres 9.3
  • NMS-12372: Add gRPC support for IPC between Minion & OpenNMS
  • NMS-12445: Integrate the new Graph Service API with the OpenNMS Integration API
  • NMS-12473: Cannot process SNMPv3 Informs due to random Engine ID associated with users
  • NMS-12505: api/v2/ifservices endpoint does not expose ID and IpInterface in JSON results
  • NMS-12520: Downtime model change was not updated in the docs
  • NMS-12531: Topology Map does not show Geocoordinates anymore

by RangerRick at February 24, 2020 07:13 PM

February 20, 2020

Join us on Discourse

The OpenNMS Community on Discourse provides a great forum to get help, share ideas, and participate in OpenNMS development. You’ll find about 2,400 searchable posts from the community (including OpenNMS Group staff) on topics like forwarding alarms via Syslog messages and SNMP traps, dealing with Java environments on CentOS and Ubuntu, a discussion of scalable OpenNMS architecture, and announcements about releases and upcoming events.

If you haven’t already, make sure to check out the community. Read, ask questions, share your experiences. Whether you post or just lurk, there’s a wealth of information from users like you that can help you get the most out of your OpenNMS implementation.

We’re especially grateful to the Discourse team who run and maintain the software for us as part of their free hosting for open source projects.

image of mascot holding Discourse logo

by Bonnie at February 20, 2020 06:14 PM

February 18, 2020

OpenNMS On the Horizon – February 18th, 2020 – Flows, Time-Series, Graph API, Karaf, Helm, SNMPv3, Search, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on flows, the time-series and graph APIs, the Karaf CLI, Helm, SNMPv3, web search, and more!

Github Project Updates

Internals, APIs, and Documentation
  • Patrick continued his work on a new time-series API.
  • Christian did more work on flow ingress/egress tagging.
  • Jesse continued working on moving all Karaf commands into an opennms prefix and cleaning up naming.
  • Markus did more work on enhancing flow rule classification configuration.
  • Markus continued his work on integrating the new graph service into OIA.
  • Ronny and I did more work on updating Helm's workflows in CircleCI.
  • Ronny updated the documentation to include the new options for downtime model handling.
  • Marcel made an enhancement to the data provided by a nodeAdded event.
  • Marcel updated the documentation to include information on the config tester.
  • Chandra worked on improving SNMPv3 support to have a persistent engine ID.
Web, ReST, and UI
  • I wrapped up some release changes for Helm.
  • Christian fixed a bug in serializing ID and IP interface in the ifservices ReST endpoint.
  • Markus did some more work on a universal search web interface.

Helm 5

Last week we released Helm 5, our custom plugin for Grafana.

Helm 5 fixes a number of issues, most notably compatibility with newer Grafana releases.
These fixes necessitated dropping compatibility with Grafana versions older than 6.3, so we have bumped the major version of Helm to 5.

Additionally, documentation has been improved and a number of behind-the-scenes changes have been made related to continuous integration and build system.

DockerHub Changes

Ronny pointed out on Discourse that as of Horizon 25, our Docker images are automatically generated from tagged releases in opennms/horizon on DockerHub. Old images that used to reside in the opennms/horizon-core-web DockerHub project have been moved into the new location.

If you have old docker-compose.yml files or K8s deployments that use the old URLs, please migrate them.

Wiki Migration

Marcel has started a project to migrate (and update!) old and outdated wiki pages to Discourse.

If you'd like to help, please check out the discussion and join in the "fun".

Calendar of Events

March Releases - March 3rd, 2020

The next OpenNMS release day is March 3rd, 2020.

There will be more details as we continue to work on issues, but currently it is expected we'll put out releases on all supported:

  • Horizon 25.2.1
  • Meridian 2016.1.24
  • Meridian 2017.1.21
  • Meridian 2018.1.16
  • Meridian 2019.1.4
SCaLE 18x - Pasadena, California - March 5th through 8th, 2020

Tarus Balog will be speaking at SCaLE 18x on alarm correlation (ALEC) and other technologies for large-scale monitoring with OpenNMS.

His presentation is on Saturday the 7th at 4:30pm.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-9495: Use the AsciiBinder framework to content management and publishing
  • NMS-10183: Evaluating Documentation Framework
  • NMS-12279: Cleanup Interfaces Tagged for Flows
  • NMS-12292: Add a "Delete" button on the Node page of the Requisition UI
  • NMS-12422: Allow multiple IP rules for discontinuous IP ranges for flow classification
  • NMS-12447: Remove getVertexType() on GraphInfo
  • NMS-12502: Filter related errors in karaf.log when using new search
  • NMS-12514: Backport date/time format fixes to Meridian 2018
  • NMS-12520: Downtime model change was not updated in the docs

by RangerRick at February 18, 2020 07:06 PM

February 13, 2020

FOSDEM 2020 – So much open source, so little time

Well, the annual pan-European open source jamboree that is FOSDEM, marking its 20th anniversary this year, has come and gone again. OpenNMS developer Ronny Trommer and I were there to sample the mood and fly the OpenNMS flag.

Geeks in Brussels

Each year around 6000 geeks (mostly male and in anoraks) descend on the Université Libre de Bruxelles where over 50 lecture rooms are dedicated to the discussion of all things open source. Subjects range from legal and licencing to open source hardware. Developer rooms are dedicated to specific technical topics such as GIS, Pearl programming, or software-defined networking (SDN). Many of the major open source projects staff a table to promote their work, with the Linux Foundation, Apache, and Eclipse among the biggest presences. The conference is free to attend and run by volunteers.

Geeks heading to the ULB campus.

Ronny and I toured the stands and mostly hung out in the IoT, monitoring, and SDN rooms. We also met up with an old friend of OpenNMS, Patrick Tuit, who was over from Ireland.

This is my fifth FOSDEM, so you might consider me an old hand. The biggest problem with the conference is that there is an awful lot going on and many of the venues are packed and hard to get into. You have to know what you want to see and get there early. My strategy is to stay put once I am in a track and leave only if I need a comfort break :). This means that I end up missing some things but I usually learn something new that I squirrel away for future reference.

IoT and OpenHAB

This year I was after information on IoT. I visited the OpenHAB table and had a long chat with one of the developers to understand the rationale of the project. OpenHAB is targeted at creating a Karaf-based platform for a home hub. It was part of the Eclipse Foundation for a while, but recently left, apparently because they felt the Eclipse process was slowing them down. My main interest in OpenHAB is to understand what, if any, synergy there might be with OpenNMS Minions. For a similar reason I was interested in the Eclipse Foundation's IoT projects, which Bosch is contributing to. Unfortunately, Ubuntu was noticeable by its absence, and I was not able to get a local take on Ubuntu Core's plans for the Raspberry Pi.

Until Next Year

As always, I came away from FOSDEM glad that I went but frustrated at all of the things I was not able to see. A few years ago OpenNMS volunteered a stand at the show, which acted as a magnet for OpenNMS users and I felt gave us a bit more focus. We have also submitted talks in the past to the monitoring track, which helps build mindshare for the project. It may be time to try that again and also to try to organize an OpenNMS training or promotional event before the show. Any feedback or opinions on this would be welcome.

by cgallen at February 13, 2020 08:14 PM

February 10, 2020

OpenNMS On the Horizon – February 10th, 2020 – Helm, BMP, Flows, Karaf, gRPC, Kafka, Graph Service, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on more Helm bugs and documentation, BMP support, flow enhancements, Karaf commands, gRPC and Kafka, graph service improvements, and more!

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie did more work cleaning up and improving Helm documentation.
  • Ronny and Bonnie worked on converting Helm's documentation to publish with Antora.
  • Chandra worked on persisting BMP data to Elasticsearch.
  • Patrick continued his work on a new persistence API.
  • Christian worked on refactoring how interfaces are tagged as having flows.
  • Jesse worked on cleaning up all the Karaf commands to be consistent and under an opennms namespace.
  • Christian added support for forwarding collected BMP telemetry to OpenBMP.
  • Chandra did a bit more work on gRPC IPC support and Kafka topic name cleanups.
  • Markus worked on updating the flow classifications to support multiple IP ranges.
  • Ronny added documentation for the new downtime model delete handling.
Web, ReST, and UI
  • Ronny worked on updating the Helm CircleCI build to do automatic merging.
  • I worked on backporting the date/time angular display fixes to Foundation 2018.
  • Markus did more work on improvements to the new graph service, including integration in OIA.
  • I fixed an issue in Helm where an error would be shown while configuring performance datasource filters.

OpenNMS February Releases

On February 4th we released Meridian 2019.1.3 and Horizon 25.2.0.

Both releases contained a few bug fixes, most notably a fix for some NPEs as well as a performance issue in topology processing.

Additionally, Horizon 25.2.0 included an enhancement to the sink API to persist to disk when the Minion can't reach the broker.

Calendar of Events

SCaLE 18x - Pasadena, California - March 5th through 8th, 2020

Tarus Balog will be speaking at SCaLE 18x on alarm correlation (ALEC) and other technologies for large-scale monitoring with OpenNMS.

His presentation is on Saturday the 7th at 4:30pm.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-208: Error appears when selecting filter type
  • HELM-216: Build docs with CircleCI and publish docs to Netlify
  • HELM-217: Convert docs from Asciibinder to Antora
  • NMS-9811: Thresholds should work without restart when putting nodes into categories
  • NMS-10280: All docs are missing for recent Meridian releases
  • NMS-12428: changing GUI date/timeformat breaks requisition update/import date/time display
  • NMS-12479: Make Kafka RPC topics configurable to use module in topic names
  • NMS-12486: Implement GRPC Server that can route all RPC/Sink messages from OpenNMS to Minion and vice versa

by RangerRick at February 10, 2020 03:29 PM

February 04, 2020

OpenNMS Horizon 25.2.0 (Biscuit Dumpling) Released

Release 25.2.0 is the fifth release in the Horizon 25 series.

It contains a number of bug fixes including a performance fix for topology updating, and an enhancement to the sink API to persist to disk when the Minion can’t reach the broker.

The codename for 25.2.0 is Biscuit Dumpling.

Bug
  • changing GUI date/timeformat breaks requisition update/import date/time display (Issue NMS-12428)
  • Inefficient locking in the TopologyUpdater class (Issue NMS-12443)
  • MIB Compiler fails with Null Pointer Exception (Issue NMS-12459)
  • The Karaf poller:test command is not location aware (Issue NMS-12460)
  • NPE while compiling a MIB (Issue NMS-12472)
Enhancement
  • Sink API: Persistent Off-Heap Storage (Issue NMS-10586)

by RangerRick at February 04, 2020 10:20 PM

OpenNMS Meridian 2019.1.3 (Mars) Released

Release 2019.1.3 is the fourth release in the Meridian 2019 series.

It contains a few bug fixes, most notably a fix for some NPEs as well as a performance issue in topology processing.

The codename for 2019.1.3 is Mars.

Bug
  • changing GUI date/timeformat breaks requisition update/import date/time display (Issue NMS-12428)
  • Inefficient locking in the TopologyUpdater class (Issue NMS-12443)
  • MIB Compiler fails with Null Pointer Exception (Issue NMS-12459)
  • The Karaf poller:test command is not location aware (Issue NMS-12460)
  • NPE while compiling a MIB (Issue NMS-12472)

by RangerRick at February 04, 2020 08:17 PM

February 03, 2020

OpenNMS On the Horizon – February 3rd, 2019 – Helm, InfluxDB, Kafka RPC, and More!

It's time for OpenNMS On the Horizon!

In the last week we cleaned up Helm compatibility, worked on InfluxDB support, continued to improve Kafka RPC, and more.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie did more work on cleaning up documentation in various places.
  • Markus continued to work on integrating the new graph service API into OIA.
  • Patrick worked on an InfluxDB implementation for the new time-series API.
  • Chandra continued his work making Kafka RPC topics more configurable.
  • Ronny worked on moving some Bamboo merge and documentation actions to CircleCI.
  • Markus did more work on fixing a performance issue in the ALEC topology updater.
Web, ReST, and UI
  • I wrapped up the code for my fix for parsing format strings in AngularJS.
  • I fixed a number of Helm bugs including Grafana 6.5 and 6.6 support.

Calendar of Events

February Releases - February 4th, 2020

The next OpenNMS release day is February 4th, 2020.

There will be more details as we continue to work on issues, but currently it is expected we'll put out the following releases:

  • Horizon 25.1.3
  • Meridian 2019.1.3

SCaLE 18x - Pasadena, California - March 5th through 8th, 2020

Tarus Balog will be speaking at SCaLE 18x on alarm correlation (ALEC) and other technologies for large-scale monitoring with OpenNMS.

His presentation is on Saturday the 7th at 4:30pm.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-196: Alarm table rendering failures with Grafana 6.5.2
  • HELM-205: Document how to use template variables and node label transforms
  • HELM-210: Documentation doesn't show latest release
  • HELM-211: Grafana dependency should be updated and should be more specific
  • HELM-212: number (count) columns render wrong in Grafana 6.5 and 6.6
  • HELM-219: Update CircleCI build pipeline from 2.0 to 2.1
  • NMS-12443: Inefficient locking in the TopologyUpdater class
  • NMS-12453: Expose status information when fetching a graph view

by RangerRick at February 03, 2020 05:41 PM

January 27, 2020

OpenNMS On the Horizon – January 27th, 2020 – Bug Fixing, Graph Service, Off-Heap Storage, Documentation, and More!

OpenNMS On the Horizon

It's time for OpenNMS On the Horizon!

In the last couple of weeks we merged a number of new features that have been in the works for a while (graph API, off-heap storage), fixed a bunch of bugs, and started on reworking some documentation.

Github Project Updates
  • Internals, APIs, and Documentation

    • Markus enhanced the new graph API to expose status information.
    • Patrick continued his work refactoring the time-series APIs.
    • Chandra continued his work on adding gRPC support for the Minion.
    • Matt fixed another bug in the dreaded syslog date parsing algorithm.
    • Bonnie made a bunch of improvements to the Helm documentation.
    • Marcel fixed a bug where datacollection failures could be masked by auto-clean.
    • Chandra fixed some issues with using the default foreign source during discovery.
    • Christian worked on normalizing our Karaf shell commands.
    • Markus worked on fixing a performance issue with locking in ALEC topology updates.
    • Pierre, Jesse, and I worked on fixing build issues with Maven Central blocking non-HTTPS connections.
    • Dustin continued his work on BMP support in Telemetryd.
    • Pierre converted events internally to be immutable.
    • Markus started adding graph API support to OIA.
    • Chandra worked on making Kafka RPC topics more configurable.
    • Matt finished his new implementation of off-heap storage for the sink API.
  • Web, ReST, and UI

    • Qauseen added pagination to the node search modal in Helm.
    • Qauseen fixed a performance issue where the Helm panel would refresh for each alarm being cleared, rather than when it finished.
    • Markus and I worked on fixing custom date formatting in AngularJS.
    • Christian fixed an NPE in the MIB compiler.
Calendar of Events
  • February Releases - February 4th, 2020

    The next OpenNMS release day is February 4th, 2020.

    There will be more details as we continue to work on issues, but currently it is expected we'll put out the following releases:

    • Horizon 25.1.3
    • Meridian 2019.1.3

  • FOSDEM 2020 - Brussels, Belgium - Feb 1st and 2nd, 2020

    Ronny Trommer will be attending FOSDEM 2020. If you want to meet and talk, contact him on Twitter, Discourse, or email him at ronny[eth]opennms-dot-com.

  • SCaLE 18x - Pasadena, California - March 5th through 8th, 2020

    Tarus Balog will be speaking at SCaLE 18x on alarm correlation (ALEC) and other technologies for large-scale monitoring with OpenNMS.
    His presentation is on Saturday the 7th at 4:30pm.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH
  • HELM-64: Node search allows only to select the first 25 nodes
  • HELM-201: Panel Refreshes After Each Request When Clearing Multiple Alarms
  • HELM-204: Document how to use filters for forecasting metrics
  • NMS-10586: Sink API: Persistent Off-Heap Storage
  • NMS-10720: Make Events immutable (avoid CMEs and fix non-deterministic behavior)
  • NMS-12086: Provide a better graph service with an actual API/Model and better import/export/integration capabilities
  • NMS-12411: Discovery and foreignSource service detection get in the way
  • NMS-12459: MIB Compiler fails with Null Pointer Exception
  • NMS-12460: The Karaf poller:test command is not location aware

by RangerRick at January 27, 2020 09:24 PM

January 23, 2020

Once Again Into the Breach – Back with Apple

After almost a decade since my divorce from Apple, I find myself back with the brand, and it is all due to the stupid watch.

TL;DR: As a proponent of free software, I grouse at the “walled garden” approach Apple takes with its products, but after a long time of not using their products I find myself back in, mainly because free software missed the boat on mobile.

Back in 2011, I stopped using Apple products. This was for a variety of reasons, and for the most part I found that I could do quite well with open source alternatives.

My operating system of choice became Linux Mint. The desktop environment, Cinnamon, allowed me to get things done without getting in the way, and the Ubuntu base allowed me to easily interact with all my hardware. I got rid of my iMac and bought a workstation from System 76, and for a time things were good.

I sold my iPhone and bought an Android phone which was easier to interact with using Linux. While I didn’t have quite all of the functionality I had before, I had more than enough to do the things I needed to do.

But then I started to have issues with the privacy of my Android phone. I came across a page which displayed all of the data Google was collecting on me, which included every call, every text and every application I opened and how long I used it. Plus the stock Google phones started to ship with all of the Google Apps, many of which I didn’t use and they just took up space. While the base operating system of Android, the Android Open Source Project (AOSP), is open source, much of the software on a stock Android phone is very proprietary, with questionable motives behind gathering all of that data.

Then I started playing with different Android operating systems known as “Custom ROMs”. Since I was frequently installing the operating system on my phone I finally figured out that when Google asks “Would you like to improve your Android experience?”, and you say “yes”, that is when they start the heavy data collection. Opt-out and the phone still works, but even basic functionality such as storing your recent location searches in Google Maps goes away. Want to be able to go to a previous destination with one click? Give them all yer infos.

The Custom ROM world is a little odd. While there is nothing wrong with using software projects run by hobbyists, the level of support can be spotty at best. ROMs that at one time were heavily supported can quickly go quiet as maintainers get other interests or other handsets. For a long time I used OmniROM with a minimal install of Google Apps (with the “do not improve my Android experience” option) and it even worked with my Android Wear smartwatch from LG.

I really liked my smartwatch. It reminded me of when we started using two monitors with our desktops. Having things like notifications show up on my wrist was a lot easier to deal with than having to pull out and unlock my phone.

But all good things must come to an end. When Android Wear 2.0 came out they nerfed a lot of the functionality, requiring Android Assistant for even the most basic tasks (which of course requires the “improved” Android experience). I contacted LG and it wasn’t possible to downgrade, so I stopped wearing the watch.

Things got a little better when I discovered the CopperheadOS project. This was an effort out of Canada to create a highly secure handset based on AOSP. It was not possible (or at least very difficult) to install Google Apps on the device, so I ended up using free software from the F-Droid repository. For those times when I really needed a proprietary app I carried a second phone running stock Android. Clunky, I know, but I made it work.

Then CopperheadOS somewhat imploded. The technical lead on the project grew unhappy with the direction it was going and left in a dramatic fashion. I tried to explore other ROMs after that, but grew frustrated in that they didn’t “just work” like Copperhead did.

So I bought an iPhone X.

Apple had started to position themselves as a privacy focused company. While they still don’t encrypt information in iCloud, I use iCloud minimally so it isn’t that important to me. It didn’t take me too long to get used to iOS again, and I got an Apple Watch 3 to replace my no longer used Android Wear watch.

This was about the time the GDPR was passed in the EU, and in order to meet the disclosure requirements Apple set up a website where you could request all of the personal data they collected on you. Now I have been a modern Apple user since February of 2003 when I ordered a 12-inch Powerbook, so I expected it to be quite large.

It was 5MB, compressed.

The majority of that was a big JSON file with my health data collected from the watch. While I’m not happy that this data could be made available to third parties as it isn’t encrypted, it is a compromise I’m willing to make in order to have some health data. Now that Fitbit is owned by Google I feel way more secure with Apple holding on to it (plus I have no current plans to commit a murder).

The Apple Watch also supports contactless payments through Apple Pay. I was surprised at how addicted I became to the ease of paying for things with the watch. I was buying some medication for my dog when I noticed their unit took Apple Pay, and the vet came by and asked “Did you just Star Trek my cash register?”.

Heh.

For many months I pretty much got by with using my iPhone and Apple Watch while still using open source for everything else. Then in July of last year I was involved in a bad car accident.

In kind of an ironic twist, at the time of the accident I was back to carrying two phones. The GrapheneOS project was created by one of the founders of Copperhead and I was once again thinking of ditching my iPhone.

I spent 33 nights in the hospital, and during that time I grew very attached to my iPhone and Watch. Since I was in a C-collar it made using a laptop difficult, so I ended up interacting with the outside world via my phone. Since I slept off and on most of the day, it was nice to get alerts on my watch that I could examine with a glance and either deal with or ignore and go back to sleep.

This level of integration made me wonder how things worked now on OSX, so I started playing with a Macbook we had in the office. I liked it so much I bought an iMac, and now I’m pretty much neck deep back in the Apple ecosystem.

The first thing I discovered is that there is a ton of open source software available on OSX, and I mainly access it through the Homebrew project. For example, I recently needed the Linux “watch” command and it wasn’t available on OSX. I simply typed “brew install watch” and had it within seconds.

The next major thing that changed for me was how integrated all my devices became. I was used to my Linux desktop not interacting with my phone, or my Kodi media server being separate from my smartwatch. I didn’t realize how convenient a higher level of integration could be.

For example, for Christmas I got an Apple TV. Last night we were watching Netflix through that device and when I picked up my iPhone I noticed that I could control the playback and see information such as time elapsed and time remaining for the program. This happened automatically without the need for me to configure anything. Also, if I have to enter in text, etc. on the Apple TV, I can use the iPhone as a keyboard.

I’ve even started to get into a little bit of home automation. I bought a “smart” outlet controller that works with Homekit. Now I don’t have the “Internet of Things”, instead I have the “LAN of Things” as I block Internet access for most of my IoT-type things such as cameras. Since the Apple TV acts as a hub I can still remotely control my devices even though I can’t reach them via the Internet. All of the interaction occurs through my iCloud account, so I don’t even have to poke a hole in my firewall. I can control this device from any of my computers, my iPhone or even my watch.

It’s pretty cool.

It really sucks that the free and open source community missed the boat on mobile. The flagship mobile open source project is AOSP, and that it heavily controlled by Google. While some brave projects are producing Linux-based phones, they have a long way to go to catch up with the two main consumer options: Apple and Google. For my piece of mind I’m going with Apple.

There are a couple of things Tim Cook could do to ease my conscience about my use of Apple products. The first would be to allow us the option of having greater control of the software we install on iOS. I would like to be able to install software outside of the App Store without having to jailbreak my device. The second would be to enable encryption on all the data stored in iCloud so that it can’t be accessed by any other party than the account holder. If they are truly serious about privacy it is the logical next step. I would assume the pressure from the government will be great to prevent that, but no other company is in a better position to defy them and do it anyway.

by Tarus at January 23, 2020 05:43 PM

January 13, 2020

OpenNMS On the Horizon – January 13th, 2020 – Refactoring, gRPC, Helm, and More!

It's time for OpenNMS On the Horizon!

In the last week we worked on a bunch of refactoring, plus gRPC support, Helm, and some other fixes.

Github Project Updates

  • Internals, APIs, and Documentation

    • I did more work on moving CI tasks to CircleCI and CloudSmith.
    • Chandra did more work wrapping up gRPC IPC support for Minion <-> OpenNMS communication.
    • Patrick continued his work on refactoring/cleaning up the time-series APIs.
    • Pierre worked on making events immutable internally, which should clean up a whole bunch of potentially undefined behaviors in OpenNMS.
  • Web, ReST, and UI

    • Qauseen worked on some enhancements and cleanup in Helm including fixes to actions and pagination.
    • Jesse fixed an issue with alarm table sorting and alarm details in Helm.

January Releases: Meridian 2018.1.15, Meridian 2019.1.2, and Horizon 25.1.2

January saw the release of 3 point updates for OpenNMS Meridian and Horizon.

Meridian 2018.1.15 was a very small release with a topology UI fix and a fix to some debug logging.

Meridian 2019.1.2 and Horizon 25.1.2, on the other hand, contained a ton of fixes to Alarmd processing, flows, and more.

For a complete list of changes, see the release notes:

Calendar of Events

  • February Releases - February 4th, 2020

    The next OpenNMS release day is February 4th, 2020.

    There will be more details as we continue to work on issues, but currently it is expected we'll put out the following releases:

    • Horizon 25.1.3
    • Meridian 2019.1.3

  • SCaLE 18x - Pasadena, California - March 5th through 8th, 2020

    Tarus Balog will be speaking at SCaLE 18x on alarm correlation (ALEC) and other technologies for large-scale monitoring with OpenNMS.

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-139: Alarm Table page has a number of bugs
  • HELM-202: Alarms details modal shows wrong alarm when table is sorted
  • NMS-12448: Avoid rebuilding the graph view when enriching
  • NMS-12467: CircleCI packages should have branch number and incrementing build
  • NMS-12471: DatacollectionFailed event definitions are located in wrong file

by RangerRick at January 13, 2020 05:42 PM

January 07, 2020

OpenNMS Horizon 25.1.2 (Pierogi) Released

Release 25.1.2 is the fourth release in the Horizon 25 series.

It contains a number of alarm classification bug fixes and performance improvements, flow enhancements, and more.

The codename for 25.1.2 is Pierogi.

Bug
  • possible issue in JCIFS Monitor - contiously increase of threads - finally heap dump (Issue NMS-12407)
  • Wrong links in the Help/Support page (Issue NMS-12418)
  • Classification Engine reload causes OOM when defining a bunch of rules (Issue NMS-12429)
  • TCP Listeners are broken (Issue NMS-12430)
  • Cannot define a specific layer in topology app URL (Issue NMS-12431)
  • Classification UI: Error responses are not shown properly (Issue NMS-12432)
  • Classification Engine: The end of the range is excluded, which is not intuitive (Issue NMS-12433)
  • Ticket-creating automations are incorrectly enabled by default (Issue NMS-12439)
  • Enable downtime model-based node deletion to happen when unmanaged interfaces exist (Issue NMS-12442)
  • Improve alarmd Drools engine performance by using STREAM mode (Issue NMS-12455)
Enhancement
  • Refactoring of the Cassandra installation instructions (Issue NMS-12397)
  • SNMP detector should use snmp profiles (Issue NMS-12406)
  • Allow telemetry flows to balance across Kafka partitions (Issue NMS-12427)
  • Add system test for IpfixTcpParser (Issue NMS-12434)
  • Associate exporter node using Observation Domain Id (Issue NMS-12435)

by RangerRick at January 07, 2020 07:43 PM

OpenNMS Meridian 2019.1.2 (Earth) Released

Release 2019.1.2 is the third release in the Meridian 2019 series.

It contains a number of alarm classification bug fixes and performance improvements, flow enhancements, and more.

The codename for 2019.1.2 is Earth.

Bug
  • possible issue in JCIFS Monitor - contiously increase of threads - finally heap dump (Issue NMS-12407)
  • Wrong links in the Help/Support page (Issue NMS-12418)
  • Classification Engine reload causes OOM when defining a bunch of rules (Issue NMS-12429)
  • Cannot define a specific layer in topology app URL (Issue NMS-12431)
  • Classification UI: Error responses are not shown properly (Issue NMS-12432)
  • Classification Engine: The end of the range is excluded, which is not intuitive (Issue NMS-12433)
  • Ticket-creating automations are incorrectly enabled by default (Issue NMS-12439)
  • Enable downtime model-based node deletion to happen when unmanaged interfaces exist (Issue NMS-12442)
  • Improve alarmd Drools engine performance by using STREAM mode (Issue NMS-12455)
Enhancement
  • Refactoring of the Cassandra installation instructions (Issue NMS-12397)
  • Allow telemetry flows to balance across Kafka partitions (Issue NMS-12427)
  • Add system test for IpfixTcpParser (Issue NMS-12434)
  • Associate exporter node using Observation Domain Id (Issue NMS-12435)

by RangerRick at January 07, 2020 05:15 PM

OpenNMS Meridian 2018.1.15 (Cyclone) Released

Release 2018.1.15 is a tiny update containing a logging fix in Provisiond and an update to allow for choosing a layer when linking to the topology UI.

The codename for 2018.1.15 is Cyclone.

Bug
  • Cannot define a specific layer in topology app URL (Issue NMS-12431)

by RangerRick at January 07, 2020 05:12 PM

January 06, 2020

OpenNMS On the Horizon – January 6th, 2020 – Graph API, SNMP Profiles, Package Repositories, Documentation, and More!

It's time for OpenNMS On the Horizon!

Since before our Holiday break we continued to work on graph and SNMP enhancements, moving packages to a (hopefully) faster and easier-to-manage cloud service, and updated documentation.

Github Project Updates

  • Internals, APIs, and Documentation

    • Markus did more work on optimizing and improving the new graph service API.
    • Chandra continued his work on updating the SNMP detector to support SNMP config profiles.
    • Ronny did more work on the Cassandra installation docs.
    • Jeff fixed the default alarmd drools rules to skip ticket creation to match the old behavior.
    • I worked on publishing our RPM and Debian packages to CloudSmith.
    • Patrick continued his work refactoring our existing time-series persistence APIs.
    • Bonnie worked on improving the Helm documentation.
  • Web, ReST, and UI

    • Jesse worked on enhancing the Alarm API to retrieve historical alarms from Elasticsearch.

Calendar of Events

Until Next Week…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-195: "Canceled:Query Changed while running" when clearing multiple alarms
  • NMS-12397: Refactoring of the Cassandra installation instructions
  • NMS-12406: SNMP detector should use snmp profiles
  • NMS-12439: Ticket-creating automations are incorrectly enabled by default
  • NMS-12442: Enable downtime model-based node deletion to happen when unmanaged interfaces exist
  • NMS-12454: Make it easy to download Debian/RPM artifacts from CircleCI
  • NMS-12455: Improve alarmd Drools engine performance by using STREAM mode
  • NMS-12463: RRDTool 1.7.0 permission bug when running as non-root
  • NMS-12464: Deploy RPMs and Debian Packages to CloudSmith

by RangerRick at January 06, 2020 04:32 PM