Planet OpenNMS

We're continuing our conversation with Alan Brown, who joined NantHealth as SVP and GM of OpenNMS in February 2024. In part two, he shared what he’s most excited to take on and the trends and challenges ahead for the industry. In this post, he’ll dive into evolving network monitoring technologies and where OpenNMS goes next.

In addition to leveraging and addressing AI/ML, I think the Nirvana state everyone is looking forward to is a true single pane of glass that delivers insights into how your end-to-end business infrastructure is performing. The network hardware, the software, and the security are all integrated so that an IT department that's already stretched thin has a single dashboard that shows the health of your systems and enables them to solve problems quickly.

The challenge is that network topologies are going to continue to complicate with expansion beyond corporate data centers to cloud computing, remote workers, and IoT, all pushing capabilities to the edge. For every vector that's pushing us to consolidate, there's an equal and opposite force pushing more complexity into the system. I think the challenge for these network monitoring companies will be picking the spot where they can add value. I don’t think OpenNMS will try to be all things to all people. Our focus will be building upon our extensible capability and solving customer problems.

In that sense, I think partnerships will be very important to us. Our customers want to hear that we're already working with vendors they have in their tech stack, and we can integrate with them easily without immediately forcing them to play parent to two fighting children. That's a nightmare nobody wants.

There's a lot of energy going into new network protocol open standards and getting into these streaming telemetries. The whole idea is to give more power to our customers so they can gather best-of-breed solutions from different products and integrate without having to unnecessarily commit to one company that gives you an A plus product in one regard and bundles in C Minus products everywhere else.

Customers want A Plus solutions for all functions and want them to integrate easily and play nice out of the box. Showing that we are living and breathing those open standards is critical.

I'm really excited about deepening our customer focus and leveraging our incredible tech base to solve our customers' pressing problems. We don't have to reinvent the widget and then go sell it. We have a unique and powerful tech base that's incredibly extensible, and there's real opportunity to grow the business by solving actual problems that no one else can solve for our customers. We don't want to be everything to everybody, but we want to solve mission-critical issues that translate across every one of our clients.

In a highly competitive and segmented space with a lot of players, it’s not just tech that will win. Our customer-driven strategy to deliver complete solutions, built on our trusted and extensible tech platform, that solve real customer pain points and deliver relevant customer value will be what takes this company to the next level.

My two key measures are intertwined: customer satisfaction and employee fulfillment. We want to make sure we’re meeting our mission of tackling our customers’ challenges and adapting to their roadmap feedback and requests. And in the tech industry, our most important resource, and means through which we achieve our goals, is our people. At the end of the day, we don't have a big factory with overhead cranes and conveyor belts. We have people developing solutions. We want to make sure we’re meeting their career expectations at NantHealth and OpenNMS. For us, employee fulfillment and customer satisfaction are really the two most important indicators of success.

We appreciate Alan taking the time to share his thoughts about where OpenNMS is today and the bright future ahead. Please feel free to reach out if you have any questions for him, feedback about the company or the solution, or just want to share your views on the industry.

We’re continuing our conversation with Alan Brown, who joined NantHealth as SVP and GM of OpenNMS in February 2024. In part one, we covered his background, what brought him to OpenNMS, and his leadership philosophy. In this post, he’ll share what he’s most excited to take on and where he sees the industry going.

We're clearly at a transition point where the business model that served this company so well and allowed it to prosper over its 20-year history needs to evolve.

That brings its own set of exciting challenges. The one thing I want folks on the outside to know is that we are reinvigorated. Our parent company, NantHealth, has been recapitalized. We're moving forward, we're investing in the future, we’re refreshing our roadmaps. We're building new capabilities in our products to address our customers’ pain points. We're not sitting down. We're on our feet; we're moving forward.

What is amazing is that our previous business model fostered this incredible diversity of customers because it was very much a relationship-driven business. It started with a small open-source capability that attracted a complete ecosystem and community around it where people engaged either by writing code or sharing their ideas.

Fortune 500, even Fortune 5 companies, use our product as well as people who are servicing just 15 nodes. That's an incredible diversity for technology to be viable across that entire range. The challenge is how to build a different flavor of business on top of that customer landscape and make sure that we're addressing pain points in a way that really provides value. So that's what the team's working on.

With any business, customer focus is a key tenet so one of the initiatives we're most excited about is the virtual customer road shows we’re planning. We’ll get feedback on our roadmaps directly from our customers and ensure we are well aligned to address their business pain points.

I’ve learned that if you stay customer focused, your business will thrive. I think the technology will be there, but I'd like to see us really understand our customers and let that drive the tech we build and offer.

Following on that we’re excited about the development plans, both for our existing product line and for our cloud-based solution. We will be investing heavily in our current core capability to ensure it continues to appeal to our client base, solve their problems, and deliver greater business value, which will translate into what we're building for the cloud.

In addition to our core capabilities, we'll be focusing on the healthcare vertical. Being a part of NantHealth, a company that builds innovative technology to simplify healthcare and deliver better patient outcomes, we have a well of unique, built-in intelligence that we can leverage to alleviate pain points for customers in that space.

The elephant in the room is artificial intelligence/ machine learning. Everyone is trying to figure out how to take advantage of these capabilities and how to use them in a way that really offers value. Everyone's trying to separate reality from the hype.

One of the ideas that stuck with me from my strategy MBA is we tend to overestimate the impact of change in the short term and underestimate it in the long term. I think this will be the case for AI and ML. So, if we focus on the customer pain points and what's real value versus what is technology for technology's sake, then I think we'll be in the right place.

OpenNMS has tried some proof-of-concept activities to dip your toes in the water, and we learned a lot. We're taking what we learned and revitalizing our AI/ML roadmap. And a key part of our conversation with our customers will be how we see the world moving forward in bringing this intelligence to monitoring. Can we build the type of intelligence into the software that replicates that 20 years of IT experience an IT expert has so he can focus on fixing the problem rather than having to diagnose what is causing it?

The whole idea is to automate the mundane so that IT professionals can truly provide their expertise in a way that really focuses on the direst of issues. Unfortunately, we’ve already seen evidence that some of these large language models can be led astray. We’ll only be able to offload the mundane when we trust that these models can provide reliable advice and can be trusted to handle the responsibility.

There will continue to be a lot of hype around this, so OpenNMS will be careful not to be one of the companies that over-promises and under-delivers.

AI/ML represents a transition point, not only in network monitoring but also in the core capabilities vendors offer. As AI/ML comes into the customers’ business and changes their network, it will also change their pain points, which may leave some vendors behind if they can’t make that transition. I think it's going to be very interesting to observe how all the disparate solution providers are able or not able to take their tech baseline and apply it to the future.

I’m excited about this for OpenNMS because one of our biggest strengths is we have a highly extensible platform approach to our solution. We don't have a product; we have a platform that can be used for a Fortune 5 company as well as Joe’s managed services out of Luling, Texas. Our bet is that having a solution that can be used in a wide variety of environments gives us the broadest opportunity to push forward versus a product that's been limited to a very narrow niche space of just one particular customer type or one particular technology.

Check back for part 3 where we explore Alan’s view of the evolving network monitoring technologies and where OpenNMS goes next.

Alan Brown joined NantHealth as SVP and GM of OpenNMS in February 2024. Now that he’s fully immersed, we took a few minutes to sit down to get to know him better and understand his vision for OpenNMS.

I started messing around with computers in the seventies, and I might be one of the few people left actively working who originally programmed in IBM punch cards. It used to be hilarious to knock 'em out of people's hands and watch 'em all go fluttering. And then you've gotta restack your cards up. That was “nerd fun” back in the day.

From there, I earned my degree in electrical engineering and came out of school right about the time the IBM PC just started to propagate, which really kind of kicked off the whole PC revolution. Just seeing how these computers have morphed into modern wireless networks that have really changed the world is awe-inspiring. Now we're all addicted to scrolling on our phones because a bunch of nerd engineers figured out how to get cell towers all working together to stream data.

I’ve spent a lot of time in aerospace and telecom, and I’ve also seen lots of different business cases. I've seen small startups, I've been part of big corporations, I've been part of the business cycle when it's booming, and I've been part of business cycles when it's in reduction mode. When you've been around long enough, it helps center you for an opportunity like OpenNMS.

We’re taking on a real challenge. There isn't anyone that I've talked to who feels that what we're trying to do is going to be easy. We have a real opportunity to excel, which is what my old boss would say. There’s a line I like from A League of Their Own: Someone says to the coach that it just got too hard. The coach says, “It's supposed to be hard. If it wasn't hard, everyone would do it. The hard...is what makes it great."

Those are the thoughts ringing around in my head when I think about our opportunity and my confidence in taking this on.

Another very important aspect that drew me in is that I believe we have high-integrity leadership at NantHealth. Through previous work I had a connection with both Lauren Schiegg, our COO, and with Dr. Haris Naseem, our new CEO. If you're going take on the challenge of trying to take a business to the next level, I think the most important thing is the people you get to work with and the leadership you're involved with. You get to a certain point in your life where the people are the most important part of getting up every morning. When they called to ask if I would join and help, it was really appealing to join such a strong team that I respect.

And I have a long legacy of building teams — that’s really my happy place. A chance to lead a team that's been through ups and downs like OpenNMS and help them get to the next level, both as a team and individually, is a calling that I respond to.

And finally, the business challenge of taking a 20-year technical legacy to the next stage is exciting. There are very few products that last that long in this space. Microsoft, Apple, and only a few others have been around that amount of time. For the tech that the OpenNMS team built to still be viable and valuable is a truly amazing thing. The trick is to honor that legacy and then move it into the next phase of the business.

I have seen in person the value of teamwork to really make breakthroughs. And to take advantage of the gifts that people bring to the team by weaving them in a way that weaknesses are identified but compensated for. Someone might be strong in one thing but weak in another. But if they can find a partner that has that strength, they'll be a lot stronger together. I've also seen failures with a bunch of A players who are incredibly smart and incredibly capable, but it's like having a Ferrari engine with no transmission. If you don't have any way of getting the work put into place, all you have is just this great big heat source that consumes a lot of fuel and does no work.

The game is to try and build a team with all those capabilities in place and look for where you need to adjust. In Good to Great by Jim Collins, there's a concept of getting the right people on the bus, but even more importantly, getting those people into the right seats on the bus. I personally have seen somebody who was in the wrong seat, really not making the impact that they wanted to make, get frustrated, and it starts to take a toll on them and the team. Sometimes, just changing the seat makes all the difference. As the team leader, it's your responsibility to move people around and give them a different role, a different opportunity. I've seen that work.

Being part of a team is also just a lot more fun. The job becomes not about the boss or even the financial rewards. You find yourself going above and beyond work because you feel like you owe it to your buddies on the team, right? And that's where real commitment comes into play, and that's where the work becomes a calling rather than just a job, which is where the fun is.

Stay tuned for part 2, where we’ll dig into Alan’s thoughts on OpenNMS so far and what he’s most excited to take on.

Keith Krebs is appointed as the Senior Vice President and General Manager for the Eviti Connect product line, bringing a wealth of experience in driving innovation and customer satisfaction. With a remarkable track record in leadership roles spanning implementations, client services and product development, Krebs is poised to lead the charge in leveraging artificial intelligence and automation to enhance the Eviti platform's capabilities.

Sean Henson assumes the role of Senior Vice President and General Manager for NaviNet, a leading payer-provider collaboration platform, facilitating provider engagement and generating actionable data throughout the continuum of care delivery. With over a decade of expertise in value-based care performance and analytics, Henson is committed to leveraging advanced technologies to optimize patient care quality and cost-effectiveness within the NaviNet platform.

Alan Brown joins NantHealth as the Senior Vice President and General Manager of the OpenNMS product line, responsible for overseeing the world's first full open-source enterprise-grade network service monitoring. With over 30 years of experience in Aerospace & Defense and Telecommunication industries, Brown is dedicated to driving innovation and efficiency through strategic business vision and results-driven tactical execution.

NantHealth's recent appointments emphasize the company's strategic commitment to integrating innovation, automation, and artificial intelligence into its product development process. With a leadership team that possesses a deep understanding of industry dynamics and a strong drive to effect positive change, NantHealth is well-positioned to consistently deliver cutting-edge products and services that cater to the evolving needs of its customers.

"We are excited to welcome Keith, Sean, and Alan to our leadership team," said Lauren Schiegg, Chief Operating Officer at NantHealth. "Their extensive experience and visionary leadership will play a crucial role in accelerating our efforts to innovate and drive positive transformation in the healthcare technology landscape. Together, we are committed to delivering unparalleled value to our customers and revolutionizing healthcare for the better."

About NantHealth, Inc.

NantHealth, a member of the NantWorks ecosystem of companies, provides enterprise solutions that help businesses transform complex data into actionable insights. By offering efficient ways to move, interpret and visualize complex and highly sensitive information, NantHealth enables customers in healthcare, life sciences, logistics, telecommunications and other industries to automate, understand and act on data while keeping it secure and scalable. NantHealth’s product portfolio comprises the latest technology in payer-provider collaboration platforms for real-time coverage, decision support and data solutions that provide multi-data analysis, reporting and professional services offerings. For more information, visit nanthealth.com, follow us on Twitter, Facebook, LinkedIn and YouTube and subscribe to our blog.

Forward Looking Statements

This news release contains certain statements of a forward-looking nature relating to future events or future business performance. Forward-looking statements can be identified by the words "expects," "anticipates," "believes," "intends," "estimates," "plans," "will," "outlook" and similar expressions. Forward-looking statements are based on management’s current plans, estimates, assumptions and projections, and speak only as of the date they are made. Risks and uncertainties include, but are not limited to, statements regarding the timing and effectiveness of the reverse stock split and the Company’s ability to maintain its listing on Nasdaq (including its ability to achieve or maintain the minimum bid price required by Nasdaq and to comply with other requirements for listing on Nasdaq). Such forward-looking statements are not meant to predict or guarantee actual results, performance, events or circumstances and may not be realized because they are based upon the Company’s current plans, objectives, beliefs, expectations, and assumptions and are subject to a number of risks and uncertainties and other influences, many of which the Company has no control over. Actual results and the timing of certain events and circumstances may differ materially from those described by the forward-looking statements as a result of these risks and uncertainties. Factors that may influence or contribute to the inaccuracy of the forward-looking statements or cause actual results to differ materially from expected or desired results may include, without limitation, the price and volume fluctuations in trading of the Company’s Common Stock, the potential adverse effect of the reduced number of shares outstanding following the reverse stock split on the liquidity of the Company’s Common Stock, potentially adverse Nasdaq decisions related to the listing of the Company’s Common Stock on the Nasdaq Capital Market. The Company undertakes no obligation to update any forward-looking statement in light of new information or future events, except as otherwise required by law. Forward-looking statements involve inherent risks and uncertainties, most of which are difficult to predict and are generally beyond our control. Actual results or outcomes may differ materially from those implied by the forward-looking statements as a result of the impact of a number of factors, many of which are discussed in more detail in our reports filed with the Securities and Exchange Commission.

Contacts

Jen Hodson

NantWorks

562-397-3639

jen@nant.com

In the dynamic landscape of network management, NetFlow traffic analyzers stand out as indispensable tools for optimizing network performance and ensuring robust security. This comprehensive guide delves into the intricacies of NetFlow technology, its manifold benefits, essential features, and practical tips for selecting and implementing the right NetFlow analyzer for your organization.

NetFlow traffic analyzers have evolved significantly since their inception in the mid-1990s. Originally developed by Cisco Systems, NetFlow technology was introduced as a means to gather network traffic statistics for capacity planning, billing, and security analysis. The early versions of NetFlow provided basic information about traffic flows, such as source and destination IP addresses, port numbers, and packet counts. Over time, NetFlow analyzers became essential tools for network administrators, enabling them to gain insights into network traffic patterns and troubleshoot performance issues.

As network environments became more complex and the volume of network traffic increased, the need for more advanced NetFlow analyzers grew. Modern NetFlow analyzers offer a wide range of features, including real-time monitoring, historical data analysis, customizable reporting, and integration with other network management tools. These advanced capabilities have made NetFlow analyzers indispensable for organizations seeking to optimize network performance, enhance security, and comply with regulatory requirements.

NetFlow analyzers offer a myriad of benefits to organizations looking to enhance their network monitoring and security capabilities. One key advantage is improved network visibility, as NetFlow analyzers provide detailed insights into traffic patterns, allowing administrators to identify bandwidth bottlenecks, monitor application usage, and optimize network performance.

Additionally, NetFlow analyzers can play a crucial role in security monitoring by detecting and mitigating potential security threats, such as DDoS attacks and malware infections, through the analysis of traffic anomalies and suspicious patterns. Furthermore, NetFlow analyzers facilitate efficient capacity planning by analyzing historical traffic data and forecasting future bandwidth requirements, enabling organizations to allocate resources more effectively.

Overall, NetFlow analyzers empower organizations with the tools to proactively manage their networks, enhance security posture, and ensure optimal performance.

• Enhanced Network Visibility: NetFlow analyzers offer a holistic view of network traffic, helping identify congestion points, bandwidth hogs, and potential security threats.
• Efficient Security Monitoring: NetFlow analyzers play a pivotal role in detecting and mitigating security incidents, such as DDoS attacks and malware infections, by spotting anomalous traffic patterns and unauthorized access attempts.
• Comprehensive Traffic Analysis: By scrutinizing NetFlow data, administrators can gain insights into traffic patterns, application usage, and user behavior, facilitating informed decision-making.

NetFlow analyzers offer a range of key features that empower organizations to gain deep insights into their network traffic and enhance overall network management.

Additionally, many NetFlow traffic analyzers offer advanced features such as anomaly detection, which can help identify and mitigate potential security threats, as well as integration with other network management tools, allowing for a more comprehensive and streamlined approach to network monitoring and management.

By carefully considering these factors and conducting thorough research, you can select a NetFlow analyzer that meets your organization's needs and helps you achieve your network monitoring and security goals.

Implementing a NetFlow analyzer requires careful planning and execution to ensure optimal performance and effectiveness. Follow these best practices to maximize the benefits of your NetFlow analyzer deployment:

1) Device Configuration

Configure all network devices, such as routers and switches, to export NetFlow data. Ensure the devices are configured to export the necessary information, such as source and destination IP addresses, ports, and protocols.

Regularly review and update the NetFlow configuration on your devices to align with changing network requirements and to ensure that you are capturing the right data.

2) Data Collection and Storage

Determine the appropriate sampling rate and retention period for your NetFlow data based on your organization's needs and network traffic volume. Consider factors such as data storage capacity and data analysis requirements.

Implement data compression and aggregation techniques to reduce the volume of NetFlow data while preserving its integrity and accuracy.

3) Network Segmentation

Segment your network into logical units, such as departments or locations, to facilitate more granular analysis of NetFlow data. This can help you identify traffic patterns and potential issues specific to each segment.

Use VLANs (Virtual Local Area Networks) and subnetting to isolate traffic and simplify NetFlow analysis for each segment.

4) Security Considerations

Ensure that the exported NetFlow data is secure and cannot be intercepted or tampered with by unauthorized users. Use encryption and secure protocols, such as IPsec or SSL/TLS, to protect the data in transit.

Implement access controls and authentication mechanisms to restrict access to the NetFlow data and the NetFlow analyzer itself, ensuring that only authorized personnel can view or manipulate the data.

5) Integration with Other Tools

Integrate the NetFlow analyzer with other network management tools, such as SIEM (Security Information and Event Management) systems, firewalls, and intrusion detection/prevention systems, to enhance your overall network monitoring and security capabilities.

Ensure that the NetFlow analyzer seamlessly integrates with your existing tools and workflows to minimize disruption and maximize efficiency.

6) Regular Monitoring and Maintenance

Monitor your NetFlow analyzer's performance regularly to ensure that it is operating efficiently and effectively. Use the monitoring data to identify and address any issues or bottlenecks.

Perform regular maintenance tasks, such as software updates and database optimizations, to keep your NetFlow analyzer running smoothly and to ensure that it can meet your organization's evolving needs.

By following these best practices, you can implement and maintain a NetFlow analyzer that provides valuable insights into your network traffic and helps optimize your network performance and security.

Expect to see NetFlow technology continue to evolve with emerging trends including support for new protocols like streaming telemetry, deeper analytics capabilities, and seamless integration with cloud-based services, paving the way for more agile and responsive network management solutions.

NetFlow analyzers are indispensable tools for modern network management, offering unparalleled visibility and control over network traffic. By harnessing the power of NetFlow technology, organizations can optimize network performance, bolster security, and stay ahead in today's dynamic business environment. Learn more about leveraging OpenNMS Meridian as your NetFlow analyzer.

We hope this blog has raised your interest in learning more about NetFlow.

See our NetFlow Traffic Analyzer solution page to learn why utilizing OpenNMS Meridian might be the best choice for your organization.

In this blog post, I’ll cover how OpenNMS Meridian can leverage SNMP network monitoring. SNMP or the Simple Network Management Protocol works as a client-server model where clients or agents provide information back to a central management server, Meridian, in our case. The management server can query specific information and events from the agents.

By default, Meridian collects information from SNMP devices of Report 161 and uses a read community string of “public.” As a best practice, though, community strings should be changed to something unique on your network devices. Meridian provides support for SNMP versions 1, 2c, and 3.

SNMP is a protocol for collecting, managing, and organizing information for network devices. It's a common standard for network monitoring. SNMP can help network administrators identify overloaded network connections and get alerts on hardware status, temperature, and potential failures.

Imagine you're a network administrator for a regional internet service provider, and you've got a group of customers who are complaining about intermittent service. It's possible to use SNMP data and Meridian to find out which connections are problematic. SNMP can also be used with servers to get information on resource usage, such as disk consumption and memory utilization. It is also used in data centers to get information from power supplies, AC units, and many other systems.

SNMP has five major components:

• Managers (command generator)
• Agents (command responder)
• MIBs (management information base)
• Commands
• Traps

It might be useful to think about SNMP by imagining you're the coach or manager of a sports team. The SNMP manager, that's you. You're responsible for managing and monitoring the team's performance and making changes when necessary. SNMP agents are the individual players on your team. Each player or agent provides specific information about their performance to you, the manager, when requested.

You can think of MIB, or the management information base, as a playbook or record that helps maintain information about the players. It contains information like positions, stats, and potential actions the players might take in the game.

SNMP commands are like the instructions or requests you give to the players during the game. For instance, if you want to know how many goals a specific player has scored, you ask for that information. SNMP traps are like unsolicited updates from players during the game. For example, if a player gets injured, they notify you immediately so that you can make substitutions or adjust your strategy accordingly. For SNMP v3, the terms manager and agent change to command generator and command responder.

By default, OpenNMS Meridian will discover and begin collecting SNMP network data from managed nodes using the default community string "public" and Port 161. Meridian collects data every five minutes and stores it in RRD files. The collection interval can be changed to enable faster or slower collection. The data can also be stored in a time series database, which we'll explore later.

The collectd or collection daemon within OpenNMS is responsible for collecting SNMP network data. Though we often refer to SNMP polling, collectd collects information and stores it within the RRDs. Pollerd or the poller daemon is used for service assurance and verifies the SNMP service is running on monitored devices.

Meridian can collect things like bits in and out, discards or errors, link quality (particularly useful for fiber optic links), system temperature, memory usage, storage space, and more, depending on what the device provides.

In addition to collecting data from SNMP devices, Meridian can also collect SNMP traps. Traps are events sent from devices with SNMP to a collector or a server, and Meridian can process them as events. The event definitions that Meridian uses come from the MIBs provided to it.

Events are structured historical records of things that happen in Meridian, along with the nodes, interfaces, and services it monitors. They are central to the operation of Meridian, and it's safe to assume that whenever something in Meridian appears to be working by magic, it's probably events working in the background. You can use events to send notifications, trigger automation, and translated into other events.

Performance data in Meridian can be stored using time series databases. By default, Meridian uses RRD files to store collected data. For small to medium-sized customers and users just looking to kick the tires, RRDs are a great option. They're incredibly performant, take up little disc space, and work out of the box.

If users want to set up their own time series database, we provide a component for Apache Cassandra called Newts that can be leveraged. This requires installing and maintaining an Apache Cassandra cluster. We also provide community support for Cortex and compatible derivatives, such as Prometheus and Thanos.

Meridian overcomes the challenges of collecting large amounts of SNMP data by distributing collection across minions. Minions are lightweight, stateless services that add monitoring capacitance and reduce the load on the Meridian core. By enabling horizontal scaling of collection, minions can be deployed as virtual machines, containers, or even physical servers. Minions can also enable collection from overlapping subnets.

We've covered the insight and intelligence that can be gained by using OpenNMS Meridian with SNMP network monitoring. However, OpenNMS Meridian goes beyond just flows and SNMP. It can ingest telemetry, syslog data, WMI, JDBC, JMX, and much more. OpenNMS Meridian is the ideal platform to provide holistic insight into your network.

If you just want to try it yourself, look at OpenNMS Horizon, our open-source, community-supported edition, where we constantly add product enhancements before they reach stability in our enterprise-grade product, Meridian.

OpenNMS Meridian is a powerful enterprise network monitoring solution, thanks in part to its flexibility and ability to connect to and monitor a wide range of network devices through network flow data. By providing comprehensive insights into device status, traffic patterns and performance metrics, Meridian empowers your organization to make data-driven decisions.

The platform’s ability to conduct detailed health checks on network devices and generate customized alerts ensures prompt issue resolution and minimal downtime. And its advanced analytics capabilities enable anomaly detection, safeguarding networks against security threats like DDoS attacks.

This blog digs into the concepts of network flow data and how OpenNMS Meridian ingests and integrates it to deliver a robust network monitoring solution.

OpenNMS Meridian is not just a monitoring tool, but a strategic asset for enterprise, ensuring networks are not only healthy and secure but also well-prepared for future growth and challenges.

Network flow data is a way to collect the meta information of a packet entering or leaving a network device. OpenNMS can leverage that metadata with the help of analytics to provide insight on sources, destinations, types of traffic, and the quality of service.

You can think of flow data like airport departure and arrival logs. Consider a network as an airport where data packets are like departing and arriving flights. Flows can be likened to the departure and arrival logs that track various details of each flight, such as the airline flight number, departure, city arrival, city passenger count, and flight duration.

Network engineers face many challenges. It can be difficult to diagnose performance issues, especially in real-time, as users encounter them. A network engineer must look at many aspects of the potential issue. Is this an application issue, or is it the user's device, or could it actually be something on the network?

Even when it has been determined to be an issue with the network, an admin will typically go through a list of questions before they can even begin the troubleshooting process:

• When did the issue start?
• Is the issue constant or intermittent?
• Is the device on the enterprise network or someone's home network?
• Is the issue related to all applications or just a particular one?
• Is there a particular part of the application that is slower, or are there other users experiencing similar issues with that application?

Network elements for data flows consist of exporters, devices like routers, switches, and firewalls; collectors, in our case OpenNMS Meridian; and management and analytics applications, also OpenNMS Meridian. It's useful to understand that while flows are often exported from networking equipment like routers and switches, flow data can also come directly from servers, and they can export telemetry data through the sFlow protocol.

OpenNMS is a collector for data flows. It leverages something called telemetryd or the telemetry daemon to ingest flow information from exporters. The telemetry daemon provides a framework to handle sensor data pushed to Meridian. The framework supports applications that use different protocols to transfer metrics. By default, we use a single port listener, which works for many flow protocols like jFlow, sFlow, and several versions of NetFlow, including IPFIX. With telemetryd, operators can define listeners supporting different protocols to receive the telemetry data and adapters transferring the received data into generic formats like flows or performance data.

OpenNMS stores flow records into Elasticsearch using an OpenNMS-created plugin that installs into your Elasticsearch cluster. You can set up persistence policy for Elasticsearch to only keep flow records for a specific period of time. OpenNMS enriches flow records by using information it already has about systems and its inventory. It tags data flows and groups them based on rules. OpenNMS can leverage node data and the metadata associated with nodes like categories to enrich flow records. This enrichment adds context to speed time to resolution when troubleshooting and can enhance forensic network analysis.

OpenNMS uses a classification engine that applies rules to filter and classify flows. The flow classification engine bundled with Meridian is adapted from IANA standards and includes a predefined set of rules that define more than 6,200 applications for basic communication protocols. You can classify flows by a combination of parameters, including source and destination, port source and destination address IP protocol, and exporter.

Conversations can be identified based on classified flow traffic between a set of hosts, information about quality of service provided by DSCP (Differentiated Services Code Point), and OpenNMS can enrich information about the specific host involved in a flow. Classifications help you determine how flows are associated with a particular appliance service or other component and how they affect your network.

For example, Bitcoin traffic on Port A 333 or all flows to Port AD marked as HTTP. Meridian allows for customized rules to classify flows. A rule includes a name for the classification or application and additional parameters such as source and destination ports and addresses that must match.

OpenNMS overcomes the challenge of collecting large amounts of flow data by distributing collection across Minions. Minions are a lightweight stateless service used to add capacity and reduce the load on Meridian core. By enabling horizontal scaling of collection, minions can be deployed as virtual machines, containers, hardware appliances, or physical servers.

Meridian overcomes the challenges of enriching large amounts of flow data by distributing processing workload through sentinels. Sentinels are purpose-built modules that allow Meridian to scale flow enrichment horizontally by transparently offloading work and placing enriched flow records directly into Elasticsearch. Sentinels can be installed on containers, virtual machines, or physical hardware and have requirements similar to Meridian.

OpenNMS can scale to your network size needs. Some of our customers ingest and enrich over 350,000 flows per second.

In summary, Meridian can ingest many types of flow and telemetry data. With the analytics Meridian provides for sources, destinations, types of traffic, and the quality of service, it's possible to gain holistic insight into your network. Using the powerful Meridian flow enrichment capabilities, you can quickly pinpoint the sources of networking issues and reduce time to resolution. OpenNMs Meridian can be deployed on a single host and can scale with your needs by using Minions and sentinels to enable collecting and enriching large amounts of data.

If you have a complex or demanding use case for flows, then get in touch. We're here to help.

In today's hyper-connected world, where billions of users interact with websites, applications, and services every second, network monitoring solutions are critical to ensuring your network operations stay consistent and reliable. When deployed effectively, they provide continuous surveillance of your network traffic, performance, and security, allowing your team to proactively identify potential trouble spots and address issues, from slow loading times to security threats, before they disrupt services.

With the right network monitoring solution in place, you can not only enhance the performance and security of your networks but also deliver a reliable and seamless internet experience for your users.

Network monitoring solutions give administrators real-time visibility into network activity, enabling them to detect and respond to anomalies promptly. By monitoring for unusual patterns or suspicious activity, network monitoring solutions can help prevent cyber-attacks such as malware infections, DDoS attacks, and data breaches, which can cripple an organization's online presence and reputation.

Network monitoring solutions can also help you optimize network performance by targeting and mitigating bottlenecks and congestion points. Network administrators can ensure that resources are allocated efficiently, preventing slowdowns and traffic blockages that can impede user experience.

Network monitoring solutions should include various features to empower network administrators to monitor and maintain their networks more efficiently.

Network Traffic Monitoring: Track the flow of data within a network, capturing information about the volume, sources, and destinations of traffic. This helps identify normal behavior patterns and anomalies that may indicate network issues or security threats. Administrators can detect and resolve issues such as bandwidth congestion, network bottlenecks, and unauthorized access attempts.

Performance Monitoring: Performance monitoring involves tracking the performance of network devices, servers, and applications to confirm they are operating efficiently. This includes monitoring metrics such as response times, packet loss, and resource utilization. This helps identify and address issues that can impact user experience, such as slow application performance, network latency, and server downtime. Administrators can optimize network resources, improve reliability, and enhance overall user satisfaction.

Security Monitoring: Security monitoring involves detecting and responding to security threats within the network. This includes monitoring for malware infections, unauthorized access attempts, and data breaches. Techniques include intrusion detection systems (IDS), intrusion prevention systems (IPS), and log analysis to identify and mitigate security threats. Administrators are empowered to protect sensitive data, maintain regulatory compliance, and prevent costly security breaches.

Alerting and Reporting: Alerting and reporting features notify administrators of critical events or issues within the network and provide detailed reports on network performance and security. Alerts can notify administrators via email, SMS, or other means when predefined thresholds are exceeded, or anomalies are detected. Reports provide valuable insights into network performance trends, security incidents, and service level agreements (SLAs) compliance. Timely alerts and reports enable administrators to respond quickly to issues, track network performance, and make informed network management and optimization decisions.

Configuration Management: Configuration management features help ensure network devices are optimized for performance and security. This includes managing device configurations, applying configuration changes, and auditing configurations for compliance with best practices and security policies. Configuration management helps reduce the risk of misconfigurations that can lead to network downtime, security vulnerabilities, and performance issues.

Scalability and Flexibility: Network monitoring solutions should accommodate the size and complexity of your network. This includes the ability to monitor a large number of devices and network segments, as well as the ability to integrate with other systems and tools. Administrators can adapt the monitoring environment to meet changing network requirements and integrate with existing network infrastructure and management tools. Monitoring capabilities should grow with the network and meet its evolving needs.

Network monitoring solutions must collect and process tens of thousands of data points per second from a variety of network devices. And networks are not static: the volume of data to be processed increases as your network expands. This changes with fluctuations in network traffic, peak hours, and other factors. Network monitoring solutions that can scale dynamically to collect and process large volumes of data help administrators respond to the most current issues promptly.

These are just some example data sources:

Traffic Data: Network traffic, including the volume of traffic, the types of traffic (e.g., web traffic, email traffic), and the sources and destinations of traffic, lets administrators monitor network performance, detect anomalies, and identify potential security threats.

Performance Metrics: Performance metrics such as CPU usage, memory usage, disk I/O, and network bandwidth from network devices, including routers, switches, and servers, so administrators can monitor the health and performance of network devices and identify and resolve performance issues.

Configuration Data: Configuration data from network devices such as routers and switches help administrators ensure that network devices are properly configured for optimal performance and security.

Event Logs: Event logs from network devices, such as syslog messages, provide information about events and activities on network devices, such as configuration changes, security incidents, and system errors. Event logs help administrators troubleshoot issues, monitor network activity, and detect security threats.

Security Data: Firewall logs and intrusion detection/prevention system (IDS/IPS) alerts help administrators monitor network security, detect and respond to threats, and ensure that security policies are enforced.

User Activity Data: User login/logout events and application usage help administrators monitor user behavior, track user activity, and detect unauthorized access attempts.

Application Performance Data: Some network monitoring solutions can collect data on application performance, such as response times, transaction times, and error rates. This data helps administrators monitor the performance of critical applications and identify and resolve issues that may impact application performance.

Virtualized Environment Data: Data from virtualized environments, such as hypervisors and virtual machines, helps administrators monitor the performance and health of virtualized resources and ensure they’re operating efficiently.

Cloud Services Data: Data from cloud service providers, such as performance metrics, usage data, and security logs, help administrators monitor the performance, efficiency, and security of cloud services.

Quality of Service (QoS) Data: Network monitoring solutions may collect data on Quality of Service (QoS) metrics, such as latency, jitter, and packet loss, to ensure that QoS requirements are being met.

Network Topology Data: Network monitoring solutions may collect data on network topology, including the physical layout of network devices and the connections between devices. This data helps administrators visualize the network layout, identify future bottlenecks or single points of failure, and optimize network performance.

Network monitoring solutions typically consist of several key components that work together to enable network admins to monitor and manage their networks. The exact components may be different depending on the solution and its capabilities as well as the specific needs of the organization, but some common components include:

Data Collection Agents: These agents are installed on network devices to collect data such as performance metrics, traffic data, and event logs. Agents may be software-based or hardware-based, depending on the device and the monitoring solution.

Data Collection and Storage: Network monitoring solutions collect and store data from data collection agents. This data includes performance metrics, traffic data, event logs, and other relevant information. The data is typically stored in a database or data repository for analysis and reporting.

Data Analysis and Processing: Network monitoring solutions analyze and process the collected data to generate reports, alerts, and visualizations. This may involve applying algorithms and statistical analysis to the data to identify patterns, anomalies, and trends.

Alerting and Notification: Network monitoring solutions provide alerting and notification capabilities to alert administrators of critical events or issues. Alerts can notify administrators via email, SMS, or other means when predefined thresholds are exceeded, or anomalies are detected.

Reporting and Visualization: Network monitoring solutions provide reporting and visualization tools to help administrators understand network performance and status. Reports may include summaries of network performance, trends over time, and details of specific events or issues.

Configuration Management: Some network monitoring solutions include configuration management capabilities to manage the configuration of network devices. This may include backing up and restoring configurations, applying configuration changes, and auditing configurations for compliance with best practices and security policies.

Integration and APIs: Network monitoring solutions may offer integration with other systems and tools through APIs (Application Programming Interfaces). This allows administrators to integrate network monitoring data with other systems, such as ticketing systems, logging systems, and automation tools.

Regardless of the solution you choose, implementing a network monitoring solution consistently requires strategy, planning, measuring results. These best practices are a good place to start.

Define Clear Monitoring Objectives: Determine what aspects of the network you need to monitor (e.g., performance, availability, security) and what specific metrics are most relevant to your organization's goals.

Regularly Review and Update Monitoring Configurations: Network monitoring is not a set-it-and-forget-it task. Regularly review and update your monitoring configurations to ensure they align with your organization's changing needs and priorities. This includes adding new devices to be monitored, updating monitoring thresholds, and adjusting alerting settings.

Monitor Key Performance Indicators (KPIs): Focus on monitoring key performance indicators (KPIs) that are most relevant to your organization's goals. This might include network uptime, response times, and bandwidth utilization. Monitoring KPIs can help you identify trends and make informed decisions about network optimization and resource allocation.

Implement Comprehensive Security Monitoring: Network monitoring solutions should include robust security monitoring capabilities to detect and respond to security threats. This includes monitoring for suspicious activity, such as unauthorized access attempts and malware infections, and implementing measures to protect against these threats.

Train Staff on How to Use the Monitoring Solution Effectively: Provide training to staff on how to use the network monitoring solution effectively. This includes understanding how to interpret monitoring data, how to respond to alerts, and how to use the solution's features to troubleshoot network issues.

Integrate Monitoring Data with Other Systems: Network monitoring data can provide valuable insights when integrated with other systems, such as ticketing systems, logging systems, and automation tools. This integration can streamline network management processes and help ensure a coordinated response to network issues.

Review and Improve Monitoring Processes: This might include adding new monitoring checks, refining alerting thresholds, or implementing new monitoring tools or techniques.

As your enterprise network edge expands with more devices, processes, services, and physical locations, so does the challenge of monitoring that distributed environment.

Security, privacy, reachability, and latency issues are more prevalent in highly distributed networks. This makes monitoring, collecting, and processing large volumes of data increasingly difficult.

Reaching and monitoring infrastructure, services, and applications located in remote sites within large, distributed networks can be challenging from a central location, such as a data center or the cloud. Specific roadblocks include firewalls, network address translation (NAT) traversal, overlapping IP address ranges, and locked-down environments.

A distributed environment requires an even more sophisticated and advanced network monitoring solution. It must be deployable in a dispersed configuration to reach into systems and networks that would otherwise be inaccessible while keeping the monitoring logic centralized for easier operation and administration.

To adapt to these changing environmental demands and ensure maximum uptime and optimal performance of your network, distributed network monitoring solutions should deliver:

• Distributed data collection: Monitor all systems and networks, including remote and restricted locations beyond the traditional reach of centralized monitoring solutions.
• Digital experience monitoring (DEM): Get different perspectives to better understand local user conditions.
• Dynamic scaling: Adapt to changing network conditions and volumes of data collected for processing and storage.
• Extended network access: Monitor devices with many different APIs or agents across the public internet without compromising security.
• Centralized data visualization, storage, and alarm correlation: View data from a central location with one tool. Store data for analysis to predict and adapt. Understand your data and improve your team’s responsiveness. Delegate issues to the right people at the right time.
• Customization: Build to your unique monitoring, workflow, and personnel needs.

OpenNMS Meridian provides a comprehensive enterprise network monitoring solution that empowers you to ensure the availability and performance of critical network services. It’s a highly scalable open-source network monitoring solution to address all your distributed network challenges:

• It leverages the OpenNMS Minion, a stateless service that communicates with devices and services in remote locations to collect network and device data.
• With perspective monitoring, you can easily monitor the digital experience of internal services and applications from the perspective of many different physical, geographical, or logical locations.
• In scenarios where a high volume of streaming data needs processing, OpenNMS can scale different components individually, including Minions, Kafka, Sentinel, Elasticsearch, and Time Series Databases like Cassandra and Cortex.
• Built-in Dashboards let you visualize collected data at a glance and provide a common location to view this information. Default graphs for alarms, notifications, outages, and other predetermined insights.
• OpenNMS Meridian provides the ability to correlate related alarms into a single “situation,” making it easier to triage and address underlying problems, reducing the amount of troubleshooting required, and improving response time.
• Finally, OpenNMS allows flexible workflow integration with existing monitoring and management stacks. OpenNMS components and plugins, including Minions, Sentinel, and OpenNMS Plugin for Grafana, are configurable to suit your needs.

We hope this blog has raised your interest in learning more about using OpenNMS to monitor your distributed network.

Get the Network Monitoring with OpenNMS White Paper to see exactly how OpenNMS solves your distributed network monitoring challenges.

SNMP transports messages utilizing User Datagram Protocol (UDP). Unlike the alternative Transmission Control Protocol (TCP), this protocol doesn't require a connection to the receiver's network to deliver the data package. Network packets are simply sent to a destination without establishing any connection with the receiving network. The UDP connectionless protocol works more like the United States Post Office: a sender puts information in the envelope, addresses it, and the USPS drops the packet in the receiver's mailbox. The receiver doesn’t need to be home, open the door, or let the deliverer in.

On the other hand, TCP connection-oriented protocol works as if the sender put the content in an envelope, drove to a house, knocked on the door, came inside, showed their credentials, then handed the receiver the letter and confirmed they understood it.

The security risks are easy to see here. How can you be certain the sender is who you think it is? How do you know it’s not Tom Cruise in a Mission Impossible mask or a Terminator impersonating someone you know? Ensuring safety in this scenario requires a level of authentication that you can simply avoid by never opening the door. In other words, allowing outsiders access to your network opens the door to risk.

In addition, SNMPv3 can include encryption on the contents of the envelope.

Non-UDP protocols rely on the authentication of the sender and receiver to ensure the information is delivered to the right place, but the data itself is not protected. SNMPv3 can provide connectionless delivery with data encryption on the contents, making both the delivery and the data more secure.

Two SNMP features we discussed earlier also make the protocol more scalable: its consistent, standard data structure and its connection-less transfer format.

Getting started with a non-standard protocol may be easy and fast, but scaling and maintaining becomes harder and harder. The other protocols available today don't follow a universal standard, so they’re very unsophisticated and difficult to scale. Prometheus, for example, uses a fairly specified JSON encoding format for its own purposes, but that structure isn't defined anywhere, so you could basically send anything, and the receiver will have to do all the work on their side to unravel and understand the information.

The connectionless UDP communication model also supports scalability by enabling asynchronous delivery. In a connection-style protocol like TCP, the sender and receiver exchange communication parameters, and then a session is opened in each network and firewall to maintain the session until the conversation is concluded. This means that the sender asks for something and then waits for a response, asks for something / waits for a response, and so on. Keeping multiple connections open ties up network and receiver resources and time. One company could be maintaining 3- or 400,000 open connections at any one time. That’s a massive overhead on the network.

In an asynchronous format like UDP, the firewalls and the routers just send the packet and forget about it. Then, when the other side gets it, and it needs to send a response, they'll just send the response. The firewalls and networks aren’t maintaining sessions; no one is waiting. Network overhead is eliminated because SNMP and UDP (and OpenNMS) are not connection-oriented and are asynchronous in nature.

We hope you’ve found this review of the SNMP standard enlightening. This sometimes taken-for-granted protocol still has much to offer today's modern network monitoring challenges. While bandwidth may be bountiful now, it never hurts to leverage lightweight solutions like SNMP to avoid ever worrying about consumption. Its highly structured format lets network monitor tools know exactly what to expect. That and its connectionless communication format support security and scalability.

That's a ton of SNMP network monitoring value in one very small packet.

When networking was in its infancy, as with many new technologies, there were many competing approaches to handling the infrastructure that made the physical connections as well as the protocols that ran on those physical connections. Novell and Microsoft, for example, were big proponents of their own protocols. But in the end, the common Internet Protocol, or IP standard, won out. With that came a big boom in the networking industry.

Once there was a connectivity standard, the need for a complementary standard for monitoring the data and programs moving over networks became clear. A group of network engineers created a task force to develop, publish, and ratify the standard that became SNMP or “Simple Network Management Protocol.” By 1990, the Internet Architecture Board (IAB) approved SNMP v1 as the Internet standard for network management but continued to optimize the standard through more iterations:

Some of us already know that the "S" stands for "simple," but why was simple a critical component? When SNMP was designed 40 years ago, bandwidth was at a premium. In 1984, total global Internet traffic was 15 Gigabytes per month. Monitoring network traffic could be a little like quantum mechanics: because monitoring tools were so heavy, you couldn’t observe the traffic without affecting the results.

Back in the late 90s, monitoring could make up 20% of network traffic. That’s why the protocol had to be so lightweight: you couldn’t get people to use the protocol or even monitor the network if monitoring took up too much bandwidth.

Today, SNMP traffic doesn't even appear in monitoring reports because the footprint is so small compared to the available bandwidth and network usage. That’s the advantage of utilizing a protocol designed when bandwidth was a premium in a time when bandwidth is a commodity.

However, “simple” means it is lightweight in terms of bandwidth, but it turns out the protocol was really only considered simple by network engineers. Monitoring is a complex subject, and no matter how you approach the task, that complexity has to go somewhere. If you simplify the network communications, the complexity gets pushed out to the applications doing the monitoring.

SNMP’s standard specifies five core protocol data units (PDUs) that make data easier to parse on the receiver or application side. Network engineers know every field of that packet and expect it to be structured in a specific way: if there's a certain byte here and another byte there, they know exactly what each byte means, and can decode it on the receiving end. It requires that users be able to understand how to structure and code the request, encrypt the request, get it into that packet, send it over, and then, on the receiving side, do the same thing. Setting up this structured packet requires some complex work.

One approach to avoiding this complexity is to use an unstructured or non-standard protocol. The problem is that this just pushes complexity to the edges. The application or user needs to take all the non-standard data and parse it into a structure that means something. It gets stored in an unstructured data store and then multi-indexed by that technology so that users can actually find and use it. And since it's not a recognized standard, someone could decide to change the data format on a whim, putting you back at square one.

Nobody took the time to abstract SNMP’s operational complexity away because it's a complicated application to write. That was one of the reasons other protocols found a foothold; some people thought, “I don't want to keep training on this SNMP thing – it's too hard.”

However, SNMP is a very simple, lightweight message that can supply huge impacts. With this format, just a few bytes on the network can deliver a surprising amount of data.

As you can see, there’s more to this “simple” protocol than meets the eye. It delivers a light load on bandwidth in a structured, predictable format – with benefits you can only get from a recognized industry standard. Part 2 will dig into how SNMP’s stable standard, connectionless approach, and encryption capabilities deliver security with scalability.

Thinking back and looking forwards, what have we learned from the last twenty years of involvement in TM Forum programs and push for open-source network management solutions?

As in the early 2000's when the telecoms bust opened the door to the possibility of open-source solutions, today we are seeing a renewed interest in open source as pressure on margins and competition from Hyperscale cloud providers are forcing service providers to look for more cost-effective solutions.

It seems that new technologies wax and wane in popularity. You can put your heart and soul into a project only to have it marginalized to irrelevance. Every interface initiative has eventually been eclipsed by a new technology so it is important to invest just enough to track changes but not bet the farm on a technology which might be replaced in a couple of years. Several companies learnt that lesson the hard way through the TIP program.

The trick, particularly for a small company is to put enough investment in to signal interest and show thought leadership but be prepared to move on quickly if the work isn't driving business. If, however, customers like the work then the early experiments can be productized quickly.

It appears that the latest interface program has learnt this lesson and has employed some developers to sustain the tools. A clear advantage is that the core open source OpenAPI tools are maintained and used by a community to which the TM Forum contribute rather than own. The small TM Forum sustaining team allows occasional contributors (i.e., the majority of TM Forum members) to make their contribution which is then merged and sustained in the wider code base. One can only hope that this will be a long-term commitment on the TM Forum's part.

A parallel observation would be that the interface program may be trying to do too much for the sustaining efforts to be effective. The first interfaces from this program were pretty much handcrafted and not necessarily consistent in data types or interaction patterns. Later, a more consistent core entity model and newer HATEOAS based design patterns have been introduced. Additionally, plans are afoot to provide AsyncAPI based implementations of some of these same interfaces.

Consequently, there are now over 50 interfaces, each of which need ongoing sustaining effort to migrate them all to the same level of compliance and to fix bugs or add necessary enhancements. Furthermore, these interfaces were originally developed by different expert teams which have since disbanded, and the documentation on the use cases for each interface can be patchy.

All of this potential churn adds uncertainty to adoption. Do I use the currently published version or wait for the latest tooling to be released? Do I treat these interfaces as 'good starting points' for my architecture or as a mandatory set of compliance requirements?

Other advanced initiatives such as the TM Forum canvas are complex and also need reference implementations which are widely visible to drive adoption. It would be very beneficial if the canvas program could contribute upstream to make the canvas a component which is sustained in the Kubernetes ecosystem.

This leads into my final point. Technology creators need to promote the network effects of adoption - i.e., the more people who use a technology the more valuable it becomes.

In particular, it is important that a potential adopter can evaluate a new technology quickly and determine how much effort will be required to learn how to use it properly. Insufficient documentation sends a bad message that the technology is either too difficult or that the creator does not support the technology on an ongoing basis.

While much of the tooling and many of the interfaces are now published on GitHub, the documentation and team communications are still restricted to TM Forum members. I believe this significantly hampers the reach and uptake of the interface work and also prevents contributions from experts outside of the TM Forum community.

The interfaces could have real value for the wider IT community. A more serious commitment to promoting the interfaces through open source would help.

I’ve found that TM Forum has navigated the difficult balance between being both a member trade association and a standards creator. It has managed to remain relevant to its core membership and deliver some very useful technology innovations to the wider industry.

I think the direction is positive and hope that OpenNMS will be able to continue to make tangible contributions towards API development and adoption in the coming years as open source continues to be proven out as a viable approach to open-source network monitoring standards.

Around 2008, the TM Forum desired to create a more implementation neutral interface technology based on WSDL (Web Services Description Language). The new TM Forum Interface Program was led by Steve Fratini from Telcordia and (unimaginatively) referred to as TIP. The objective of the program was to use model driven engineering to generate WSDL interfaces and PDF documentation directly from the TM Forum SID.

By now open source network management was somewhat on the TM Forum's agenda. The TIP tooling, called the Joint Open-Source Interface Framework (JOSIF) was to be completely open source and was based on Eclipse Tigerstripe, a tool originally developed to help create OSS/J interfaces. However, although the tooling was open source, the resulting interfaces’ artifacts were mostly still restricted to only TM Forum members.

After I finished my doctorate, OpenNMS agreed to sponsor my work with the TIP program. The hope was that OpenNMS could contribute open-source expertise and ultimately implement these interfaces on top of OpenNMS thus exhibiting thought leadership in the TM Forum.

I participated heavily in this program on behalf of OpenNMS for about 3 years and OpenNMS also participated in a number of catalysts demonstrating integration to other vendors using the TIP interfaces.

The TIP interfaces are still available, but like OSS/J, TIP was superseded by later developments. The TIP program ultimately closed because of three factors.

Firstly, it was targeting WSDL, and the industry began to favour ReST interfaces using JSON.

Secondly, with hindsight it was a mistake to try and use the TM Forum Information Framework (SID) UML model as the starting point for interface definition. Using the SID made the tooling complicated to learn and use. We came to realize that the SID as an information model was not optimized for interface definition. OSS/J had avoided this trap by creating an intermediate data model, but TIP mistakenly tried to tie interface definitions directly back to the SID UML.

Thirdly, and perhaps most importantly, the cost of maintaining the open-source TIP tooling was difficult to sustain within the small TM Forum community. Although it was actively promoted to other standards organizations such as the ITU-T, the tooling really never reached critical mass adoption both within and outside the TM Forum.

After their initial enthusiasm, various contributors began to reign back their involvement and sustaining development of the capability fell on fewer and fewer members until eventually the program could not continue.

As TIP was becoming a legacy project, another interface program began to emerge under the leadership of Pierre Gautier. The wider IT industry was becoming aware of a new technology neutral interface definition language called Swagger (now OpenAPI) that had a set of code generators which could generate reference code and documentation. OpenAPI was getting wide adoption and the TM Forum decided to start a program to create a set of ReST / Json interfaces using OpenAPI.

The big difference was that the OpenAPI tooling was commercially supported (by Smart Bear) and already had a wide following outside of the telecoms industry. The TM Forum additionally agreed to fund several developers to contribute to the tooling and adapt it to TM Forum needs.

This reflected the lessons learnt in supporting the TIP tooling where all of the resources came only from individual TM Forum members. Someone needs to centrally own the sustaining of the project, and this can’t fall on individual contributors. Having spent a lot of effort on the previous TIP incarnation which had limited commercial adoption, OpenNMS has been more cautiously involved in the newer interface program.

In 2004, the telecoms bubble had burst, and the telecoms industry was still in shock with over 500,000 layoffs and $2 Trillion Dollars of value wiped out globally. Over-investment in fibre capacity and 3G licenses had left many suppliers and operators on the verge of bankruptcy.

This did not seem a particularly auspicious time to launch a new project, but I had just started Doctoral Research at Southampton University and wanted to investigate the potential of Open Source network management in the telecoms industry.

My first step was to somewhat nervously propose an open source 'Birds Of a Feather' (BOF) session at TMW Nice 2004. The session attracted a lot more interest than expected, and it seemed industry players were more willing to consider the open-source network management option as they desperately looked for opportunities to de-risk R&D investments and reduce overall IT costs. The TM Forum also saw this as a possible new strand to increase the value of participation.

BT, Agilent, and Sun (now Oracle) all generously sponsored several Southampton University undergraduates to work with me on an open-source proof of concept (PoC) through the summer before traveling to demonstrate it at another BOF in October 2004 at TMW Long Beach.

In the course of my research, I discovered OpenNMS – one of the few scalable open-source network management tools in existence at that time. It also appeared to be the only open-source network management platform written in Java which was a viable candidate for integration using OSS through Java (OSS/J) APIs.

I decided to use it as part of the PoC.

The OpenNMS company had just been founded, and I met CEO David Hustace when he travelled to join us for the demonstration in Long Beach. That was the start of more than twenty years of working together on OpenNMS.

TMW Long Beach raised even more interest in the possibilities of open-source, and we began to be referred to by TM Forum members as the 'open-source pirates'.

But not everyone was happy. Questions were asked at board level by some of the software vendors concerned about whether the TM Forum should be getting involved in open source. Fortunately, their objections did not prevail, and the BOF excited a group of people who were invited to a two-day workshop at the University of Southampton later that year. The workshop agreed to a set of objectives for what was to become the OpenOSS catalyst project.

TM Forum were then heavily promoting NGOSS, the Next Generation Operations Support System architecture (which was a precursor to today's TM Forum Open Digital Architecture). The Southampton workshop was able to broker a link between the open-source catalyst and a parallel NGOSS Model Driven Architecture catalyst. The OpenOSS catalyst would be modeled in UML as NGOSS contracts by the NGOSS catalyst team. The OpenOSS catalyst team was initiated at Team Action Week in January 2005, and the catalyst presented with Southampton students at TMW Nice in May 2005.

The catalyst demonstrated to TM Forum members for the first time that open source network management could enable collaboration, research, and education around TM Forum technologies, just a year from the first open-source BOF session.

Sun (Oracle) had previously initiated the OSS through Java (OSS/J) program in collaboration with a number of TM Forum members but outside of the TM Forum because of intellectual property rights issues. The objective of OSS/J was to encourage the use of the Java ecosystem (J2EE and XML over JMS) to develop OSS components which reflected the TM Forum's NGOSS design principles. OSS/J standardized a number of common OSS interfaces and the Java Community Process mandated that each published API had a publicly available Reference Implementation (RI) and Compatibility Test Kit (CTK).

Although the RI and CTK's were not necessarily published under a fully open-source license, OSS/J was clearly demonstrating that standards adoption would be greatly helped by examples which developers could leverage in their own products. Major Java enterprise components were increasingly developed as open-source projects and as these projects matured, they were becoming sufficiently functional to compete with their commercial equivalents. (Indeed, as part of Oracle's acquisition of Sun, the Java code base was itself open source as Open JDK). OSS/J APIs are still used in the industry and OSS/J was eventually subsumed into the TM Forum, but OSS/J reduced in popularity as the XML and EJB technologies on which it is based became less fashionable among developers.

Rather than pay the Splunk bill, Cisco just bought the company.

Cisco’s planned acquisition of Splunk has caused ripples across the network and security ecosystem since it was announced in September 2023. It may be a win for both by bringing together Splunk’s cybersecurity with Cisco’s network data, but as with any merger, there are some questions.

In this case, I’ve seen concerns around the potential culture clash, the pace of innovation, and especially how this could affect Splunk costs.

Observability costs can already spiral, surprisingly, out of control as demonstrated by Datadog’s shocking $65M/year customer bill (hint: it was Coinbase). Unfortunately, when budgets are tight and customer-facing services are sacrosanct, observability might be first on the chopping block when companies are looking to shave 10% off quarterly cloud costs.

Some vendors have reacted to the issue of steeply rising spending on observability metrics by introducing a way to pull together unused and partly used metrics into lower cardinality versions to reduce costs.

In this blog, I’m going to take a look at what’s driving these growing cloud costs and how they can be curbed so monitoring doesn’t have to be sacrificed.

When services like Splunk and Datadog and others first launched, one of the key promises of the cloud-delivery model was scalability – companies could use as little or as much of the service as they needed. But as the model has expanded over time, we’re starting to see some cracks along with the benefits:

Before joining OpenNMS, I was in the position to make the decision on which network monitoring solution to utilize. The non-profit I worked for was very budget-conscious, so having a predictable cost for network monitoring was critical but so was the scope of coverage. To avoid the blind spots and surprises listed above, we chose the on-premises implementation of OpenNMS Meridian.

With OpenNMS, everything is included, and the pricing is straightforward – there’s no piecemeal solution, no picking and choosing between metrics, no consumption-based costs. I never had to justify what I was measuring, why, or how much. We could plan and predict the cost and coverage.

When something happened, this let me turn the conversation from “The network is broken” to “The network isn’t broken, and I have the data to prove it. Do you?”

As cloud software usage has grown, most companies have run into the nasty shock of a surprisingly large bill at the end of the month. Elasticity is, in effect, gone when you have to justify additional budget to expand the solution, or you simply can't because the planned budget doesn't allow it. This is scale in name only.

The first line of this blog is a joke but with a painful, realistic point: even the best-funded companies can feel the burn of scaling cloud software costs.

For organizations requiring more predictability without sacrificing visibility (and can't afford to just buy the company!), it's worth exploring other options.

Find yourself stuck in the maze of network issues? Frustrated by monitoring problems you just can't seem to untangle? Full of network monitoring questions? Not sure how to take your network monitoring to the next level? We get it!

While ChatGPT can give you the answers to some of life’s big questions, there are still key insights you can only get from real people – like our OpenNMS experts.

With our “Ask an Expert” sessions, you can schedule time with real OpenNMS gurus to have a real conversation with an experienced network monitoring professional. No jargon, no tech-heavy mumbo-jumbo—just friendly advice, suggestions, and answers to your network monitoring questions.

Just fill out the contact form. Choose a date and time that works for you (we'll provide calendar links and an email for your convenience). Come to the session prepared with your questions, issues, and concerns.

Final step: have a fun, engaging, enlightening chat with people who have deep domain expertise.

Dr. Craig Gallen
Business Development Manager, OpenNMS

Dr Craig Gallen has been a committer to OpenNMS for over 10 years. He has worked as an engineer in broadcasting, telecommunications, and academia where his doctoral research explored the role of Open Source in the Telecommunications industry. Presently Craig splits his time between teaching at Solent University Southampton and influencing the strategic direction of OpenNMS.

Mike Huot
Principal Product Strategist, OpenNMS

Mike offers a blend of strategic leadership and technical expertise, with a focus on monitoring and infrastructure management. As Principal Product Strategist and Infrastructure Architect, he’s led diverse initiatives, overseeing deployment and automation across networking, computing, virtualization, storage, and cloud, emphasizing monitoring and observability. At OpenNMS, he shares expertise, advocates for open-source solutions, and engages in community collaboration. He balances hands-on technical work with strategic input, driving product direction and enhancing network performance management, while contributing to the OpenNMS community.

If your schedule doesn’t allow you to carve a specific time out of your day for a conversation, no problem. As an open-source solution, OpenNMS has a community of users ready and willing to lend a helping hand. You can dig through the available resources on your own or join our community to connect with other users facing the same issues.

"When I decided to choose OpenNMS, I used the following criteria:

• Open source: This is important to me because I wanted to be able to customize OpenNMS to meet the specific needs of my organization.
• Scalability: I wanted to be able to use OpenNMS to monitor my network as it grows in the future.
• Features: I wanted a software that could monitor all aspects of my network.
• Community: OpenNMS has a large and active community of users and developers you can interact with in forums and mailing lists to get help.
• Cost: Last, but not least, saving costs."

"For me, the most important aspect of OpenNMS is its customizability. It is an enterprise-grade solution, but it still allows you to define exactly what and how to monitor, and to establish under which conditions you will receive an alert when something happens in your network. It has a wide range of features that makes it suitable for almost every need and situation.

This is why I describe it as the "Swiss Army Knife" of network monitoring. Other important aspects I took into account when choosing OpenNMS over other solutions include:

• It has a large and helpful community
• It can monitor large networks, it can grow with your company
• No hidden costs or fees to enable features ,you can maintain it completely on your own.
• The solution has been evolving constantly and adding very helpful features."

"Network monitoring software should be flexible enough to provide an at-a-glance overview of the current status of your network, with critical metrics from routers, switches, firewalls, servers, services, application, URLs, printers, UPS, and other infrastructure devices. We’ve provided solutions using OpenNMS and helped them adjust the platform to monitor the required specifics that can help administrators quickly troubleshoot problems and overview metrics metrics to make decisions proactively in order to avoid unnecessary downtime in their services.

Some of the most common metrics we used to track are:

• Device uptime: The most straightforward, high-level KPI is uptime, which measures the fundamental goal: how often the service is available.
• Network traffic: In our actual use case this metric tracks the amount of network traffic that is flowing through a device or a network. This help us to identify devices that are experiencing congestion and make adjustments on the fly.
• Packet loss and re-transmissions: Packet loss often signals interference or congestion on the network. A common symptom of this issue is data transferring from one device to another but not entirely reaching its destination. Monitoring packet loss is vital because it's a surrogate for the wireless network's overall health.

By tracking these metrics, we gain valuable insights into the performance of our network and business."

"Since the average cost of a license for a network monitoring solution goes from more than $2,000 for the first year of use up to $30,000 or $50,000, there is a clear reduction in costs when you use OpenNMS Horizon. Of course, you have to keep in mind that you need to have the skills to maintain the solution adapted to your needs. Even when there’s an active and supportive community, skills are required.

In some cases you need to weigh the possibility of acquiring an OpenNMS Meridian subscription, which is the best cost-effective solution for an enterprise-grade monitoring system—and you'll still be able to reduce costs, directly or indirectly."

"Using OpenNMS has made our business more efficient by helping us track network performance quickly and accurately. OpenNMS can instantly gather information from every part of a network, ensuring that each part is performing its function. This helps us to identify and resolve issues before they cause downtime, which in turn increases productivity and less support tickets to solve ;-) …

One of the major advantages of using OpenNMS is that it gives us the ability to identify issues before our customers do. This allows us to take proactive measures to resolve the issues, which helps to improve customer satisfaction.

As a result of using OpenNMS, Urbalink Networks has built a very stable customer base without the need of aggressive marketing. We have a reputation for excellent customer service and reliability, which has helped us to increase our customer satisfaction, reduce our costs, and improve our profitability."

"One of the things I look forward to is the continued growth of the OpenNMS community. I am excited to see the community continue to grow and to see what new and innovative things they come up with.

I am also excited to see how OpenNMS Horizon evolves and how it becomes more accessible to a wider range of users. In this regard, I think that the learning curve could be improved by making the interface more intuitive and by providing more wizards and other tools to help new users get started."

"My humble advice to anyone considering using OpenNMS would be:

• Get involved in the community: Getting involved in the community is a great way to learn more about OpenNMS and to get help from other users.
• Start small: OpenNMS can be a complex platform. It is a good idea to start small and to gradually enable features and functionalities as you need them.
• Be patient: Learning OpenNMS takes time. Be stubborn, don't give up, and don't be discouraged if you don't understand everything right away. Just keep learning and experimenting, and you will eventually get the hang of it."

Special thanks to Jesus Palacio for his time and insight—as well as his support for OpenNMS over the past two decades.

Learn more about OpenNMS Horizon and OpenNMS Meridian, our supported enterprise network monitoring platform.