11 Replies Latest reply on Mar 17, 2016 12:32 PM by ikomrad

    Identity of critical logs please


      I would like to know the name and file location of all of the critical logs that one should monitor relating to Orion NPM. Whether it is installation, repair, upgrade or just day-to-day operation, I want to know which logs server what purpose so I know what to look for.

      Thanks for the help.

        • Re: Identity of critical logs please

          run this: "C:\Program Files\SolarWinds\Orion\SolarwindsDiagnostics.exe"

          It's pretty self explanatory

            • Re: Identity of critical logs please

              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


                • Re: Identity of critical logs please

                  The important logs are in there, so you can get the names and do a search on the filesystem to get the exact path

                    • Re: Identity of critical logs please

                      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?

                          • Re: Identity of critical logs please

                            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.)

                            • Re: Identity of critical logs please

                              Hi Freemen,


                              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

                              => SolarWinds.JobEngineService_XYZ.txt

                              => SWJobEngineWorker_XYZ_%property{WorkerProccessSession}_[%processid].log

                              Orion Job Scheduler

                              => SolarWinds.SchedulingService_XYZ.txt

                              Alerting Engine

                              => swalert.log

                              Orion Network Performance Monitor

                              => NetPerfMonService.log

                              => Debug.log

                              Information Service

                              => InformationService.log

                              Orion Information Service v1/2

                              => Orion.InformationService.log

                              Orion Module Engine

                              => NPM.BusinessLayer.log

                              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.

                              2 of 2 people found this helpful
                    • Re: Identity of critical logs please

                      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!