Release Automation

Expand all | Collapse all

Monitoring CA Release Automation components

Jump to Best Answer
  • 1.  Monitoring CA Release Automation components

    Posted 08-19-2016 10:47 AM



    What is the best way to monitor all the components of Release Automation?


    • Management Servers
    • Execution Servers
    • Agents
    • Database
    • Repository


    Should I monitor the ports that each of them listen to or the Release Automation services that is runing in our servers?


    Thank you,


  • 2.  Re: Monitoring CA Release Automation components

    Posted 08-19-2016 12:23 PM


       There is a section in the architecture guide that has some recommendations on monitoring that you may find useful.


    CA Release Automation 5.x / 6.x Architecture and Implementation Best Practice Guide




  • 3.  Re: Monitoring CA Release Automation components

    Posted 08-29-2016 03:55 AM


    Did this answer from James answered your question? If it did please mark it as answered"

    If the question is still unanswered or the answer is unclear please let us know .

    With Kind regards


  • 4.  Re: Monitoring CA Release Automation components

    Posted 08-29-2016 04:24 PM

    No, his answer was not helpful.


    I want to monitor if the ports and/or services of each component that is part of Release Automation is up or down. If it is listening or not.


    His document only mentions Windows Services. What about Linux Services?

    I was hoping for more technical and in-depth information about monitoring Release Automation.



  • 5.  Re: Monitoring CA Release Automation components
    Best Answer

    Posted 08-31-2016 12:49 AM

    Hi Eduardo,


    You're question is a little tricky. But I'll give it a shot. First, the document that Keith supplied has a list of most ports used by RA on page 8. I say most because I didn't go further than page 8 and that didn't show ports used by DB (since that can be different: 1433 for SQL 1521 for Oracle). I also don't see a port explicitly mentioned for the repository. But on an all-in-one system that would be the same port as the datamanagement/NAC component (8080). If you were using CA's standalone repository installer then it would still be 8080. But if you used the installer provided by Nexus then I think it uses 8081. If you're using Artifactory then I'm not sure exactly what port it uses. But I think there is an Artifactory document on the community or google will help in last resort. I think that covers all ports.


    As for Linux services, on RHEL you have:

    Both the Management and Execution Server Uses:

    ServiceName: NolioASAP

    Process: java (with switches that load the following into its classpath: /opt/ReleaseAutomationServer/bin/bootstrap.jar:/opt/ReleaseAutomationServer/bin/tomcat-juli.jar - as found in /proc/<pidid>/cmdline) 


    Agent Service: nolioagent

    Agent Process: NolioAgent


    Standalone Repository Service: looks like it is "Nolio Repository Service"

    Standalone Repository Process: java (with switches that load the following into its classpath: /opt/ReleaseAutomationServer/bin/bootstrap.jar:/opt/ReleaseAutomationServer/bin/tomcat-juli.jar)


    As for whether you should monitor these services, processes, ports, etc.. 

    This is the part that I find tricky. I have some monitoring experience. And in that realm you have have the possibility to define corrective actions (like restarting an agent/service if it were detected as not running). I wouldn't advise this unless you have change control procedures that allow you to put the monitored watchers in some sort of maintenance mode since you don't want those watchers automatically restarting a service that is being patched (for example). 


    Overall, monitoring for the process/services and/or availability via a reachable URL is good if you want to avoid unexpected end user problems. Though I'm not sure about monitoring the listening status of ports. I can't say that I've heard anyone express that need before. Especially since you might have some applications that disconnect/reconnect on purpose and leave the the port in a timed_wait state (or something to that effect). 


    Depending on whether or not you're comfortable with JMX being enabled you could potentially use this as an endpoint test throughout your environment for most everything except a standalone repo and database. 


    There are Rest APIs that I see the UI uses for getting results of Agent status (like the Offline Agents dashboard widget - which you can see in chrome's F12 -> Network analyzer). But if you want something that will definitely not change then you may want to ask for this as a feature since it is not formally documented as being a public Rest call.


    I hope this helps.


    Kind regards,


  • 6.  Re: Monitoring CA Release Automation components

    Posted 08-31-2016 02:46 PM

    Thank you for your answer!