Introduction to opennms Architecture

I. Introduction to opennms

Opennms is developed based on the TMN and fcaps models.

Telecommunications Management Network (TMN) is a reference model proposed by ITU-T recommendation m.3000 in 1985 as an Operation Support System (OSS) held by telecom service providers. In terms of concept, TMN is a structure system that connects different types of OSS components and network elements. TMN also contains standardized interfaces and protocols for exchanging information between OSS components and network units and all functions required for network management.

The TMN model consists of the following four layers:

(1) Business Management Layer: implements business-related functions, analyzes development trends, such as quality issues, and provides basic accounting and other financial reports.

(2) Service management layer: implements network service processing functions: definition, management, and service control.

(3) network management layer: implements the network resource allocation function: configuration, control, and network supervision.

(4) Element Management Layer: contains the processing functions of individual network units. Namely, alarm management, information processing, file backup, log, hardware and software maintenance, etc.

Each layer of the TMN model corresponds to the following five functional areas (fcaps:

(1) fault management: Fault Identification, isolation, reporting and recording.

(2) billing management: Collects, caches, transfers and charges information.

(3) Performance management: Collect, buffer, transfer of running statistics related to network optimization, and capacity planning)

(4) Configuration Management: network device installation, status and parameter settings, and network capacity configuration.

(5) Security management: the authentication function management: OSS is used at the same time to prevent illegal user intrusion.

Opennms provides comprehensive fault management. In opennms, there are three different and independent methods for fault discovery:

(1) Regular Service Query (periodic service check)

(2) Receive automatically sent notification messages (such as SNMP Trap)

(3) performance data threshold check

Opennms also provides improved performance management. In opennms, it periodically Collects performance data through the data collection interface provided by the data collector, including SNMP, JMX, HTTP, and nsclient. The collected performance data can be used to display performance charts, threshold checks, and topn analysis.

 

For the remaining three items of fcaps, namely configuration management, billing management, and security management, opennms only implements some of its functions to some extent. For example, for the billing function, opennms only provides network usage data, system resources such as bandwidth, CPU, and disk space usage.

 

For configuration management, opennms provides Asset Management. In addition, you can enable/disable the device interface through the UI, or only use these functions.

 

For security management, SNMPv3 is supported, and user-based access control and LDAP security model are also provided.

 

According to the TMN layer-4 model, opennms mainly provides the service management layer (SM) and network management layer (Nm) functions.

 

Opennms concepts:

 

Interface: Any IP address specified to a network device that can respond to network requirements, or any IP address that claims to be an interface through the SNMP protocol.

 

Service: any single network service that is pre-defined to an interface.

 

Node: Any physical device that has more than one interface. A node may have several interfaces, and each interface may have several services. (whether a specific interface "belongs" to a node can be determined in several different ways, such as SNMP or NetBIOS name. however, if a specific interface does not belong to any node, it is represented as an independent node .)

 

Event: any major occurrence or discovery.

 

Outage: a temporary shutdown, characterized by failure to communicate with a monitored service (not polling)

 

Notice: when a specific event is generated, the system can issue an alarm. sending an alarm means notifying the user or a group of users by email, calling (pagers), or other means about the event. In some cases, the correction may be triggered.

 

Ii. opennms Architecture Design

 

Process description:

First, ping the network IP address range configured by the user for node discovery, corresponding to the discovery and ICMPD in the figure. When a new IP address is found (that is, the Ping is successful ), the event mechanism (corresponding to eventd) notifies capsd to perform a service scan to discover the services running on this IP address. After the service discovery is complete, poller starts to regularly check the services on these IP addresses. Once the service is found inaccessible, the fault information is generated through the event mechanism. For devices that support SNMP, SNMP periodically Collects performance data and stores the results in the RRD file for GUI display.

 

 

Opennms is a "user-centered" NMS. It takes a typical Network Administrator (or network management team) as its only focus to determine the required functions. Initially, some members of the team came from network management consultants who put their knowledge well into practice and defined their operational models around the objects, tasks, and workflows that a network administrator typically focuses on. This is in contrast to some commercial NMS products (these products are typically centered on devices, networks, or software services due to their vendor inheritance.

 

If you do not consider the specific application fields, code lineage, or vendor, many NMS products have similar concepts in hierarchical composition. Shows this common composition.

 

 

 

This component usually has three layers. The frontend layer is connected with the network of the managed devices and services, the users using the system, and external systems. The intermediate layer contains a large number of logics that provide various NMS features. The backend layer stores and operates data.

 

Due to the need to dynamically (but robust) Track Complex relationships and a large amount of information, NMs inevitably deploys a commercial relational database management system (RDBMS) at the backend layer ).

 

In the first layer, the monitoring, management, and control components usually contain many concurrent tasks that must be executed during NMS operations. The first layer is responsible for discovering active networks, polling services and devices for faults, and intercepting or processing asynchronous events from devices, services, or higher-level distributed proxies. This component can also perform operations driven by the configuration logic, supply logic, workflow actuator, or other custom logic in the NMS middle layer.

There are also user interface components at the front-end layer. NMS provides a "Fat Client GUI" interface and a web-based user interface that is easy to customize. The report tool resides at this layer. It can interact with the UI to provide real-time soft copy reports and hard copy reports in the form of batch processing.

 

The external interface component in the first layer can process notifications to users and/or external systems. This can take the form of paging, email, telephone, or specific events sent to the external management system. The API and extension plug-in infrastructure allows you to customize NMS, connect NMS with other systems, or integrate NMS with other systems.

 

The middle layer is where the NMS logic is located. It provides NMS with a set of personalized and distinctive features. It also provides some common features, such as inventory or asset management, data collection and analysis, user or role management, and workflow management/execution.

 

Inventory (or asset) management is the main function of most NMS products. However, the projects tracked vary with different NMS, such as devices, lines, servers, installed software services, and applications. The user interface and application logic of this component must be flexibly adapted to various items that may be managed.

 

The data collection and analysis feature provides current and historical statistics on the managed devices and services. It also provides statistical analysis to reveal the performance of networks and subnets and the availability of devices/services. This component can also interact with workflow execution logic to process custom workflows.

 

The user and role management components provide different levels of access to NMS. Most large networks are managed by one or more teams. Roles assigned to users can be used in the design and implementation of custom security policies, as well as in custom workflow and event upgrade flows.

 

Workflow management and execution are provided for the management and Automatic Execution of short-term and long-term management tasks. To adapt NMS to the needs of different organizations for various businesses, it is necessary to customize automated workflows.

 

Although not every NMS has all these components-and some may have other more specialized variants-the components mentioned here are sufficient to outline the NMS components.

 

 

The component diagram of opennms is displayed:

 

 

 

 

At the backend layer, opennms uses PostgreSQL as its RDBMS. On the frontend layer, it uses the free JSP and Servlet technologies of Apache Jakarta Tomcat to provide a flexible and customizable user interface. You can also use the previous Perl-based user interface. There are several management utilities written in Unix shell scripts and Perl. Opennms uses a set of Concurrent Java tasks corresponding to the monitoring, management, and control components to provide this function. These concurrent tasks are represented in circles.

 

Port used by opennms

Httpadaptor8180

RTC 5817

Jetty 8980

Jetty/HTTPS 8443

Jetty/AJP 8981

Syslogd 514 or 1514

SNMP Trap 162.

(Vulnscan 1241)

 

Iii. oennms concurrent tasks

The Monitoring, Control, and data collection features of opennms are handled by a group of concurrent tasks called daemon (bsd unix conventions. The following table lists the concurrent management tasks.

 

Concurrent tasks	Daemon name	Description
Operation daemon	Actiond	The automatic operation execution tool is used to automatically perform operations (workflows) based on inbound events ).
Collection daemon	CollectD	Collect data from managed nodes.
Function daemon	Capsd	Perform a function check on the detected nodes. It usually checks the port of an interface to see if it supports known service protocols.
DHCP daemon	DHCPD	Provides the DHCP Client function for opennms.
Daemon found	Discovery	Initial and continuous discovery of managed network nodes.
Event manager daemon	Eventd	Manage events from other concurrent tasks and store them to RDBMS
Notification daemon	Notifd	Execute external notifications to users.
Fault manager daemon	Outaged	Merge events to provide a continuous historical fault view for each managed node/service.
Poll daemon	Pollerd	Periodically polls managed nodes/services to determine the operation status.
RTC manager daemon	Rtcd	Collects data in real time to provide availability information for various managed nodes/services.
SNMP Trap daemon	Trapd	Handle SNMP Traps (events ).
Threshold service daemon	Threshd	Monitor managed nodes/services based on whether the property value reaches the specified threshold.

 

Iv. opennms Extension

Opennms provides robust SNMP support for managed devices/services. SNMP is a de facto standard for the industry to manage devices/services. This standard enables opennms to manage a large number of devices on TCP/IP networks.

In addition to SNMP, opennms can also detect and manage popular software services (such as FTP, file server, and database server ). It provides a set of service-specific plug-ins (for protocol scanning) and monitoring programs (for polling) to complete these tasks. By creating new plug-ins and monitoring programs, you can expand opennms to detect and monitor any new devices or services, including clickmeter applications that support JMX.

The opennms discovery daemon (discovery) is responsible for discovering the managed network during the initial and subsequent execution processes. Once the discovery discovers a node (usually through ICMP ping), it will ask the functional daemon (capsd) to determine what services the node supports. By cyclically processing the specified protocol plug-in set, this function daemon checks the supported services. Compile a custom protocol plug-in to make it suitable for any new opennms services.

 

V. opennms Database Design