I have an application that runs within a tomcat (a handful of java servlets) on linux. Now I am tasked to monitor the ressources (such as CPU, memory usage, etc.) within this tomcat (not the single servlets).
I am not a programmer (so I cannot change code) and I am not allowed to change anything within the code. I am also not very familiar with Java (so my apologies if I throw a few things together).
The only thing I can do is start tomcat with java-parameters that activate jmx. So I can remotly check tomcat and the application/servlets running within from remote using JMX.
Question:
What tools (or possibilities) are available to find out what kind of monitoring/ressource information the tomcat (or application with the mbeans) is offering?
I am thinking along the lines of a snmpwalk which would allow me to discover the information provided by snmp. However, I have no idea how to do this with java and jmx (found tons of articles on the internet on how to program it, but that is out of the question).
Thank you very much for your help
You are better off looking at an APM tool to fit this use case. I work for AppDynamics and we do just this. The other common tools are Dynatrace and New Relic. These tools will attach to a Java application at runtime and provide deep monitoring, visibility, transaction tracing, and troubleshooting capabilities. AppDynamics also automatically baselines all of the metrics and alerts you when things start having issues.
Related
I have been playing around with JMX for the last few days and although I don't mind JConsole or the standard JMX web admin tool, it would be nice to create my own web app that somehow queried the registered JMX MBeans and presented a nice, rich-UI-style "dashboard" with charts and graphs; things that the JMX console or JConsole simply do not have.
Is this possible? I've heard of something called a JMX "agent" but not sure if that has anything to do with how JMX can be queried and managed by a dashboard-style app. Thanks in advance!
Jolokia is an agent based approach to JMX which translates JMX native calls to JSON-over-HTTP. It comes with a Javascript library which is perfectly suited for used within the browser. For a sample usage within a web page look at the demo of the Jolokia-Cubism Integration or even better have a look at the blog post from Tomasz Nurkiewicz which gives a very nice example of using Jolokia along with the Highcharts graphing library.
Said all this, there is even more: Ají, Jolokia's fancy sister, has been started as project which will provide an JMX console bundled along with Jolokia clients. I'm still sorting things outs (well, it moves slowly ...), but I think that over the summer more will be there. One can already play around with it and we still look for volunteers (hint ;-) ....
What you are looking to do has probably already been built unless you really want to do it yourself. Have you looked at VisualVM before? I really like it http://visualvm.java.net/mbeans_tab.html/
To write your own application that manages MBeans remotely I think you could start with this tutorial. Seems to be a good starting point.
http://docs.oracle.com/javase/tutorial/jmx/remote/custom.html
One of the comments here is that VisualVM is a profiler. VisualVM isn't a profiler, it's a platform built on top of the NetBeans platform. The platform supports connecting to a VM in flight a number ways including using a JMXConnector to the MBeanPlatformServer, Serviceability Agent (SA), Attach on demand and so on.
VisualVM does contain 2 different profilers but there is also an MBean plugin that allows you to view and manipulate MBeans that have been registered with the MBeansPlatformServer.
A number of the view in VisualVM scrape data from the MXBeans found in the java.lang.management package that are registered with the MBeansPlatformServer. Many of these MXBeans are wrappers over the SA, a component of HotSpot that maintains a set of performance counters. For example, counters can give you some information about JIT compiler activity, GC activity and even host platform CPU utilization and so on.
You can easily build your own plugins to view or manipulate MBeans. The tutorial mentioned in a posting here is one source of information as to how to get it done. I have written a demonstration VisualVM plugin that looks at data from the MemoryPool MXBeans. That plugin has been augmented by others to do a number of other things. All the code can be found at java.net in the project MemoryPoolView. It covers reading data. However executing functionality is really just executing a method against the JMXConnector with the parameters required by the MBean you are interacting with. IOWs, it's a fairly trivial extension of the plugin.
HawtIO Is about the best plug-and-play, works out of the box solution for getting JMX stuff on a web page. You can put multiple mbeans on the same page and see them all at once, it works in a browser, you don't have to write a bunch of front-end code yourself, and it can be done without opening up weird ports that your IT department will get nervous about. The data visualization options that work with the simple drag and drop interface are pretty minimal, but there is documentation for writing more advanced plugins.
The backend uses Jolokia to put an HTTP REST interface on JMX, which is probably going to be true for any solution you might look at.
I've been researching Apache's commons-daemon and it seems pretty cool: basically its an API as well as a library that helps register your JAR with the underlying OS so that it can be started and stopped like a daemon service. Additionally, it intercepts OS signals that would normally kill your app and instead gives you a chance to shutdown politely.
So it's got me wondering, if given the choice between deploying your business logic inside EJBs and wrapping them in a container like OGS or JBoss, why not just create a daemon JAR that listens on a port and responds to client requests?
Is it just the benefit of all the features/services that an app container provides out of the box (security, logging, etc.), or are there times when it would be favorable to choose a daemon over an app container/EJB solution?
Basically, what I'm asking if: when is it more appropriate to use an app container/EJB solution, and when is it more appropriate to use commons-daemon to help build a system-level service (in Java)?
Disclaimer: just interested in these two choices, I am aware that other solutions exist (web containers, ESBs, OSGi, etc.). But for the purposes of this question I am only interested in hearing the reasoning between app container or daemon solutions. Thanks in advance!
Why don't you look at it like System level (daemon) vs Application level (in container)?
This will give more or less clear distinction (especially if worked with Linux some time).
For Daemon:
has its own life cycle (you can start and stop it separately);
different privileges (could be run under different user);
use case is something like CRON, MailServer, synchronization and any system-level service.
For Container:
managed app (by some privileged user via Container console);
plenty of out-of-the-box features (which you'd already mentioned);
use case some general case business application.
Well the simple answer is yes, the app server (Glassfish or JBoss) give you plenty of nice things that you would have to implement or setup yourself in a plain Java SE app.
However it is not so black and white, and you can get a lot of the application server goodness with very little effort, I am in the process of writing a blog series on exactly this topic.
My reason for not using an app server, was that we had a project for a widely distributed software product, and we wanted to avoid having to patch and maintain thousands of application server instances!
However if your app will be running in one place, there is little reason to go Java SE.
Problem: I have a standalone Java app (henceforth known as "the agent") that runs as a service on internal company servers. It acts as a remote agent for some central servers. As the agent gets deployed in more places, managing them is getting more complicated. Specifically: pushing updates is painful because it's a fairly manual process, and getting access to the logs and other info about the environments where the agents are running is problematic, making debugging difficult. The servers under discussion are headless and unattended, meaning that this has to be a fully automated process with no manual intervention, hence Java Web Start isn't a viable solution.
Proposed solution: Make the agent phone home (to the central servers) periodically to provide agent status and check for updates.
I'm open to other suggested solutions to the problem, but I've already got a working prototype for the "status and self-updates" idea, which is what this question is focused on.
What I came up with is actually a separate project that acts as a wrapper for the agent. The wrapper periodically calls the central server via HTTP to check for an updated version of the agent. Upon finding an update, it downloads the new version, shuts down the running agent, and starts the new one. If that seems like an odd or roundabout solution, here are a few other considerations/constraints worth noting:
When the wrapper gets a new version of the agent, there may be new JAR dependencies, meaning class path changes, meaning I probably want to spawn a separate Java process instead of fiddling with ClassLoaders and running the risk of a permanent generation memory leak, which would require manual intervention--exactly what I'm trying to get away from. This is why I ended up with a separate, "wrapper" process to manage the agent updates in my prototype.
Some servers where the agents are deployed are resource-limited, so any solution needs to be low on CPU and memory usage. That makes me want a solution that doesn't involve spinning up a new JVM and is a stroke against having a separate wrapper process.
The agent is already deployed to both Windows and RHEL servers, so the solution must be cross-platform, though I wouldn't have a problem duplicating a reasonable amount of the process in batch and bash scripts to get things rolling.
Question: As stated, I want to know how to make a self-updating Java app. More specifically, are there any frameworks/libraries out there that would help me with this? Can someone with experience in this area give me some pointers?
If your application is OSGi based, you could let OSGi handle bundle updates for you. It is similar to the wrapper approach you suggest, in that the OSGi container itself is "the wrapper" and some of it won't be updated. Here's a discussion on this
Different solution: use (and pay for) install4j. Check out the auto-update features here
No need for wrapper (save memory) or java web start (adds more restrictions on your application), simply let a thread in you application check periodically for updates (e.g. from cloud) and download updates if available, then code these two calls in you application:
launch a shell script (.sh or .cmd) to update your artifacts and launch your application after few seconds pause in the script(to avoid having two instances of your application at the same time).
Terminate your application (first instance)
The script can overwrite needed artifacts and re-launch your application.
enjoy !
Have a look at Java Web Start.
It is technology that's been part of Java since... 1.5? maybe 1.4? and allows deployment and install of standalone Java-based apps through a web browswer. It also enables you to always run the latest app.
http://www.oracle.com/technetwork/java/javase/overview-137531.html
http://en.wikipedia.org/wiki/JNLP#Java_Network_Launching_Protocol_.28JNLP.29
also see this question: What's the best way to add a self-update feature to a Java Swing application?
It appears as though Webstart is the only built in way to do this at the moment.
Just wondering if anyone has ever converted a Websphere project to run under tc server? I run on a Mac and would love to be able to run my application locally without having to run Websphere in a VM.
I realize there are differences which would have to be accounted for, and that's really my question - what would I have to change? I also realize that even if this is possible, one couldn't depend on the tc server configuration before going to production - it would have to be tested in Websphere first.
As we know, application server provides lot more features than a tomcat. Hence first, you would have to check if your application is using any of those features. If so, then you would have to see if that missing functionality could be plugged-in somehow. To exemplify, you could be using the transactional capability of the application server. Tomcat doesn't come with transaction capability. You would need to plug-in a a third party component for that. For this to happen less intrusively, the code should be configurable so that based on the environment it would know whether to make use of the capabilities of the application server or use the capabilities of the plugged-in components in case of tomcat.
Advantage of this: It would certainly be boosting to the productivity if you use tomcat to develop rather than any application server, as the time it takes to start and stop tomcat if far less than the coffee time (To me ,one coffee time is the amount it takes for an application server to stop and start even when you have the minimal hardware requirements mentioned by it)
Warning:: Again this approach has a negative point that you would miss to see how your component interacts with the classes in the production environment, while you develop. Hence it becomes mandatory to have your QA environment and above to make use of the application server. This way you could avoid any surprises in production.
We're using Windows 2008 and we are thinking of switching application servers from Adobe ColdFusion 9 to Railo 3.1. This would mean using a new Java servlet container, so instead of Adobe JRun 4, we're looking at Apache Tomcat.
Adobe have a helpful perfmon plugin for CF9. We can gather most stats with that. The problem is, as far as I understand, there is no perfmon plugin for Tomcat.
I wanted to know if there are any kind of free profiling tools we can use to get metrics and performance data on Tomcat, for example requests/sec, memory usage etc.
I don't mind if they are just written to logs so long as we can read them in some format. Also, it doesn't have to be a stand-alone product.
Any and all help appreciated!
Just curious - which application server are you using now? Which one uses perfmon now?
Because you've got to run Tomcat on an operating system - Windows, Linux, etc. You seem to imply that perfmon is useless to you now. I don't believe that's the case.
If you need to embellish info from perfmon, you can certainly buy something. But the cheapest solution for you would be filters that would intercept every incoming request and outgoing response to calculate request counts, response time, etc. You'd write these classes once and declare them in your web.xml. They could write to logs using log4j.
Or maybe Hyperic's solution is what you have in mind. It used to be open source, but Spring bought them a few years back. Then VMWare bought Spring. It's all part of a grander solution.
LambdaProbe will give you monitoring for sessions, memory used, web app sessions and servlets, connections etc.
Take a look at the demo site http://demo.lambdaprobe.org/ for more.
Site login: demo/demo