Trouble with https monitors after upgrade to SAM 5.2

Hello all,

I am having trouble with some https user experience monitors after our upgrade to SAM 5.2.

The monitors in question are pointed to URLs on one of our web servers and used to monitor the response of the web services running on the server. Prior the the upgrade I had the https monitor pointed to the url of the web service and all worked fine... but now I am getting 404 errors on the same monitors. I have looked at the application monitor logs for this specific monitor and see no issues with the GET request generated by Orion and being sent to the server. I am able to connect to the polling server which polls this particular web server and can open the web browser on the polling server and hit the URL in the monitor with no errors...

Has anyone experienced this issue?

Best regards,

Find more posts tagged with

https_monitor

apm

https_user_experience

Accepted answers

mharvey

I just worked on a deployment where this was an issue for HTTP monitors. Turns out there is a hotfix to resolve issues with case sensitivity that turned out to be the problem we were experiencing. The issue was being caused by case sensitivity which, in our case, was an issue with these monitors as they were pointing to apache and tomcat sites. Have you applied this fix?

Regards,

Matthew Harvey

Loop1 Systems

http://www.loop1systems.com

All comments

mharvey

Regards,

Matthew Harvey

Loop1 Systems

http://www.loop1systems.com

bmills99

Matthew,

Many thanks! After a closer look at the logs, that's exactly what is occurring with our https monitors. I have downloaded the hotfix and I am currently rolling it out to our polling servers. I will let you know how it goes.

Best regards,

Bryan

bmills99

Thanks again, the hotfix resolved our issues!

bmills99

HELP!

The hotfix resolved the issue with the HTTP monitors but essentially killed all of our SQL user experience monitors. I had to roll back the hotfix I put in place to get our monitoring back up and running. So we are back a square one on the HTTP monitors. I am in the process of opening a trouble case with SW at this time. Has anyone experienced this same issue?

Best regards to all,

mharvey

Bryan,

What was happening with the SQL monitors after the hotfix?

bmills99

Matthew,

The monitors basically stopped working. They would not poll at all. I attempted to manually test some of the APMs. I turned on logging for a few of our more critical SQL monitors and then tested via the web console. The APMs were not logging information at all on the pollers. The web console indicated testing was in progress but no logs on the poller.

Solarwinds case 386209 has been opened for this issue.

bmills99

I forgot to mention that, we (solarwinds support and I) have looked at the windows logs and application logs on my primary poller and could find no issues that would be a smoking gun. I am in the process of pulling diagnostics on the primary poller.

aLTeReGo

Brian, looking at the case notes it looks like Erica may have provided you with a solution. Can you verify if that worked for you?

bmills99

aLTeReGo,

Many thanks for the update, I have reviewed the email from Erica and had a couple of questions concerning the fix. I need to clarify the procedure to replace the job engine and collector. Once I have this information I will roll out the hotfix again and let you know how it goes.

Best regards,

mharvey

You should just be able to run the JobEnginev2.msi and the CollectorInstaller.msi, choose remove, then rerun to reinstall. That will effectively replace the sdf files if that is what they are asking you to do.

Regards,

Matthew Harvey

bmills99

Thanks to all who replied to this thread, we resolved the issue with our HTTP monitors. The hotfix worked as it should. There was an issue on our side when the hotfix was applied which caused the issue.

Thanks again for the input!

Best regards,

skipdog77

I'm having the same issue. I've applied the hotfix and i'm observing..

I've received one HTTPS down after the hotfix, but no others.

Can someone tell me which log file to look in to see the debug logs? I've enabled debug on the templates. I guess I could look at the IIS logs on the servers in question. I can't find where to see the conversation and what error is being returned (in APM)

Skip

edit: I want to add i was seeing the https down messages when it was polling the IP address and not the DNS name.. so i'm having a hard time understanding why the case issue would have impacted my particular issue.

slaj

Hello Skip,

if you enabled debug logging on a template or an application then you should see debug logs for particular applications and their polls under the folder c:\ProgramData\Solarwinds\Logs\APM\ApplicationLogs\AppId{ApplicationId}\

Best regards, Petr Schmeister

skipdog77

Petr,

I started a new thread since this one appears to be mostly related to the case hotfix1.

Thanks

Skip