Announcement Announcement Module
Collapse
No announcement yet.
Please Recommend Monitoring/Management Tools Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Please Recommend Monitoring/Management Tools

    I work at a small shop, and we've been discussing general user help desk type support. As a result we're looking more into monitoring sessions and their states. Along with internal metrics of the core system. I am familiar with JMX and currently have several MBeans exported. However, this gives me no insight into individual sessions. Anyone help with that issue?

    Also, are there any other tools that may be helpful in day-to-day administration of our Spring-based apps - or even just our Tomcat container? Of course integrating easily with Spring is a huge advantage.

    Let me know what you use and what advantages it provides you in your administration. What about help with troublshooting? Metrics?

    Currently I run jconsole and jprobe.

    Thanks for any input!

  • #2
    Re: Please Recommend Monitoring/Management Tools

    pbdavey,

    It sounds like you are looking for what SpringSource Application Management Suite (SpringSource AMS) provides out of the box. It gives a great visibility into your Spring web apps.

    Here is the datasheet, which provides a good summary of what SpringSource AMS does. SpringSource AMS Datasheet


    Jason

    Comment


    • #3
      Looking into AMS...have problem...

      So I've downloaded and installed the AMS server and agent. In development, I was able to start my application with the instrumented jars. I was also able to deploy to Tomcat this application and view it through jconsole. Tons of new MBeans are there.

      The problem is that the agent reports:
      Code:
      2009-03-02 16:29:59,753 ERROR [Thread-1] [RuntimeAutodiscoverer] Unexpected error running autodiscoverer for plugin: Tomcat 5.5: Unable to get MBean info: No
       JMX URL configured
      org.hyperic.hq.product.PluginException: Unable to get MBean info: No JMX URL configured
              at org.hyperic.hq.plugin.servlet.ServletDiscoveryPlugin.getMBeanInfo(ServletDiscoveryPlugin.java:111)
              at org.hyperic.hq.plugin.servlet.Tomcat55RuntimeADPlugin.discoverResources(Tomcat55RuntimeADPlugin.java:76)
      I'm not sure where to put the JMX URL. In the section "Instrumenting YOur Application for Management with AMS#Instrumenting-deploy", if says I should verify in the log that it was discovered...but as above, I have the error in the agent.log. Any ideas?

      Comment


      • #4
        RE: Looking into AMS...have problem...

        Not really sure of your problem, so wanted to get a better understanding:

        - What OS?
        - What version of tomcat are you using?

        - Where you able to log into AMS? By default it should be http://<machine>:7080.

        - Did your tomcat get autodiscovered? (Note:There is an built-in tomcat 5.5 in AMS also that gets discovered)

        - If it was discovered.. check that AMS autodiscovered your jmx.url, once AMS discovers your tomcat and you have "Add to Inventory" from the dashboard, you should be able to go to Resources -> Browse. There you can select your tomcat instance. Once you are looking at your tomcat instance, you can select the Inventory tab. Then select the "Configuration Properties" topic slider -> Make sure the JMX.url is correct.


        -Jason

        Comment


        • #5
          The text is embedded in bold -

          Originally posted by Jason Konicki View Post
          Not really sure of your problem, so wanted to get a better understanding:

          - What OS?
          RHEL 4
          - What version of tomcat are you using?
          5.5.27
          - Where you able to log into AMS? By default it should be http://<machine>:7080.
          Yes
          - Did your tomcat get autodiscovered? (Note:There is an built-in tomcat 5.5 in AMS also that gets discovered)
          In Auto-Discovery, I see AMS Agent 2.0.0.RC1 and AMS Tomcat 5.5, so I don't think so, which is why I was wondering if the agent exception meant I was supposed to register the jmx url somewhere in the agent.
          - If it was discovered.. check that AMS autodiscovered your jmx.url, once AMS discovers your tomcat and you have "Add to Inventory" from the dashboard, you should be able to go to Resources -> Browse. There you can select your tomcat instance. Once you are looking at your tomcat instance, you can select the Inventory tab. Then select the "Configuration Properties" topic slider -> Make sure the JMX.url is correct.


          -Jason

          Comment


          • #6
            Your tomcat 5.5.27 should be auto-discovered without a problem.. The jmx.url is not a factor in the auto-discovery, it is used for the retrieving metrics, service info, etc.

            Are you starting tomcat in any unique way? Or are you just using the catalina.sh?

            AMS does a process scan and looks for the following information on the process:
            1. -Dcatalina.home=<somecatalinahome>
            2. -Dcatalina.base=<somecatalinabase>
            3. Whether the following file exists <catalina.home>/server/lib/catalina-storeconfig.jar

            Please verify that all of the above criteria exist. I have tested my tomcat5.5.27 from a direct download and it worked fine.

            Note: By default the agent does an auto-discovery search every 15 mins, if you would like to speed this up you can change the default in agent.properties or the on-demand way is to restart the agent (which is fairly fast). Then you should see the new auto-discovered item in dashboard after a couple mins.

            Comment


            • #7
              Thank you, "starting tomcat in any unique way" is what got me. I'm using jsvc to start Tomcat at runlevel 3. So now I'll look through docs again and post any other issues. I fixed up catalina.sh and it picked right up.

              I would like to know (since jsvc is our preferred way of auto-starting Tomcat) if there is a way...or maybe jsvc isn't starting quite as cleanly as I thought.


              Originally posted by Jason Konicki View Post
              Your tomcat 5.5.27 should be auto-discovered without a problem.. The jmx.url is not a factor in the auto-discovery, it is used for the retrieving metrics, service info, etc.

              Are you starting tomcat in any unique way? Or are you just using the catalina.sh?

              AMS does a process scan and looks for the following information on the process:
              1. -Dcatalina.home=<somecatalinahome>
              2. -Dcatalina.base=<somecatalinabase>
              3. Whether the following file exists <catalina.home>/server/lib/catalina-storeconfig.jar

              Please verify that all of the above criteria exist. I have tested my tomcat5.5.27 from a direct download and it worked fine.

              Note: By default the agent does an auto-discovery search every 15 mins, if you would like to speed this up you can change the default in agent.properties or the on-demand way is to restart the agent (which is fairly fast). Then you should see the new auto-discovered item in dashboard after a couple mins.

              Comment


              • #8
                So AMS seems to be running fine. I can see a lot of internals to my Spring app in AMS...looks good. Except for one minor detail, the app doesn't appear to be producing statistics. Via jconsole, I can look at different MBeans and the values are just not right. I have certain controllers that I know I've gone through with everything turned on, and they report 0 RequestsHandled. Very strange...not quite sure what to make of it other than I think something must be wrong in the Tomcat setup, since the raw MBeans don't seem to be reporting things. MonitoringEnabled is set to true.

                The only setup on Tomcat I've done other than enable jmx is replace the jar files (which explains all the spring.application Mbeans I have). Is there anything else that should be done to enable MBean metrics collection?

                Comment


                • #9
                  After a quick look at jsvc, I think the easiest way would be to add both the -Dcatalina.home=<catalinahome> and -Dcatalina.base=<catalinabase> properties to the current system properties being passed in to jsvc ( there should be an example in the native directory of <catalinahome>bin/jsvc/native/tomcat.sh). The agent should find it due to it having those properties.

                  I will open a jira to investigate jsvc further.

                  Comment


                  • #10
                    re: your controllers not showing metrics in JConsole - are these components annotated with @Controller? If so, do you have other components under spring.application aside from annotated ones that you think are not updating properly?

                    Thanks,
                    Jennifer

                    Comment


                    • #11
                      @Jason
                      FYI...jsvc was setup very similarly to how catalina.sh was setup. For Tomcat5.sh, I exported several env vars in my bash script, CATALINA_HOME/BASE, JAVA_OPTS, CATALINA_OPTS, etc the exact values I put in my .bash_profile so that catalina.sh would start properly. I could provide more environment details if it would help (listings of .bash_profile, Tomcat5.sh).

                      @Jen
                      No, all controllers are configured via xml. We use ant to configure xml for different application targets. However, I looked at different controllers, eg ParameterizedViewController vs. SimpleCommandControllers, and all are not reporting metrics. Tomcat is not devoid of metrics. The several internal MBeans are reporting and even some Spring MBeans that appear to be reporting some (View, Auth Provider). Of course, I may be unreliable as a source since I've not had a working AMS yet.

                      -Phil

                      Comment


                      • #12
                        Phil,

                        Looks like currently the process must be a java process in order to be discovered. There is a jira ticket opened for providing support for jsvc.

                        -Jason

                        Comment


                        • #13
                          AMS will export an MBean for any implementation of org.springframework.web.servlet.Controller that it finds. However, it can only monitor the Controller implementations that have been woven by the monitoring aspect at build time - so the impl has to be in one of the instrumented Spring jars.

                          If you are looking to monitor your own Controller implementations, AMS automatically creates Spring AOP proxies to monitor any of your components that are marked with the @Controller annotation. Beyond that, we are also planning to publish the monitoring API in the near future so you can hook monitoring into your own components.

                          Does this seem to match what you are seeing?

                          Comment


                          • #14
                            Thanks for the follow ups!

                            I'll try in the next couple of days to rebuild, ensuring that build time has the right jars and then that run time has the right jars. I think they were correct before though, but I'll make sure as I suppose it's possible that I'm seeing a strange artifact that is the result of changing jars between compile and run. Other than that, is it necessary that @Controller is used? Can it not handle xml configured controllers? What about the Spring's Java config project?

                            Comment


                            • #15
                              We can monitor and export any bean that is instantiated via an ApplicationContext, so you should be able to monitor beans configured in XML or Java Config. By default, any implementation of the Controller interface or any bean marked with @Controller is exported as a JMX MBean.

                              However, the controllers are woven with aspects for monitoring at compile time by SpringSource (except for @Controller which we use Spring AOP proxies for). org.springframework.web.servlet.mvc.AbstractContro ller's handleRequest method is woven, so any class extending that should get metrics updated unless it one of your own and overrides the handleRequest method (instead of handleRequestInternal). In that case, we can't weave it since it's yours and we don't have access to it at build time

                              Comment

                              Working...
                              X