Planet OpenNMS

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 costs for Splunk users.

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 expenses.

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 software 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? 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 solutions to your network monitoring dilemmas.

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.

"I first interacted with OpenNMS in 2003, when I was a network analyst at my first job after college. My boss, who was very involved in open-source initiatives, introduced me to the project. He had implemented OpenNMS as an alternative to HP OpenView. The company we worked for at the time was a value-added provider to cellular carriers, both domestic and international. We had very strict SLAs with our customers, so one of our main tasks was to ensure compliance with those SLAs. OpenNMS was a perfect fit for our needs because it enabled us to do early warning and comprehensive monitoring, which were key aspects of our roles.

Later on, my then-boss and I became business partners. We offered a wide range of technology solutions together and founded a company called Codexware (2007-2010). Unfortunately, the company is no longer in business as we moved on to different projects."

"I proudly remember two deployments of OpenNMS during my time as an open source solutions provider for Codexware from 2007 to 2010:

• Eleval: In this project OpenNMS was used to monitor the performance and early warning of a wireless microwave network that was used to monitor a complex electrical power grid serving Valencia city in Carabobo state, Venezuela.
• Genesis Telecom: This was one of the first Internet service providers (ISPs) oriented to business clients in Venezuela. At the time, their network was completely wireless and composed of a diverse range of technologies, each with its own monitoring solution. This made it difficult for their NOC (network operations center) personnel to troubleshoot and resolve problems.

We offered them OpenNMS because its agentless monitoring concept was a perfect fit for their needs. OpenNMS was able to unify the monitoring process into a single, comprehensive solution, which made it much easier for the NOC personnel to track and manage their network."

"I’m the Chief Technology Officer of Urbalink Networks, but—beyond the title of the position—I am responsible of the technology strategy and execution of the organization.

As part of my job, I also:

• Oversee the development and implementation of new technologies, as well as the maintenance and security of existing network infrastructure.
• Ensure network performance and availability as our goal is to deliver reliable and high-quality services to our customers.
• Manage the IT & Customer Support Team who are stationed in the network operations center (NOC), with the help of team leaders. This includes hiring and training new staff, as well as setting performance goals and managing the team's budget.
• Oversee compliance with legal regulations and working with the marketing team to develop new products and services is a integral part of my position."

"Urbalink Networks is a Venezuelan company that provides internet access, network solutions, specialized on the business segment. Through the years we have built a strong track record of providing reliable and secure services to our customers. We have a team of experienced professionals who are dedicated to providing solutions that meet the specific needs of our clients. Urbalink Networks now operates a hybrid network of fiber optic and high capacity wireless links servicing over 400 locations.

In addition, we offer the following services to our clients:

• Network solutions: We specialize in designing, deploying, and managing networks and Wi-Fi managed access.
• Consultancy: We offer help designing and implementing telecommunications solutions. This is a great option for businesses that are not sure where to start.

Most of the companies we help are looking for ways to reduce the cost of their monitoring solution without having to give up the possibility of customizing according to their needs. In general, we are able to work anywhere in which solutions that are tailored to fit any customer’s unique requirements are needed."

"One of the things I love about my position as CTO of Urbalink Networks is the bird's-eye view of the entire organization and the ability to help shape its future. I get to make decisions that will impact the company's success, I get to see the fruits of my labor as the company grows and evolves.

The technology industry is constantly changing, so I need to be a lifelong learner. I try my best to stay up-to-date on the latest trends and technologies, and I like to apply my knowledge to solve real-world problems. Urbalink Networks is the perfect place for this because I have the opportunity to make a real difference in the world. Our products and services are used by people every day, and we help businesses succeed.

Of course, there are also challenges. Some days can be demanding and stressful, and you need to be able to handle a lot of responsibility. However, I believe that the rewards of this role far outweigh the challenges."

"First, I am a strong believer in the DIY (do it yourself) philosophy and open source software aligns well with that. Being able to modify and adapt a product to my needs, if I have the capacity to do so, is an amazing benefit. Additionally, OpenNMS has a large and active community of users and developers who are always willing to help, so I am never alone or helpless.

I have been able to implement and adapt OpenNMS to meet our own needs and those of our clients who've requested a network monitoring solution. No matter what type of network or devices need to be monitored, OpenNMS has always been a perfect fit. That's why I implemented OpenNMS for Urbalink when I got the position in 2009. To this day, OpenNMS is a foundational part of my daily work.

OpenNMS aligns with my values of open collaboration and sharing of knowledge. I believe that open source software will play an important role is the future of software development, and I am excited to be a part of the OpenNMS community and of course to give back. OpenNMS also has a clear mission and vision to "be the leading open source network management platform in the world." This aligns with my own goals of using the best technology available and evolving with it. I believe that OpenNMS is well-positioned to achieve this goal, and I am excited to be a part of the journey."

Integrating systems from two different vendors can be a challenging endeavor.

However, these challenges often present unique opportunities for problem-solving. With today's innovative tools such as Red Hat Event-Driven Ansible and OpenNMS, we now have more robust and sustainable solutions at our disposal for such issues.

I'd like to share a personal experience from my previous job where we dealt with a Network Attached Storage (NAS) system issue.

Check out this Ansible demo:

https://www.youtube.com/watch?v=aqQq5vD8-n0

Our NAS setup featured a policy server that scrutinized every operation to prevent protected data from ending up in incorrect locations within our drive shares. This process was managed synchronously via a TCP connection initiated by the policy server. Every operation on the NAS required either approval or rejection from this server.

However, an unexpected bug brought this smooth process to a standstill when the policy server would set its TCP window size to zero. The notorious 'zero window' condition means the receiver, in this case the policy server, is no longer able to receive data. The NAS will respect this request of a zero window and stop sending operations for approval. Under normal operations, this is a good thing. A receiver like the policy server maybe temporarily overloaded unfortunately, in this case it never recovered. As the connection appeared alive from both the policy server and NAS neither end would reset it to restore the window, leading to inaccessible drive shares and subsequently halting users' work.

Resolving this issue swiftly became a critical priority. Our immediate fix involved manually resetting the connection for the policy server. We probably lost some transactions during this, but the alternative of a full stop to everything was far worse. To automate this process, we crafted several bespoke scripts. However, these were problem-specific and led to a duplication of effort. Thankfully, with the advent of modern solutions, we can now address such situations in a more efficient, reliable, and sophisticated manner.

Red Hat Event-Driven Ansible is a fantastic tool that enables instant responses to events detected by OpenNMS. In the context of our NAS system issue, the policy server traffic remained above 1 megabit per second under normal circumstances, but when the bug appeared, the traffic plunged to less than 100 kilobits per second. OpenNMS was already collecting network interface data via SNMP from the policy server, and we could simply configure this as a low threshold event.

The amalgamation of Ansible's real-time automation and OpenNMS's comprehensive monitoring and event management capabilities provides a powerful solution for network system issues. When OpenNMS triggers an event like a traffic drop below a set threshold, this information is sent to Ansible. Ansible then springs into action, running a playbook that resets the TCP connection, validates service restoration, and sends an all-clear signal.

In conclusion, modern tools and technology have revolutionized how we address complex problems, simplifying our work and providing elegant solutions. With the power of Red Hat Event-Driven Ansible and OpenNMS at your fingertips, you're well-prepared to tackle any system issues head-on!

In September, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 32.0.3.

Meridian Stable Updates

Meridians 2023.1.7, 2022.1.20, 2021.1.31, 2020.1.39 contains a few security fixes, as well as a couple other improvements.

For a list of changes, see the release notes:

• 2020.1.39 (Beach Cusps)
• 2021.1.31 (Next Mars Orbiter (NeMO))
• 2022.1.20 (Taurus)
• 2023.1.7 (Zoot)

Horizon 32.0.3

Release 32.0.3 contains a bunch of documentation updates, as well as a number of bug fixes and enhancements including improvements to the Karaf core startup, polling and node search fixes, IPv6 support in ILR, and a fix for loading the Cortex timeseries plugin.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.3 is Acid Techno.

Simply deploying a monitoring solution, like OpenNMS Meridian, opens up new security challenges and implications. Fortunately, there are steps, precautions, best practices, and a guide, to help you make Meridian as secure as possible.

The OpenNMS Meridian security reference architecture presents the structural components of the monitoring solution and gives you recommendations for a more secure network monitoring implementation.

This document describes out-of-the-box components and typical use patterns for OpenNMS Meridian. Of course, your implementation may vary, but this is a great place to start—or a resource to double check that you've got your security basics under control.

From the reference architecture: A typical OpenNMS deployment

The reference architecture describes everything from a minimal deployment of Meridian (simply Meridian Core, a PostgresSQL database, and the networked devices you with to monitor) all the way to a more advanced deployment with Kafka, visualization through Grafana, load balancers, a reverse proxy, and more.

It also addresses:

• Roles vs. permissions vs. groups within OpenNMS
• Authentication and authorization, including default passwords and where to change them
• SSO integration and recommendations
• How to secure your communications
• Zero-trust vs. protected networks
• Java KeyStore and TrustStore, to securely store certificates and private keys

The reference architecture is all about securing your Meridian installation. It doesn't specifically address how to install or customize the OpenNMS software.

Thankfully, that's why you also have OpenNMS documentation to lean on. If you're just getting started with OpenNMS, that's the best place to go to learn more.

Want to take the next step, or need a helping hand with your OpenNMS deployment or implementation?

We're here to help—contact us to get the most out of your monitoring.

Lōkahi by OpenNMS is a new open source project focused on turning OpenNMS Horizon into a cloud-native application, built on a microservices-based architecture.

Lōkahi, pronounced [loh-KAH-hee], is the Hawaiian word for "unity." (As you may or may not know, one of The OpenNMS Group's founders, David Hustace, is of Hawaiian descent.)

The underlying objective is very much about unifying everything the OpenNMS community has been building for the past 20+ years and reimagining it as an orchestrated, elastic service.

The Lōkahi project is the next generation of open source network monitoring.

You might have noticed activity in GitHub recently, referring to this project as "Horizon Stream." You may have recently found the repository for it and poked around.

Feature-wise, the priority now is around Flow technologies and advanced traffic analysis and migrating these and other capabilities from Horizon while greatly improving the user experience. Naturally, this requires inventory (network discovery and provisioning) and SNMP capabilities to fully support these features.

Just like Horizon, Lōkahi is open source and encourages all contribution. If you want to submit code, ask design questions, or make recommendations to the project, you can chat with the community developers in the project's Mattermost development channel and the Discourse community.

We believe this is an important, fun project—and we can't wait to see where it takes the OpenNMS community.

OpenNMS celebrates the importance of girls, women, and non-binary folk in Information and Communications Technology (ICT). Last year, people on our team shared stories about the importance of access and safety in ICT. This year's theme is "Digital Skills for Life."

Looking around OpenNMS, this theme is especially meaningful. We have people from many different walks of life, paths into the technology industry, and unique experiences. Despite differing backgrounds, those who shared their stories this year had some common observations: learn through experimentation and always be open to new ideas.

Zoë

My parents were very supportive of my interests in tech and always encouraged me and bought things that I needed. My high school CS teacher saw potential and put me in charge of the school network and lab computers after he found me hacking root on them. I helped out the other students with their lab assignments.

Sandy

Well, I was a C-level executive about 10 years ago and I worked directly with the CEO. We went through the downturn of 2009, lost more than half of our staff, and had some software that was extremely difficult to use. We were paying hefty, hefty consulting bills to answer simple questions about the software. So, I taught myself how to use it. They actually ended up visiting us because they wanted to find out why we stopped racking up all of those charges. I was walking by the CEO's office one day and he says, "That's the reason why we're not paying your fees anymore."

Veena

My mother used to be a science teacher while I was growing up and always referred to science, logic, and reasoning during everyday activities. She is one of my role models. In addition, there were many women around me (family, friends, colleagues, etc.) that I have observed and learned many things from over the years that I apply or practice.

Amanda

I tend to shy away from giving advice. I feel like it implies I know what I’m doing. But I guess if I have to give any advice it would be to keep an open mind and to not be afraid to explore all of the different career choices that might interest you!

Jen

Prioritize your personal goals and see how they can align to a professional career. Too often many people are driven into jobs for all the wrong reasons instead of taking advantage of every opportunity when you are younger to try things out. Be inquisitive, talk to people you meet, ask them what they really do for work every day and start to piece together your own dream job.

Nicole

Learn as much as you can and take advantage of the opportunities you have now. If you have access to specialized courses take them. If you don’t, there are a lot of great online resources and tutorials to help you learn the basics of the tools of the trade.

Veena

Stay curious and never stop learning. Don’t be afraid of change.

Network segmentation is the process of dividing a network into smaller, more manageable pieces (segments) to improve its security posture. Network segmentation creates secure zones (subnetworks or subnets) within your larger network to help mitigate the impact of a security breach. By breaking the network into smaller pieces, you limit the spread of malicious events and activities within the contained segment and provide additional protections for insecure devices.

Modern networks facilitate essential operations, communication, and data transfer. And networks continue to get more complex, growing in scope with more services, more devices, more locations, and a more mobile workforce. Administrators have to constantly improve security standards, controlling what happens, where, on the network—while also being able to monitor and understand it all.

Network segmentation is a critical piece of an overall cybersecurity / network security model. It's used to help you:

• Improve your security posture. Network segmentation improves the security posture of an organization by limiting the potential attack surface. By dividing the network into smaller segments, businesses can control access to different areas of the network and limit the exposure of sensitive data.
• Mitigate risk. Network segmentation helps businesses mitigate the risks associated with data breaches and malware. If a breach occurs in one segment of the network, it will not impact other segments, thereby reducing the overall risk of data loss.
• Meet compliance requirements. It's crucial to industry standards such as PCI DSS, HIPAA, and GDPR. These standards require strict control over storage and access to sensitive data.

You can accomplish network segmentation through the use of firewalls, ACLs (Access Control Lists), and VLANs (Virtual Local Area Networks). Your approach depends on how you break down your datacenter and networked infrastructure into subnetworks: physical vs. virtual (logical).

Physical segmentation works exactly how it sounds—you use physical hardware (firewalls, routers, etc) to divide your network. Oftentimes, the location of your networked infrastructure becomes a segment.

Virtual (logical) segmentation uses software to define the segment. This approach can be easier, since you aren't limited by access to physical devices and can build virtual networks or use ACLs to separate networked devices.

Not exactly. Network segmentation and microsegmentation are very similar in approach, but differ in capability and execution. While network segmentation relies on a single constraint to govern access (for example, physical location), microsegmentation goes a bit further, isolating each device or application into its own segment. For organizations looking to adhere to a zero-trust architecture approach, microsegmentation is essential. Since you separate each entity from all others, access and traffic must be explicitly granted, regardless of whether it originated within the same segmented network.

Think of your network as a city block, full of apartment buildings. Each building has a locked front door and only the people living there have the code, so you trust them with access to the building itself. That's a segment on your network. Microsegmentation is each locked apartment. You trust entities with access to the building, but not the apartment. So, only the owner of each apartment, or microsegment, has the ability to enter—or grant entry—to their apartment.

The typical steps in segmenting networks include:

Different industries have very similar issues where segmentation can help—whether it's devices with insufficient security protections or which hold sensitive data (or both). Creating a microsegment for each of these devices, or for all of a type of device, to protect them is critical to keeping them safe. The microsegmentation becomes a compensating control for devices with limited protections.

• Healthcare. There has been a recent proliferation in network-connected medical devices. Devices include radiology modalities, lab analyzers, blood glucose meters, IV pumps, patient monitors, or nurse call systems, just to name a few. These devices often use outdated security practices—making them vulnerable. In many cases, you won't be able to deploy the usual endpoint protections, such as anti-malware and anti-virus software. And the criticality of these devices make them likely targets for cyberattacks. Bad actors know they contain valuable patient data. In extreme cases disruption of patient care is a concern.
• Manufacturing. As production lines grow in complexity, with more automation and speed, the number of network-connected monitoring devices also grows. In many cases, these devices sit alongside older devices that are running on outdated, unsecure operating systems. Oftentimes, we measure downtime in lost revenue.
• Retail. Internal systems, including point-of-sale systems, manage card holder data (CHD). Segmenting or microsegmenting these systems is necessary to comply with PCI requirements.

Controlling what these devices can communicate with—and what can communicate with the devices—reduces the risk of malicious software or people from accessing them. Furthermore, you limit attack spread in cases of a compromised device.

Your job doesn't end at building a segmented network. You're need to be able to monitor these segments, find issues, and continue to adapt as your environment changes. But, an outside-in approach to monitoring (where your monitoring system connects to, and monitors, from outside of the segment) creates holes in your security—the very thing you were limiting by implementing network segmentation. OpenNMS is able to collect relevant data from within the segment itself, an inside-out view, through the use of OpenNMS Appliance.

OpenNMS Appliance is physical hardware, or virtual machines, that reliably and securely collect network monitoring data from hard-to-access areas of your infrastructure.

Appliances are the network monitoring data collectors for OpenNMS. They run lightweight services that enable OpenNMS to communicate with devices and services on your network. By deploying Appliances, you also gain better control and management capabilities.

Appliances let you:

• Configure your entire fleet of Appliances in one action.
• Define groups of Appliances and apply batch configurations to specific groups, as needed.
• Schedule or automate updates for your Appliances—ensuring they have the latest bug and security fixes.
• Keep your fleet of Appliances in sync with the core OpenNMS platform. This guarantees monitoring data continuity through updates.

OpenNMS Appliance fits best in this model through network overlays—a virtual layer, or abstraction, that sits over your network. Within network segmentation, a network overlay is part of the logical approach to defining segments, with VLANs playing a prominent role as your overlay. Add an Appliance to specific segments to provide a secure way to monitor the segment from inside, rather than permitting external monitoring a view into the segment.

An example:

Let's say you're a network engineer at a hospital. Some of the devices on the hospital network include MRI machines. So, you place all of the MRIs into a segment. Now, you could externally monitor the health of these devices, increasing the risk of the devices being compromised due to more opening in your firewall, for example. Or, you use OpenNMS Appliance, placed as part of the segment, without any outside connections needed to monitor the devices. The Appliance talks out to your central OpenNMS Meridian network monitoring platform, but no communication into the Appliance is necessary.

You get the data you need, without unnecessarily exposing sensitive equipment to attacks.

OpenNMS Appliance can be quickly integrated into your existing network infrastructure—deploying Appliance hardware or deploying a virtual Appliance. The Meridian platform supports various network protocols and standards, including SNMP, NetFlow, sFlow, IPFIX, and more.

Additionally, OpenNMS offers numerous integrations with third-party applications and services, such as Grafana, Elasticsearch, and Slack, providing additional functionality and enhancing overall network management capabilities.

OpenNMS offers several tools and features designed to improve network segment visibility, including:

• Discovery and provisioning. OpenNMS can automatically discover network devices, allowing for a complete and up-to-date inventory. This process can be customized to match specific network segments, ensuring you discover and monitor relevant devices.
• Performance monitoring. OpenNMS provides detailed performance data for network devices, including bandwidth usage, latency, and packet loss. This information allows administrators to quickly identify potential bottlenecks or issues within network segments.
• Alerts and notifications. The platform offers a customizable alerting system, enabling administrators to set thresholds and receive notifications when issues arise. This feature allows for rapid identification and resolution of network segment problems.
• Visualization tools. OpenNMS includes various visualization tools, such as topology maps, geographical maps, and customizable dashboards. These tools provide administrators with an easy-to-understand visual representation of their network segments, improving overall visibility and facilitating quick decision-making.
• Log and event management. The platform collects and stores logs and events from network devices, allowing administrators to review historical data and identify trends or recurring issues within network segments.

Enhanced network segment visibility is crucial for maintaining an efficient and reliable network infrastructure. OpenNMS Appliance offers a comprehensive solution for managing and monitoring networks, providing administrators with the tools they need to keep their networks running smoothly.

Use OpenNMS Appliance to optimize network performance, reduce downtime, and improve your overall operational efficiency.

In April, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.6.

Meridian Stable Updates

Meridians 2023.1.2, 2022.1.15, 2021.1.26, 2020.1.34 contains a bunch of bug fixes, along with a fix for a security vulnerability.

For a list of changes, see the release notes:

• 2020.1.34 (Spit)
• 2021.1.26 (Clementine)
• 2022.1.15 (Crater)
• 2023.1.2 (Count von Count)

Horizon 31.0.6

Release 31.0.6 contains a bunch of bug fixes, along with fixes for several security vulnerabilities. It also upgrades the embedded Drools library from v7.x to v8.x, so be sure to test any custom rules that you depend on before moving to production.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.6 is Coyotas.