SolarWinds error messages--share the ones that you think need to be improved!

We've all experienced those unhelpful, frustrating, support-call generating error messages that make you think "if this would have been written better, I would have been able to solve the problem myself without calling support." What error messages in SolarWinds Orion products can you share with us that you think we should re-write? Feel free to share screenshots along the product name, and how/when you got the error message. We promise to take a look at what you share!

Find more posts tagged with

ux_feedback

Accepted answers

All comments

rschroeder

I'll offer a philosophy regarding error messages. If a condition warrants a message, the message should be clear and intuitive, and should include references or links to how to remedy the condition.

An example from the Thwack logs is every case where someone has requested help with an "object reference not being set to an instance of an object." If you aren't familiar with the backend process, you won't know what this means unless you research it. https://thwack.solarwinds.com/search.jspa?q=not%20an%20instance%20of

After digging through various frustrations of other users, and sundry guesses (rebuild your view, try using a different brand of web browser, etc.), this Thwack entry seems to provide enough information about the problem, and its fix, that helped me better understand the error alert: Universal Device Poller: Browsing MIB tree results in "Object reference not set to an instance of an object."

In basic English, an "object reference not set to an instance of an object" seems confusing and paradoxical. Every error message should be crafted to both be intuitive, and provide either instructions to directly remediate or investigate the error, or a link that has that information. Obviously if the link ever changes, the application referencing the link must automatically be updated simultaneously--which makes it better to provide the fix in the error instead of a link to the fix for the error.

For this particular error, I understand it to mean "A custom poller has been created and remains assigned to nodes that have all been deleted. Please remove all custom pollers assigned to nodes before deleting the nodes."

Why not say that instead? Or why not provide this information in the error, or a link to this information somewhere in the logs:

"A custom poller has been created and remains assigned to nodes that have all been deleted.

This condition normally would be automatically corrected when the database maintenance job has successfully completed running. Verify that automatic database maintenance is scheduled and is completing successfully by going here (insert path & links to the area where this solution is located).

To prevent this condition, use the UnDP tool to remove custom pollers from nodes before deleting the nodes.

To manually correct this condition, open the UnDP tool, expand it down to the node level, expand that node that will be deleted, and view/remove all pollers assigned to the node by right-clicking and unassigning pollers from this tool."

I was lucky enough to get this information from @Malik_Haider here: Universal Device Poller: Browsing MIB tree results in "Object reference not set to an instance of an object."

Of course, the BEST SOLUTION is for UnDP and NPM to be smart enough to unassign all custom pollers to nodes as the nodes are deleted. But barring that improvement, errors should be intuitive--even when taken out of context--and should provide the steps necessary to correct the problem.

Another lovely error is this one:

I'd be totally supportive of more / better information in this kind of situation. In this case I am building a new report to show the status of cdp / duplex in all Cisco 45xx chassis switches, and either I picked too many devices/ports, or I built it incorrectly in some other fashion. But the error tells me nothing about how to fix it. At least it DOES say to capture the logs & talk to Support. But that's involving Support, which hasn't had the greatest reputation for timely communications or resolutions of issues in recent years. Another issue entirely, which I'd like to avoid by making a great product better for having intuitive and complete explanations, answers, and resolutions for every error seen. I know that's not possible--but it's an ideal to reach for.

rschroeder

I'd link to think there'd be easier ways to understand & remedy this error:

When I click the link I'm taken to a page of the last 200 unknown traffic events, in Admin > NetFlow Settings > .

Often I'll see subinterface / SVI NetFlow sources listed, along with a handy link to add them into NetFlow. Well, is that always the right thing to do? I can imagine some options:

A link that adds ALL unregistered or unknown NetFlow sources to NTA
NTA automatically accepting this data and adding the sources all by itself, without any action by me
Advice about when to add these subinterfaces or SVI's to NTA, and when NOT to add them.

Some mighty fine options have been added to NTA in this area:

But even with these options, I keep getting the notifications. Some experienced folks I've talked to say I should NOT add these unknown interfaces--that they're already covered by info from Loopbacks and the like, which means the alerts are false ones. I'm not sure I trust this advice. But confusion about the error is not uncommon; search for people asking about it in Thwack: https://thwack.solarwinds.com/search.jspa?q=NTA%3A%20Unknown%20traffic%20was%20received

A better solution would be one that explained in detail the error made by someone when setting up a device to send NetFlow info to NTA, how they probably did it incorrectly, and how you can correct it. AND the answer for this would also provide links or descriptions for how to correctly implement NetFlow on common equipment. The descriptions would have to be detailed enough to use as a true guide for doing it right.

A fine solution would be one that takes care of the issue automatically and begins monitoring & recording & alerting on the NetFlow data without any intervention by the NTA administrator.

rschroeder

Here's a fun error to troubleshoot / understand:

I got this when trying some options I read about in Thwack. The goal was to discover all ports that are operating in half duplex.

It's not a helpful error, despite the amount of characters. It should say how to correct the problem, or point me to a resource for doing so.

How would you correct this error?

meech

To your point Richard, yes indeed! The best is the craft the UI in a way to prevent error messages. I love this "Of course, the BEST SOLUTION is for UnDP and NPM to be smart enough to unassign all custom pollers to nodes as the nodes are deleted." In the meantime, perhaps there are some small error message improvements we could focus on, so, keep the ideas coming!

rschroeder

Here's one from another user--this error belongs here, I think:

Maximum request length exceeded NPM in 12.0