Questions on running the Web plugin

[alecxvs]

I'm interested in collecting metrics provided by the web plugin, but I'm a bit confused about how to get it running. There seem to be some undocumented properties (stagemonitor.server.threadpool.*) involving JMX and MBeans. I'm not sure how to configure these, and I don't think my web service uses either of these.

[felixbarny]

What do you mean by getting the web plugin running? If you are using a web application you cant't not run it. To see which plugins are running, you can also go to the configuration tab of the in browser widget. Here you can see a panel for each active plugin.

Concerning the threadpool.* settings... They can be used to monitor the thread pool of the application server. For example, if you are using tomcat, you could set these properties:

stagemonitor.server.threadpool.objectName=Catalina:type=ThreadPool,*
stagemonitor.server.threadpool.mbeanKeyPropertyName=name
stagemonitor.server.threadpool.mbeanActiveAttribute=currentThreadsBusy
stagemonitor.server.threadpool.mbeanCountAttribute=currentThreadCount
stagemonitor.server.threadpool.mbeanMaxAttribute=maxThreads

But that is not very user friendly, I know. It's already on my TODO list to revisit application thread pool monitoring. Probably the best thing would be to detect which server is used and to have some kind of database, which JMX names they are using for the thread pool metrics or to just try all known names.

But before I can effectively do that, I first have to create integration tests for all supported application servers (see #8).

One thing that would help me is links to the documentation of the MBean names of the different application servers.

Out of curiosity, would you tell me a bit about your use case and what you are using stagemonitor for (dev, qa, prod)?

[alecxvs]

It's not exactly a web application, it's a REST service I'm running stage monitor on. It states in the console output that the web plugin is not loaded because the thread pool properties are required. If the plugin is intended to be usable without thread pool info, that requirement may need to be changed.

I did figure out that the server is set up with jmx and i am using tomcat so I will try those properties.

My use case is measuring performance of a number of REST services, primarily in development at the moment.

[felixbarny]

Now I see what the problem is. I the log it says * is empty, Server Plugin deactivated. Well, the log message is a bit misleading there. The web plugin does work without these properties set and actually, there is no such thing as a Server Plugin. I'll probably just remove the log.

So when you say its just a REST server, can you use the in browser widget there or are you using the grafana dashboards?

[alecxvs]

I'm using the grafana dashboards. I'm not sure about the browser widget, the only APIs are json responses. It isn't meant to load any javascript or anything like that. I assumed that the plugin wasn't operating at all since I wasn't getting session metrics and it printed that in the console. Is the thread pool configuration necessary for session metrics to work or am I missing something else?

[felixbarny]

That indeed is strange. The session counter should work, even if the thread pool properties are not set.

Maybe your application is stateless and does not have sessions? To diagnose, you could debug the org.stagemonitor.web.session.SessionCounter to see if it gets invoked. You could also set stagemonitor.reporting.interval.console to something like 10 so that every 10 seconds a log message with alle the current metrics will be produced.

Maybe it would be a good idea to have the stagemonitor widget at a url like /stagemonitor. The Call Tree and Request tab wouldn't be available, but you could use the Metrics and Configuration tab.

Are you using your REST service with some kind of JavaScript framework like AngularJS?

[alecxvs]

You're right, the service is stateless. I used those properties and thread pool metrics are showing, but still not sessions. I assumed sessions were active HTTP connections but I see now they're more like browser sessions.