Hi,
We have configured App Dynamics to monitor a windows service (using CLR agent).
But if the service is stopped or crashes we just see it as inactive in the App D controller. Is there a way to detect the service status and actually trigger an alert?
Thanks for any suggestions or ideas.
Rob
Hi Rob,
Are you referring to Reporting status in agent section (in reference to inactive status) as listed below:
If this is the case, you can define a health rule on metric "Agent | App | Availabiity" for the corresponding CLR Agent as referred in below screenshot (please be sure that we assume that agent reporting status is done not due to agent controller connectivity issues here) and associate an alert for the health rule to trigger if the availability metric reports zero:
Let us know if there is any disconnect in our understanding here.
Regards,
Arun
Hi Rob,
Are you referring to Reporting status in agent section (in reference to inactive status) as listed below:
If this is the case, you can define a health rule on metric "Agent | App | Availabiity" for the corresponding CLR Agent as referred in below screenshot (please be sure that we assume that agent reporting status is done not due to agent controller connectivity issues here) and associate an alert for the health rule to trigger if the availability metric reports zero:
Let us know if there is any disconnect in our understanding here.
Regards,
Arun
Thanks for the quick response Arun!
This looks really promising - sorry it's probably a basic newbie question, but i didn't know you could do that.
This is working well, however I still have a problem with this approach. We seem to have duplicates of the service listed in the servers section. (on has a "-1" appended to the end of the name). When we deploy new versions of the service, the one that is listed as running stops and the other (duplicate) one starts. This means that every time we deploy we would need to reconfigure the alert.
Do you know why this would be happening or if there was away to stop this duplication.
Thanks again for your kind help!
Cheers,
Rob
Hi Rob,
Glad to hear that suggested steps had helped. Can you please send the screenshots depicting the latest issue for better clarity of the issue?
Regards,
Arun
Hi Arun,
Thanks for coming back to me again this morning. Please see the screenshot below.
I've been experimenting this morning and it seems that when I restart the service it switches from one of the rows below to the other. This would mean that I need to reconfigure the alert every time that the services are restarted.
Is this duplication expected behaviour? If so is there anywhere I can read about it and is there a way to configure App Dynamics to have a single entry instead?
Cheers,
Rob
Hi Rob,
Thanks for sharing the screenshot. For a preliminary investigation can you please confirm the below.
1) Is your Windows service using multiple app domains.
2) The zip of "DotNetAgent" folder (default location is "C:\ProgramData\AppDynamics\") to double check the configuration and windows host process entries in Agent log.
3) You mentioned that you deploy new versions of this service - Please let us know the steps/process to deploy the new versions of the service.
Just to give you a brief idea about how AppAgent instruments the process and creates the nodes in a single app domain and multiple app domains scenarios. Please refer the following doc link for the details http://docs.appdynamics.com/display/PRO13S/Configure+Application+Domain+Monitoring.
Single Application Domain:
In the case of a single application running inside its own process, the runtime host typically manages the AppDomain. The application executable and the AppDomain have the same name. The App Agent for .NET (agent) installs itself inside the single AppDomain and creates a node for the application.
Multiple Application Domains:
When developers include multiple AppDomains in an application, all the AppDomains run inside a single process. The application executable may have the same name as one AppDomain, but there are other, uniquely named AppDomains. By default, the agent installs itself inside all the AppDomains and creates nodes for them.If the application you monitor contains multiple AppDomains, the App Agent for .NET automatically instruments each AppDomain and creates a node.
From 3.7.12, you can configure the App Agent for .NET to instrument only the AppDomains you specify. This is useful to exclude AppDomains you don't want to monitor and to limit the number of nodes in a tier, but this is not advisable as you will miss some important transactions and metrics inside those excluded App Domains.
Thanks,
Venu.
Thanks again for the reply. Sorry this has taken me a while to get back to you.
The link is much appreciated, it has given me a lot to think about and check. Here are the answers so far:
1. It is possible we might be running multiple app-domains, however not intentionally. We are wrapping a simple console application with an installer called TopShelf. This may be creating a new app-domain to run code. (I'm still reading up on this to check)
2. I have checked with our Ops department and they are not keen on me zipping up files that have the controller passcode inside and uploading to a forum (understandable) but hopefully I can summarise what is in the config:
<windows-services>
<windows-service name="Adactus.Pulse.Components.Service_UAT">
<tier name="Windows Services" />
</windows-service>
</windows-services>
3. To deploy the service we use a tool called Octopus deploy. This will take a package containing our executable and copy it to the server. Each release goes in a new folder named after the build number. We then run a powershell script to stop and uninstall the old service with the command
(Get-WmiObject Win32_Service -filter "name='$ComponentsServiceName'").Delete()
We then install the new service using topshelf commandline.
Does that help explain what might be happening, or give you any other ideas I can try?
I've also looked at the CLR settings screen which is discussed in that article you link to. I have a attached a screenshot from each of the duplicate services. (I blanked out the full path to save sensitive info being visible sorry) The interesting thing is that they both have the same AppDomain name. Also, in the screenshot you can see CLR Startup Options, what bearing do they have on things? It's just that I can see the path is incorrect and points to an old version (probably the version that was installed when app-D started monitoring and detected the service)
Cheers,
Rob
1st:
2nd:
Just a quick update. I will accept the first answer as this looks like a good way to monitor the services.
The problems we are seeing with multiple services. i.e. MyService, MyService-1, MyService-2 is really starting to cause issues, so I will raise this as a support request. I can confirm though that we are definitely not running multiple app domains.