IT Operations Management (ITOM)

Monitoring ACI ports that are not externally reachable with HP SiteScope

Monitoring ACI ports that are not externally reachable with HP SiteScope


SiteScope offers application monitoring capabilities which can help with monitoring your ACI ports. Here is a detailed situation to describe how to best utilize these capabilities.

Let’s say we have the SiteScope server running to monitor various information of the server whether on Windows or Linux such as Ping response, CPU, Memory utilization etc. We now want to monitor the ACI ports which are actually the Query ports for the services running on the windows server queried through the browser. So, by hitting that port into the browser gives you the running service details on it in an unformatted XML form. The only problem with these ACI ports is that they are not accessible externally—meaning we can’t query the status of the ports externally, but we can still avail the services.


So, this Perl script has been developed to monitor the ACI ports running on the Windows server. This script is actually an Agent-Based program which gets deployed automatically on the server and pulls out the required status information. The advantage of this script is that we don’t need any TELNET or SSH services running on that server. This script uses various powerful mechanisms to get into the server. It uses various enhanced policies to get full, detailed information about each check—which particularly includes, “overall status of the port”, “database connectivity”, “queue database connectivity”, “documents size”, “index-queue queued size” plus many more.


The second advantage of this Perl script is that it is universal and we don’t need any kind of utility or third-party software to be installed on the server to get this done. Otherwise, we have many tools present in the market such as Openssh, SSH for Windows, etc. that need to be installed for performing such tasks. The reason behind this is that some customers may not be willing to install any third-party software on their Windows servers. This script easily accepts the Windows platform features and uses Windows based out-of-box components.


Hence, this script does not requires any Telnet, SSH, utility or any software on the end servers to which we are monitoring.

The third advantage of this script is that it is universal, and can be integrated with any server which knows the trap it sends. As of now, we have integrated it with SiteScope server. In this way, Script is doing its task and SiteScope responds. We can send alerts/E-mail/SMS from SiteScope server if the script founds any errors on one or more checks on one or more ports.


The fourth advantage of this script is that this script is so thorough in its task that it can report about the exact problem of the service status it finds to the SiteScope server. With this knowledge in hand, SiteScope server can send the alerts accordingly.





This script first checks for the Ping response from the end-server it is monitoring. After it gets the response, the script starts working on creating a Network-Virtual-Path (NVT) and using the NET-Bios mechanism to get into the server. After creating the NVT-path, it updates the Windows NVT table and adds it into the database for further use, allowing for an updated cache every time.

Once the table has been updated, it creates an agent which actually is a function that knows what to do in respective server. Once the agent has been created, this script again uses BIOS to deploy it on the respective server. Once the check has been made to see if the agent is deployed correctly, the Perl script tells the agent to run and gather the response. Once the response has been received, it forwards it to the management server and then various checks need to be performed to get the real-time status of each port on the server. If it finds errors or an unexpected status, it reports it to the SiteScope server to respond. The SiteScope server—which has already been configured in a way to react based on the value it gets, sends an e-mail to the concerned team.






This script has many benefits:

  2. No need to install any third-party Software on the end servers
  3. Can be integrated to any server
  4. Less time-consuming than traditional methods





The only pre-requisite for this is:

  1. Should have Perl v5 or latest installed on the server from where we are running this script.
  2. Ping response is required for the end-server to monitor


Where we can use it?


As of now, this Perl script checks the Http Status code and queries about the status of any ACI ports.


 But this script can efficiently be used to:

  1. Query any ACI ports status running on the servers
  2. Receive information from the end servers or issuing commands remotely
  3. Monitor any Website that are not accessible externally
  4. Make any checks on the server which are not open externally
  5. Check on any XML response


Steps involved when integrating with Site-scope



In the script, we can see, the column name “CUSTOM VARIABLE” where we need to change host <should be IP address>, Port, Username and Password.


my $host = '<must be IP address>’;                        # Change with care, if required

my $pass = '<Password>';                                          # Change with care, if required

my $user = '<user name>';                                          # Change with care, if required

my $port = qw(20000 21000 22000);                   # These variables must be set prior to running the script



2. After changing the values, rename the script starting with the hostname, followed by underscore and script name. For an instance, if there is a server “alvn4masmc01”, then rename it to “alvn4masmc01_Sis_url_grabber” and placed in C:\SiteScope\scripts folder.


3. Once done, go to the SiteScope server, and go to “master.config” file located in C:\SiteScope\groups. Open it in an editor, and look for the below lines, if not found add it there :; .py; .php; .exe;


_scriptMonitorErrorMsgs2=Failed to.* Error code:


NOTE: Take a backup before doing any changes in the file.



  1. Once completed, open the SiteScope URL, and perform the configuration as shown in the below screenshots :

First, deploy this script on the server we want to monitor with the following parameters :

Go to properties tab of the Script monitor, and put the details as:

Name -           “alvn4masstr3_ports_query”

And, monitor run settings will be according to the frequency as managed.


In script monitor settings > Skip entering the values for “Match expression” as this is going to be handled by “Calculated metrics formula”.


Now, go to Calculated metrics tab >enter the Expression as


“((<<status>>== /\d/) || (<<status>>== /\d\d/))”


and click validate.


If not validated, then it means, there is some error in writing the expression. This expression is crucial and belongs to both SiteScope and the script. It actually acts as an “Adapter” which transforms the value into a SiteScope action. The same has to be in the “Alert-templates” so that upon getting the value, it sends an alert with the service name it found as an error.


Last, go to threshold settings >

Error if: status > 0

Good if: status == 0

Note: This can be set according to your policy configuration


Once done, the script will start running.


Here, you can see, the exit value is “0” which means “No error”.



These below errors are based on the port 20000, and will be different for different ports. Error=1 will be same for all the ports.


If Error=1:

Reason: “Ping response not received from <host>”

Alert: Ping response is not coming when trying to get status of the port 20000 on <host>.

If Error – 2:

Reason:   “overall status of the port is not “SUCCESS””

Alert: Overall status of the port 20000 on <host> is not SUCCESS.

If Error – 3:

Reason: “Data-sift connectivity status is not “true””

Alert: Data-sift connectivity of the port 20000 on <host>has not found the status as “true”

If Error – 4:

Reason: “Database connectivity status is not true”

Alert: Database connectivity of the port 20000 on <host>has not found the status as “true”

If Error- 5:

Reason: “Queue connectivity status is not true”

Alert: Queue connectivity of the port 20000 on <host>has not found the status as “true”


NOTE: It may also give us an error, 23, 24, 25 in the combinations which means two of the services are not running. For an instance, 34 means “Data-sift connectivity” and “database connectivity” found the status as not “true”. So, this way, it makes it more self-explanatory and easy to directly go and troubleshoot the problem instead of working on all the services.



And there will be the log file which will help us to troubleshoot the problem if happens. This log file is located in C:\url_grabber\log. Each log file created is for all the ports running on single host. For an instance, if we are monitoring “” then the log file will be generated as “”. It will tell us the exact problem it found on any service, and this script also handles if the service gets hung, this problem will also get written into the log file. Through this, this script comes up as a proactive approach to capture the errors.


You may find the attached ppt which shows how the script has been integrated with site-scope and the working of an agent and also the document which shows the steps to perform on Sitescope with screenshots.


You will find the attached script as well.


  • infrastructure management
0 Kudos
About the Author



This is really awesome !!!

Vikram Thank you so much for sharing this as it helped me a lot.

From past couple of years, I was struggling with few terms but now I would be able to do great in my field.



Amazingly elaborated explaination .. It Simplifies and answers all the querries.. Welldone Mr. Vikram.. Awesome Job.. HP have jewels..
//Add this to "OnDomLoad" event