Out-of-the-box, System Center Operations Manager can discover several different application server platforms and versions (support matrix is here); however, this is not every version of every application server. Also, for an application server to be discovered and monitored in Operations Manager, the machine it runs on must be discoverd and monitored by Operations Manager. Luckily, the System Center 2012 Operations Manager monitoring packs includes PowerShell scripts for manually discovering JEE application servers where such application servers cannot be automatically discovered.
The following steps (taken from the README.txt - see here for feature download) describe how to manually discover a JEE application server.
Step #1: Deploy BeanSpy to your JEE application server.
Step #2: If your application server requires authentication, create a Run As account to be associated with "JEE Monitoring Account" Run As profile for monitoring. Create another Run As account to be associated with "JEE Invoke Account" Run As profile for invoking methods on MBeans.
Step #3: Obtain PowerShell scripts using one of the following methods:
1) If you have at least one JEE application server automatically discovered by Operations Manager, go to Operations Console, select an automatically discovered JEE application server instance, and run the task "Copy BeanSpy and Universal discovery files" in the Tasks pane. This will copy the BeanSpy files to the %WINDIR%\temp folder.
2) Search the Operations Manager installation folder for BeanSpy*. For example, if Operations Manager is installed under "C:\Program Files\System Center 2012\Operations Manager", BeanSpy files are located in one of the folders under C:\Program Files\System Center 2012\Operations Manager\Server\Health Service State\Resources\ as of this writing.
There should be three PowerShell script files:
Step #4: Run PowerShell scripts to add or remove application servers.
1) You can add or remove application servers one by one. However, if you have multiple application servers, you can create a configuration file. Each line of this file should contain a URL where your JEE application server is listening on for http or https requests. For example:
2) To add JEE application servers for monitoring, run NewJEEAppServer.ps1. Run this script with -help for details of command line options. You can pipe the configuration file you created to this script, or specify a single URL on the command line.
Discovers JEE App Servers into Operations Manager. BeanSpy should be deployed to each application server to be discovered.
The script accepts a number of JEE App Servers on the input pipe. Each JEE App Server is represented as a fully qualified URL, for example, http://www.contoso.com:8080.
The script displays an error message for each app server it fails to discover.
Parameters: ManagementServer - Name of OpsMgr server to use. Use current computer if not specified JEEAppServerType - Supported types are JBoss, Tomcat, WebSphere, and WebLogic. Will query each application server if not specified. JEEAppServerVersion - Supported versions are JBoss 4, 5, 6, Tomcat 5, 6, 7, WebSphere 6, 7, and WebLogic 10, 11. Will query each application server if not specified. UserName - User name to access the App Server URL. If provided, the script will prompt for password Target - Additional JEE App Server to discover (done before any JEE App Server piped into the script)
help - Prints this help
.\NewJEEAppServer.ps1 -Target http://www.contoso.com:8080
type c:\MyAppServers.txt | .\NewJEEAppServer.ps1 -JEEAppServerType WebLogic -JEEAppServerVersion 11
type c:\MyAppServers.txt | .\NewJEEAppServer.ps1 -UserName mymonitor
3) To remove JEE application servers currently being monitored, run RemoveJEEAppServer.ps1. Run this script with -help for details of command line options. You can pipe the configuration file you created to this script, or specify a single URL on the command line.
Update August 30th, 2013: Only instances added by the NewJEEAppServer.ps1 can be removed. You cannot remove instances that have been discovered by the application server-specific MP. The quickest way to tell which discovery was used is if the instance has a DiskPath. Instances discovered via the Universal Discovery method do not have a disk path. So if the Path is blank, then it is a candidate to be removed.
Removes JEE App Servers from Operations Manager.
The script accepts a number of JEE App Servers on the input pipe.
Each JEE App Server is represented as a fully qualified URL, for example, http://www.contoso.com:8080.
The script displays an error message for each app server it fails to remove.
ManagementServer - Name of OpsMgr server to use. Use current computer if not specified Target - Additional JEE App Server to discover (done before any JEE App Server piped into the script)
help - Prints this help
.\RemoveJEEAppServer.ps1 -Target http://www.contoso.com:8080 type c:\MyAppServers.txt | .\RemoveJEEAppServer.ps1
The discovered application servers will first appear under "Universal application servers" folder in the "Configured application servers" view. Verify that the application server type and version are populated correctly. After multi-stage discovery (ranging from a few minutes to four hours by default), the discovered application server should appear under the application server folder specific to its type, in the deep monitored application server view, with detailed application server information populated.
The help messages for the PowerShell scripts of NewJEEAppServer.ps1 and RemoveJEEAppServer.ps1 released as part of RTM and CU1 contain typos.
Actual Help Message output:
New-JEEAppServer.ps1 -Target http://www.contoso.com:8080
type c:\MyAppServers.txt | New-JEEAppServer.ps1 -JEEAppServerType WebLogic -JEEAppServerVersion 11
type c:\MyAppServers.txt | New-JEEAppServer.ps1 -UserName mymonitor
Expected Help Message output:
Thanks for theGreat Tutorial! I have discovered my Jboss instace as you have suggested it worked all good and now i can see it now at my deep monitored configurations yet still i cant get to see my JMX MBeans ? Can you give me some pointers or advises on that also please?
It is a little unclear to me what you're expecting to see.
Are you asking to see a list of _all_ MBeans in SCOM in some type of View? That is not supported.
Only a list of applications (which the discovery occurs by looking at the MBeans which represent applications) is discovered by default.
Perhaps you could review the article www.systemcentercentral.com/.../Default.aspx that I mentioned in this post blogs.technet.com/.../recommended-demystifying-jee-app-performance-monitoring-in-opsmgr-2012-jee-faqs.aspx.
If you want to browse the list of MBeans and choose one to monitor, you can use the template wizard. For more information on that, you can look at this article blog.scomfaq.ch/.../scom-2012-jee-application-availability-monitor-template.
BTW: you probably do not want to monitor all MBeans on all servers, it would be quite a bit strain on OM. Are there a specific set of MBeans you want to look at?
I followed your guide (thx btw), and i now have my 2 tomcat servers under the configured application servers view. They are also under the deep monitored configuration. But the state there is not monitored. Do you know why this is? Also when i look under applications, only applications from 1 server are being shown. Also not monitored… Any ideas?
Quick check: Is security (i.e. basic auth) enabled for these application servers? If so, have you configured the Run As accounts in SCOM so that it is passing the correct credentials to the HTTP calls? (See documentation www.microsoft.com/.../details.aspx for more details)
Is this Tomcat 5.x? If so try looking at blogs.technet.com/.../tomcat-5-5-additional-steps-to-connect-to-the-mbean-server.aspx
Finally, BeanSpy should be working since the discovery went through, but in a browser can you check the JMXQuery listed in this post (blogs.technet.com/.../beanspy-apache-tomcat-jmxquery-to-list-deployed-applications.aspx)?
Added Tomcat server using this scripts.
But there is a problem.
I see the server in Deep Monitoring Configurations, but don't see it in Configurations view.
Does that mean, I won't be able to set up the Tomcat Process Avaliability monitor against this tomcat?
That is expected behavior.
The PowerShell script creates a "deep" instance of the application server and bases availability on it's ability to establish a HTTP connection with BeanSpy.
The "basic" view are instances discovered sans BeanSpy (i.e. registry entries or running processes - depends on the application server).
The PowerShell-based discovery doesn't know anything about the application server process or location on disk (for instance, that is why the disk path attribute is empty). The script approach only needs to know the host and port of the application server... but that means we only know the host and port of the application server. :)
This script was designed as a workaround to manage application servers that are running on machines not typically under SCOM control - as such it does not try to reverse discover the basic instances.
While you will not have a process monitor, is there a reason why the availability monitor of BeanSpy (which roles up) isn't sufficient for your monitoring needs?
I have noticed that profile, cell, node and server are blank.
What causes this to not show up in Deep Monitored Profiles monitoring?
I can see the State as Healthy but those fields are empty.
The universal/manual discovery does not gather this information. All it really cares about is that the application server is there. Those WebSphere specific details are not gathered by the universal approach. Alas, this is not ideal - but it is how it is.
Thank you for your quick response.
I was wondering why it would present as a category if the information isn't returned.