Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Orion SLX Purchasing Question

Hey guys & girls, have a couple questions for those with multiple pollers.

We are currently running a single SLX server as a VM with a 3.0Ghz processor. We are nearing 4000 elements and seeing gaps in the data. Support tells me we are over the recommended number of elements for the box. Database is hosted on a seperate SQL server. First question is - is there anyway in Orion to warn that you are missing polls of devices, other then to look for gaps in graphs? Does Orion have no way of warning (event log, etc) that it can't keep up?

We also have a licence for Netflow on the SLX box, but haven't yet deployed it.

It looks like I have to try and sell the purchase of a second SLX polling engine licence to management, but I'm not sure what this means for our Netflow license. Do I have to purchase yet another Netflow licence for the second polling engine? If that is so, will Orion work if I have SLX & Netflow on one box, but just SLX on a second box?

Thanks

Find more posts tagged with

Accepted answers

All comments

borgan

I am a little surprised that you were told to consider adding a polling engine with only 4000 elements in your network. The rule of thumb (and it seems to hold quite well) is that a polling engine should handle 8,000 to 10,000 elements. Of course, that is assuming that the server hardware is up to the task. You mentioned that you have a 3 GHz processor. How much RAM do you have? What is your drive array configuration on both the polling server and the database server? Is there any chance that you have any bottlenecks at the network level?

Also, if your server is having trouble keeping up and you are unable to find a root cause at the physical level, I would definitely NOT add NetFlow to this server. That will likely only make the problem worse due to the intensive nature of NetFlow data collection and handling.

FormerMember

Keep in mind that it's not just the number of elements, it's the polling frequency. While you can do usually do 8000 elements at 12-minute polling intervals, we have customers who want to polling every 5 minutes or every 1 minute. In those circumstances, you won't get anywhere near 8000 elements. And the database and server hardware matter, too.

BryanBecker

It looks like I have to try and sell the purchase of a second SLX polling engine licence to management, but I'm not sure what this means for our Netflow license. Do I have to purchase yet another Netflow licence for the second polling engine? If that is so, will Orion work if I have SLX & Netflow on one box, but just SLX on a second box?

Thanks

If you what Netflow data on any devices being managed by that 2nd poller then you'll need a 2nd NTA license. Basically for any device you want NetFlow data on you'll need a license for the poller in which is polling it.

Yes...Orion will work in that configuration. Like in our network we have 1 poller running VoIP and NTA but the other pollers just run NTA. It works just fine.

BB

Network_Guru

I think the VM adds overhead as well.

If this was a dedicated hardware platform & your polling is left at default, you should be good for close to 8000 elements before having to look at a second poller.

EverestM

Hmm, strange. We were origionally working with 9-minute statistics collection. I yesterday moved it to 12-minute collection, and it hasn't helped the problem at all. The server is 3.0G with 4Gig of ram. The drive on the Orion server is a VM, acting like just a regulard HD ... I don't know the stats on the DB server (managed by our database group), but I'm told it rarely peaks above 5% usage, and is quite beefy. Both servers are hosted in the same colocation, and there is no contention for bandwidth on their interfaces or along the path between them.

Shouldn't have moving from 9 to 12 minute stats collection have helped?

Here is a picture of what I'm seeing -- does this look like the server can't keep up, or should I be looking at something else?

ORION-Gaps.JPG

jonchill

We currently have a remote poller on the end of our WAN link this was more for accurate stats rather than load. When we first put them in, our Main poller was only polling 4000 elements and now it's up to 8000 and running well and our remote poller was originally running around 2000 elements and now its up to 3500.

HTH

Network_Guru

This does not look like you are anywhere near the maximum polling limit.

Do you see gaps in the ICMP graphs as well, or just the SNMP polls?
What is the interval on that CPU graph - 15 minutes?

I find that Solarwinds support has taken a downturn in the past year.
Rather than trying to fix a problem, they take the Microsoft approach & try to sell you more product or tell you to upgrade to the latest version or SP. Their troubleshooting process is weak at best. Quite a change from a couple of years ago when you could call and talk to a knowledgeable person on the phone. I guess that's the price you pay when a company grows too quickly.

EverestM

Well we're certainly not at the number of nodes other people have said they use...

No, I only see the breakups in graphs built by SNMP. The interval on the graph I've shown is every 10 minutes.

I'm not sure what else to try -- getting money from management for a polling engine is going to be next to impossible because we are at about half the number of nodes we 'expected' to be able to monitor - but regardless I have more nodes to enter, and I'm gussing more will just make the problem worse.

The confusing part is that I changed stats collection from 9 to 12 minutes, and the graphs didn't get any better --- shouldn't this have reduced the load on the server, cleaning up the graphs?

FormerMember

It looks like I have to try and sell the purchase of a second SLX polling engine licence to management, but I'm not sure what this means for our Netflow license. Do I have to purchase yet another Netflow licence for the second polling engine? If that is so, will Orion work if I have SLX & Netflow on one box, but just SLX on a second box?

I'm not sure why you're seeing gaps in your data. I don't know if you really need a second polling engine, but I can tell you that if you bought one that it would not impact your NTA license.

Did Support close your ticket, or is it still being worked?

mark_wiggans

EverestM-

Gaps in data can be a vexing issue.
First you have to understand what it is you are actually seeing. Here are a
couple things to check to make sure you are actually missing
data;

For a section of time,
4 or 5 hours, choose several different graphs to look
at.
For each one maximize
the level of detail to where all you see are individual data
points.
Confirm that there are
areas where there are true gaps in data.

This first set of steps will tell
you whether or not you are seeing true data collection gaps or charting object
anomalies. It is important to remember that the chart is trying to match up data
to specific time slots. So in a case where you may be polling every 9 minutes,
but select a graph with an interval of every 5 minutes, you will see what looks
like gaps. If after this series of steps you truly do see legitimate gaps then
we need to see if there is any sort of correlation.

Do they appear at
certain times of day?
Do they appear in both
SNMP and ICMP based data?
Has the Polling Engine
been tuned?
Are there gaps across
all nodes and/or interfaces?

In this particular case running on a
VM system is not necessarily a smoking gun. There is a certain amount of
overhead that this sort of environment presents but it is manageable. One aspect
that may need to be explored is the database server. Many times we see that the
SQL server is not able to keep up with the amount of write requests that are
generated by Orion and its associated modules.