Goliath Performance Monitor (GPM) Advanced Watch monitors your Windows servers/workstations by executing any Windows program, command, script, or batch file executable that you provide. It runs the executable periodically on the monitored server/workstation according to a schedule that you specify. 

Configure the Monitoring

1. To create a new monitoring condition, navigate to the Management - Monitors page and click New.
2. For the Group dropdown, select a group in which to store the rule. This is for organizational purposes in the Monitors display.
3. In the Type dropdown, select Advanced.
4. Name the Monitoring Rule via the Name field, as well as define the description and the severity.
5. In the Devices tab, select the devices to assign to the monitor.
   1. Please note, a machine can only be applied to one VMware ESX/ESXi Host monitoring rule type at a time.
6. The Options tab is where you will define condition(s) to be monitored.
   1. In the Program Name field, define the name of the program that Goliath will run. 
      1. For example, Windows Powershell, Command Line, etc.
      2. This must be a fully qualified program name path.
      3. In order to access the network share, the agent must have rights to the share
      4. Environment variable substitution is supported when bracketed with the percent character, for example, %SystemRoot% 
      5. Examples:

         1. Windows Powershell

            C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

         2. Command Line

            C:\Windows\system32\cmd.exe

            \\1.1.1.1\c$\temp\test.bat

   2. You can optionally specify an Executable Time-Out value and Goliath will terminate the executable if it does not complete on its own before the timeout expires.
   3. In the Cmd-Line Options field, define an 'Argument' string that will be passed to the program named in the Program Name field
      1. Please note, the parameters are case sensitive and must be upper case.
      2. Environment variable substitution is supported when bracketed with the percent character; for example, %SystemRoot%.
      3. 9 different path variables are supported as well using macro substitution. 

         1. The macro &Pn can be referenced anywhere in the string, where n is 1 through 9.

         2. The macro definition can then be defined in the GPMServer.cfg file in the Bin directory as AdvancedWatchPathn, where n is 1 through 9. For example:

            1. "AdvancedWatchPath1": "C:\\Temp\\Test1",
               "AdvancedWatchPath2": "D:\\Temp\\Test2",
               "AdvancedWatchPath3": "C:\\Temp\\Test3",
               "AdvancedWatchPath4": "C:\\Goliath\\Scripts\\Test4",
               "AdvancedWatchPath5": "C:\\Temp\\Test5",
               "AdvancedWatchPath6": "C:\\Temp\\Test6",
               "AdvancedWatchPath7": "C:\\Temp\\Test7",
               "AdvancedWatchPath8": "\\\\10.10.10.1\Test8",
               "AdvancedWatchPath9": "GDEV"

            2. Note, in the GPMServer.cfg file all backslashes must be escaped.
      4. If you are returning an Exit code from your script for processing in Goliath, please see the next step for some options surrounding how you call the script.
      5. If referencing a file, the location will be based on the machine where the execution is taking place. If the file is not local, the agent must have rights to the network share/location. 
      6. Examples: 

         1. Windows Powershell:

            "& 'C:\Program Files\MonitorIT\Scripts\test.ps1'"

            $reg = ((GP -Path 'HKLM:\SOFTWARE\Citrix\VirtualDesktopAgent\State' -Name Registered).Registered); exit $reg

            "& '\\10.20.20.20.\Scripts\test.ps1'"
            

            "& '&P2\"& '&P2\"& '&P2\"& '&P2\Scripts\test.ps1'"
            "& 'C:\Temp\&P4\Scripts\test.ps1'"
            CreateFiles.ps1'"

         2. Command Line

            net stop Spooler

   4. In the Exit Code field, optionally define an exit code. When an exit code is defined, the Goliath Agent will make compare the script/programs exit code to what is defined in the rule. If the comparison fails, an alert will be generated.
      1. For example, if the Exit Code in the rule configuration is =0 but the program/script returns an exit code of 5, an alert will trigger.
      2. For Exit Codes coming back from a PowerShell script, there are two configuration options:
          
         1. Option 1 - define the Exit Code in your PowerShell using [Environment]::Exit(###) where ### is the Exit Code number you want to pass back to Goliath. 

         2. Option 2 - define the Exit Code using a powershell variable within the script, for example $exitCode = #. When using a variable for the exit code, you then want to call the variable in the Cmd-Line Options field with the following format: 
             

            "& 'c:\commands\ExitCodeTest.ps1'"; exit $exitCode

   5. The optional username and password fields are where you would, if necessary, define a user that the Goliath Agent will use to run the executable in this user’s security context.
   6. In the Start Directory field, optionally specify the location where the agent will create the process and run the executable from.
   7. Set the Show Program Window check box to have the executable window GUI appear on the screen or uncheck to run the executable in the background; hidden. 
7. The Schedule tab of a monitoring rule allows users to define how frequently the rule will alert. This can be done by adjusting the following fields:
8. Alert Every Time: Defines whether an alert is generated every time the conditions are on the previous tab are met.
   1. When checked, an alert is generated every time the specified condition is met.
   2. When unchecked, the alert is only generated if the alert conditions are met, and the Minimal Notification Interval, see below, is exceeded since the last alert for this type.
9. Minimal Notification Interval: Defines the minimum amount of time that must elapse between events for the specified condition before another alert will be generated.
   1. For example, if the interval is 15 minutes and the condition is being met every 3 mins, you will receive 1 alert every 15 minutes instead of being alerted at each occurrence.
      1. However, each alert occurrence is considered unique based on the details. For example, an Event Log alert is considered the same based on being the same Event Type and ID, from the same server/workstation.
   2. The Alert Every Time checkbox must be unchecked in order to use this option.
   3. For ServerWatch IP Services, this also defines the minimum elapsed time since a service is first detected as down or failed before an alert is generated.
10. Maximum Notification Interval: Defines the maximum number of times you want to be notified during a continuous failure situation.
    1. The default value of '0' means infinite; no maximum is defined so you will continue to be notified according to your Alert Every Time and Minimal Notification Interval settings.
    2. A non-zero value means that after you have been notified the number of times defined in the Maximum Alert Notifications, and according to your Alert Every Time and Minimal Notification Interval settings, you will not be notified again.
       1. For example, if "5" is selected, the event will alert for the first 5 events and all additional events will be ignored.
11. Notify On Restore: Defines whether a 'Restore' alert is generated if you have previously been alerted due to a failure.
    1. For example, if CPU has been 90%, and then dropped below the alert threshold, the notify on restore email will inform you that the condition has returned to a normal state.
    2. There is always a Notify on Restore for a ServerWatch type alerts.
12. Service Check Frequency, Every: Defines the frequency with which the service specified for this Monitoring Rule is checked. It is no recommended to do this check any fewer then 3 mins. 
13. Alert 1^st Time After X Failures: Define a value 1 or greater that defines how many successive failures should occur before the 1^st alert notification 'Action' is executed.
    1. The Alert Every Time and Minimum Notification Interval settings do no become applicable until after this threshold setting is exceeded.
    2. The default value for this setting is blank which means not applicable. When not applicable, the Alert Every Time and Minimum Notification Interval settings are active immediately and the 1^st alert does not occur until the Minimum Notification Interval threshold is equaled or exceeded if it is active.