Wednesday, December 30, 2009

Laufen 2009 / 2010 (German)

Das Jahr neigt sich dem Ende zu; Zeit für einen Jahresrückblick: ich habe beide gesteckten Laufziele gut geschafft:

- Stuttgart-Lauf ankommen. Ich habe das Ziel dann zweimal hochgesetzt. Erst auf unter 2:30h und dann auf unter 2:15h. Letztlich war es dann besser :-)

- Mehr als 750km laufen - das habe ich mit 792km auch gut hinbekommen - wenngleich ich im Dezember nochmals richtig Gas geben musste









Einheiten75
Distanz792,23 km
Distanz pro Einheit Ø10,56 km
Pace Ø5:55 min/km
Geschwindigkeit Ø10,14 km/h
Fitness46 (37-45)
Puls Ø / Max159/191
Kalorien62237

Bester Monat war der Dezember mit 135km

Läufe an "exotischen" Plätzen:



Ziele für 2010

- Stuttgart-Lauf schneller als 2009 (also unter 1:59:04) - wenn das Wetter mitspielt und ich nicht krank bin

- 900 Laufkilometer

Monday, December 21, 2009

RHQ / Jopr tab sweep

This post is to gather a few of the recent developments around RHQ and Jopr

Just in case you have missed it: RHQ 1.4.0.B01 is out - this build contains the Jopr plugins and thus is the successor of the Jopr-server builds that you have seen before.

Mailing lists:

We have opened two mailing lists for RHQ where we expect to bundle the email activities in the future:

  • rhq-users: for user questions around RHQ (including the Jopr plugins

  • rhq-devel: for developing with and on RHQ


Video:

Galder Zamarenno from Infinispan has created a video showing a three-node Infinispan cluster being monitored. It demonstrates graphical measurements, and non-graphical information of running Infinispan instances, addition or removal of monitored metrics and finally, execution of management operations on a Infinispan instance.

Mazz has created a demo on how to use the new server side plugins to periodically create reports on the server.

Alert senders:

Alert notifications can now be processed by plugins. This means that it is finally possible to easily write own notification schemes to forward alerts to various devices. Two posts show how to write such a sender (Part 1 & Part 2).

Agent plugins:

A new agent plugin allows to use script in Ruby and JavaScript to do monitoring. This allows to easily monitor resources via dynamic scripting languages without writing Java code.

Tuesday, December 15, 2009

How to write an alert sender plugin for RHQ/Jopr (Part 2)

Now that we have seen the "theoretical side" of writing an alert sender, lets just start and code one up.

First grab RHQ from GIT and then change into
modules/enterprise/server/plugins.


  • Run this little script:

    mkdir alert-url
    cd alert-url
    mkdir -p src/main/java/org/rhq/enterprise/server/plugins/alertUrl
    mkdir -p src/main/resources/META-INF

  • copy over the pom.xml from alert-email and change email to url in it:

    cp ../alert-email/pom.xml pom.xml,1
    sed -e 's/email/url/' < pom.xml,1 > pom.xml

  • Lets edit the plugin descriptor

    vi src/main/resources/META-INF/rhq-serverplugin.xml

    <alert-plugin
    name="alert-url"
    displayName="Alert:Url"
    xmlns="urn:xmlns:rhq-serverplugin.alert"
    xmlns:c="urn:xmlns:rhq-configuration"
    xmlns:serverplugin="urn:xmlns:rhq-serverplugin"
    package="org.rhq.enterprise.server.plugins.alertUrl"
    description="Alert sender plugin"
    version="1.0"
    >

    This is just the generic header. Now lets set the target host name on the server-wide preferences and

    <serverplugin:plugin-configuration>
    <c:simple-property name="hostName"
    default="localhost" />
    </serverplugin:plugin-configuration>

    Now the name of the sender and its alert sender class

    <short-name>Url</short-name>
     
    <!-- Class that does the actual sending -->
    <plugin-class>UrlSender</plugin-class>

    And now finally the Information that is specific to an alert definition. Lets just set the port here for demonstation purposes.

    <alert-configuration>
    <c:simple-property name="port" type="integer"/>
    </alert-configuration>
    </alert-plugin>

  • Now lets implement the Java sender class

    $ cd src/main/java/org/rhq/enterprise/server/plugins/alertUrl
    $ vi UrlSender.java

    package org.rhq.enterprise.server.plugins.alertUrl;
     
    import java.io.OutputStream;
    import java.net.HttpURLConnection;
    import java.net.URL;
     
    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
     
    import org.rhq.core.domain.alert.Alert;
    import org.rhq.enterprise.server.alert.AlertManagerLocal;
    import org.rhq.enterprise.server.plugin.pc.alert.AlertSender;
    import org.rhq.enterprise.server.plugin.pc.alert.ResultState;
    import org.rhq.enterprise.server.plugin.pc.alert.SenderResult;
    import org.rhq.enterprise.server.util.LookupUtil;
    import org.rhq.enterprise.server.xmlschema.generated.serverplugin.perspective.ResourceTaskElement;
     
    public class UrlSender extends AlertSender{
     
    @Override
    public SenderResult send(Alert alert) {

    So this was just the bolier plate code - now lets get the work done by first getting our data that the user entered in the UI

    String hostname = preferences.getSimpleValue("hostname","localhost");
    String portS = alertParameters.getSimpleValue("port","80");

    Then construct an URL and URL connection

    HttpURLConnection conn = null;
    try {
    URL url = new URL("http://" + hostname + ":" + portS);
    conn = (HttpURLConnection) url.openConnection();
    conn.setRequestMethod("POST");
    conn.setDoOutput(true);
    conn.setDoInput(true);
    OutputStream out = conn.getOutputStream();

    Then we get the message together - you see, you can even call into the EJB layer to get things done - and send it off.
         
    AlertManagerLocal alertManager = LookupUtil.getAlertManager();
    StringBuilder b = new StringBuilder("Alert: '");
    b.append(alert.getAlertDefinition().getResource().getName());
    b.append("' (");
    b.append(alert.getAlertDefinition().getResource().getId());
    b.append("): ");
    b.append(alertManager.prettyPrintAlertConditions(alert));
     
    out.write(b.toString().getBytes());
    out.flush();
    conn.connect();
    } catch (Exception e) {
    return new SenderResult(ResultState.FAILURE,"Sending failed " + e.getMessage());
    }
    finally {
    if (conn!=null)
    conn.disconnect();
    }
     
    return new SenderResult(ResultState.SUCCESS,"Sending to " + hostname + ":" + portS + " worked");
    }
    }

    After this was done, we return our operation result in a new SenderResult object - that's all.

    Now just change back to the root directory (the one with the pom.xml file) and fire "mvn install". This leaves you with a jar archive in target/ that you can then deploy into a (running) server:

    Deploying the plugin



    You can deploy the plugin in three ways, where the first one is probably the best, when developing such a plugin:

    • run mvn install above with option -Pdev - this will automatically deploy into the development containter
    • copy the plugin manually into the dropbox at $RHQ_SERVER/plugins (that directory is in parallel to bin/ and jbossas/ )
    • Deploy via GUI:


      • Go to the plugins page
        Bildschirmfoto 2009-12-15 um 21.00.37.png


        and select server plugins at the top tab
      • Scroll down to the upload box, select add, select the plugin in the open dialog and then when done, click on "upload".
      • Press "scan for updates" at the bottom of the plugin list above - it should now show up in the list of plugins


    Configuring it



    Click on "Alert:Url" in the list of plugins. This will bring you to the plugin details. And then on "Configure Alert:Url" (configuring could also happen from the Administration->System Configuration->Settings menu).

    You will see a list of plugins where the Alert:Url one is selected on the left and the current site wide preferences on the right:

    Bildschirmfoto 2009-12-15 um 21.41.18.png


    If you click on Edit, you can edit the host to some other value than the default.

    Using it in an alert definition




    Go to the usual screen for alert definitions of a resource - in the preliminary gui, there is a link To Alert sender plugins; click it.

    You will come to a screen with a drop down - select Url from it

    THIS UI IS CURRENTLY WORK IN PROGRESS

    Click on "Go" and then in the configuration enter the port number to use. Click on "submit it".

    Done

    Congratulations


    you have just written and deployed your first alert sender plugin for RHQ and Jopr




Monday, December 14, 2009

How to write an alert sender plugin for RHQ/Jopr (Part 1)

Now that RHQ 1.4.0-B01 is out, it is time to show you how you can easily write your own alert notification mechanism and plug it into RHQ (see also "RHQ and the future of alerts").

As an example we'll use a sender that will use a http-POST request to a remote host where the body of the request will contain the alert message (like the one you know from the existing email-sender).

But before we do this, I'll show you the bits involved, so that the source code is easier to understand.

In order to write the plugin you need two things at least:

  • plugin descriptor

  • a sender class


Sometimes you also want to implement a component class (more later).

So lets have a look at them in turn:

Plugin descriptor



The structure of the plugin descriptor, rhq-serverplugin.xml, looks like this:

rhq-serverplugin-alert.png


It follows the schema definition in rhq-serverplugin-alert.xsd.
Elements in it are the following.
  • alert-plugin: This is the parent element for the whole descriptor. It contains the following attributes, which are all taken from the general server plugin descriptor:

    • name: name of the plugin

    • displayName: name of the plugin as it shows up in the UI

    • package: the package of the plugin. Is used to determine the fully qualified class name if it contains no package. Within RHQ, there is a naming convention of Alert:medium for this

    • description: A description of the plugin as it shows up in the list of plugins

    • version: the version of the plugin.




The first few child elements come from the general server-plugin descriptor and apply to all server side plugins.

  • help: general information about the plugin, that also shows up in the list of plugins

  • plugin-component: class name of a class that gets loaded on plugin start and stays there as a "singleton" until unload. See below.

  • scheduled-jobs: this is a configuration that allows you to have your plugin code be run at regular intervals; it is probably less of interest for alert senders

  • plugin-configuration: properties listed here will end up in the system-wide preferences system UI and serve to do general configuration of the plugin (like e.g. the name of a remote host where alert notifications should be sent to)


The next batch of elements is specific to the alert-plugins:

  • short-name: the short name of the sender. This is used e.g. in UI drop downs to select the sender

  • plugin-class: the name of the class that implements the abstract AlertSender class to build the actual sender.

  • alert-configuration: specific properties on a per AlertDefinition basis. This can e.g. be the list of email addresses the alert notification should be sent to.

  • custom-ui: this element is not yet active and is supposed to help building a custom UI if the UI via alert-configuration is not powerful enough.



The sender class



All senders need to extend the class org.rhq.enterprise.server.plugin.pc.alert.AlertSender which looks a little like this:

public abstract class AlertSender {
 
/** Configuration from the global per plugin type preferences */
protected Configuration preferences;
 
/** Configuration from the per alert definition parameters */
protected Configuration alertParameters;
 
/** Global component holding persistent resources */
protected T pluginComponent;
 
/** Do the work */
public abstract SenderResult send(Alert alert) ;
}


The method of interest is send(Alert) where you get the data for this specific alert passed in. You need to implement it.

The preferences or the alert definition specific properties are injected by the RHQ server, as well as the plugin component, so that you can just get your properties that you set up in the deployment descriptor via calls like this:

String hostname = preferences.getSimpleValue("hostName","localhost");

assuming that you have the following in the plugin descriptor:

....
<serverplugin:plugin-configuration>
<c:simple-property name="hostName" />
</serverplugin:plugin-configuration>
...


Component class (optional)



The component class is a class that implements the interface org.rhq.enterprise.server.plugin.pc.ServerPluginComponent. It can be used to e.g start up a connection to a remote host within the start() method and tear it down when stop() is called. You need to expect that start() and stop() can get calles multiple times during the life of a plugin.

The interface has two more methods: initialize() and shutdown() - those are called directly after loading and before unloading an alert sender. The idea here could e.g. to load an external library and unload it at plugin unload.

The component class is a "singleton" in the lifecycle of a server plugin and stays present while the plugin is loaded. It is optional for alert Plugins - if it is present, it will be injected into AlertSender.pluginComponent.

Plugin structure



The alert sender is created in the standard Maven-2 directory structure. Java sources go into src/main/java/, while the plugin descriptor goes into src/main/resources/META-INF/rhq-serverplugin.xml:

File system structure for an alert sender plugin


Round up


Ok, that's it for now. You have seen what is involved in writing an alert sender plugin for RHQ and Jopr (versions 1.4.0.B01 and up).

As always give me and us feedback - e.g. via Irc at #rhq on freenode.


Continue with part 2...

Friday, December 11, 2009

RHQ 1.4.0.B01 released - includes Jopr

The RHQ project is pleased to announce the release the first developer build of the RHQ 1.4.0 platform. This developer release, 1.4.0-B01, provides an early looks at the new features which we are planning for the 1.4.0. This release contains many of the plugins which had been available as part of the Jopr project, along with the plugins that were included in previous RHQ releases.

Note: we do not advise to upgrade any existing Jopr or RHQ installs with this build!

Check out the
Release notes.

And
download the software.
The individual maven project artifacts have been published to the JBoss maven repository under org/rhq/ and org/jboss/on/.

Source code can be found in the git repository at fedorahosted.

If you have questions, join us on #rhq on irc.freenode.net or use the mailing lists:

Of course you can still use the existing mailing lists and forums.

Tuesday, December 08, 2009

New experimental (ruby) script plugin for RHQ / Jopr (updated)

I've just committed an experimental 'script2' plugin to the RHQ git repository, that allows to write monitoring scripts in the Ruby programming language.

This plugin is not yet enabled in the normal build because of issues (see below) - if you want to have a look at it, go to modules/plugins/script2 and issue mvn -Pdev install.

To use the script, go to the platform and manually add a script2 resource
For the connection properties you need to specify the scripting language to use and the name of the script, which needs to exist at $AGENT/data/script2/ in the agents file system.

Your script needs to provide 3 functions: avail, metric(name) and trait(name) - here is an example to show this. By default 4 metrics named 'metric1'..'metric4' are collected as well as one trait called 'trait1'.



def avail
return 1
end
 
def metric(name)
return 4
end
 
def trait(name)
return "Hello Ruby World: #{name}"
end




Unfortunately there is still one issue in the code that makes the scripting engine "forget" the script, so that after some time you'll see
exceptions like the following show up:

:1: undefined method `avail' for main:Object (NoMethodError)

If you have an idea what is going on, please tell me.


UPDATE
Thanks to Yoko Harada I was able to isolate the issue and fix it. Basically the issue is that the script was evaluated in one thread and later its methods got invoked in other threads which did not contain the evaluated script. So now I am just always re-evaluating the script before calling invokeFunction(). This is somewhat slower, but works.

It looks like if I would use the Red Bridge api directly (which is part of the JRuby 1.4 distro), there would be a better way, but the current implementation would allow for different scripting languages. Which brings me to:

Also if you want to help to get other languages implemented, contact me.

Friday, December 04, 2009

Facelets ui:include considered powerful

Just as a preface: I am very far from being a JSF or Facelets expert - more a novice.


So lately I have been looking at how to dynamically include Facelets or general xhtml snippets into my JSF/Facelets pages. One of the tags made for this is of course <ui:include>. In its src-attribute you give a path to a page to include like <ui:include src="/path/to/file.xhtml"/>. So far so cool.

Now I want to have the page to include to be dynamic - after a lot of googling I found that I can actually pass an EL expression like this <ui:include src="#{BackingBean.path}"/>. This did first not work at all, because I had a typo in the name of the backing bean - and I just got an error "there is an error" :-/ After the typo was fixed, I was able to get the path from the backing bean.

Now there are situations where my included page can or should not be shown.

First (naive) approach was (we are using RichFaces):

<rich:panel rendered="someCondition">
<ui:include src="#{BackingBean.path}"/>
</rich:panel>

But no matter the condition, BackingBean.path was evaluated and this could return something that does not point to the file, which screwed up the whole page with the above "there is an error" message.

So I ended up with creating an empty page, that I put into the webapp and my BackingBean.path now looks like this:


public String getPath() {
if (someCondition)
return stringExpression;
else
return "/path/to/empty.xhtml";
}


This works like a charm.

And I also found out that the src-attribute of ui:include actually is an URL, which means, that it is possible to get the included snippet from a remote web site or from within a Jar file like


public String getPath() {
URL pathUrl = getClassloader().getResource("nameOnClasspath");
return pathUrl.toString();
}


So yes, <ui:include> is a powerful feature of Facelets.

Thursday, November 26, 2009

RHQ and the future of alerts

So don't get me wrong, alerts will stay within RHQ - I am not questioning them.
In contrary - I am actually working on improving the alert subsystem. As a start I've written some design documents that can be found on the RHQ wiki:


Please go through them and give us feedback.

But before I continue - a little teaser:

Sms_alert.jpg


I've extended the Mobicents sender in my experimental branch (see 'Jopr talking') to also support sending via SMS now. So the image above shows an alert sent via that mechanism. Thanks to Jean Deruelle again for helping me on the Mobicents side.

But now back to future alert design...

We have identified the following four fields of change / improvement:

  • Allow for pluggable alert senders

  • Allow to acknowledge alerts by users

  • When a resource is in maintenance mode, do not send alerts about it

  • Escalate alert notifications if an alert is not reacted on


Of course some of those are meant for the future - e.g. there is no maintenance mode yet.

The first thing - which I am currently working on are pluggable alert senders. So if you want to e.g write a sender that posts alert notifications to an IRC channel, you can do so now. This is done in a pluggable fashion, which means that the code that does the work and also the UI is encoded in your plugin.

If you want to write such a plugin, you need to do two things:

Extend the abstract AlertSender class and write a plugin descriptor (here is the schema)

I've started an example on how to use this API.

Note that all of this is not yet finished and may change at any time - again I'd like to hear your feedback.

In the very first version only UI elements that follow a <configuration> will be supported. Later it will also be possible to supply a XHTHL snippet for UI fields, where you need to write your own backing beans to transfer the values into the alert subsystem.

Monday, November 23, 2009

Struts 1 and enums - heads up

I lost some good hours on the weekend trying to find out, why a field in my struts form bean was not filled with the correct value, while I could see in the HttpRequest, that the browser / page was indeed sending the correct data.

My form bean contained something like:

public class MyBean extends ValidatorForm {
 
private MyEnum anEnum;
private String someField;
 
public MyEnum getAnEmum() {...}
public void setAnEnum(MyEnum val) {...}
 
public String getSomeField() {...}
public void setSomeField(String val) {...}
}


Not only did my class compile well, I also did not get any errors when running the code - except that anEnum was always populated with the first value listed in MyEnum.

After I changed anEnum to String (and the getter/setter too) and did the conversion to Enum in the backend code, all was fine.

And yes, after I found the solution, I remembered, that we did have such an issue in the past already :-/

Monday, October 26, 2009

RHQ and Jopr: new source repository

Yes, we can as well :)

In the past it was often confusing to users that we have two source repositories for RHQ and Jopr. We have recently changed this.

The new RHQ repository lives now at http://git.fedorahosted.org/. There are a few branches defined, but the main one of interest is origin/master.

As you can see, we have not only move the repository location, but also move to the git version control system and even merged Jopr and RHQ together into one repository - so no more riddling where to find what.


See also this post about the change to bug tracking.

RHQ Bugtracker moves to Bugzilla - action required

RHQ project logo

Project RHQ, which is the foundation for Jopr will soon move all bug tracking from the old JIRA system at jira.rhq-project.org over to a bugzilla instance at Red Hat.

So when you have an account at the jira and reported bugs, you should follow those steps to have your cases linked to you on the new bugzilla site:


  1. Go to bugzilla at bugzilla.redhat.com

    1. If you don't yet have an account create one with your preferred email address.
    2. If you do have an account, login (or submit a password change request then login). And make a note of the email address you are using.

  2. Go to RHQ jira (http://jira.rhq-project.org/browse/RHQ),
    log in and set your email address through your profile (http://jira.rhq-project.org/secure/EditProfile!default.jspa) to the one you are using in bugzilla above.

Cutover will happen within the next few days

For now, the Jopr bugtracker will stay at the JBoss jira, but will probably also merged into bugzilla in the future.

Tuesday, October 13, 2009

Embedding ruby in java - less than trivial so far

Currently I am trying to get puppet, a configuration management system to be executed in Jruby - and especially embedded within some java code.

Luckily there is the JSR 223 scripting available in Java6, so the start is relatively easy: get jruby from jruby.org and add it to the java programs classpath, java program code looks like this:


// Define path to jruby libraries
System.setProperty("jruby.home","/opt/local/share/java/jruby");

// Get the scripting engine
ScriptEngineManager m = new ScriptEngineManager();
ScriptEngine rubyEngine = m.getEngineByName("jruby");

// Define the puppet script to run as arguments
rubyEngine.put(ScriptEngine.ARGV,new String[]{"example.pp"});

// read the script
File f = new File("puppet.rb");
BufferedReader br = new BufferedReader(new FileReader(f));

// and execute it
rubyEngine.eval(br, context);


Simple - eh?

Unfortunately is it not that simple (yet).

Passing the argument vector to my script does not yet work in jruby 1.4 cr1 (see JRUBY-4090), so I need to do a work around of defining a script, that sets this and then calls puppet


ARGV << 'example.pp'

require 'puppet/application/puppet'

Puppet::Application[:puppet].run



Next, puppet is complaining about missing stuff like OpenSSL (which is a difficult beast in jruby, as the standard ruby implementation needs some C code, which can not directly run in jruby).

Also it is somehow complaining about yecht not being found - I still don't really grok setting and properties up things like jruby.lib, jruby.home etc.

If anyone can shed some light on it, I would appreciate it :-)

Wednesday, October 07, 2009

Jopr, RHQ and the availability check interval (updated)



Jopr and RHQ check from time to time for each resources availability. This is done in the agent, where a periodic thread calls the getAvailability() method of each ResourceComponent. After this scan the result is sent to the server and the server shows the red and green state on the resource.

This server side processing creates a certain stress in large environements (say: hundreds of agents with ten thousands of resources), so that in Jopr 2.3 we have increased the interval this check is done to 5 minutes.

For many use cases (smaller installs, testing) this is too long. Luckily, this interval is not cast in stone, but configurable in the agent settings file, conf/agent-configuration.xml:


<!--
 
_______________________________________________________________
rhq.agent.plugins.availability-scan.period-secs
 
Defines how often an availability scan is run. This type
of scan is used to determine what resources are up and running
and what resources have gone down. The value is specified in
seconds.
-->
<!--
<entry key="rhq.agent.plugins.availability-scan.period-secs" value="300"/>
-->


You see the default is shown as commented value. To change this to a different value, remove the xml comment signs around it and change this back to e.g. 60 seconds (it will probably not make any sense to go lower than that, as the load on the agent, your managed resource and also the Jopr server will increase again):

<!--
-->
<entry key="rhq.agent.plugins.availability-scan.period-secs" value="60"/>


After this is done, you need to restart the agent to have it read the new value (see also next paragraph).

UPDATE

As the agent writes its configuration into the java preferences as backing store, the above change will not directly be honored. This may sound strange at first, but it has the advantage that you can run an agent, remove it, install a newer version of it and have the new version automatically use the saved values of the first agent install.

So you need to tell the agent that it indeed should read the new configuration file. This can be done by starting the agent with the option --clenanconfig or better by supplying -c agent-configuration.xml. This is explained at the top of the agent-configuration.xml file and also in the yellow box in the agent install document.


Of course this applies to JBoss ON 2.3 as well.

Monday, October 05, 2009

Jopr installer bug - careful when testing



The RHQ 1.3 and Jopr 2.3.1 installer has a little issue (see RHQ-2222 jira), where it clears out the database password when you click on "Test connection".

Lets have a look at a screen shot:

Bildschirmfoto 2009-10-05 um 17.48.13.png


When setting a database password (green circle) and then testing the connection (orange circle), the password will be reset and the install will fail later on.

If you are using the embedded H2 database, just re-select it in the drop down (violet circle) to have the database password filled in again by the system. Actually with H2, there is no need to test the connection in the first place :-)

Friday, October 02, 2009

RHQ tip of the day: agent confused?

Darko asked the other day on the Jopr Irc channel:

I have an agent, which isn't collecting my cpu-load data any more. I also have many more problems with the agent. How can I reset the agent to collect all data again? It may have to do with the fact that I had a server crash on the system with the running agent. Since the crash the agent isn't working any more.

It looks like the internal state database of the agent got confused. When the agent is fully configured and working, it will save its inventory of locally managed resources (a part of the global inventory kept on the server) along with their measurement schedules in a local database.

The agent can use this database to start working on the next start even if the server is not reachable. Changes on the server will synchronized when the connection is up again.

Now back to the original question: To get the agent going again, you need to erase the bad inventory and sync with the server again. You can do this by passing option --purgedata to the agent commandline:

$ bin/rhq-agent.sh --purgedata

To see a full list of the agents command line options, you can pass the --help option to the agent start script.

Thursday, October 01, 2009

RHQ tip of the day: Help, my resource does not show in the tree!



We see it from time to time that people have correctly set up Jopr or RHQ and want to monitor e.g. a JBoss AS server or other resources. They even have an agent running on the machine with the JBoss AS on, but still it does not show up in the resource tree of this platform.

Most often this is a simple issue, as the resource is just sitting in the queue to be imported into inventory:

Screenshot of autodiscovery portlet


Just select the ones you want to import, click on the import button and after a second, the resource will show up in the resource tree below its platform.

Jopr and RHQ require this on purpose, as this way you can ignore e.g. servers that are just up at the moment of import, but which are not to be managed.

As you have seen that resources can be ignored, there is also a way to "bring them back" when you decide later to import them. Either click on "View all..." in the Auto-Discovery portlet seen above or select Auto discovery queue from the Overview menu, then select Both new and Ignored from the drop-down:

Bildschirmfoto 2009-10-01 um 10.14.02.png


This will show ignored resources, that you can check and then click un-ignore to get them back into the new state from where you can finally import them.

Wednesday, September 30, 2009

RHQ plugins - platform services

There was recently a question on the Jopr devel mailinglist, that Ian Springer answered - I've taken his answers to write this post, as this is of general interest to plugin writers.

Bruno asks:
I have written a plugin which defines a single service like so:
<plugin ...>
<service
name="Interdomain Service"
...
supportsManualAdd="true">
</service>
</plugin>

But during auto-discovery, the resource discovery component does not get called. It only gets called, if I define the Interdomain Service to be a server. What am I missing here?

Lets first have a look at the resource hierarchy within RHQ:
PSS-hierarchy.png


So for <server>s that are standalone within a <plugin> tag, it is obvious that the parent is the <platform>, while <service> can have both other ResourceCategory as parent.

This means that you have to define the service's parent type(s), so RHQ knows where to stick it in the type hierarchy once it's discovered. There are a few ways to do this, depending on your needs.

If it's a platform service (i.e. a service whose parent is the platform
itself), you'd do something like:

<service name="Interdomain Service" ...>
<runs-inside>
<parent-resource-type name="Windows" plugin="Platforms"/>
<parent-resource-type name="Linux" plugin="Platforms"/>
<parent-resource-type name="Solaris" plugin="Platforms"/>
<parent-resource-type name="HP-UX" plugin="Platforms"/>
<parent-resource-type name="AIX" plugin="Platforms"/>
<parent-resource-type name="FreeBSD" plugin="Platforms"/>
<parent-resource-type name="Mac OS X" plugin="Platforms"/>
<parent-resource-type name="Java" plugin="Platforms"/> <!-- any OS that RHQ doesn't have native (i.e. SIGAR) support for -->
</runs-inside>
...
</service>


(If your service will only run on certain OS'es, you could remove the
unsupported platform types from the list of parent types).

Or you could do something similar to say it can be the child of multiple
server or service types, e.g.:

<service name="Interdomain Service" ...>       
<runs-inside>
<parent-resource-type name="JMX Server" plugin="JMX"/>
<parent-resource-type name="JBossAS Server" plugin="JBossAS"/>
<parent-resource-type name="JBossAS Server" plugin="JBossAS5"/>
</runs-inside>
...
</service>


Finally, if you want it to be a child of a single server or service type
defined in the same plugin, just nest it inside the parent server or
service element, e.g.:

<server name="CoolServer">
<service name="Interdomain Service" ...>
...
</service>
...
</server>



The reason it works if you change it to a server, rather
than a service, is because, when parsing the plugin descriptor, if RHQ
encounters a server element at the top level with no runs-inside types
defined, it assumes the server is a platform server (a server who has
all the platform types as its parents). So:

<server name="Interdomain Service" ...>
...
</server>


is essentially equivalent to:

<server name="Interdomain Service" ...>
<runs-inside>
<parent-resource-type name="Windows" plugin="Platforms"/>
<parent-resource-type name="Linux" plugin="Platforms"/>
...
<parent-resource-type name="Mac OS X" plugin="Platforms"/>
<parent-resource-type name="Java" plugin="Platforms"/> <!-- any OS that RHQ doesn't have native (i.e. SIGAR) support for -->
</runs-inside>
...
</server>


Most of the time when writing a plugin you will probably start with a server at the top level of your plugin, so it will just work.

1000 km :-)

Last weekend I crossed the 1000km mark since I started running last year (see here). I took me quite some time since the 800km mark at Stuttgart-Lauf. This had to a big extend to do with the fact that I was not really able to go out much while kids were on vacation from Kindergarden and also needed some rest after Üetliberg. But since start of september I am back on track :-)

So what are my next goals? I don't really know yet. Running Stuttgart-Lauf faster than this year probably. And just improving my overall fitness to be able to run at same pace with a lot lower heart rate.

Thursday, September 24, 2009

RHQ / Jopr agent waiting at startup

I have written in the past about RHQ and Jopr "agent waiting at startup. That actually was before high availability has been released, so it is a little outdated.

With high availability (HA) you will see one new type of issues: ip address forward and backward mappings do not match.

Basically you need to make sure that the IP address of your computer can be reverse mapped to the computer name and that this name mapps back to the same ip address.
And this needs to be true along all your hosts.

Suppose you have an IP address of 172.31.7.7, then the results of name resolution should look like the following:


$ dig -x 172.31.7.7
[...]
;; ANSWER SECTION:
7.7.31.172.in-addr.arpa. 86400 IN PTR snert
$
$ dig snert
[...]
;; ANSWER SECTION:
snert 74030 IN A 172.31.7.7


If you had agent-server communication working before and it stopped all of a sudden, go to the Jopr server UI, to the Administration -> High Availability -> Server section and check if the name shown there matches what you expect - same for the agents.


If this all works, and the agent is still hanging, have a look at the older post to rule out other possibilities for misconfiguration.

New api for manual discovery on RHQ and Jopr

The other day I was writing about manual discovery/addition of resources. Now that Jopr 2.3 (and its JBoss ON counterpart is out), we have updated the API for manual discovery to provide its own interface so that you don't need to fiddle around with finding the passed configuration.

The new API lives in the ManualAddFacet, which has one method
DiscoveredResourceDetails discoverResource(Configuration pluginConfiguration, ResourceDiscoveryContext<T> context)
throws InvalidPluginConfigurationException;
that you need to implement. This Facet is implemented in addition to the ResourceDiscoveryComponent within the discovery component. Ips has already converted all existing plugins to the new api, so you can have a look at many examples there, so I'll only show a short one here, which is an excerpt from the Twitter plugin:


public class TwitterDiscovery
implements ResourceDiscoveryComponent,ManualAddFacet {
 
// Auto-discovery not supported, so return an empty set
public Set discoverResources
(ResourceDiscoveryContext discoveryContext)
throws Exception {
 
// We don't support auto-discovery.
return Collections.emptySet();
}
 
// perform the manual add
public DiscoveredResourceDetails discoverResource(
Configuration pluginConfig,
ResourceDiscoveryContext discoveryContext)
throws InvalidPluginConfigurationException {
 
DiscoveredResourceDetails detail =
new DiscoveredResourceDetails(
discoveryContext.getResourceType(), //ResourceType
url + "_"+ user, // ResourceKey
url + " feed for " +user, // ResourceName
null, // Version
"One " + url + " user", // Description
pluginConfig, // Passed plugin config
null ); // Process scans
return detail;
}
}

I have also updated the plugin skeleton generator code in svn to support this new API and have uploaded the new version to jopr.org

Saturday, September 19, 2009

Jopr 2.3.1 released



The Jopr team has released version 2.3.1 of Jopr.

The major difference over Jopr 2.3 is a fix in the dbupgrade scripts.

If you are still on 2.2 and want to upgrade, use 2.3.1, as 2.3 will not correctly update your database schema.

You can download the release from SourceForge.

Friday, September 18, 2009

Jopr talking


I have added an experimental alert sender to Jopr that can call administrators on their phone, tell them the alert conditions and can then take input via DTMF tones. This input can be used to disable or re-enable the alert definition or to clean out this alert from the alert history.

This all has been made possible by via the Mobicents server and SIP servlet.

Mobicents logo

A special thanks goes to Jean Deruelle from Mobicents, who wrote the integration part on the Mobicents side.

Podcast episode

I have created an episode of the Jopr podcast that shows the setup and some UI demo (the call on the SIP phone has been faked a little bit, as my screen capture program is always crashing at this point, but the message read is real).

As usual, this podcast episode is available on iTunes.

Show me the code...

The code on the Jopr side lives in http://svn.rhq-project.org/repos/rhq/branches/HEIKO-EXP/. There is also code on the Mobicents side, but we still need to clean up things and write some documentation on how to integrate them.

Ping me if you are interested in this integration.

Monday, September 14, 2009

Snow Leopard - mixed feelings?

So far Snow Leopard is somewhat disappointing for me:

  • DNS - especially when VPN is on sucks, as SL is sometimes blacklisting very valid hosts all of a sudden. This results in e.g. "The computer is not connected to the internet" messages in Safari for sites like www.google.com (see e.g. here)

  • The upgrade broke Aperture - the upgrade process removed a framework needed by Aperture. For me re-installing /Library/Frameworks/Pluginmanager.framework from a TimeMachine backup worked. (see e.g. here)

  • Older Software like Parallels 2.5 no longer works

  • Nambu 1.2 no longer works (and Nambu 2 is still in closed beta)

  • X-Lite 3 has no sound in/out. Dialing works though. And the beta of X-Lite 4 is not even able to show the preferences.



The biggest item for me is currently the DNS one, as this renders the system more or less unusable.


But then there is at least some good thing about it:


  • The internal VPN now works against Cisco concentrators, which is very nice

  • JDK 1.6 is finally available on 32 bit macs like my 3 years old MacBook



I will update this post, when I see more pros and cons.

Friday, September 11, 2009

Jopr podcast iTunes URL has changed

The Jopr podcast is now available on iTunes at the following new place
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=331189266.

Please update your feeds or iTunes subscriptions accordingly. Thanks.

Thursday, September 10, 2009

New episode of the Jopr podcast: Manik from Infinispan (updated)

At JBossWorld Chicago I had the pleasure to do a short interview with Manik Surtani, lead of the Infinispan project.

The interview is now available in the Jopr Podcast home page and is also available on iTunes (note, the iTunes url has changed).

Enjoy!

Again: if you like it, please rate it up on iTunes and/or provide Feedback via email to me.

Tuesday, September 08, 2009

What a weekend

I am currentl staying in New Jersey, as the opportunity to give a talk at JBossWorld in Chicago also gave me the opportunity to go to NJ to meet the biger part of theJopr developers.

I arrived friday evening and as the car rental company ran out of cars, I got the last one remaining: a Chrysler Sebring convertible. On Saturday I went running and also drove around a lot with the roof open and music turned on - very nice :-)

Sunday I spent with Jess and family. Jess and I went climbing - my first time, but this was fun. One one side I can't imagine to do it more often, but on the other side I can :)

Today was Labour Day, so no one in America is working (only joking) and I went to New York. Walked around a lot and visited important landmarks like the Brookly bridge and the Apple store on 5th avenue.

Saturday, September 05, 2009

Jopr 2.3 released



Jopr version 2.3 has been released. You can find the binaries http://sourceforge.net/projects/rhq/ on SourceForge.

IMPORTANT UPDATE: 2.3.1 is out with a fix for dbupgrade

Notable changes are:
  • Support for JBoss EAP 5

  • A new command line interface: you can now talk to Jopr from a Linux or Windows command line. This interface uses the Java 6 script support, so that you can create scripts for re-use.

  • Group alerts: it is now possible to fire an alert when any resource in a group runs into an error condition by defining alert templates on the group

  • Experimental support for embedded H2 database and MS SQL Server (same as in 2.2.1)

  • Plugins can now depend one of several others: if you have e.g. a plugin that uses JMX it is now possible to either depend on JBossAS when the resource types are used within the JBossAS or depend directly (and only) on JMX plugin to discover standalone JVM versions of those resources.

  • Support for taking snapshots of resource configurations: it is now possible to gather e.g. all config files from one of your JBossAS servers and have that zipped up and put in a place on the Jopr server

  • Dynagroups have been extended to support searching more levels of ancestry

  • Postgres 8.4 is now officially supported

  • Autodiscovery of JBossAS jnp credentials: Jopr is now looking at the config files to obtain the security credentials for secured JBossAS instances, so that you do not need to type them in by hand in the inventory



And many many more improvements. You can see lists of closed Jiras for
RHQ and Jopr projects.

Matching SVN tags are http://svn.rhq-project.org/repos/rhq/tags/RHQ_1_3_0/ and Jopr_2_3_0.

As so often :) join us on irc.freenode.net #jopr or in the forums or or or :)

Thursday, August 27, 2009

Twitter plugin + alert sender for Jopr updated



I've updated the twitter plugin for Jopr:

Manual add instead of auto discovery

The Twitter feed is no longer autodiscovered, but you have to go to the platform and explicitly add it there.

Bild 11.png


The reason behind it is that most users don't want to have a twitter feed discovered on each agent.

To learn more about auto discovery vs. manuall add, have a look at my post "Jopr plugins: Autodiscovery vs. manual add".

Support for other Twitter-like services

The plugin is now also able to post to other twitter-like services like identi.ca (or your own private one based on the laconi.ca code).
The serverBase is http://identi.ca/api/ for Identi.ca, as well as the search base.
For Twitter, serverBase is http://twitter.com and searchBase is http://search.twitter.com/

If you select the right template, this will automatically be filled in for you.
Bild 12.png


Alert sender updated too

I've also updated the Alert sending in the HEIKO-EXP branch to be able to send to other networks than Twitter.
This means that in the system configuration, there is a new field for the base url of the services api. See above for possible values.

related...

I've just seen that Twitter is offering a streaming api. This may be a nice addition to the plugin. Today every request to obtain values opens a new connection to Twitter. With the streaming api, this could probably go away.

Wednesday, August 26, 2009

Jopr plugins: Autodiscovery vs. manual add


One thing that I have neglected so far in the plugin development articles for Jopr that I wrote is the possibility to just manually add a resource instead of having it auto discovered.

Why would you want to manually add a resource?

Some resources are virtual like e.g. Twitter feeds in the twitter plugin. If you have 100 agents, it makes no sense to either take the twitter feeds into inventory on all 100 of them or to have to ignore them all in the auto discovery portlet.

When to use auto discovery then?

Auto discovery is best used for more concrete resources like e.g. processes that can exist on a system (a JBossAS for example) or file systems etc. Those are items you usually want to monitor on each system.

Ok, show me the code

Well, actually the code is not that different from what you already know. Within ResourceDiscoveryComponent.discoverResources() the change is to check for passed resource configurations and use those to create the concrete discovered resource:

for (Configuration config :
(Iterable)
discoveryContext.getPluginConfigurations()) {
DiscoveredResourceDetails detail =
new DiscoveredResourceDetails(
discoveryContext.getResourceType(), // ResourceType
url + "_"+ user, // ResourceKey
url + " feed for " +user,
null,
"One " + url + " user",
config,
null );

return Collections.singleton(detail);
}
return null;

As the plugin container will only pass us one configuration at a time (even if the call to getPluginConfigurations() is returning a List), we can safely return the constructed detail. And this is already all :-)


One thing you need to change though is in the plugin descriptor:

<server
name="Twitter"
discovery="TwitterDiscovery"
class="TwitterComponent"
description="Twitter monitoring subsystem"
supportsManualAdd="true"

This supportsManualAdd is what lets the resource type show up in its parent (usually platform for a standalone server) "Manually Add" dialog:

Bild 11.png


For more resources related to plugin development have a look at this post.

Thursday, August 13, 2009

Monday, August 03, 2009

Twitter, OAuth, Java and Twitter4j

For alert notifications in Jopr, I am using the Twitter4j library, as well as for the twitter plugin.

As Twitter now requires the usage of OAuth to register new applications, I was looking into this as well. Luckily, Twitter4j has support for OAuth.

Unfortunately this did not work for me ;-(

After some digging, I found the solution (code is the one from the samples page):


...

System.out.println("Open the following URL and grant access to your account:");

System.out.println(requestToken.getAuthorizationURL());

System.out.print("Hit enter when it's done.[Enter]:");

String pin = br.readLine();

 

try{

  accessToken = twitter.getOAuthAccessToken(requestToken, pin);

...


So basically Twitter is returning a PIN to me after I have granted access - and this PIN needs to be passed to the call to get the auth token. This also means to use a different method than in the original example.


Friday, July 31, 2009

Experimental alerting via Twitter in Jopr (and RHQ)


Something for the weekend :-)

I have just committed support for sending alert notifications via Twitter into Jopr and RHQ.

Bild 12.png


The code currently lives in an experimental branch in the RHQ code base.

The twitter notification can be enabled in the usual place in the alert UI

Bild 11.png


while the twitter account is set in the System preferences

Bild 13.png


This code is still experimental, but works for me :-)

And then there is the Twitter plugin (and here), that allows you to watch twitter feeds from within Jopr.

Please provide feedback.

Wednesday, July 29, 2009

Jopr Twitter plugin renamed



Two days ago I have commited a Jopr plugin to monitor Twitter feeds

Due to popular demand (and also because 'twit' has some negative connotation in some slang forms of English) I have renamed the Jopr TwitStats plugin to Twitter plugin.
This also means that the location of the source has moved to
modules/plugins/twitter within the RHQ svn repository.

Monday, July 27, 2009

Jopr meets Twitter -- new plugin to monitor Twitter



As you surely know, I am also active on Twitter as pilhuhn. So I have sat down and started to write a TwitStat plugin for Jopr and RHQ just to show the possibilities of the Jopr platform, that it is not exclusively about managing JBoss products (as some people say) and to show more example code.

Currently the TwitStats plugin lets you:


  • Post your own tweets

    Bild 4.png


  • Monitor the number of tweets


    • Your friends timeline

    • Public users timelines

    • Search for stuff

    • Bild 5.png


      Interesting detail is that the Event dots (green ones) show the post date of a tweet, while the blue monitor dots (number of tweets since last poll) show that number at the time of polling.


  • Show the monitored tweets as events in the Events Subsystem:

    Bild 3.png




I have built the plugin around the Twitter4J library, which helps a lot in getting things done.

There are still some open issues:

  • OAuth support is missing

  • Calls to get tweets are synchronous and block the plugin for too long - those need to converted into async calls



You can find the source code in RHQ svn in modules/plugins/twitstats.

Please provide feedback - either in the RHQ Jira, in the Forums or on Irc

Monday, July 13, 2009

Jopr Java1 sessions available

The mini theatre sessions about Jopr are now online at YouTube. This is a four part series of videos. Greg Hinkle, lead of the Jopr, RHQ and JBoss ON projects is presenting:

Part1: http://www.youtube.com/watch?v=5X0kXk16sEw (shown below)




Part 2: http://www.youtube.com/watch?v=6VGXc7__OCg


Part 3: http://www.youtube.com/watch?v=whc5UH197qY


Part 4: http://www.youtube.com/watch?v=FqpyLWtJyBw


Tuesday, July 07, 2009

Resources for plugin development for Jopr, RHQ and the JBossAS admin-console

I have been asked a few times in the last weeks about writing plugins for Jopr, RHQ and JBoss ON. People were interested, but still were not completely sure what to do.

So the first thing to know is that a plugin written for Jopr will also run in JBossON2 and (most probably *) in the new admin-console of JBoss AS 5.1

So I've complied a short list of resources to go through for starting development of a plugin



Also Jopr Developers are online on IRC at irc://irc.freenode.net in #jopr


Contact me if you think that stuff is missing







*) You should of course always check it before delivering your plugin, but in most cases it should just work.

Infinispan presentation at JUG-Stuttgart next Thu

Manik Surtani will talk about Inifispan at the Java User Group Stuttgart.

Check out the following link for details and to register for the event.

http://jugs.org/veranstaltung-2009-07-16.html.

Dzone did a nice interview with Manik, that you can checkout here.

Friday, June 26, 2009

Small Jazoon sum-up




So, I have been at Jazoon for the last few days. I arrived on tuesday at noon - just missing the keynote by James Gosling - I have heard that it was not that good from the content, but I would have liked to see it nevertheless. Then I attended some sessions and had lunch (a "Bratwurst" - sausage, every attendee only one piece). There was a talk about "IPhone hacking for java programmers" - I was expecting to hear about e.g this x-compile effort, but the session really just presented the Apple tools and Objective C. Not that I did not find this interesting and the talk was also well presented, but it just was not what I was expecting.

In the afternoon I went with Bela for a run and then basically went with the other JBoss guys for dinner.

On Wednesday I had my own presentation, which did not that well as I wished - the 50 mins time constraint irritated me totally resulting in me being done too early. But at least I created enough interest to have people come to me later and asking about how to write plugins :)

Rickard Öberg was supposed to give a talk, but did not show up. Everyone said that he was perhaps captured by the CIA :-)

The last session of the day was the final of the "rookies competition" - rookies were asked to submit a talk and the program committee selected three talks that got presented and jury selected the final winner. The talks were of mixed quality and I had the feeling that the 3rd guy was pushed by Sun to the last 3. Luckily at least Bela Ban gave the guys an honest feedback - otherwise the jury process would just have been a big joke.
On wednesday evening was the party with burgers for dinner (lunch was pizza). I had some nice talks with some nice guys.

Thursday was the last day for me. Again some sessions, then lunch (sausage again), more sessions and then some talking with Alexander Neumann from iX magazine. Ed Burns was giving a talk (as a backup for a cancelled one) about his new book (I later got a copy of it that he signed) - for me one of the better sessions in the conference.

On all of the three days, the conference network had issues - either it was impossible to get an IP address or some other issue occurred.

So Jazoon leaves a very mixed feeling for me - on one side I had very good face to face talks and fun with people I met and on the other hand I was not happy with many of the talks I attended, the food and the network.

For food and network I could imagine that just raising the conference price slightly and then getting better food for that would work (and buy some more (private) IP addresses too. But for the sessions it is very subjective, so that someone else who was in the exact same sessions than I was, may have found it super.

Tuesday, June 23, 2009

Üetliberg

Today, while being at Jazoon in Zürich, I took a run together with Bela from the Saalsporthalle (close to the conference venue) to the top of the Üetliberg.

Things went a bit strange, as at some point we switched on the most direct track to the hilltop. So in summary we did more than 400m of altitude. This included 'crawling' over tree roots on a very wet soil.

You can have a look at the track at GPSies.com.

Here is a snapshot from Trailrunner about my performance (grey shows the heigth):

Bild 6.png


In both cases start height and end height do not match, as my Forerunner took a long time to discover the satellites and only did so while we were already running. This also means the distance has probably slightly longer.

A very nice thing is that at the Saalsporthalle, it is possible to just go into a public cloak room with showers, to change to sporting clothes and to shower later. Outside is even a possibility to clean the running shoes.

Update

A nice fellow at the top of the Üetliberg took photos of Bela and me and sent them via email to me:

103MSDCF 465.jpg

At the right you can see a bit of the Zürichsee.


103MSDCF 466.jpg

Monday, June 22, 2009

Stuttgart-Lauf

Yesterday was Stuttgart-Lauf again. Unlike the other years (see here for last year) I did participate in the Half-marathon (21 km).

When practicing, I was able to run the distance in 2:08h, but on a very flat course, so I was thinking that 2:15h would be realistic for this more demanding course.

But then at km 17 it looked like I would be able to run the track within 2h, so I tried to and here is the result:

Bild 4.png


My first half-marathon in 1:59:04h - wow, I am happy.

While running I also crossed the 800km border since I started running last year (see e.g. here).

Monday, May 11, 2009

Announcing the Jopr podcast


It is a pleasure to announce the Jopr podcast, a source for news, interviews and technical content around Jopr.

The first two episodes are online:

0 - A short intro

1 - A walk through the Jopr source modules

You can follow the Podcast on its home page and also directly subscribe to it on iTunes.

If you like it, please rate it up on ITunes or provide Feedback via email to me.

Also if you are German, you may also want to have a look at the video from my presentation at rheinjug earlier this year.

Friday, May 08, 2009

Video from my rheinjug presentation about Jopr online

The nice folks from rheinjug finally made the video of my presentation available together with the slides in an integrated player.

Bild 2.png


You can directly view this at rheinjug.tv. At the top of the page is also a possibility to download the video.

Video and slides are in German.
Minutes from the talk are available too.

Thanks again, Georg and Michael.

Thursday, April 30, 2009

Jopr 2.2 released



You may have seen yesterday and the day before that JBoss Operations Network 2.2 has been released. And you probably also know that Jopr is the upstream project for JBoss ON.

So we are pleased to announce the availability of Jopr 2.2.






You can download Jopr 2.2 from Sourceforge.

Note that the distro does not have a separate agent download, but the agent is included in the server. Set up the server, log in and then in the top menu you will find Admin->Agents->Download

Otherwise have a look at the install docs in our wiki.

Joe Marques has a longer list of new features in his respective blog post.

Wednesday, April 29, 2009

JBoss ON 2.2 has been released

Greg Hinkle already wrote it: JBossON 2.2 has been released.
This has been a big release for us - with arounds six month of work.

Some of you may already had a peek at the Jopr 2.2 beta and my know about some of the new stuff.



Changes were (in addition to hundreds of small enhancements and bugfixes):

* UI - Completely updated (and mostly rewritten from Struts to JSF), AJAX based UI with tree views, search and common menu system
* Clusters - Cluster oriented tree views with group-wise configuration management and monitoring
* Security - Improved DynaGroups queries and new support for recursive compatible groups simplifies access control
* Monitoring - Configuration change detection, auditing and historical review
* Agent auto upgrade - Agents automatically update themselves when new servers are installed
* Subsystem views - Pages that e.g. show alert info over all existing resources
* Much better IE support
* Speed improvements
* Automatic recalculatin of DynaGroups
* Plugin skeleton generator


More information about JBossON 2.2 can be found at http://www.jboss.com/products/jbosson

Wednesday, April 22, 2009

I love the Standalone container in Jopr (updated)


I am just working on a plugin when I have some spare cycles (I will tell you which one in a few days :-)

To test the plugin I am using the Standalone Container where I have deployed my plugin, the JMX and the platform plugin.
So when I have compiled a new version of the plugin I just copy it over and start the standalone container:

snert:rhq-agent hrupp$ bin/standalone.sh

Listening for transport dt_socket at address: 8788



Starting the plugin container.

Loading plugins

...Loaded plugin: Platforms

...Loaded plugin: JMX

...Loaded plugin: MyNewOne



Ready.

[0]:0 >


This takes 3 seconds and then I am ready to discover resources:

[0]:0 > disc s

Discovery took: 2269ms

[Resource[id=-3, type=Secret, key=service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector, name=Secret, parent=snert]]

[1]:0 >


Now I can test if my invokeOperation() method from the OperationFacet works:

[2]:-0 > set res -3

[3]:-3 > invoke getProperty name=test

[PropertySimple[id=0, name=result, value=null, override=null]]


So set the resource id to the resource I want to work with and then invoke the getProperty operation with parameter name and value test. The Operation then returned null, as the underlying resource does not know this specific value.

This all took around 10 seconds now for a round trip - you can't really do faster testing :-)

When I want to repeat those steps with an updated version of the plugin, I can save my work:

[4]:-3 > !w /tmp/foo

This creates a file and saves the commands given in it. The name of the file can later be given on the command line to just run the action as a script without any need to manually type in the commands.

There is currently one caveat: Resource ids will change in each startup so the "set" command in step 2 above will not work exactly like this.

[UPDATE]


I will work on adding variables to the find command in the standalone container which can then be passed to set -- if you want to help out contact me.


What you can do is to use $r as 2nd parameter to set after finding a single resource:

[5]:0 > find r *myFooBar*

-12: MyFooBar ( Resource[id=-3, ... )

[6]:0 > set r $r

[7]:-12 >



With this trick it is now possible to just run the container with the saved file as input again and again

$snert bin/standalone.sh /tmp/foo

Monday, April 20, 2009

RHQ and Jopr plugins: What about &lt;T> ?

When writing a Plugin for RHQ, JBoss ON and Jopr (or for completeness: Embedded Jopr, you will run into Generic types for ResourceComponent and ResourceDiscoveryComponent. And I am sure you have often wondered what the T in ResourceComponent<T> should be.

The following diagram tries to help here. We have two ResourceTypes that from a Parent-Child relationship e.g. a Database and a DatabaseTable.

If you don't know what parent you will run in, you can just leave the generic bit away, as in ParentDiscovery and Parent in the diagram. This is usually the case for ResourceTypes of the Server category that live in their own plugin. One could also use the platform component as parent if its clear that the plugin will only run as a child of the platform, but never e.g. within another resource like a JBossAS.



InheritanceDiagram.png


Children of this server Parent will set the T to the parent component. This allows them to e.g. access the parent ResourceContext.

For examples of all this, check the Jopr source code, which contains many examples.

Friday, April 17, 2009

♫ I'm running in the rain ... ♫

Today it was raining, but I had the urge to go out for a run, so I went out nevertheless. Normally I am more a like a sissy in that area though.

But after around 1km I felt warm enough so that it did not feel uncomfortable anymore and later on it did not even feel bad being splashed by a car driving through a puddle. And this is how I looked when I was coming home:

DSC00039.JPG


But hey, it felt great !

And the best: my Adidas (Supernova) shoes stayed dry inside. No wet feet - I just love those.

( The very best was actually that my ankle did not hurt )

Jopr/RHQ plugin generator updated

The plugin generator has been updated for the plugin lifecycle listener. I have uploaded a new version to the description page on the RHQ wiki.
So you can grab the standalone jar file from there without the need to download the RHQ source and compile it from scratch -- which would not be hard actually:


$ cd $RHQ/modules/helpers/pluginGen

$ mvn install


You can find the resulting rhq-pluginGen*-jar-with-dependencies.jar in target/ then.

Sunday, April 05, 2009

List of Jopr / RHQ resources


Just as a FYI:

Mazz has, while answering a forums post made a nice list of resources
related to Jopr and RHQ.

Check out the post at the Jopr user forum.

Saturday, March 28, 2009

GSoC students where are you? Jopr wants you!



JBoss and Fedora are this year again participating in Google Summer of Code as mentoring organization.

We have set up a list of ideas at the JBoss Wiki.

For Jopr some ideas are:

  • Baselining that respects hourly and weekly variances to get better out-of-bounds conditions

  • Proactive alerting - alerting operators of bad conditions before they actually happen

  • Correlation of arbitrary input values to generate new results - often one input parameter is not enough to determine if a bad condition is in place

  • Multidimensional multimetric multidevice graphing of measurement values

  • Portal-UI for Jopr so that users can compose their own UI. This includes adding of other related consoles

Of course contributions are not limited to these ideas.

If you want to participate, be quick as deadline for submissions is on April 4th !

For more information have a look at the GSoC FAQ.

Friday, March 20, 2009

Working on a standalone PluginContainer wrapper

I have been working on a standalone plugin container wrapper for RHQ and Jopr which allows to call plugin functionality without the need for a fully running agent and server. Of course this only makes sense while developing a plugin.

This video shows how this may look like (swf format).

This stuff is not yet committed to subversion, but I guess I will do that in the next few days.

Please provide feeback.

Review of my talk @RheinJug with pictures

Yesterday I was talking at Rheinjug in Düsseldorf about RHQ, Jopr and JBoss ON.

To get to Düsseldorf, I took the ICE fast train which took 2:41h for 410km distance, which is the fastest way to travel between those cities. On this course, Deutsche Bahn is offering WiFi on board (unfortunately not for free), so you basically have Internet at 300km/h - nice. While being on the train I also started about implementing a Standalone PluginContainer wrapper that can be used when implementing a new plugin to test it; I will post about this separately.

After I arrived in Düsseldorf I first went to my Hotel, which is nicely located in the old town - only 5 mins by subway from the main station. after check in I walked around a little bit in the old town and went to the Rhein river. On the next picture you can see locals with one of their favorite occupations:




People were just standing outside a brewery and drinking Altbier. In summer that place is crowded.

Düsseldorf is supposed to have "die längste Theke der Welt" ( 'the longest bar counter of the world', which is not to be taken literally ) see also:


There are lots of other restaurants and bars in that area too, as you can see from this picture:


 



I took the tram to the Heinrich-Heine-University where the talk was taking place in an auditorium. The first people were already there and enjoying food and drinks sponsored by Red Hat Germany.













Michael Jastram from the JUG opening the evening by welcoming all of us and doing a little lottery - prizes were a Jetbrains license, a backpack and a copy of my EJB-3 book.

After this my colleague Joachim Schröder who is living close to Düsseldorf briefly introduced Red Hat before my talk started:




My talk was taped by the user group and should soon be available on the Rheinjug.tv web page



(Installation of the camera)

Around 40 people had found their way to the presentation at that time. The talk itself went well. As usual I was also talking about the thermometer chip monitoring that I implemented a while ago. And of course I did a live demo of the system which was well received. In the Q&A session we had some good questions from people who obviously have an administration background.











When this "official" part was over we relocated to a different part of the building and did some more socializing.







Joachim drove me to my hotel, where I arrived around midnight. While this he told me that he especially found the thermometer chip part very interesting, as he recently implemented some monitoring of his heating system with this exact chip and with some proprietary code. So he is now interested in replacing this with a Jopr based solution :)

This morning when I went back to the main station, I met Mete again, who was in the talk yesterday. He invited me for a coffee (thanks again) while I was waiting for my train and we had another good conversation.