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:
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.
Got the Tomcat/Java MPs all added, BeanSpy deployed to the Tomcat app servers, and manual discovery through SCOM, distributed runas accounts in 'more secure' mode (using Basic Authentication) to the app servers. Modified web/tomcat-users.xml to reflect the
Four of these servers run HTTPS/443 with Basic Authentication, two of them are HTTP with no authentication.
The latter two are being health checked fine in SCOM, but having a problem with the four using HTTPS/Basic Authentication. If I go to the URL directly on the app servers - e.g.
appserver.domain.local/.../Stats then sure enough I get an authentication box, enter the credentials as per what's in the runas accounts, and it returns the XML data fine.
Doesn't seem to work from SCOM though as part of the Health Service Script, we get logged in the SCOM management server that tries to do the health check:
Source: Health Service Script
Event ID: 100
HTTPGet.vbs : HTTP commucation failed with:
appserver.domain.local/.../Stats - Send Error - -2147024891
So far have tried re-creating runas accounts/profiles, re-distributing them to the app servers, checked firewalls and anti-virus on both SCOM management servers and app servers, but still to no avail :/
Do I need to distribute the Tomcat runas account to the SCOM management servers too? I presumed that the runas account would be invoked on the app servers themselves when the SCOM management server fires the health service script.
I'm trying to work out from the above error, where the 'send error' lies? Is the HTTPGet.vbs script being run on the app server locally (and supposed to be using those runas credentials), or does it run on the calling management server with the runas credentials?
Any help gratefully received as this has been confusing me for a few days and I can't find anything on the net about this 'Send Error' error particularly!
Well... It could be several things. For starters, I noticed that the error you have pasted into the above comment has a hostname of 'appserver.domain.local' - is this a hostname that will resolve to the desired IP address? As this is a HTTP call, the infrastructure relies on DNS appropriately resolving this hostname to the correct network address.
Regarding your second point about the distribution of account credentials, it would depend on if this is Windows or Linux. The Health Service making the HTTP call to Tomcat is what needs the credentials. For a better primer on secure credentials, try this blog post: blogs.technet.com/.../configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx
The credentials are needed by the machine in the SCOM infrastructure making the HTTP call. If you use the default Windows discovery, the credentials are needed on the Windows machine. If you are using the manual discovery or Linux, the credentials need to be available to the Management Server(s) managing the machine.
FYI: the rationale for the Universal/PowerShell discovery was the ability to manage instance of applications servers outside of the traditional SCOM infrastructure. Because of this, the machines in the selected Management Pool need to have the credentials to make the HTTPS calls.
Try this and let me know how you fair.
Hi, yes, I've just used that as an example here - DNS is resolving things ok from the management servers to app servers.
I've now distributed the runas account we set up for Tomcat to the Management Server that's doing the https calls to the app server (as we had to manually 'discover' our Tomcat app servers through the NewJEEAppServer.ps1 script). Still getting the same error as above.
Is there anything else I can test? I did the 'rename health service state' folder to allow it to re-build again which it's done and everything is clean and healthy with the SCOM state apart from the BeanSpy stuff. I've also started looking through the Tomcat5 XML to see precisely what the scripts are doing.
Further to the above, i can see from a TCP trace the SCOM MS server talking to the app server on the HTTPS port:
tomcat5.exe:3808 TCP appserver:https scomms:62654 established
If I click on the URL which is inline in the event log on the calling management server (e.g. HTTPGet.vbs : HTTP commucation failed with: appserver.domain.local/.../Stats - Send Error - -2147024891) - that link on the SCOM management server opens the URL in IE, prompts for the authentication details, and if I enter them manually (as per what's in the Basic Authentication runas account/profile), it returns the XML :/
I still want to try and ascertain what the 'Send Error' entails?
In the BeanSpy section, in Health Explorer, its reporting a 401 (which is what you'd get it you don't authenticate with the username/password to the app server URL):
HTTP Status Code 401
Error Code 2147942487
DNS Resolution Failure false
DNS Resolution Time (seconds) 0
TCP Connect Time (seconds) 0
Time To First Byte (seconds) 0
Time To Last Byte (seconds) 0
Redirect Time (seconds) 0
Download Time (seconds) 0
Total Response Time (seconds) 0
Content Size (bytes) 0
Secure Failure Code 0
Certificate will expire in (days) 695
Certificate Expired false
Certificate Authority Untrusted false
Certificate CN Invalid false
Response Headers HTTP/1.1 401 Unauthorized Cache-Control: no-cache Date: Fri, 06 Dec 2013 10:05:03 GMT Pragma: No-cache Content-Length: 954 Content-Type: text/html;charset=utf-8 Expires: Thu, 01 Jan 1970 01:00:00 GMT Server: Apache-Coyote/1.1 WWW-Authenticate: Basic realm="myrealm"
GET /BeanSpy/Stats HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Connection: Keep-Alive
Response Body See end of page for full Response Body
Hrmmm... Well it certainly sounds like you have covered all of items on the checklist. And you said that you know that the credentials in SCOM are correct b/c they work when you put them in a browser (i.e. that means Tomcat has been configured correctly)...
As you said, the 401 indicates an authentication failture - either no credentials or the wrong ones.
As a sanity check, mind if I ask if did mapped the appropriate RunAs Accounts with the RunAs Profile?