Jfrazier ✭✭✭✭✭

To properly build a monitor you would use TNSping and an actual query. Before you query the database you would check with TNSPing to ensure the listener is up. If it is not, then the database is not reachable. If it is, then you can run your query to ensure the database is up and responding. Please note there are several…

TNSping will only show that the listener is up. You need to do a simple query to the database to know that it is up and available.

Seems to me in the past things of this sort would pop up about this time of year. They always generated lively conversation.

I feel your pain...and my total point count is not as high as yours.

In your alerts it helps to provide a string of data to indicate where it came from so it is easier to locate the alert rule after the fact. We used a catalog id in the alert rule name and included that in the alert text. The catalog id was a reference from a spreadsheet where we kept a version/modification history as well…

Chrome had also generated the same issue in trying to send a message. I had emailed @"KMSigma.SWI" out of band reporting this issue.

I had similar issues. It appears, at least in my case it was an issue with chrome. I switched over to edge and it is working fine for me there.

mark them as abusive. It provides notification to the Thwack_admins.

Are you just using ping to determine reachability or are you polling specific oid's? I'd start with using SNMP to track interface utilization...if the interface is not being over utilized then maybe there are external influences (routes, DNS - round robin or not all DNS sources have correct data). Also using SNMP you can…

you really need to know what the device is doing during those times...as well as interface utilization. ping is not going to tell you that.

And what is your device doing during those times it is not responding? (cpu utilization, memory, interface utilization, etc.) If it is too busy ping/udp traffic will be dropped first.

What sort of false alarms are you receiving? Ping won't tell you much about congestion...as latency can be attributed to various things.

Nice......

It appears 1.2 is only suspect if the JMSAppender is being utilized.

it is probably looking for all log4j*.jar files to be sure.

version 1.x is not in the vulnerability list..

So if the service is not set to be started automatically, the rule should be set to only alert for items that are set to autostart. Thus other states are ignored.

somewhere between your create a data migration plan and switch over to production there needs to be some validation and testing of the data once it is in place. You need to re-establish new baselines as well.

yes

that is depending on some qualifications. Transient MSMQ queues with nothing in them will not appear to exist. They only exist when there is a message in them. Other MSMQ's that have been sitting empty for a period of time will have their perfmon data age out and will appear to not exist. Transient MSMQ's may best be…

We have been asking for a data warehouse capability for years now. https://thwack.solarwinds.com/product-forums/the-orion-platform/i/feature-requests/data-warehouse-for-long-term-interface-statistics-reporting-trending-and-capacity-planning The good thing is it is still open for voting which means they have not killed the…

^^^^^ This. dynamic groups and/or custom properties are you best bet.

Part of the challenge that would be faced is what happens when resources are scarce? UDP is one of the first protocols dropped. SNMP is a fire and forget protocol. You have no validation the request makes it to the target. Then you have to create different tooling to fit different environments where you may not have the…

This is the concept I created years ago on this topic.

Go with @"aLTeReGo" recommendation, but it never hurts to have an out of band simple/cheap tool to watch the watcher. You always want your monitoring tools to be out of band from production so that monitoring is a little impactful as possible, but you also need something watching the watcher. Otherwise the tree will fall…

Is there a specific reason you want to send a trap to another management system? Is it capable of handling other event types as input? The reason I ask those questions is that yes you can potentially forward a trap but you likely won't be able to modify it. Then the receiving system may show the intermediate server as the…

Be aware that in many cases the uptime value you receive is the uptime of the SNMP agent and not the device/server. You will need to validate that be sure on various devices.

If the system is having a problem causing the kernel to panic you may not have the resources to generate a trap. A trap is a last resort since it is fire and forget and of a protocol that gets quickly dropped if resources are unavailable. So likely this is going to be a heads up this just happened sort of notification. 

First you need to identify a related message in a log file such as /var/log/messages. Then you can work on ways to get the event out of the logfile. I believe there is an ability to watch logs with the agent. As well as in RHEL you can issue the command uptime, it will give you how log the system has been up since the last…

The best thing is to be able to monitor a log to see if there is a specific event you can trigger on. Many of the VM servers can reboot so fast that they are never really seen as down and the only way to know is to either track system uptime (not agent uptime as an agent can be restarted by outside influences) or look for…