Поделиться через

Manually Discovering JEE Application Servers with SCOM 2012

  • Статья

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:

  • JEEAppServerLibrary.ps1
  • NewJEEAppServer.ps1
  • RemoveJEEAppServer.ps1 

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:

 

https://linux.contoso.com:8080https://myredhat:8180https://10.0.0.1  

 

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.

NewJEEAppServer.ps1

Discovers JEE App Servers into Operations Manager. BeanSpy should be deployed to each application server to be discovered.

Input:

  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, https://www.contoso.com:8080.

Output:

  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

Examples:

.\NewJEEAppServer.ps1 -Target https://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.

 

RemoveJEEAppServer.ps1

Removes JEE App Servers from Operations Manager.

Input:

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, https://www.contoso.com:8080.

 

Output:

The script displays an error message for each app server it fails to remove.

Parameters:

  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

Examples:

  .\RemoveJEEAppServer.ps1 -Target https://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.

Comments

  • Anonymous
    January 01, 2003
    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: .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

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    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)?  

  • Anonymous
    September 13, 2012
    The comment has been removed

  • Anonymous
    February 06, 2013
    Hello, 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? Thanks!

  • Anonymous
    September 23, 2013
    Hi! 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?

  • Anonymous
    November 13, 2013
    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.

  • Anonymous
    November 14, 2013
    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.

  • Anonymous
    November 20, 2013
    Thank you for your quick response. I was wondering why it would present as a category if the information isn't returned.

  • Anonymous
    December 08, 2013
    The comment has been removed

  • Anonymous
    December 09, 2013
    The comment has been removed

  • Anonymous
    December 11, 2013
    The comment has been removed

  • Anonymous
    December 11, 2013
    The comment has been removed

  • Anonymous
    December 11, 2013
    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?  

  • Anonymous
    June 12, 2014
    Hi again... lost track of this a while back.

    We have a Tomcat action account set as a 'Basic Authentication Account' (pretty sure we also tried 'Simple' too). The credentials have been checked multiple times (and work running manually).

    This is distributed to the Health Service for all of the Tomcat app servers.

    We then have Jee Invoke and Jee Monitoring runas accounts set to use this action account in the Profiles, these are specified to class 'Windows Computer' for the Tomcat app servers.

    Do we have to use 'All Targeted Objects' or another class/group, instead of 'Windows Computer'? Should I be able to use the latter ok?

    Do we have to also distribute the action account and runas accounts to management servers?

  • Anonymous
    February 12, 2015
    This blog is a continuation of “Managing JBoss Application Server 7 with System Center Operations

  • Anonymous
    February 12, 2015
    This blog is a continuation of “Managing JBoss Application Server 7 with System Center Operations

  • Anonymous
    October 06, 2015
    i dont know how to run this script can anyone help

  • Anonymous
    October 07, 2015
    i run it thanks .

  • Anonymous
    March 22, 2016
    Hi Step, I know it's a very old post - but just in case you see this message, could you please let me know if you were ever able to fix this issue? I am experiencing exactly the same issue while I am trying to setup Tomcat monitoring with SCOM.

  • Anonymous
    March 22, 2016
    Hi Step, I know it's a very old post - but just in case you see this message, could you please let me know if you were ever able to fix this issue? I am experiencing exactly the same issue while I am trying to setup Tomcat monitoring with SCOM.

  • Anonymous
    March 22, 2016
    Hi Step, I know it's a very old post - but just in case you see this message, could you please let me know if you were ever able to fix this issue? I am experiencing exactly the same issue while I am trying to setup Tomcat monitoring with SCOM.

  • Anonymous
    April 05, 2016
    Hi guys, sorry about the duplicate posts earlier, my browser had some issues.

    Anyways, just wanted to let you know that we have identified the root cause of this issue and fixed. It was a manual error - an incorrect URL was registered while running the NewJEEAppServer.ps1 script. Removing and re-registering the correct URL fixed the issue. There might be other root causes, but I wanted to update the blog - just in case if someone else did the same mistake, worth verifying the URL.