THWACKcamp 2017 - Orion at Scale: Best Practices for the Big League

Anyone who is having issues with performance or considering expanding their deployment has had to wrestle with the question of how, exactly, to get the performance they need. This session will focus on maximizing performance, whether tuning equipment to optimize capabilities, tuning polling intervals to capture the data you need, or adding additional pollers for load balancing and better network visibility.

In the "Orion at Scale: Best Practices for the Big League" session, Kevin Sparenberg, product manager, SolarWinds, and Head Geek Patrick Hubbard will teach you best practices for scaling your monitoring environment and ways to confidently plan monitoring expansion. They will focus on maximizing the performance of your expanded deployment, and more!

THWACKcamp 2017 is a two-day, live, virtual learning event with eighteen sessions split into two tracks. This year, THWACKcamp has expanded to include topics from the breadth of the SolarWinds portfolio: there will be deep-dive presentations, thought leadership discussions, and panels that cover more than best practices, insider tips, and recommendations from the community about the SolarWinds Orion suite. This year we also introduce SolarWinds Monitoring Cloud product how-tos for cloud-native developers, as well as a peek into managed service providers’ approaches to assuring reliable service delivery to their subscribers.

Check out our promo video and register now for THWACKcamp 2017! And don't forget to catch our session!

Parents
  • I discovered the hard way that EOC isn't a good fit for my environment, and that we can scale our pollers pretty well across 300 miles while having them report to just one instance of NPM--which is ideal, in my opinion.

    Where scaling isn't ideal is when a single chassis switch can consume 1300 elements by itself.  I'd much prefer that SW (somehow) enable me to monitor all my nodes and their ports without having to grow to a second instance of NPM.

    That's what EOC is designed to handle--multiple NPM's aggregating many pollers.  But EOC isn't nearly as fast or responsive as viewing the original info on NPM.  And having to buy multiple NPM's and view them all separately isn't affordable or effective.

    I guess I just need a smaller organization . . .

Comment
  • I discovered the hard way that EOC isn't a good fit for my environment, and that we can scale our pollers pretty well across 300 miles while having them report to just one instance of NPM--which is ideal, in my opinion.

    Where scaling isn't ideal is when a single chassis switch can consume 1300 elements by itself.  I'd much prefer that SW (somehow) enable me to monitor all my nodes and their ports without having to grow to a second instance of NPM.

    That's what EOC is designed to handle--multiple NPM's aggregating many pollers.  But EOC isn't nearly as fast or responsive as viewing the original info on NPM.  And having to buy multiple NPM's and view them all separately isn't affordable or effective.

    I guess I just need a smaller organization . . .

Children
No Data
Thwack - Symbolize TM, R, and C