In this webinar, you will discover how to enhance capacity planning using advanced SolarWinds® dashboards and techniques. This webinar examines how to make capacity forecasting more effective with custom SWQL and SQL dashboards. You will learn how to increase capacity planning accuracy using trend analysis and performance KPI’s; and how to use advanced forecasting techniques to more efficiently prepare for future resource demands.

What you will learn on this webinar:

• Benchmark & Analyse Current Capacity Requirements: Learn how to go beyond the default capacity planning charts and metrics within SolarWinds to identify issues before they reach critical thresholds and impact performance.
• Analyse Capacity Trends & Key Performance Metrics: Discover how to easily understand capacity trends and get valuable resource utilisation performance metrics using advanced custom dashboards built with SQL queries.
• Forecast Future Growth & Capacity Requirements: Explore how to make more informed decisions on future resource purchases by accurately forecasting capacity using advanced forecasting techniques hidden within SolarWinds Orion®.
• Live Demonstrations & Q&A Session: A Senior SolarWinds Engineer will demonstrate how to implement these dashboards, and provide the custom code and resources you need to import them into your own SolarWinds platform.

Capacity Forecast is one of the features available in the SolarWinds® Orion platform, that allows you to monitor the trends of some of the main KPIs in your network. However, SolarWinds Orion will not analyse the capacity forecast information for every single metric that is being gathered in the platform.

Available out of the box, only CPU and memory at the node level, interface traffic at the interface level, and disk space used at the volume level are compatible with the capacity forecast feature.

The Problem

There have been situations where I would have loved to get the capacity forecast information for other metrics, especially when analysing future capacity requirements for my applications, but as mentioned before, SolarWinds Orion does not give us that info for every single metric.

This might look like a problem, however, SolarWinds Orion stores the historical data for the whole retention period, i.e. the data is available for us, we just need to create the report to show the data in the format we want.

The Report

The following custom Orion report displays the capacity forecast analysis of all the performance counters monitors in SolarWinds Server & Application Monitor, showing the average value of that monitor per month for the last 6 months, the average increase/decrease per day, the warning and critical thresholds (if defined) and the amount days left until the metric reaches the threshold.

This report may be very useful for lots of customers, however, in big installations of SolarWinds SAM, there might be thousands of performance counters monitors, and some of those monitors maybe not as important as some others.

It would be nice if we could filter the performance counters displayed on this report in some way and show only the important ones. We can do this by creating SQL filters with the SQL query used to create this report.

There are three filters that we will use to include the monitors required. In order to edit the filters, we just need to edit the SQL query configured on the data selection of the report.

The three filters used here are and note how I have utilised SQL variables to separate the filter values, which I prefer just to make it easier to define, as it can be edited outside of the SELECT statement:

• @Component: filters by component name
• @Application: filters by application name
• @node: filters by node name

These three filters can be used at the same time if required. As an example, the following configuration would show all the components where the component name contains ‘job engine’ and application name contains Orion and node name contains ‘SW’.

In case you don’t want to use one or more of these filters, just leave the variable with no value (as default).

Real Case

The first time I thought about creating this report was when a SolarWinds customer asked me to create a capacity report that showed the trend of web users on their IIS servers. They wanted to know if their current web servers were currently saturated, and, if they were not, they wanted to know when they will require a new webserver to be added to the pool in order not to impact on the web performance. Typically, a line or bar chart would be used, as this gives a nice clear trend display, but where many lines would be shown, it would make it very difficult to read information out or would require multiple charts. Therefore, a different approach was necessary, hence this report.

In this scenario, we can use this report using the application name filter @application = ‘IIS Web Users’. The ‘IIS Web Users’ application is a custom template I’m using instead of the Appinsight for IIS template due to license restrictions (the NFR licenses are quite small). Otherwise, if you guys are using Appinsight for IIS, I would use the filter @application = ‘Microsoft IIS’ and @component = ‘Current’.

NOTE: the default retention period of SAM is 90 days, which means you will be restricted to this time period of analysis. If you wish to extend it to a period your report requires to cover, this setting can be edited on SAM Settings -> Data and Database Settings. It is important to note, this setting has a significant impact on Database size, as more data is being recorded and therefore please ensure your SQL Server can both store, but more importantly compute resource to allow it to process the higher data volume.

So, if you wish to use a report like this one, please feel free to download the report available below, and please let us know your feedback.

I hope this article has been informative for you and thank you for your time reading it.

I know that there is the option to automatic geolocate devices based on the field ‘location’ available in SNMP, with the following KB detailing how to use this, but:

• who is using that field properly?
• what happens with the rest of the devices? Say devices monitored using WMI, Agent or even ICMP

There is also a way to import coordinates within the GUI of Orion, but this is a manual process, which would need to be performed regularly in order to keep objects on the map up to date.

That’s why in Prosperon Networks we have created a SQL script that will set the coordinates of the devices based on the value of a custom property. This script can be scheduled to be run every day, or any other frequency that you might consider in order to place any new device on the map.

There are just a few prerequisites in order to use this script properly:

• Create a custom property named Site
• Assign the correct Site to each device
• Modify the SQL script adding your locations and the coordinates of those locations in Site: Add more locations just by adding more options in each case.
• Create a job in SQL to run this script every day

BONUS INSIGHT

We can use IP addresses instead of the custom property site if you wish. The script would look like
…

Case

When IP_address like ‘192.168.% then 50.813104

When IP_address like ‘172.16.1.% then 41.429853

In this webinar, you will discover how to increase network visibility & resolve issues faster by integrating SolarWinds® with the NetBrain® adaptive network automation platform. This webinar examines how to visualise your network and simplify documentation using dynamic maps. You will learn how to accelerate troubleshooting using runbooks to automate vital diagnostics steps. Finally, discover how to use workflow integrations with your existing ticketing and monitoring solutions to streamline critical IT tasks.

What you will learn on this webinar:

• Create On-demand Dynamic Network Maps: Learn how to go beyond static network diagrams.Use on-demand mapping that provides end-to-end visibility, and one-click drill down into infinite detail, contextualised to the task at hand.
• Automate Troubleshooting Diagnostics Steps: Discover how to easily identify the root cause of network problems and automate repetitive troubleshooting tasks using runbooks – automatically executed step-by-step diagnostic procedures.
• Integrate All Your IT Tools Into One Pane-of-Glass: Explore how to enhance workflows by integrating ticketing or monitoring solutions to trigger NetBrain to collect, analyse and visualise critical network data in one pane-of-glass.
• Live Demonstrations & Q&A Session: A Senior SolarWinds Engineer will demonstrate how SolarWinds and NetBrain work together, and will answer all of your questions.

One of the common pains in the monitoring world is alerting, and more specifically how to avoid being flooded with false alerts.

What is an Alert

Before we start reviewing how to minimise false alerts, we should define what a false alert is, and in order to do so, first of all, we need to define what an alert is.

An alert is an event that occurs within a monitoring solution where it identifies a potential status or health issue within the ICT infrastructure that can potentially generate issues or problems. Hence a false alert is when an alert is generated but there is no potential issue assigned to that event.

What kind of event can generate a potential issue? Well, this is a tricky question, because what a potential issue looks like will differ among different people and different infrastructure. For some people having a device with CPU 100% is a potential performance issue, whereas for others this is an acceptable condition. There is, and never can be, a one size fits all when it comes to the conditions that require an alert to be generated.

How to Minimise False Alerts in SolarWinds

Can we eliminate all false alerts? I’m afraid this is a very difficult task, however, we can try to minimise them using some techniques and features that we have in SolarWinds® Orion alerts.

We have the following tips for you:

• Monitor what you really need
• Create only meaningful alerts
• Use time delays before triggering
• Use object level thresholds
• Filter common offenders
• Take advantage of Complex conditions
• Custom SQL/SWQL definition alerts

Monitor What You Really Need
It is very impressive when you talk to your colleagues and you tell them how you manage to gather 300+ different metrics from your switch, but, in reality, do you really need everything. Do you just need to know the traffic utilization of the interfaces, CPU/Memory and the VLANs configured?

Monitor only what you really need will avoid temptations of creating alerts for metrics that you don’t really need.

Create Only Meaningful Alerts
Even though you have picked carefully the metrics you really need, it doesn’t mean that all the metrics need an alert assigned.

For example, it is very useful to know how many people are connected to one of your websites. This allows you to correlate this value with other metrics such as database activity, website response time, etc…, but you probably don’t need to receive an alert when the number of users connected is higher than XX. Include this information in the alert output when the performance of the website is poor, but don’t trigger on this single threshold.

Use Time Delays Before Triggering
One simple but powerful trick to reduce the alerts is waiting some time before triggering the alert. This way we make sure the condition that we have defined is true for a continuous period of time, avoiding alerts generated by spikes.

For example, where you are monitoring metrics such as CPU load or interface traffic, it is better to wait for one, two, or even more polling intervals before triggering the alert. Otherwise, just a spike of CPU can potentially trigger an alert when that situation is not a potential issue on your network. In the diagram above, the default High CPU alert would have triggered, when in fact the red cross is a more appropriate point to fire an alert.

On the alert Trigger page, utilise the following setting, converting the polling frequency into a value here, for example, 600 seconds would guarantee at least 2 polls of data are evaluated on a node statistic value polled every 10 minutes.

Use Object Level Thresholds
I think that configuring an alert that is triggered when any volume percentage of space used is more than 95% is a good idea. Full disks are a clear issue on your network because it can stop applications, not allow backups to be stored, etc.

However, what happens with disks that are 10TB+ of size? 5% would mean at least 500GB free space available, and I’m sure you don’t want to receive an alert when a disk still has more than 500GB capacity.

Using custom thresholds would allow you to receive only alerts when the problem is real. In SolarWinds there are two ways to use custom thresholds:

• Built-in custom thresholds: available on some metrics such as CPU, memory, packet loss, interface traffic, errors and discards, custom pollers, SAM components, VM metrics,…

• Using custom properties: for any other metric that doesn’t have a built-in custom threshold, you can create custom properties to be used as custom thresholds. Examples: percentage disk space used, temperature, connections,…

In those situations, the best way to move forward is to eliminate the option of that device triggering the alert. There are two main options here:

• • Mute alerts on that device: this device will stop triggering any alert. Bear in mind that any alert means any alert.

• Editing trigger conditions
• Create a Custom Property to which you can use as a filter to exclude from common alerts
• Priority, for example, could work well for this, where this is an integer and the definition states ‘is not equal to’ 3

Take Advantage of Complex Conditions
In some situations, one way to configure the ultimate alert that you need is by using ‘complex conditions ’. This is an option available in SolarWinds that allows you to create more complex trigger conditions. This feature allows us to:

• Trigger when at least more than one device/object is triggering the alert: for example, trigger the alert when there are at least two devices from a cluster down
• Additional sections: allowing you to mix conditions from different types of objects. For example, alert me when the VM latency is high but the latency of the VM datastore is not high.

I personally use this feature when I use alerts to trigger automation processes for self-healing purposes, as this feature allows you to be very (very) specific on when to trigger the alert.

However, today’s topic is not how to use SolarWinds alerts to automatically self-heal your network, we will leave this discussion for another day.

Custom SQL/SWQL Definition Alerts
When all the options above are not helping you to create the alert you need, then you should try using SQL/SWQL alerts.

This is the most flexible option mentioned on this blog, but also the most complicated, as it requires SQL/SWQL query skills and knowledge of the SolarWinds database schema. However, this way to create the alert will allow you to define (almost) any type of alert.

This type of alert is commonly used when you need to achieve the following:

• Alerts involving historical data: common conditions only alert using the last value polled (unless you use the option of a wait before trigger), but what if you need to trigger an alert based on the average value for the last xx hours?

• Complex filters: when an alert becomes extremely long or complex using any of the other methods, using SQL/SWQL will potentially make it easy to configure. You are in control of the logic

In this webinar, you will discover how to enhance your SolarWinds® platform using advanced dashboard views. This webinar examines how to increase your visibility and monitoring capabilities by going beyond out-of-the-box dashboards. You will learn how advanced dashboards can help you to accelerate troubleshooting by baselining your network. You will discover how to use trend analysis to simplify capacity planning, and behaviour analysis to reduce mean-time-to-recovery.

What you will learn on this webinar:

• Create Powerful Custom Dashboards Views: Learn how to go beyond out-of-the-box dashboards using SolarWinds Query Language (SWQL), SQL and custom tables, charts, queries and HTML to better monitor your infrastructure.
• Analyse Trends & Forecast Capacity Requirements: Discover how to easily view and analyse network trends, and get valuable capacity forecasting data using custom dashboards built with powerful scripts and queries.
• Baseline Your Network & Analyse Behaviours: Understand how advanced dashboards and alerts can be used to baseline your network, so you know what is “normal”, and can quickly identify and address abnormal behaviour.
• Live Demonstrations & Q&A Session: A Senior SolarWinds Engineer will demonstrate how to implement these dashboards, and provide the custom code and resources you need to import them into your own SolarWinds platform.

SolarWinds® Orion is a magnificent tool for troubleshooting performance issues in your network, however when it comes to analysing future capacity or trends, even though it has some good insights, it doesn’t give you the fully comprehensive view that we would like to get, at least the way it is configured out of the box.

Nonetheless, SolarWinds stores historical data for each of the metrics that we monitor for analysis and forecasting purposes, as well as the option to use SQL or SWQ queries directly against the database. Hence it shouldn’t be too difficult to create trends and analyse data if we have a little bit of knowledge in SQL (or SWQL).

I’m not saying that SolarWinds Orion doesn’t have any way to get capacity forecast data if you don’t create custom dashboards using SQL queries. Actually, there are some nice resources available out of the box that will give you valuable capacity forecast data and tell you when your devices will run out of CPU capacity, memory, disk or interface bandwidth.

Let’s get the data

To extract the data from the SolarWinds database, the first thing we need to do is to find the tables that contain the data we want. SolarWinds database is quite intuitive in this matter, and the name of the tables from SQL or SWQL are clear enough to help us to locate the data we need. However, due to the quantity and inherent complexity of the database, there are some content structures which are more difficult to find.

As an example, the following table contains some of the most common metrics that we monitor from our network devices and the SWQL tables where you can find this data:

Let’s test this with a couple of examples that have had really good feedback when we have configured them for our customers as part of our professional services. The first example displays a chart with the CPU time consumed per hour for the last 30 days (or another time period); and the second example displays the amount of time WAN interfaces are over a specific threshold (in the example, over 75% utilization).

CPU Time
Question: over the last few months, are the devices on your network consuming more CPU or less CPU time than their normal baseline behaviour?

I guess that your first thought would be they use more CPU, because we always think that this is the case, but is it true? How can we answer this question?

Actually, if I tell you that your servers are consuming 1000 min of CPU time per hour currently, you wouldn’t be able to answer me if this is a high or a small number, because, as with lots of other types of metrics, you need something to compare these values with, a baseline to tell you what is normal and what is not. Therefore the real question here is how we can create a baseline and calculate the trend of CPU time used in our network.

The following resource sums the CPU time consumed each hour by all the devices monitored in SolarWinds, and displays it in a chart. As we are displaying hourly data, the time frame has to be equal or lower than the hourly retention period (by default 30 days, but we recommend to extend it to 62 days, two full months).

On this example we see that the trend is going down, therefore we are using less CPU time than before, which makes sense, as this chart was generated during Christmas time, where there are more people on holidays and the servers are not as busy as usual.

We can also create some variants of these resource displaying last 12 months (we should group data daily instead of hourly) or display CPU time from critical devices only (using custom properties or name conventions).

If you want to configure this resource in your SolarWinds platform, please follow these steps:

• Go to a summary view
• Add new widget custom chart
• Change the Datasource at the top to Advanced Database Query, and then set the query type to SWQL
• Add the following SWQL Query to the white text field

[code]Select DATETRUNC('hour',datetime) as [Date],
round(sum((avgload * weight)/6000),2) as [CPU Time],
'in Minutes' as [Minutes]
from orion.CPULoad
where datetime >= ${FromTime} and datetime < ${ToTime}
and weight <= 3600
group by  DATETRUNC('hour',datetime)[/code]

• Time period: choose anything equal to or lower than the hourly retention period, for example, Last 30 days
• Data Series: CPU Time
  • More -> Time Column -> Date
  • Calculated series: Show Trend
• Units Displayed:
  • Custom-> min
• Group chart data by: Minutes
• The legend shows: Minutes
• Sample Interval: Every hour

WAN Interface Time Over 75%
Question: are your WAN connections saturated?You might think that, as you have some alerts configured in SolarWinds that emails you when a WAN interface is saturated, that is enough. Further questions exist; are you really going to upgrade a circuit because, once, you received an email saying that the bandwidth utilisation of that link was high? Should you wait until this happens twice? Three-time? In a week? A month? The big issue here is alert analysis is only part of the trend analysis you need to be doing and that does not allow you to answer questions on the utilisation of a key metric such as this WAN connection example.

The following chart shows you the amount of time per day that WAN interfaces are over a specific threshold (75% in this example). In this case there is not a specific limit in terms of time frame for the chart, however the longer the retention periods are, the more accurate date this chart will display.

NOTE: in order to display WAN interface data, first of all, we need to find a way to identify the interfaces are connected to the WAN network and which ones are not. There are several ways to accomplish this in SolarWinds, however, we would always recommend the use of custom properties. For this chart, we are using a custom property called WANInterface, type Boolean, that defines normal interfaces (WANInterface = false) from WAN interfaces (WANInterface = true).

Based on this chart, it is fair to say that the last few days we had a little bit more of traffic (buying Christmas presents during working hours?), except for the last few days, the trend does not show any increase on WAN traffic. Therefore in this situation, I wouldn’t recommend upgrading your WAN links and I would want to correlate this to further event and Netflow analysis to understand what was generating more traffic during these 4 days.

If you want to configure this resource in your SolarWinds platform, please follow these steps:

• Go to a summary view
• Add new widget custom chart
• Change the Datasource at the top to Advanced Database Query, and then set the query type to SWQL
• Add the following SWQL Query to the white text field

[code]Select sum(it.weight)/60 as [Time],
datetrunc(‘day’,it.datetime) as [Date],
‘Time’ as label
from orion.npm.InterfaceTraffic it
where (it.inpercentutil >75 or it.outpercentutil > 75)
and it.datetime >= ${FromTime} and it.datetime < ${ToTime}
and it.interface.customproperties.WANInterface = 1
group by datetrunc(‘day’,it.datetime)[/code]

• Time period: choose anything equal to or lower than the hourly retention period, for example, Last 60 days
• Data Series: Time
  • More -> Time Column -> Date
  • Calculated series: Show Trend
• Units Displayed:
  • Custom-> min
• Line: Stacked Column
• Group chart data by: Label
• Legend shows: Label
• Sample Interval: Every day

Other Trends
The charts we have created for CPU or interface traffic can be replicated for any of the metrics available in SolarWinds such as disk utilization, firewall connections, VPN connections, availability, etc. Just think about which metric you would like to forecast. I hope this article has been informative for you and thank you for your time reading it.

The following week, at another customer, the IT director’s boss came down to the networks department asking when the network is less busy. This company was thinking about doing some stress tests on the network, and he was asking when the best time of the week to perform these tests is. This created a bit of a discussion as some guys immediately replied that the weekend is when the network is less busy, but some other mentioned all those backup jobs configured on Saturday and Sunday. In the end, there was no consensus and the IT director left a little bit frustrated with the situation.

These are just two of the multiple scenarios where IT engineers need to know what is ‘normal’ in the network infrastructure and what is not. In order to find anomalies in your infrastructure, it is essential to have an understanding of what the baselines are.

Baseline your network

The question now is how we can baseline our network traffic, as collecting data is the essential ingredient here. If we have SolarWinds (for this example we will use SolarWinds Network Performance Monitor, however depending on the metric you want to baseline other modules will be required. The tool will store in the database every time we poll data from our network during the retention period. In plain English, this means that SolarWinds will keep historical data of the metrics we get from the devices we are monitoring.

In this example, if we need to baseline interface traffic, I would recommend getting the average of traffic per hour and per weekday. This makes sense to me as, normally, IT engineers create admin tasks with daily or weekly frequency. For example, we take VM backups daily at 23:00 or running configs of our network devices on Sunday at 02:00. If you guys create tasks with a different frequency (say monthly), I would recommend baselining your network based on that frequency (for example based on the day of the month).

Steps to display your average weekday traffic

Having the option to see what is normal and what is not in my network sounds great to me, but the question remains the same: how can we display the data we want on the format we need?

SolarWinds Orion gives us a lot of options to display the metrics we are polling from our network devices, and in situations where we need something a little bit more customized (like the current one) we can use SWQL/SQL queries to display the information the way we need.

If you want to display the average traffic per hour and per weekday on a SolarWinds view, please follow these steps:

NOTE: if you want to create a report instead of a SolarWinds view, the steps are quite similar

• Go to the dashboards you want to edit in SolarWinds
• Customize page

• Add new widget
• Create a custom chart
• Datasource -> Advanced Database Query -> SWQL
• Enter the following query:

• Time Period: Custom
  • Named time period: Average
  • Relative time period -> Last 1 DaysData Series: Total Bytes
• Data Series: Total Bytes
  • More -> Time Column -> Date
• Units displayed: Bytes

• Group chart data by: DayWeek
• Legend shows: DayWeek
• Sample Interval: Every hour

If you have followed the steps above, the chart should look like something similar to this one:

Based on the chart above, we can see that every day we have a spike of traffic around 21:00, and a similar amount of traffic on Sundays and Mondays around 01:00. This makes sense as every day at 21:00 is when we back up our VMs to our internal backup server and on Sundays we backup the VMs to the cloud. However, it is not clear why we have the same spike on Mondays, probably a misconfiguration that I will need to review internally.

What if we want to profile the traffic of one single interface? That is also possible using the following script, with the same steps described before, just add the widget on the Interface Details View (view displayed when you click on any monitored interface).

Bear in mind that now we are displaying bits per second, and not total bytes, therefore in ‘Units displayed’ select Bit/s.

Other Baselines

To be fair, any metric that is monitored in SolarWinds can be baselined as shown above. Think about what is important in your network and create the chart that will display the data you need. Metrics like the following are good candidates to baseline:

• CPU load
• Volume space used
• Availability
• Virtual Machine latency
• Volume IOPs

Thank you for your time reading this article, and please let us know which metrics you would like to baseline in your network.

During the time I was working as a network engineer, one of the tasks I hated the most was when I had to spend several days per month updating those Visio diagrams with the topology information of the network. I remember how tedious it was to SSH to all the switches and routers of the diagram I had to update, and start executing show commands such as ‘show cdp neighbors’ and ‘show lldp neighbors’, or even worse, having to go onsite and manually follow the cables to see where they connected to.

Example of my pain:

Don’t get me wrong, I understand this, it is critical to have updated maps of your infrastructure. I don’t have enough fingers to count how many times an accurate network diagram of a remote site has saved my life (or the company).

So, how can we keep updated maps of our network without compromising the time we have to spend on other tasks? This is where I have a solution for it, using Netbrain’s dynamic map functionality.

Netbrain® Integrated Edition allows you to create and continually maintain up to date diagrams of your network including layer 2 connections, layer 3 connections, even extending connections through an MPLS/VPN cloud. This means a full picture of the connections of your network devices, all fully automated, and with the option to export these maps into Visio, maybe to share with an external consultant or service provider.

Let’s see Netbrain in action: first, let’s create a map of the site I want to document. It is extremely easy to do this in Netbrain, just add the devices from that site on the map, and Netbrain will do the rest (i.e. the connections):

I’ve created this map displaying layer 2 connections between the devices, but I could have displayed layer 3 connections if I wanted, or also add other types of information, such as BGP data, STP topology data or even maintenance information.

I like multicast (sorry!):

First, it’s time to create a task to discover any new neighbour connected to any of the devices that I have added to Netbrain. I can do this by creating a discovery task in Netbrain that discovers all the live network with a discovery depth of 1. If I also wanted to discover the neighbours of the neighbours of the devices in Netbrian, I should configure discovery depth of 2. For the neighbours of the neighbours of the neighbours, discovery depth of 3, etc….

Now that Netbrain has added any new neighbour into the data model, it’s time to update the connections in between devices. This step is also important because sometimes the interfaces used to connect devices change, maybe from g0/1 to g0/2, or even from VLAN 100 to VLAN 200. To do this, I will create a benchmark task that will build the new topology based on the new information gathered. I will run this task daily, although it may also be triggered weekly, monthly, etc as I did with the discovery task.

Let’s get stuff updated:

As you may have noticed in the picture above, there is the option to export these updated maps to Visio format as part of the benchmark task, and either replace the existing Visio diagram or create a new version of it. Netbrain completes the circle, from creating a map, keeping it updated, and saving it as a Visio diagram.

Now the map I have created will be updated automatically and saved in Visio format, all done just in a few minutes. I think I deserve a break

It is not a secret that SNMP is a little bit of a mess when we need to know whether a device is compatible with a particular OID. The only way to be sure about it is by testing the OID against the device, and the result of this test will depend on several variables such as device model, firmware version, firmware package (IP Base, IP Services…) , features enabled (EIGRP, HSRP …) or even how the features are configured (BGP in basic mode or AF mode).

Therefore, in the real world, we regularly see that customers assign the custom pollers to any device that ‘should’ be compatible with them. And this often generates a bunch of incompatible custom pollers that in turn means Orion is performing unnecessary polling, is causing ‘no data’ errors in the interface, overall increasing the UnDP polling rate and the load on the polling engines unnecessarily.

What can we do to solve this?
One way would be testing every single OID on each device in order to ensure the custom poller is compatible. In my opinion, that is often too much time consuming where a lot of assignments are applied.  Another way is by checking within the database to look if any custom poller that is assigned to a device but is not returning any value, i.e. that device is not compatible with that OID.

The Solution
We’ve created this report that will show the devices that have incompatible custom pollers, and the details of custom pollers that are not compatible. In a nutshell, what this report does is to check if there is a value for each custom poller assignment within the database via an SWQL query. Where a custom poller assignment does not have a value within the data fields, this means that node is not compatible with that OID. Included is an exclusion to look for devices that are currently not replying to SNMP queries, just to make sure we only add those nodes where SNMP is working fine.

Here is the output from the report, where you can clearly see the devices and the assigned pollers that are not returning any values:

But, in my opinion, this report is not perfect yet, I know it looks nice and shows you which are the custom pollers that are not working, but, in order to delete these custom pollers, you have to manually do it.  What can I suggest? I always like to automate things (I know, I’m lazy), hence I created a PowerShell script that uses the SolarWinds® API to identify those custom pollers that are not working and delete them. I run this script upon a Windows schedule task daily to make sure no incompatible custom pollers are assigned in my SolarWinds installation.

Note: Before running this script please ensure you have a current backup of the database

I hope this blog article helps you clean up your Orion platform and aid keeping it clean and healthy.