New and Noteworthy (1.3.x through 1.5.x)

From OpenNMS
Jump to navigation Jump to search

New in OpenNMS 1.5.99

OpenNMS 1.5.99 is the third release candidate for OpenNMS 1.6.

Bug Fixes

  • A bug in the poller which caused the reason code not to be associated with node lost service events was fixed. (bug #2846)

New in OpenNMS 1.5.98

OpenNMS 1.5.98 is the second release candidate for OpenNMS 1.6.

Bug Fixes

  • A bug in the OTRS integration was fixed. (bug #2835)
  • A critical bug in the poller and HTTP monitor which could cause services from being restored in some cases was fixed. (bug #2841 and bug #2842)

Known Issues

A few small issues have been found in rc1 that will not make it into 1.6.0. They will be a part of the 1.6.1 release.

  • KSC reports sort by ID rather than by name (bug #2817)
  • Graphs for load averages should show typical units rather than si units (bug #2824)
  • A URL added in the discovery admin UI cannot be deleted. (bug #2829)

In addition, there are a number of small bugs and features which are slated for future 1.6 releases. They can be viewed (and voted on) in the bugzilla 1.6.1 milestone.

New in OpenNMS 1.5.97

OpenNMS 1.5.97 is the first release candidate for OpenNMS 1.6.

New Features

  • When searching for a node, if the search returns only a single node, it will redirect directly to the node page. (bug #1518)
  • Support for new Ricoh/Savin Printer data collections was added. (bug #1941)
  • The default thresholding behavior has been changed to use the new in-line collectd-based thresholder. (bug #2611)
  • The comment field in assets no longer has a size limit. (bug #2763)
  • The default logging level is now WARN instead of DEBUG. (bug #2796)
  • PostgreSQL 8.3 is now officially supported in the installer. (bug #2808)

Bug Fixes

  • A bug in the scheduled outages UI was fixed. (bug #2670)
  • A number of thread concurrency issues have been fixed. (bug #2715)
  • The HTTP collector now handles string attributes correctly. (bug #2806)
  • A few other bugs have been fixed since 1.5.96, in the process of preparing for 1.6.0. A full list of bugs fixed in the release can be found in bugzilla.

New in OpenNMS 1.5.96

OpenNMS 1.5.96 is the seventh beta on the road to a 1.6 stable release.

Bug Fixes

  • An exception introduced into the notification browser as part of the XSS security fixes was made unexceptional. (bug #2776)

New in OpenNMS 1.5.95

OpenNMS 1.5.95 is the sixth beta on the road to a 1.6 stable release.

New Features

  • Nodes in category list are now sorted by name. (bug #2708)

Bug Fixes

  • A bug in the poller that would cause failed services to be shown as available was fixed. (bug #2769)
  • A few other bugs have been fixed since 1.5.94, in the process of preparing for 1.6.0. A full list of bugs fixed in the release can be found in bugzilla
  • A number of security issues have been fixed. (bug #2760)

New in OpenNMS 1.5.94

OpenNMS 1.5.94 is the fifth beta on the road to a 1.6 stable release.

New Features

  • OpenNMS now has provisional support for PostgreSQL 8.3. All known bugs have been fixed, but there may be some corner cases left that aren't covered by unit tests. To use OpenNMS with PostgreSQL 8.3, you will need to run the install tool with the "-Q" option. (bug #2613)
  • OpenNMS now automatically writes a thread dump to output.log on shutdown, for easier debugging. (bug #2181)
  • SNMP parameters can now be set in the Collectd configuration. (bug #2195)
  • Relative thresholds can now use negative numbers. Additionally, you can now threshold on absolute changes as well (loss in dB on fiber links, etc.) (bug #2275, bug #2604)
  • XmlRpcNotifier now allows a timeout parameter. (bug #2342)
  • The java web start remote poller can now be run in a headless mode. See this page for configuration details. (bug #2354)
  • Asset comments now retain formatting. In addition, the exporter creates real CSV files, so you can have asset data with commas in them. ;) (bug #2363)
  • The OSS/J QoS interface has been enhanced in a number of ways, mostly related to documentation and simplifying importing. See bug #2618 for details.
  • A new ticketing plugin for OTRS has been added. (bug #2658)
  • Initial support was added for interfacing with devices that speak Transactional Language 1, or TL-1. (bug #2693)
  • The HTTP Collector can now substitute IP addresses in URLs it's collecting from (bug #2590)
  • Support for new Aedilis, Cisco, Citrix, Compaq, McAfee, Polycom, Radlan, and UPS-MIB traps (bug #2511, bug #2542, bug #2554, bug #2566, bug #2581, bug #2598, bug #2599, bug #2643, bug #2671, bug #2722)
  • Support for new Brocade, Citrix, Dell, Fortinet, HP-UX, Kyocera, Liebert, Novell, and SNMP Informant data collections (bug #2370, bug #2371, bug #2391, bug #2511, bug #2579, bug #2624, bug #2629, bug #2663, bug #2686, bug #2700)

Bug Fixes

  • A rare but insidious bug in the poller that caused some outages to not be properly resolved was fixed. (bug #2702)
  • A large number of other bugs have been fixed since 1.5.93, in the process of preparing for 1.6.0. A full list of bugs fixed in the release can be found in bugzilla
  • A number of cross-site scripting (XSS) security issues have been fixed. (bug #2631, bug #2633, bug #2634)

Changes

  • In the plugins for capsd and the monitors for the service poller, the correct parameter to use for retries is "retry" however some used "retries". This has been corrected, but on upgrading one may want to change the configuration files if they have been customized. Those changed were:
    • service poller monitors
      • SNMP Monitor
      • OMSA Storage Monitor
      • PERC Monitor
      • Disk Usage Monitor
    • capsd plugins
      • NTP Plugin
      • DNS Plugin
  • The default RRD roll-up schedule for data collected using the NSClient Collector has been changed to match that used for some time by the SNMP Collector. When upgrading to release 1.5.94, users who rely on NSClient data collection and do not wish to lose any historical data must take care to preserve the existing roll-up schedule in the nsclient-datacollection-config.xml file. Users who are not concerned with keeping historical NSClient performance data can adopt the new roll-up schedule, but will need to delete all RRD files created while the old roll-up schedule was in effect. Failure to do so will result in new data not being stored.

New in OpenNMS 1.5.93

OpenNMS 1.5.93 is the fourth beta on the road to a 1.6 stable release.

This release is intended primarily to solve an issue in SNMP4J which could cause performance issues from excessive logging in some situations. (bug #2552)

In addition, the installer was updated to not force a specific amount of memory when run, so it should work with large databases without the need to edit the upgrade script.

New in OpenNMS 1.5.92

OpenNMS 1.5.92 is the third beta on the road to a 1.6 stable release.

Xmlrpcd has been improved to allow multicasting events as well as a few other changes. (bug #1487)

Support for logging logins, failed login attempts, logouts, and session timeouts was added. (bug #1580)

Support for new Juniper, Cisco, Sonus, and VMware traps was added. (bug #2368, bug #2487, bug #2500, bug #2502, and bug #2540)

Support for new Asterisk, Juniper, Cisco, Windows, Mikrotik, and UCD data collections was added. (bug #2356, bug #2367, bug #2384, bug #2387, bug #2390, bug #2420, bug #2477, bug #2483, and bug #2529)

There is a new parameter that can be used to extract asset information for use in events and notices. The parameter %asset[fieldname]% will look up the field in the assets table represented by "fieldname" for the nodeid in the event. For example: %asset[description]% will return the description field. If a field is empty or not available it will return "Unknown". (bug #2465)

A full list of bugs fixed in the release can be found in bugzilla.

New in OpenNMS 1.5.91

The scheduled outage web UI improvements that were partially implemented in 1.5.91 are finished. You can now create daily scheduled outages.

OpenNMS XML configuration files will now be validated if xmllint is available at startup.

A number of exceptions and other code errors have been fixed.

A few issues relating to thresholding and data collection have been resolved.

A full list of bugs fixed in the release can be found in bugzilla.

New in OpenNMS 1.5.90

NSClient and HTTP collections used to need a "nsclient-collection" and "http-collection" parameter (respectively) in collectd-configuration.xml. This is now supported, but deprecated, and the name changed to "collection", as is the case for SNMP collection.

Data collection from systems supporting the UCD-SNMP SYSSTAT MIB group now includes the raw counters for context and interrupts. The deprecated one-minute gauge versions of these metrics are still collected if the agent provides them, but their resource graphs are no longer in the default list.

A full list of bugs fixed in the release can be found in bugzilla. There were over 70 of them.

In addition, a number of new event definitions were added. Note that the UEIs for Foundry Networks now all read "foundry" whereas before some read "foundry" and others read "FoundryNetworks". This will affect any notifications based on those UEIs.

New in OpenNMS 1.3.11

There are no new features in 1.3.11, but there was one that was left out of the description for 1.3.10 that should be mentioned.

The Mail Transport Monitor tests a mail server by actually sending an e-mail and checking that it was received. This can be a very useful for measuring the response time of mail systems.

A lot of changes were made under the covers to the eventd process in 1.3.10. One of those changes broke events from interfaces with an IP address that exists on more than one node. While not a problem that the average person is likely to encounter, it was enough of an issue to warrant a fix. The list of bugs fixed in this release are available here.

New in OpenNMS 1.3.10

OpenNMS now supports an integration with the Hyperic HQ server. There is a detailed white paper available that describes the necessary configuration changes.

The classes used to discover and poll NRPE (Nagios Remote Plugin Execution) checks from OpenNMS now support the NRPE protocol over secure sockets layer (SSL). Since both the official NRPE addon from Nagios and the NRPE listener of NSClient++ use SSL by default, the new default in OpenNMS is to use SSL for NRPE.

OpenNMS now supports discovery and monitoring of Windows services (even those that do not provide network services, such as the Task Scheduler) via the SNMP service that ships with Windows.

Thresholding has been (optionally) moved into the collection daemon. Changes to your configuration is required to use this new code, but once done, thresholds are calculated on data as it is collected. This is significantly more efficient (data is not read back from the RRD/JRB files on disk), and also removes the need for the "range" parameter.

It is now possible to relocate the /var/opennms and /var/log/opennms when installing the RPMs, using the "--relocate" option to RPM.

A large number of bugs were addressed in this release. Bugzilla contains the complete list. Also, a large number of changes were made under the covers to such processes as eventd.

New in OpenNMS 1.3.9

This is mostly a small bug-fix release.

You can add/delete groups through the webUI, and end users can change their own passwords.

Also, a major bug fix that fixes a deadlock condition between OpenNMS and the database.

New in OpenNMS 1.3.8

OpenNMS now runs on Windows.

Linkd and Syslogd both have been significantly improved.

The split-personality issues with configuration differences between running the embedded Jetty web UI and running in Tomcat have been improved. The Jetty server is also more configurable, with support for being proxied.

Rudimentary RSS feed support has been added to the Web UI.

As always, a number of bugs, big and small have been fixed.

New in OpenNMS 1.3.7

Performance is an order of magnitude better than 1.3.6. We've also added a new monitor called StrafePing. This is a port of Tobi Oeticker's Smokeping application which provides a graphical view of ICMP latency by sending out 20 pings every 5 minutes and measuring the time it takes to return. The median value is graphed and the deviations show up as grey "smoke". This monitor is also useful if you would like to get alerted when an interface starts dropping packets. It can be configured to be marked as "down" when less than 20 packets are returned.

Check out StrafePing

We have also become a silver sponsor on Tobi's Smokeping page in recognition of his work.

We also removed the need for tomcat, so no more struggling with that app (unless you want to, as it is still supported). OpenNMS comes bundled with the jetty servlet container. It runs on port 8980 instead of 8080, so be aware of that.

In addition to our CentricCRM Trouble Ticketing plugin, there is now one for Jira.

In order to make upgrades easier, there are yum and apt based repositories to make it easier to stay up to date.

Syslogd refactor for smarter event matching.

New in OpenNMS 1.3.6

This week finds the OpenNMS gang in Minneapolis, Minnesota for our annual developer's conference: Dev-Jam. People started arriving this weekend, so on Sunday we decided to tag and release OpenNMS 1.3.6.

1.3.6 is a milestone in that all of the C code that OpenNMS uses has been moved to separate packages. This allows us to compile OpenNMS once for use on all of the different platforms we support.

The first time that 1.3.6 is installed, some additional packages will be required. Since 1.3.3, the iplike functionality needs to be installed on the server running the PostgreSQL database using the iplike package. If RRDtool is being used, the jrrd package should be installed (if JRobin is being used to record and display performance data, this package is optional). The jicmp package *must* be installed in order for OpenNMS to monitor and use ICMP. All of these packages are available from the OpenNMS Sourceforge download page.

If you use an RPM-based distribution and we do not provide a package for your distro, simply download the tar.gz file and run:

 rpmbuild -tb filename.tar.gz

This should build an RPM for you. Make sure Java is installed and in your path.

The updated install guide can be found here.

1.3.6 contains some more data collection performance improvements, as well as improvements to the way JRobin reports look. If you are using JRobin, you can also extract the data from the individual files into an XML file for use outside of OpenNMS. Read the full release notes here.

Debian and Ubuntu packages are available from the OpenNMS Debian repo, and Solaris packages should be along soon.

New in OpenNMS 1.3.5

(OpenNMS 1.3.4 was released only for a short period of time, due to a few bugs that were deemed serious enough to abort the release.)

Invert Parameter Feature for Monitors

Support for inverting the result of a monitor was added. By adding the parameter "invert-status" to a monitor, up becomes down, and down becomes up. Useful for monitoring things, like an ISDN link, that indicate a problem when they are available. This was available for ICMP in 1.2.x, but it has now been ported to deal with all monitors.

Data Collection Performance Updates

Some major changes were made to the way OpenNMS data collection is started in order to use a smaller memory footprint and provide better performance.

Bug Fixes

The main reason for this release is a bug involving notifications.

  • The 1.3.3 severity matching code had a bug which would cause it to block notifications based on traps.
  • There was also a bug with packages with just <specific> tags (no include-range tags) passing all IP addresses thas has been addressed.
  • Due to the move toward database independence some code was introduced that caused notifications on events with a serviceid of null (such as those from traps) to fail. The original problem was misdiagnosed and the attempt to fix it, version 1.3.4, made the problem worse. It has been correctly resolved in this release.

New in OpenNMS 1.3.3

Dashboard

Okay, okay, OpenNMS isn't known for its super flashy Web 2.0 UI, but, with 1.3.2 OpenNMS was released with a purdy new facelift via a contribution from our community developers and serious look and feel help from an appreciative OpenNMS Group customer. Now in 1.3.3, we begin the trek to Web 2.0 with a new dashboard built on the Google Web Toolkit. See: Dashboard for more information on this new cool piece of technology added to OpenNMS.

Drools Correlation Engine

Cool, new distributed monitoring in OpenNMS 1.3.2! Oops, now what? Do I notify when one distributed monitor reports a service down while 29 others report the same service as up?

When you perceive an outage from a central location only, then it's a pretty easy decision whether a service is up or down: present an alarm, send a notification, etc. What do you do when you are monitoring a service from 30 locations and one monitor reports the service as down? Sure, this is interesting, but if other monitors in that location report the service is up, probably not an urgent issue for the application, server, or network admin teams. To address this issue, OpenNMS required that business logic could be added to the system to control behavior. Enter the Drools correlation engine and 2 new OpenNMS correlators: Widespread Outage Detection and Isolated Service Flapping Detection. See: Drools Correlation Engine for more information.

TopN Reporting

We believe that OpenNMS sports the fastest bestest SNMP data collector ever. It also sports a very flexible collector API such that other network communication protocols can be used for collection of performance data (currently JMX, NSClient, and HTTP data collectors have been implemented). This allows the metrics to be seamlessly used within the other OpenNMS management components (i.e. Thresholding, Reporting). The one component missing in OpenNMS was an automated process of reporting of the most utilized or underutilized corporate resources during a configurable period of time. Well, no longer! This feature is now available called TopN. See: TopN Reporting for more information about the great new feature (thanks djgregor!!!).

Trouble Ticketing API

The ability to integrate with other corporate enterprise applications is one of the key aspects that qualifies an NMS as an enterprise application, itself. Integration of an NMS's Alarm system with Trouble Ticketing is a natural extension and progression of an enterprise NMS. With this release, OpenNMS now sports a new seamless Trouble Ticketing API that allows users, help desk vendors and others (ISVs) to develop an OpenNMS plugin that provides integration with their Trouble Ticketing application and OpenNMS Alarms. The first implementation of this API is the CentricCRM Trouble Ticket Plugin. For more information about CentricCRM, see: CentricCRM]

Improved in OpenNMS 1.3.3

Thresholding

Relative Change Thresholds

Threshold Expressions

You can create thresholds in which the checked value is an expression. We use the JEP library, which provides basic mathematical expression support (all the common operators you'd expect). Expressions can include any "datasource" items (being values collected and stored by the Data Collector). Use the new "expression" element instead of "threshold", and you're away.

Custom Threshold UEIs

Sometimes "thresholdTriggered" and "thresholdRearmed" do not have sufficient granularity for easily configuring useful notifications. Thus, it is possible to give any threshold a custom UEI (event identifier) to send when the threshold is triggered, and another when it is re-armed. Both are independently optional (you can specify neither, one, or both), and if not specified, the threshold will default to the standard UEIs. If configuring manually via XML, then it is your responsibility to add appropriate UEI configuration to eventconf.xml. If you use the web-interface, new simple UEI configuration will be created for you in events/programmatic.events.xml. However, this may need further customization to be useful.

Threshold WebUI configurations

In the admin section there is a "Manage Thresholds" link. From that section you can add/edit/delete Basic Thresholds, and the new Expression-based Thresholds. If you have a custom UEI for the trigger or re-arm events, then you can quickly add notifications for those UEIs (the UEI names are links to a partially preconfigured Notification - fill in the remaining details and finish the notification wizard and you're done)

Notifications

Quick Add Event Notification