run this: "C:\Program Files\SolarWinds\Orion\SolarwindsDiagnostics.exe"
It's pretty self explanatory
Thanks jtimes, but that is not what I am after. I want to know what the important logs are by name and what they are used for so I can:
1. Troubleshoot some issues myself, and
2. Learn more about Orion functionality
The important logs are in there, so you can get the names and do a search on the filesystem to get the exact path
Yes, but surely I don't need to be concerned with all of the logs that are in the diagnostics app. Aren't there a few that you can identify that would be useful in day-to-day performace and troubleshooting of Orion?
Most, if not all of the useful log files are in C:\Program Files\SolarWinds\Orion. There names are exactly what they are; such as AlertEngine.Log is the Alert Engine log.
I can honestly state that after several years of running Orion I have only looked at one log file on a regular basis (swdebugMaintenance.log.) That is the nightly maintenance log, and haven't even looked at it since version 8.5.
It has been my experience that if you setup some system level alerts and alarms; as well as reviewing the Last 24 hour Events Orion pretty much runs itself as long as the hardware and OS are good (oh and thats where the majority of my issues have came from; which is outside of any of the Orion log files.)
2 of 2 people found this helpful
The SolarWinds Diagnostics gather files that are useful to troubleshoot issues. It would be inefficient to use it for day to day performance purpose.
You should instead keep an eye if the services are running and check the Event logs.
You can access through WMI some information about most of the services like if you were in front of the perfmon console.
Concerning the Database, a DBA should be able to tell you what to monitor on it (file size, fragmentation of the indexes, disk performances)
Orion NPM is not a monolith and has therefore multiple services performing their own duties.
When you start looking at an issue, first identify which service is causing problems, then identify the log files that the service or component is generating. It is hard to detail you everything as this is on case per case basis that you figure out where is the information you need...
Orion Job Engine
Orion Job Scheduler
Orion Network Performance Monitor
Orion Information Service v1/2
Orion Module Engine
Orion Syslog Service
=> Review the SolarWinds.Net events.
Orion Trap Service
=> Review the SolarWinds.Net events.
Other log files are created during the installation or when you apply a SP.
Others are created by Utilities (e.g. UnDP tool => UniversalDevicePoller.log) or by the DB Maintenance.
How to increase Logging Level: \Program Files\SolarWinds\Orion\LogAdjuster.exe
Remember to set the options to their initial levels once done your testings.
If I did not describe a file (which is the case I am sure :), please ask.
Thank you so much Yann. That is the level of detail I was looking for. Appreciate it.
Larry - Take a look at the alertlog table in the database. This is where the result of the trigger actions are stored.
This is a great post. It has good info for newly minted SLW admins who do not go through any application training prior to be given responsibility for supporting and configuring the application. It's the proverbial being thrown into the pool to learn to swim. The video course is pretty good, but if a written introduction works better, I don't know where to point you. I am just getting a grasp on what the individual services do, where to configure them, and where their log files are located for monitoring and troubleshooting purposes.
Speaking of log files, I discovered the logadjuster utility yesterday. It lets you configure the logging level, max file size, and # of files retained for each service. I learned that everything had been set to debug by my predecessor, and set all of the logs to "warning" and above level. If you need to troubleshoot a module, you can set it to "debug" level until you are done. Don't forget to turn it back to higher level of logging when you are done, otherwise the hard drive may fill up. Also, debug level lowers the responsiveness of the application. My web console was timing out a lot until I turned down the logging level. Now it's pretty zippy!