The service assurance features of OpenNMS allow for the availability of network-based services to be determined. The provisioning process is asynchronous for scalability, and has been shown to provision networks of more than 50,000 discrete devices and to networks of single devices with over 200,000 virtual interfaces, each ( Juniper E320). The provisioning system contains adapters to integrate with other processes within the application and to external software, such as a Dynamic DNS server and RANCID. The underlying technology for this configuration is XML, so users can either use the web-based user interface or they can automate the process by scripting the creation of the XML configuration files. Devices can also be expressly added to the system. This process can occur automatically by submitting a list or range of IP addresses to the system (both IPv4 and IPv6). OpenNMS contains an advanced provisioning system for adding devices to the management system. OpenNMS has been shown to be able to process 125,000 syslog messages per minute, continuously. Įvents can generate notifications via e-mail, SMS, XMPP and custom notification methods. The software also contains an Event Translator where incoming events can be augmented with additional data (such as the impact to customers) and turned into new events. The Alarm subsystem can also integrate with a variety of trouble ticketing systems, such as Request Tracker, OTRS, Jira, Quickbase and Concursive. Alarms clear from the system over time, unlike events that persist as long as desired. Alarms can also generate events of their own, such as when an alarm is escalated in severity. While events represent a history of information from the network, alarms can be used to create correlation workflow (resolving "down" alarms when matching "up" alarms are created) and performing "event reduction" by representing multiple, identical events as a single alarm with a counter. In addition, OpenNMS can receive events in the form of SNMP Traps, syslog messages, TL/1 events or custom messages sent as XML to port 5817.Įvents can be configured to generate alarms. Processes within the software can publish events, and other processes can subscribe to them. OpenNMS is based around a " publish and subscribe" message bus. There are four main functional areas of OpenNMS.Įvent Management and Notifications While useful when first installed, the software was designed to be highly customizable to work in a wide variety of network environments. OpenNMS describes itself as a "network management application platform". In addition to Java, it requires the PostgreSQL database, although work is being done to make the application database independent by leveraging the Hibernate project. Precompiled binaries are available for most Linux distributions, Windows, Solaris and OS X. OpenNMS is written in Java, and thus can run on any platform with support for a Java SDK version 8 or higher. While many members of the OGP are also employees of The OpenNMS Group, it remains a separate organization. Shortly after that, The Order of the Green Polo (OGP) was founded to manage the OpenNMS Project itself. In September 2004, The OpenNMS Group was started by Balog, Matt Brozowski and David Hustace to provide a commercial services and support business around the project. Tarus Balog, then an Oculan employee, left the company to continue to focus on the project. In September 2002, Oculan decided to stop supporting the OpenNMS project. In July 2001, Atipa changed its name to Oculan. On September 28, 2000, PlatformWorks was acquired by Atipa, a Kansas City-based competitor to VA Linux Systems. ![]() It was registered as project 4141 on SourceForge in March 2000. The OpenNMS Project was started in July, 1999 by Steve Giles, Brian Weaver and Luke Rindfuss and their company PlatformWorks.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |