There is a built-in feature in the product to automatically restart Virtual Services that go down for some reason. These options are available during deployment and also from PORTAL VSE Monitor page. However Auto-Restart will not work if anyone STOPS the Virtual Service Manually and in such cases, you could use the following approach to monitor and start virtual services that someone accidentally stops.
This was a question that I recently answered for a community question. An user wanted to know if there is a way to continuously monitor running virtual service and do the following when anything goes down due to someone manually shutting a virtual service:
1. Notify an Admin through email about the event
2. Automatically start the Virtual Service(s) that went down due to someone stopping the Virtual Service
Both the requirements were met by implementing a simple test case, which does the following:
1. Get the list of VSEs by invoking LISA Invoke 2 API http://localhost:1505/api/Dcm/VSEs
2. Filter using XPATH Query and extract the Virtual Services that are NOT IN RUNNING status(!=2) and need to be started
3. Write all the Virtual services start links (from step 2 filtered list) into a .csv file
4. Iterate through the csv file(Using CSV Dataset) and invoke the Virtual Service Start link (Eg: http://localhost:1505/api/Dcm/VSEs/VSE/GoogleVS1/actions/start )
5. Within the same loop an email is sent to the ADMIN about the Virtual Service that is down and that the automatic monitor has started the same
Note: When you open the test case VSMonitor2.0.tst in your environment, you may get an error that the kickonvs.csv file is missing since the testcase uses a temporary CSV file. The kickonvs.csv file is generated within the test case (Step 3 mentioned above) and then read later in the test. The file gets created and destroyed within the life of the test cycle.
The kickonvs.csv file at run time would contain entries like this:
It would just contain the START URLs of those Virtual Services that are currently in DOWN status (2)
The test case has been designed such that with just a Single user & Single Iteration, all the rows of the .csv file would be read. IN order to make this happen, the last step calls itself and the loop breaks due to the following condition which is defined as part of the Dataset.
If the last step is not looped back to itself like the way it is now, then the only way to make sure all the rows are read is by having multiple users (instances) as part of staging document. More information and examples in looping can be found here: Branching and Looping in a Test Case - DevTest Solutions - 10.4 - CA Technologies Documentation
Example Scenarios of Data Sets - DevTest Solutions - 10.4 - CA Technologies Documentation
Things to Remember If you want to use this Monitor
1. Make sure you configure the hostname where LISA Invoke APIs are running. The test case refers to localhost
2. Give correct admin user name and password to access LISA Invoke APIs
3. Configure Email sending step with correct SMTP Server address, post and authentication information
NOTE: Feel free to parameterize all the inputs and make the test case easy to use.
Using CVS Monitor for Continuous Monitoring
The real power of the DevTest comes in handy to run this test case as a TRUE-MONITOR by deploying the test as a CVS monitor with a frequency to run say once in 1 min, 5 mins or an interval that suits you.
Attached with this document is the fully working, fully tested test case MAR file. Please share your feedback on how it goes.
Notifications As Received