Planet OpenNMS

July 10, 2024

July 2024 Releases – Horizon 33.0.6, 2024.1.2, 2023.1.18

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

Meridian Stable Updates

Meridians 2024.1.2 and 2023.1.18 contains an enhancement and a couple of bug fixes.

For a list of changes, see the release notes:

Horizon 33.0.6

Release 33.0.6 contains an enhancement and a couple of bug fixes.

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.6 is Mango.

The post July 2024 Releases – Horizon 33.0.6, 2024.1.2, 2023.1.18 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at July 10, 2024 02:58 PM

OpenNMS Horizon 33.0.6 (Mango)

Release 33.0.6

Release 33.0.6 contains a couple of bug fixes and an enhancement.

The codename for Horizon 33.0.6 is Mango.

Task
  • Stalled threads in telemetryd parser (Issue NMS-16243)
Bug
  • Cross-Frame Scripting-CWE ID : 1021 Web scan vulnerability (Issue NMS-16369)
  • Address CVE-2020-15522 (Issue NMS-16384)
  • Querying Alarms by alarmId leads to a page that loses context on refresh (Issue NMS-16417)
  • NMS-16243 fix missing from 33.x release series (Issue NMS-16441)
  • Stored XSS on "MIB Compiler" (Issue NMS-16444)
  • Stored XSS on "Scheduled Outages" (Issue NMS-16445)
  • Missing Access Control on "Grafana Endpoints" (Issue NMS-16446)
  • Missing Access Control on "Geocoder Configuration" (Issue NMS-16447)
  • Stored XSS on "Node Label" (Issue NMS-16448)
  • Detailed server configuration in the error (Issue NMS-16449)
  • Services are deleted and recreated on each provisioning run (Issue NMS-16458)

by mershad-manesh at July 10, 2024 02:56 PM

July 05, 2024

Interview with Alan Brown, SVP and GM, OpenNMS Pt. 3

Evolving network monitoring technologies and what's next for 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.

alt

How do you foresee network monitoring technologies evolving over the next five years?

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.

Alan Brown

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

What excites you about the future of OpenNMS?

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.

Alan Brown

How will you measure success for OpenNMS?

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.

Conclusion

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.

The post Interview with Alan Brown, SVP and GM, OpenNMS Pt. 3 appeared first on The OpenNMS Group, Inc..

by Jen Fekin at July 05, 2024 12:43 PM

June 26, 2024

Interview with Alan Brown, SVP and GM, OpenNMS Pt. 2

Exciting OpenNMS Projects and the Industry's Future

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.

alt

Now that you’ve been here ~4 months, what have you learned about OpenNMS that the world should know?

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.

Alan Brown

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

What initiatives or projects are you most eager to take 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.

Alan Brown

What trends are influencing the network monitoring industry, and how is OpenNMS positioned to respond?

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.

alt

What are the biggest challenges facing the network monitoring industry?

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.

Conclusion

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

The post Interview with Alan Brown, SVP and GM, OpenNMS Pt. 2 appeared first on The OpenNMS Group, Inc..

by Jen Fekin at June 26, 2024 03:27 PM

June 20, 2024

Interview with Alan Brown, SVP and GM, OpenNMS

Background and Journey to OpenNMS

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.

alt

Can you give us a few highlights from your career that led you to this point?

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.

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

What drew you to OpenNMS and this role?

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.

Alan Brown

Can you talk a little about your leadership and team-building philosophy?

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.

Alan Brown

Conclusion

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.

The post Interview with Alan Brown, SVP and GM, OpenNMS appeared first on The OpenNMS Group, Inc..

by Jen Fekin at June 20, 2024 03:40 PM

June 12, 2024

June 2024 Releases – Horizon 33.0.5, 2024.1.1, 2023.1.17

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

Meridian Stable Updates

Meridians 2024.1.1 and 2023.1.17 contain a couple of bug fixes and an enhancement.

For a list of changes, see the release notes:

Horizon 33.0.5

Release 33.0.5 contains a bunch of bug fixes and enhancements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.5 is Black Pine.

The post June 2024 Releases – Horizon 33.0.5, 2024.1.1, 2023.1.17 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at June 12, 2024 03:31 PM

OpenNMS Horizon 33.0.5 (Black Pine)

Release 33.0.5

Release 33.0.5 contains a bug fix and an enhancement.

The codename for Horizon 33.0.5 is Black Pine.

Enhancement
  • Update Provisiond scan to remove old primary IP inteface (Issue NMS-16347)
Bug
  • Unable to set collection on detectors (Issue NMS-16360)

by mershad-manesh at June 12, 2024 03:21 PM

May 14, 2024

Introducing OpenNMS Meridian 2024

We are excited to announce the release of OpenNMS Meridian 2024, the latest advancement in cutting-edge enterprise network monitoring software, designed to meet the evolving needs of modern enterprises.

This release marks a significant leap forward, delivering upgraded support for enterprise-scale network monitoring, featuring robust technical upgrades and user-friendly enhancements that empower network administrators to manage network infrastructure more efficiently and securely than ever before.

Future-Proof Java Support with JDK 17

Meridian 2024 includes support for JDK 17, ensuring that the software remains future-proof and benefits from performance enhancements and compatibility with the latest Java versions. This update enables faster execution, improved security, and better resource management for your network monitoring tasks, keeping your network operations running smoothly.

Upgrade to Meridian 2024 today to experience the future of enterprise-scale network monitoring.

Revamped Node List Interface for Enhanced Troubleshooting

The revamped structured node list interface in Meridian 2024 is a game-changer for network administrators. Featuring new sorting and filtering options, this interface empowers administrators to swiftly locate and manage network devices, streamlining troubleshooting and maintenance tasks. This feature simplifies your workflow, saving you time and effort.

Seamless Containerized Deployments with RedHat’s Universal Base Image

Meridian 2024 now supports RedHat’s Universal Base Image (ubi9-minimal) for containerized deployments. This shift optimizes image size, simplifies updates, and ensures seamless compatibility with restrictive OpenShift environments. Your containerized deployments just got smoother, allowing for easier management and scalability.

Enhanced Apache Cassandra Data Storage with DataStax Driver Upgrade

Upgrading the DataStax driver for Cassandra to version 4.x in Meridian 2024 brings reliability improvements and additional configuration options. This enhancement directly impacts performance and stability, ensuring that your data is stored securely and is readily accessible when needed.

Advanced Predictive Monitoring with Native Holt-Winters Forecasting

The adoption of native Holt-Winters forecasting in Meridian 2024 delivers accuracy and efficiency gains. Whether you’re predicting network traffic patterns or anticipating resource demands, this feature enhances your monitoring capabilities, enabling you to make informed decisions about future workloads and optimize your network performance.

Simplify Your Network Monitoring and Management: Upgrade to Meridian 2024 Today

With OpenNMS Meridian 2024, managing your enterprise network becomes significantly less complicated. You can focus on driving innovation and growth, rather than spending time on the intricacies of network management. From deployment to network-wide management, Meridian 2024 is your scalable, efficient, and secure network monitoring solution.

Upgrade to Meridian 2024 today to experience the future of enterprise-scale network monitoring.

The post Introducing OpenNMS Meridian 2024 appeared first on The OpenNMS Group, Inc..

by Jen Fekin at May 14, 2024 01:55 PM

May 08, 2024

May 2024 Releases – Horizon 33.0.4, 2023.1.16, 2022.1.27, 2021.1.38

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

Meridian Stable Updates

Meridians 2023.1.16, 2022.1.27, 2021.1.38 contains a bunch of bug fixes.

For a list of changes, see the release notes:

Horizon 33.0.4

Release 33.0.4 contains a bunch of bug fixes and enhancements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.4 is Anacahuita.

The post May 2024 Releases – Horizon 33.0.4, 2023.1.16, 2022.1.27, 2021.1.38 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at May 08, 2024 09:15 PM

OpenNMS Horizon 33.0.4 (Anacahuita)

Release 33.0.4

Release 33.0.4 contains a bunch of bug fixes and enhancements.

The codename for Horizon 33.0.4 is Anacahuita.

Bug
  • PostgreSQL monitor url parameter metadata cannot be resolved properly and collection fails consequently (Issue NMS-16374)
  • Unable to display varbind’s form feed characters and other control characters in events (Issue NMS-16395)
Enhancement
  • Allow fix-permissions and update-package-permissions scripts to set ownership for customized users (Issue NMS-16406)

by mershad-manesh at May 08, 2024 09:12 PM

April 11, 2024

NantHealth Strengthens Product Leadership Team to Drive Innovation in Healthcare Technology

WINTERVILLE, N.C., April 10, 2024 -- NantHealth, Inc. (NASDAQ-GS: NH), proudly announces the expansion of its product leadership team by appointing three seasoned executives who will spearhead efforts to integrate innovation, automation, and artificial intelligence into the company's product offerings. This strategic move underscores NantHealth's unwavering commitment to revolutionizing healthcare technology and delivering excellence to its customers.

product leadership

Keith Krebs - Senior Vice President and General Manager, Eviti

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.

product leadership

Sean Henson - Senior Vice President and General Manager, NaviNet

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.

product leadership

Alan Brown - Senior Vice President and General Manager, OpenNMS

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

The post NantHealth Strengthens Product Leadership Team to Drive Innovation in Healthcare Technology appeared first on The OpenNMS Group, Inc..

by Jen Fekin at April 11, 2024 03:19 PM

April 10, 2024

April 2024 Releases – Horizon 33.0.3, 2023.1.15

In April, we released updates to OpenNMS Meridian 2023, as well as Horizon 33.0.3.

Meridian Stable Update

Meridians 2023.1.15 contains a couple of bug fixes.

For a list of changes, see the release notes:

Horizon 33.0.3

Release 33.0.3 contains a number of bug fixes and a documentation update.

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.3 is Weeping European Beech.

The post April 2024 Releases – Horizon 33.0.3, 2023.1.15 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at April 10, 2024 03:04 PM

OpenNMS Horizon 33.0.3 (Weeping European Beech)

Release 33.0.3

Release 33.0.3 contains a number of bug fixes and a documentation update.

The codename for Horizon 33.0.3 is Weeping European Beech.

Bug
  • Running the config-tester -a throws an IllegalStateException for ActiveMQ context (Issue NMS-16355)
  • CVE-2024-3094 investigation (Issue NMS-16396)
  • Container image build fails with a wrong reference to deploy-base:ubi9-3.3.0.b265-jre-17 (Issue NMS-16399)

by mershad-manesh at April 10, 2024 03:02 PM

April 02, 2024

NetFlow Traffic Analyzer for Network Monitoring: A Comprehensive Guide

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.

alt

What is a NetFlow Traffic Analyzer?

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.

network monitoring solutions

“Advanced capabilities makes NetFlow analyzers indispensable for organizations seeking to optimize network performance, enhance security, and comply with regulatory requirements."

Benefits of Using a NetFlow Traffic Analyzer

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 traffic analyzer

Key Features of a NetFlow Traffic Analyzer

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

  • Real-time Monitoring: NetFlow analyzers provide real-time data on network traffic, allowing administrators to promptly address performance issues and security threats.
  • Historical Data Analysis: By storing and analyzing historical NetFlow data, administrators can identify trends, forecast future capacity needs, and optimize network resources.
  • Customizable Reporting: NetFlow traffic analyzers offer customizable reports based on specific criteria to gain a deeper understanding of network usage, aiding in trend analysis, compliance reporting, and resource allocation.

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.

netflow traffic analyzer use cases

Choosing the Right NetFlow Traffic Analyzer

  • Scalability: Ensure that the NetFlow analyzer can scale with your network infrastructure. It should be capable of handling the volume of traffic generated by your network without compromising performance. Look for features like distributed architecture and load balancing to support large-scale deployments.
  • Compatibility: Verify that the NetFlow analyzer is compatible with your existing network devices and infrastructure. It should support the NetFlow version used by your routers and switches. Consider whether the NetFlow analyzer can integrate with other network management tools and systems in your environment.
  • Feature Set: Assess the NetFlow analyzer's feature set to ensure it meets your specific requirements. Look for features such as real-time monitoring, historical data analysis, customizable reporting, and security incident detection. Consider whether the NetFlow analyzer offers advanced features like anomaly detection, traffic forensics, and integration with threat intelligence feeds.
  • Ease of Use: Choose a NetFlow analyzer that is user-friendly and easy to configure. It should provide intuitive dashboards and reports that allow you to quickly understand and analyze network traffic. Look for features like automatic device discovery and template-based reporting to simplify deployment and management.
  • Cost-Effectiveness: Evaluate the total cost of ownership (TCO) of the NetFlow analyzer, including initial purchase price, maintenance fees, and any additional costs for scalability or feature upgrades. Consider whether the NetFlow analyzer offers flexible licensing options that align with your budget and requirements.
  • Vendor Reputation and Support: Research the vendor's industry reputation and track record of delivering reliable and innovative network management solutions. Ensure the vendor provides comprehensive support and resources, including documentation, training, and technical support services.
  • Security Considerations: If applicable to your organization, verify that the NetFlow analyzer complies with relevant security standards and regulations, such as GDPR or HIPAA. Look for features that enhance security, such as encryption of NetFlow data and integration with SIEM (Security Information and Event Management) systems.

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.

Success Story

A top global oil and gas company uses OpenNMS to analyze flows from 438 devices simultaneously.

This data allows the team to identify the source and destination of network traffic along with % of usage for the specific interface or link.

The analysis is critical to identifying traffic types, troubleshooting high utilization cases, and capacity planning for individual sites.

See the benefits of utilizing OpenNMS Meridian as your NetFlow analyzer>>

Meridian netflow traffic analyzer

Implementation Best Practices

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.

Conclusion

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.

network monitoring solutions

Learn more

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.

The post NetFlow Traffic Analyzer for Network Monitoring: A Comprehensive Guide appeared first on The OpenNMS Group, Inc..

by Marshall Massengill at April 02, 2024 07:24 PM

March 21, 2024

SNMP Network Monitoring with OpenNMS Meridian

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.

What is SNMP Network Monitoring?

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 network monitoring

SNMP Monitoring Components

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.

snmp network monitoring components

Collecting SNMP Network Device Data

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.

snmp network monitoring data collection

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.

snmp network monitoring

Collecting SNMP Network Trap Data

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.

snmp network monitoring alerts

Storing SNMP Network Performance Data

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.

snmp network monitoring

Conclusion

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.

See Real OpenNMS Meridian Demos

Watch the webinar with Marshall Massengill, Principal Solutions Delivery Architect, OpenNMS.

See demos of SNMP network data discussed in this blog:

  • SNMP Node Performance Data in OpenNMS Meridian
  • OpenNMS Meridian MIB Compiler
  • SNMP Traps with OpenNMS Meridian
  • SNMP Data Visualization with OpenNMS and Grafana
flow data

The post SNMP Network Monitoring with OpenNMS Meridian appeared first on The OpenNMS Group, Inc..

by Marshall Massengill at March 21, 2024 01:35 PM

March 13, 2024

March 2024 Releases – Horizon 33.0.2, 2023.1.14, 2022.1.26, 2021.1.37

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

Meridian Stable Updates

Meridians 2023.1.14, 2022.1.26, 2021.1.37 contains a bunch of bug fixes and enhancements.

For a list of changes, see the release notes:

Horizon 33.0.2

Release 33.0.2 contains a bunch of bug fixes and enhancements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.2 is Old Man's Beard.

The post March 2024 Releases – Horizon 33.0.2, 2023.1.14, 2022.1.26, 2021.1.37 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at March 13, 2024 03:37 PM

OpenNMS Horizon 33.0.2 (Old Man’s Beard)

Release 33.0.2

Release 33.0.2 contains a bunch of bug fixes and enhancements.

The codename for Horizon 33.0.2 is Old Man’s Beard.

Bug
  • Access Denied when deleting a node with admin user (Issue NMS-15746)
  • Device config upload failed with org.apache.sshd.common.SshException: EdDSA provider not supported (Issue NMS-16131)
  • Event parameters with <> not rendering in event/alarm views (Issue NMS-16157)
  • Hikari CP leaking threads (Issue NMS-16345)
  • LdapMonitor does not work when a Minion is the poller (Issue NMS-16349)
  • The script showing the Karaf process status in our container image requires "ps" (Issue NMS-16356)
  • VMware credentials exposed in provisiond log file (Issue NMS-16357)
  • Collectd can’t persist time series data and throwing a NPE with "java.util.List.size()" because "rraList" is null (Issue NMS-16358)
Enhancement
  • Update install script to clear Karaf cache (Issue NMS-16226)
  • Add option to import-requisition command to block until import is done (Issue NMS-16343)
  • Rename User Data Collection feature to Product Update Enrollment (Issue NMS-16353)
  • Configurable option for Kafka Producer CollectionSet buffer size (Issue NMS-16366)

by mershad-manesh at March 13, 2024 03:30 PM

Enterprise Network Monitoring with Flow Data

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.

What is Network Flow Data?

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.

alt

What Problems Does Monitoring Network Flow Data Help Solve?

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?
alt

Where Do Data Flows Come From?

flow data

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.

How Does OpenNMS Manage, Enrich, and Classify Flow 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.

See Real OpenNMS Meridian Demos

Watch the webinar with Marshall Massengill, Principal Solutions Delivery Architect, OpenNMS. See demos of data flows discussed in this blog:

  • Visualizing Flow Data with OpenNMS Meridian
  • Configuring Devices to Export Flows: Cisco, Juniper, pfSense, and VMware vSphere Distributed Switch (VDS) 

  • Visualizing Flows with OpenNMS and Grafana

  • Flow Data Thresholding: leverage flow data to monitor your network for performance and anomalies

flow data

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

Collecting and Enriching Large Amounts of Flow Data

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.

alt

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.

flow data

Conclusion

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.

The post Enterprise Network Monitoring with Flow Data appeared first on The OpenNMS Group, Inc..

by Marshall Massengill at March 13, 2024 02:17 PM

March 06, 2024

Network Monitoring Solutions: Your Complete Guide

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

What are Network Monitoring Solutions?

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.

“Distributed environments require a network monitoring solution that is 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.

network monitoring solutions FAQ

Network Monitoring FAQ

  • Why is network monitoring important?

    Network monitoring is important because it helps ensure the smooth operation of networks by identifying and mitigating issues before they escalate. It also helps optimize network performance, detect security threats, and ensure compliance with regulatory requirements.

  • How does a network monitoring solution work?

    A network monitoring solution works by collecting data from network devices and traffic, analyzing this data to identify issues and trends, and presenting the findings to administrators through reports, alerts, and visualizations.

  • What are the benefits of using a network monitoring solution?

    The benefits of using a network monitoring solution include improved network performance and reliability, enhanced security, reduced downtime, and increased operational efficiency.

  • How do network monitoring solutions help with troubleshooting?

    Network monitoring solutions help troubleshoot by providing real-time visibility into network performance and security, allowing administrators to quickly identify and resolve issues.

  • How can I choose the right network monitoring solution for my organization?

    When choosing a network monitoring solution, consider the scale and complexity of your network, your budget, the features, ease of use and integration capabilities of the solution, and the level of support the vendor provides. It's also a good idea to try out a few different solutions before deciding.

network monitoring solutions features

Network Monitoring Solutions Features

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 data sources

Data Sources for Network Monitoring

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.

alt

Components of Network Monitoring Solutions

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.

alt

Best Practices for Implementing Network Monitoring Programs

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.

distributed network monitoring solutions

Network Monitoring for Highly Distributed Networks

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

OpenNMS Meridian Network Monitoring

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.
network monitoring solutions

Learn more

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.

The post Network Monitoring Solutions: Your Complete Guide appeared first on The OpenNMS Group, Inc..

by Jen Fekin at March 06, 2024 01:18 PM

February 15, 2024

SNMP: Why it’s Still the Best Monitoring Protocol pt. 2

Security and Scalability Are Always Critical

Part one of this series on “Simple Network Management Protocol” (SNMP) looked back at the standard’s origins, explained what “simple” means in this context (hint: it doesn’t mean no complexity!), and why data structure predictability is so powerful.

In part two, we’ll look at the security and scalability benefits this protocol still delivers.

The “S” Could Stand for “Secure”

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.

Standard and Asynchronous Enable Scalability

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.

“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.”

Conclusion

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.

Learn more

We hope this series has raised your interest in learning more about utilizing flows and SNMP in your monitoring.

Please check out our Webinar: Flows & SNMP Explained

Marshall Massengill, OpenNMS Principal Solutions Delivery Architect, demos how you can collect, understand, and visualize SNMP flows with OpenNMS Meridian.

The post SNMP: Why it’s Still the Best Monitoring Protocol pt. 2 appeared first on The OpenNMS Group, Inc..

by Jen Fekin at February 15, 2024 02:25 PM

February 14, 2024

OpenNMS Horizon 33.0.1 (Coast Redwood)

Release 33.0.1

Release 33.0.1 is a re-release of 33.0.0, reverting the async poller changes and fixing a packaging issue.

The codename for Horizon 33.0.1 is Coast Redwood.

Bug
  • Issue installing on Debian 11 Reported by Customer (Issue NMS-16309)
  • REVERT: enable async polling by default (Issue NMS-15738)
  • Missing information in downtime model docs (Issue NMS-10133)
  • R-Core fails to install following the Horizon 30 Install Docs (Issue NMS-14777)
  • Surveillance Dashboard shows acknowledged Alarms (Issue NMS-15448)
  • Access Denied when deleting a node with admin user (Issue NMS-15746)
  • Typo in Configuring Minion via confd README (Issue NMS-15901)
  • "Dismiss" in Usage Statistics Sharing Notice is misleading (Issue NMS-16027)
  • Links in node table open both in current tab and in a new tab (Issue NMS-16047)
  • Fix Geographical Map after vue-leaflet upgrade (Issue NMS-16065)
  • Top of page search displays Show nodes with severity multiple times (Issue NMS-16067)
  • Device config upload failed with org.apache.sshd.common.SshException: EdDSA provider not supported (Issue NMS-16131)
  • Data choices plugin throws a NPE when user clicks on show collected data. (Issue NMS-16151)
  • Event parameters with <> not rendering in event/alarm views (Issue NMS-16157)
  • Users with ROLE_READONLY can add, modify, and delete alarm memos (Issue NMS-16162)
  • Docs: Meridian plugins reference wrong package names (Issue NMS-16164)
  • Fix resource types for default Postgres collection (Issue NMS-16165)
  • Service detail page displays wrong collectd package (Issue NMS-16167)
  • enlinkd logging hibernate errors (lack of unique index) (Issue NMS-16199)
  • Zookeeper 3.4.6 version mismatch in Meridian 2021 (Issue NMS-16209)
  • upgrade ActiveMQ to latest 5.15.x (Issue NMS-16218)
  • Documentation build failing: cannot find antora/xref-validator (Issue NMS-16227)
  • Node structure: fix sorting (Issue NMS-16246)
  • OpenConfig Connector parameter frequency in incorrect unit (Issue NMS-16253)
  • Container flag -t does not pass correct arguments (Issue NMS-16265)
  • Cortex plugin does not start automatically (Issue NMS-16272)
Enhancement
  • Add var-bind section into notification docs (Issue NMS-13273)
  • Provisiond threads description discrepancies (Issue NMS-14766)
  • Metadata DSL: Add metadata interpolation capability onto more threshold fields (Issue NMS-15667)
  • enable async polling by default (Issue NMS-15738)
  • Switch our Docker base to UBI (Issue NMS-15788)
  • Docs: Add install note on DNS resolution (Issue NMS-15792)
  • Extend PageSequenceMonitor to allow basic auth credentials (Issue NMS-15802)
  • Expand BlueCat DNS Data Collection (Issue NMS-15865)
  • Add confd support to Sentinel container (Issue NMS-16149)
  • Docs: Remove deprecated resourcecli section (Issue NMS-16216)
  • Update install script to clear Karaf cache (Issue NMS-16226)
  • Upgrade to latest Karaf 4.3 (Issue NMS-16249)
  • Deprecate VMware 3-5 collection/graphs (Issue NMS-16266)
  • Fix formatting in snmp-graph.properties.d files (Issue NMS-16269)
  • Docs: Update install docs for monitoring database connection (Issue NMS-16286)
  • Update container confd to default Postgres SSL to prefer (Issue NMS-16287)
Task
  • Metadata DSL: Elasticsearch Integration (Issue NMS-15752)
  • Update UI for Admin password change prompt (Issue NMS-15780)
  • Create Initial Node Structure Page (Issue NMS-16037)
  • Update UI dependencies to latest Vue3, feather, etc. (Issue NMS-16045)
  • Node structure page: Union/Intersection category filter switch (Issue NMS-16058)
  • Node structure: add unit tests (Issue NMS-16060)
  • Structured Node List: Add smoke test (Issue NMS-16061)
  • Structured node list: Export CSV/XLS (Issue NMS-16064)
  • Unzip command is missing from UBI images (Issue NMS-16087)
  • Convert Menu store to pinia (Issue NMS-16092)
  • Structured node list: UX Updates (Issue NMS-16103)
  • Structured node list: handle legacy query strings (Issue NMS-16116)
  • Structured node list: UX updates Part 2 (Issue NMS-16123)
  • Structured node list: Merge feature branch to develop (Issue NMS-16124)
  • Convert NodeStructure store to pinia (Issue NMS-16125)
  • Node structure: Add management IP address (Issue NMS-16126)
  • Node structure: Make preferences persistent (Issue NMS-16130)
  • Convert Node store to pinia (Issue NMS-16136)
  • Update Vue UI README with dev workflow instructions (Issue NMS-16142)
  • Convert more stores to pinia (Issue NMS-16144)
  • Convert auth, usageStats and other stores to pinia (Issue NMS-16154)
  • Convert deviceStore etc to pinia, remove vuex from project (Issue NMS-16156)
  • DOCS: Document structured node list (Issue NMS-16210)
  • Docs: Remove reference to opennms-cloud-plugin plugin (Issue NMS-16231)
  • Stalled threads in telemetryd parser (Issue NMS-16243)
New Feature
  • Metadata DSL: VMware Integration (Issue NMS-15753)
  • Metadata DSL: WSMAN Integration (Issue NMS-15754)
  • Metadata DSL: TL1D Integration (Issue NMS-15755)
  • Metadata DSL: JMX Data-collection (Issue NMS-15756)
  • Metadata DSL: XML Data-collection (Issue NMS-15757)
  • Metadata DSL: HTTP/HTTPS Data-collection (Issue NMS-15758)
  • Metadata DSL: Notification Credentials (Issue NMS-15759)
  • Metadata DSL: Ticketer Plugins (Issue NMS-15760)
  • Metadata DSL: Trapd Configuration (Issue NMS-15761)
  • Metadata DSL: JCIFS Monitor (Issue NMS-15762)
  • Metadata DSL: IFTTT Configuration (Issue NMS-15763)
  • Metadata DSL: Repository Configuration (Issue NMS-15764)
  • Metadata DSL: [OPTIONAL] Consistent *-config.xml Configurations (Issue NMS-15765)
  • Metadata DSL: Evaluate feasability to support metadata in Drools rules (Issue NMS-15766)
  • Metadata DSL: Change default poller and collectd configuration files to reflect ability to use metadata (Issue NMS-16016)
  • Metadata DSL: snmp-config.xml & SNMP Profiles (Issue NMS-16028)
  • Metadata DSL: change default opennms-datasources.xml to reflect the possibility of using metadata (Issue NMS-16029)
  • OpenShift: Document the impact of disabling allowPrivilegeEscalation (Issue NMS-16239)
  • Update wording to Product Update Sign Up (Issue NMS-16352)
Story
  • Metadata DSL: Documentation for Metadata DSL updates (Issue NMS-15774)
  • Document change in login password behaviour (Issue NMS-15775)
  • Smoke test for Admin password change (Issue NMS-15866)
  • Admin Password Change: UX Review and Updates (Issue NMS-15867)
  • Admin Password Change: Merge to develop (Issue NMS-15868)
  • User is redirected to landing page after password change is done (Issue NMS-16036)
  • Use pinia instead of vuex in Vue UI (Issue NMS-16043)
  • Add pinia stores to UI but do not yet activate them (Issue NMS-16068)
  • Metadata DSL: Persist poller parameters as meta data (Issue NMS-16146)
  • Node structure: more query params (fs:fid, snmp, sys) (Issue NMS-16197)
  • Remove plugin opennms-cloud-plugin from installation (Issue NMS-16219)
  • Geo Map: enable user-defined map to be the default one (Issue NMS-16229)
  • DOCS: Document Geographical Map user-defined map (Issue NMS-16230)
  • Add node-gyp to fix CircleCI build-ui errors (Issue NMS-16242)
  • News Feed: UI Panel and REST Service (Issue NMS-16282)
  • Web UI for User Data Collection (Issue NMS-16283)
  • User Data Collection: Database / Rest / CM work (Issue NMS-16284)
Epic
  • Opt-In User Data: Name, email and company Collection (Issue NMS-16279)

by mershad-manesh at February 14, 2024 11:44 PM

February 2024 Releases – Horizon 33.0.1, 2023.1.13, 2022.1.25, 2021.1.36

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

Meridian Stable Updates

Meridians 2023.1.13, 2022.1.25, 2021.1.36 contains a bunch of small bugfixes along with other improvements.

For a list of changes, see the release notes:

Horizon 33.0.1

Release 33.0.1 is a re-release of 33.0.0 with a rollback of a change related to asynchronous polling. Horizon 33 contains a bunch of changes, including metadata support in many more configs, a revamped node list, and more...

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

For a complete list of changes, see the changelog.

The codename for Horizon 33.0.1 is Coast Redwood.

The post February 2024 Releases – Horizon 33.0.1, 2023.1.13, 2022.1.25, 2021.1.36 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at February 14, 2024 05:51 PM

February 08, 2024

SNMP: Why it’s Still the Best Monitoring Protocol pt. 1

A Simple and Structured Approach Delivers Big Benefits

If you’re someone with a long history in the network monitoring space, you’ve seen trends in standards and protocols come and go over the years.

In this two-part blog series, we discuss one that deserves a second look: SNMP or “Simple Network Management Protocol.” It delivers lightweight bandwidth requirements, a predictable data format, security benefits, and asynchronous scalability. These advantages make it still one of the best monitoring protocols available today.

SNMP History

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:

  • SNMPv1 worked just fine in a time when networks were still very, very private, and security wasn't a significant concern.
  • SNMPv2 was introduced when the Internet came around, and networks started becoming interconnected. People could communicate to outside networks from computers within their own private networks, exposing their systems and data with SNMP. Security became a concern, so v2 included an authentication component that, unfortunately, became too complex to manage efficiently.
  • SNMPv2c reverted to a previous version of SNMP used by communities with the community name as the authenticator. This has become the standard version of SNMPv2.
  • SNMPv3 includes features to beef up security even further: encryption and authentication of the source. The information inside the envelope is encrypted, and you have the key to decrypt it on the acceptance side. Both SNMPv2c and SNMPv3 are relatively common with v3 being the standard that more security-focused companies are adopting.

A Simple Protocol for Limited Bandwidth

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.

“Monitoring is a complex subject, and no matter how you approach the task, that complexity has to go somewhere.”

Standard Data Structure Delivers Predictability

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.

Conclusion

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.

Learn more

We hope this series has raised your interest in learning more about utilizing flows and SNMP in your monitoring.

Please check out our Webinar: Flows & SNMP Explained

Marshall Massengill, OpenNMS Principal Solutions Delivery Architect, demos how you can collect, understand, and visualize SNMP flows with OpenNMS Meridian.

The post SNMP: Why it’s Still the Best Monitoring Protocol pt. 1 appeared first on The OpenNMS Group, Inc..

by Jen Fekin at February 08, 2024 01:12 PM

January 10, 2024

January 2024 Releases – Horizon 32.0.6, 2023.1.12, 2022.1.24, 2021.1.35

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

Meridian Stable Updates

Meridians 2023.1.12, 2022.1.24, 2021.1.35 contains a bunch of small enhancements to aid in debugging along with other minor improvements.

For a list of changes, see the release notes:

Horizon 32.0.6

Release 32.0.6 contains a bunch of changes including UI cleanups, a number of access/role fixes, and other bug fixes, plus a ton of documentation updates and a new feature to show news and tips from an RSS feed in the UI.

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.6 is Breakcore.

The post January 2024 Releases – Horizon 32.0.6, 2023.1.12, 2022.1.24, 2021.1.35 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at January 10, 2024 04:44 PM

OpenNMS Horizon 32.0.6 (Breakcore)

Release 32.0.6

Release 32.0.6 contains a bunch of changes including UI cleanups, a number of access/role fixes, and other bug fixes, plus a ton of documentation updates and a new feature to show news and tips from an RSS feed in the UI.

The codename for Horizon 32.0.6 is Breakcore.

Bug
  • Missing information in downtime model docs (Issue NMS-10133)
  • R-Core fails to install following the Horizon 30 Install Docs (Issue NMS-14777)
  • Surveillance Dashboard shows acknowledged Alarms (Issue NMS-15448)
  • Access Denied when deleting a node with admin user (Issue NMS-15746)
  • Event parameters with <> not rendering in event/alarm views (Issue NMS-16157)
  • Users with ROLE_READONLY can add, modify, and delete alarm memos (Issue NMS-16162)
  • Events: filter and advanced search / method GET is not supported (Issue NMS-16232)
  • VmwareCimMonitor/VmwareCimCollector not working anymore (Issue NMS-16236)
  • OpenConfig Connector parameter frequency in incorrect unit (Issue NMS-16253)
  • Container flag -t does not pass correct arguments (Issue NMS-16265)
  • OpenConfig server logs invalid sample interval unit ?s when frequency is set to 4 digits or higher (Issue NMS-16280)
  • LegacyDatetimeFormatterTest.testParse fails to parse date time when locale is set to en_CA-UTF-8 (Issue NMS-16288)
Enhancement
  • Add command to Karaf shell to manually trigger Metadata Adapter (Issue NMS-13922)
  • Karaf command to display event details (Issue NMS-15130)
  • Add debug logging to SNMP Property Extenders on match failure (Issue NMS-15743)
  • Remove plugin opennms-cloud-plugin from installation (Issue NMS-16219)
  • Update install script to clear Karaf cache (Issue NMS-16226)
  • Docs: Remove reference to opennms-cloud-plugin plugin (Issue NMS-16231)
  • OpenShift: Document the impact of disabling allowPrivilegeEscalation (Issue NMS-16239)
  • RSS Feeds Panel showing OpenNMS Blog content (Issue NMS-16250)
  • Document RSS feature (Issue NMS-16255)
  • Docs: Create documentation on how to create graph definitions (Issue NMS-16258)
  • News Feed: UI Panel and REST Service (Issue NMS-16282)
  • Docs: Update install docs for monitoring database connection (Issue NMS-16286)
  • Update container confd to default Postgres SSL to prefer (Issue NMS-16287)

by mershad-manesh at January 10, 2024 04:44 PM

December 27, 2023

From Pirate to Proven: 20 Years in Open-Source Network Management pt. 3

Dr. Craig Gallen looks back over his history with open-source network management and the TM Forum.

In the final part of this series, he collects 4 key learnings on how to successfully move open-source initiatives forward.

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?

1) Crisis opens the door to change.

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.

2) Software is a fashion industry.

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.

3) Open-source network management tools need a sustaining revenue steam.

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.

4) Open education, examples, and documentation are critical to adoption.

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.

Conclusion

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.

Learn more

We hope this series has raised your interest in learning more about or even participating in the OpenNMS community. Your conversation and collaboration are what brings open-source solutions to life.

Please take a moment to see how you can get involved.

The post From Pirate to Proven: 20 Years in Open-Source Network Management pt. 3 appeared first on The OpenNMS Group, Inc..

by Craig Gallen at December 27, 2023 03:20 PM

December 19, 2023

From Pirate to Proven: 20 Years in Open-Source Network Management pt. 2

Dr. Craig Gallen looks back over his history with open-source network management and the TM Forum.

In the second part of this series, he dives into the history of interface programs including the rise and fall of TIP and the growth of OpenAPI.

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.

TIP Loses Traction

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.

OpenAPI Gains Wide Support

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.

Part 3

The last part of this series, I’ll wrap up what I’ve learned from twenty years of experience with open-source network monitoring technologies and TM Forum.

The post From Pirate to Proven: 20 Years in Open-Source Network Management pt. 2 appeared first on The OpenNMS Group, Inc..

by Craig Gallen at December 19, 2023 08:22 PM

December 14, 2023

December 2023 Releases – Meridian 2023.1.11, 2022.1.23, 2021.1.34

In December, we released updates to all OpenNMS Meridian versions under active support.

Meridian Stable Updates

Meridians 2022.1.23, 2021.1.34 contains a few small bug fixes.

Meridian 2023.1.11, contains a bunch of documentation updates, bug fixes, some major security-focused upgrades including Karaf and Camel and one fix related to the Metadata REST service.

For a list of changes, see the release notes:

The post December 2023 Releases – Meridian 2023.1.11, 2022.1.23, 2021.1.34 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at December 14, 2023 01:23 AM

December 13, 2023

From Pirate to Proven: 20 Years in Open-Source Network Management pt. 1

Dr. Craig Gallen looks back over his history with open-source network management and the TM Forum.

In the first part of this series, he covers the kick off of the 'open-source pirates' at TM Forum Nice 2004 to open source coming into its own and starting to compete with commercial solutions.

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.

The Telecom Bust Opens the Door to Open-Source

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

OpenOSS Brings Open-Source Full Circle

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.

Open-Source Starts to Compete with Commercial

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.

Part 2

In the next part of this series, I’ll cover the development, adoption and abandonment of interface technology TIP and the rise of OpenAPI in the network management toolset.

The post From Pirate to Proven: 20 Years in Open-Source Network Management pt. 1 appeared first on The OpenNMS Group, Inc..

by Craig Gallen at December 13, 2023 06:09 PM

December 05, 2023

Splunk Acquisition Brings Cloud Costs into Focus

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.

Hazy Cloud Costs

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:

alt

Complex Contracts
You may run into a menu that offers hundreds of ways the services can be priced and combined – by user, feature, device, or more – and end up paying more for the “flexibility” of buying a la carte. It's like a new car purchase where you choose the model, the trim, the colors, and the add-on features as packages or priced separately. It’s not always easy to compare the options: you might find that the price is different for each feature depending on which base model you select, or you even forget to include cruise control!

alt

Per Metric Pricing
Cruise control is a no-brainer, but how can you be sure which optional metrics you should include to track with your monitoring service? How can you know where the problem will crop up? How can you know what data you need to collect before you collect and review the data? Without the ability to see the whole picture, you can end up with blind spots that just happen to be the source of a network-crashing crisis. You could choose to monitor everything, but with a la carte pricing, can you afford it? Or maybe you realize after you’ve signed the contract that you missed critical metrics and adding them requires going back for more budget each time. How flexible is that?

alt

Unpredictable consumption costs
Once you choose your options, the price can still vary. Again, this can be one of the advantages of a cloud-based service, but as we’ve seen in the last few years, this can become a drawback instead. Imagine the same car, but your monthly payment changes based on how much you drive. Cost conscience organizations want to keep spend under control and predictable. As we reach year-end, this is especially important for companies trying to lock in budgets for next year. A cloud-based service loses its scalability advantage if the only way to make the cost predictable is to lock in the usage and not scale to the usage you actually need.

The Predictability of OpenNMS

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?”

Conclusion

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.

The post Splunk Acquisition Brings Cloud Costs into Focus appeared first on The OpenNMS Group, Inc..

by Mike Huot at December 05, 2023 03:34 PM

November 30, 2023

Ask a Network Monitoring Expert

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.

Solve Complex Network Monitoring Challenges

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.

Our Experts

network monitoring questions

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.

network monitoring questions

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.

What to Expect

alt

Friendly chats: Nothing formal here, just relevant information and inspiring conversation with some knowledgeable people from OpenNMS.

alt

Live demos: See how OpenNMS Meridian works and how you can use it to address your most challenging network needs.

alt

Sneak peeks: Be the first to glimpse behind the curtains. We might just share some upcoming features and projects we're excited about.

Want to learn on your own? That works too!

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.

Explore our resources

Visit our website to access a wealth of informative content, including product documentation, resources, and customer testimonials.

Join the community

Connect with like-minded professionals and OpenNMS users on our community forums or chat to share insights and experiences.

The post Ask a Network Monitoring Expert appeared first on The OpenNMS Group, Inc..

by Jen Fekin at November 30, 2023 04:16 PM

November 08, 2023

OpenNMS Horizon 32.0.5 (Deep Swedish Rock)

Release 32.0.5

Release 32.0.5 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

The codename for Horizon 32.0.5 is Deep Swedish Rock.

Enhancement
  • BMP docs could use some TLC (Issue NMS-13891)
  • Provisiond threads description discrepancies (Issue NMS-14766)
  • OpenShift: Documentation (Issue NMS-16108)
  • Backport Drools 8.x to foundation 2023 to address a couple of CVEs (Issue NMS-16179)
  • Integrate hibernate-core related patch from Debian (Issue NMS-16181)
  • Version bump of json for CVE-2023-5072 (Issue NMS-16191)
  • Version bump of jetty to 9.4.53 version (Issue NMS-16192)
  • Bump to the latest netty 4 version (Issue NMS-16193)
  • Version bump of snappy java (Issue NMS-16194)
  • Docs: Remove deprecated resourcecli section (Issue NMS-16216)
  • Post install/upgrade instructions on how to join OpenNMS Community (Issue NMS-16213)
Bug
  • Local Geo Map (using gwt.openlayers.url) working in version 29.0.1 is not anymore in 31.0.3-1 (Issue NMS-15400)
  • Access Denied when deleting a node with admin user (Issue NMS-15746)
  • Map dashlet for Ops Boards references old map systems (Issue NMS-16044)
  • Reports → Chart page does not load graphs (Issue NMS-16085)
  • Event parameters with <> not rendering in event/alarm views (Issue NMS-16157)
  • Add Basic Auth to OpenConfig gNMI for Call Credentials (Issue NMS-16158)

by mershad-manesh at November 08, 2023 04:14 PM

November 2023 Releases – Horizon 32.0.5, 2023.1.9, 2022.1.22, 2021.1.33

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

Meridian Stable Updates

Meridians 2023.1.9, 2022.1.22, 2021.1.33 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

For a list of changes, see the release notes:

Horizon 32.0.5

Release 32.0.5 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

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.5 is Deep Swedish Rock.

The post November 2023 Releases – Horizon 32.0.5, 2023.1.9, 2022.1.22, 2021.1.33 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at November 08, 2023 04:10 PM

October 24, 2023

An Interview with Horizon User, Jesus Palacio: Part 2

We're highlighting Jesus Palacio, CTO of Urbalink Networks, and an OpenNMS Horizon user for more than 20 years.

In the first part of our interview, we got to know Jesus and how he got started using OpenNMS.

In the second, and final, part of our interview, we'll learn how he chose OpenNMS and the benefits he's seen from using Horizon as his preferred network monitoring platform.

What were the criteria you used to choose OpenNMS?

"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."
Jesus Palacio of Urbalink Networks standing

Why do you continue to you choose OpenNMS?

"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."
alt

Urbalink Network's OpenNMS Horizon dashboard

How does OpenNMS help you achieve your objectives?

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

alt

OpenNMS Horizon maps Urbalink Network's network

Can you measure any reduced costs, thanks to OpenNMS?

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

Can you measure any improvements in productivity or time savings?

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

alt

Monitoring the regional status of Urbalink Network's network

What are you looking forward to for the future of OpenNMS?

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

alt

What is your advice to others who might be considering OpenNMS?

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

Learn more

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.

The post An Interview with Horizon User, Jesus Palacio: Part 2 appeared first on The OpenNMS Group, Inc..

by Colby Hoke at October 24, 2023 01:00 PM