Friday, July 10, 2009

Monitoring Generic Processes

A previous blog of mine talked about how you can monitor an application or generic operating system process by going through its Script/CLI interface (you can watch a demo of the Script plugin to see it in action).

There is now another way to do this in Jopr, thanks to the new process monitoring feature introduced in the platform plugin.

Even if you do not have a CLI interface for the operating system process you want to monitor, you can still ask Jopr to monitor it - you do so by pointing Jopr to a pidfile containing the process's pid, or you can give Jopr a PIQL process query to execute to find the process. (PIQL = process information query langage). Note that this is all cross-platform - you can monitor processes on Windows just as easily as you can on any UNIX flavored operating system, so long as there is native support for your platform and it is enabled (which is normally the case, so you typically don't have to worry about this - you'll get this stuff for free).

What this means is for any process running anywhere out on your network, you can monitor that process. This process monitoring mechanism can be used to inform you if your managed process is up or down, and it can collect some metrics on the managed process, such as CPU utilization, memory consumption, and file descriptor usage.

You can watch a demo of this process monitoring feature to get a feel for how it can be used and what it does.

2 comments:

  1. Nice plug-in.
    I start JOPR experience with it.
    Only one thing: Could we fetch Measurement definition from out side Script Plugin jar?

    Arnaud

    ReplyDelete
  2. What you are asking for is what we call "dynamic metadata" - this means things like measurement definitions can be determined at runtime while the plugin is running.

    Today, that is not supported in the core plugin container but is on our TODO list. See the dynamic metadata design wiki page

    Today, you'll have to define your measurement definitions via metric elements in your custom plugin's descriptor (where that custom plugin extends the Script plugin - that's what I did to show measurement data at the end of the Script Plugin demo).

    ReplyDelete