En particular es algo que necesito muy a menudo así que lo tengo encapsulado en el siguiente método estática en una clase de utilidades:

public class Time {
	/**
	 * @param initial Initial time in milliseconds.
	 * @return a message with the shape: "xxx seconds (YYY millis)"
	 */
	public static String getLapseTimeMessage(long initial) {
		TimeUnit secondsUnit = TimeUnit.SECONDS;
		TimeUnit millisUnit = TimeUnit.MILLISECONDS;

		long timeLapse = System.currentTimeMillis() - initial;
		long seconds = secondsUnit.convert(timeLapse, millisUnit);
		long millis = millisUnit.convert(timeLapse, millisUnit);

		return seconds + " seconds (" + millis + " millis)";
	}
	../..
}

Una clase cliente la utilizaría como sigue:

long initial = 0;
if (logger.isDebugEnabled()) {
	initial = System.currentTimeMillis();
}

Parser parser=new ParserFactory().makeParser();
String text=this.programText;
this.program=parser.parse(text);//ParseException, IOException

logger.debug("Javascript parser needed " + Time.getLapseTimeMessage(initial));

Que dejaría una traza como la siguiente:

Javascript parser needed 1 seconds (1542 millis)

Obviamente esta es una aproximación muy básica que puede ser mejorada y más parametrizada, pero para casos sencillos cumple su cometido.

Estraído literalmente de dicha oferta:

Buscamos programador Java con experiencia en J2EE para ampliar nuestro equipo IT, compuesto actualmente por 9 personas.

El candidato se incorporará a un subequipo de 3 personas dirigido por un arquitecto senior y trabajará en la ampliación funcional de una de nuestras aplicaciones propietarias, clave en la estrategia de la empresa.

Todo nuestro desarrollo (2 aplicaciones propietarias líderes en España y latinoamerica en el ámbito de la Investigación de Mercados) se basa en J2EE + MySQL.

Ofrecemos:

• remuneración en función de conocimientos técnicos y experiencia demostrable
• formación a cargo de la empresa

Aspectos destacados del trabajo en Netquest:

1. Muy buen clima laboral.
2. Nos esforzamos por desarrollar software de calidad.
3. Aspiramos a convertir nuestra tecnología, lider en España y latinoamérica, en una de las tres mejores del mundo en su ámbito.

En la aplicación que estoy construyendo queremos que unos componentes personalizados sirvan para mostrar información pero a su vez permitan editarla y queremos diferenciar claramente si el componente está en modo edición o no. En definitiva queremos tener etiquetas que bajo según qué circunstancias se puedan editar. Puesto que el JLabel no nos brinda esta opción, hemos tenido que trabajar un poco más y crear un componente personalizado.

El truco consistente en tener un componente, por ejemplo un JPanel, con un layout del tipo CardLayout con dos ‘cartas’ una de las cuales muestra una JLabel de toda la vida y otra un JTextField. El componente aporta la lógica para cambiar la carta en respuesta a ciertas interacciones del usuario. Si mantenemos el contenido de los dos componentes de forma coherente, tenemos la ilusión que la etiqueta se convierte en un campo de texto cuando entramos en modo edición y al revés al salir de este modo.

El siguiente código muestra una versión incipiente (pero funcional) de este ‘etiqueta editable’. Para entrar en modo edición hacemos doble click en la etiqueta y para salir del estado de edición pulsamos RETURN para confirmar los cambios o ESCAPE para cancelarlos.

Tomadlo como una prueba de concepto (que es lo que es) y no como una clase terminada con calidad industrial.

public class EditableLabel extends JPanel {
	/** The user is editing the component (JTextField is shown at the moment) */
	private boolean editing;

	/** The confirm edition key is Return */
	private static final int confirmKeyCode = KeyEvent.VK_ENTER;

	/** The cancel edition key is Return */
	private static final int cancelKeyCode = KeyEvent.VK_ESCAPE;

	/** The value which holds this component */
	private String value;

	// graphical components

	private CardLayout cl;
	private JPanel pnlCards;
	private static final String TEXT_FIELD = "text field";
	private JTextField textField;
	private static final String LABEL = "label";
	private JLabel label;

	public EditableLabel(String initialText) {
		this.value = initialText;

		cl = new CardLayout();
		pnlCards = new JPanel(cl);
		textField = new JTextField();
		label = new JLabel(initialText);
		pnlCards.add(textField, TEXT_FIELD);
		pnlCards.add(label, LABEL);
		cl.show(pnlCards, LABEL);
		add(pnlCards);

		// register the listeners
		label.addMouseListener(new MouseAdapter() {
			@Override
			public void mouseClicked(MouseEvent e) {
				// if double click, set edition mode
				if (e.getClickCount() == 2) {
					startEdition();
				}
			}
		});

		textField.addKeyListener(new KeyAdapter() {
			@Override
			public void keyReleased(KeyEvent e) {
				if (e.getKeyCode() == confirmKeyCode) {
					/* confirmation key pressed, so changing to non-edition
					 * and confirm changes */
					confirmEdition();
				} else if (e.getKeyCode() == cancelKeyCode) {
					/* cancel key pressed, so changing to non edition and
					 * cancel the changes */
					cancelEdition();
				}
			}
		});
	}

	private void startEdition() {
		cl.show(pnlCards, TEXT_FIELD);
		textField.setText(value);
		textField.requestFocus();
		textField.selectAll();
	}

	private void cancelEdition() {
		textField.setText(value);
		cl.show(pnlCards, LABEL);
	}

	private void confirmEdition() {
		value = textField.getText();
		label.setText(value);
		cl.show(pnlCards, LABEL);
	}

	/**
	 * @return the value
	 */
	public String getValue() {
		return value;
	}

	/**
	 * @param value the value to set
	 */
	public void setValue(String value) {
		this.value = value;
	}

	/**
	 * @return returns true if the component is currently showing the text
	 *  field or false otherwise.
	 */
	public boolean isEditing() {
		return editing;
	}
}

La aplicación en la que estoy trabajando es un cliente Swing con componentes personalizados para construir una vista similar a diagramas de flujo. Estos componentes heredan de JPanel son más o menos complejos y sobrescriben los métodos de pintado como paintComponent. A su vez tienen componentes anidados y áreas ‘blancas’ que forman parte del componente Swing pero que en realidad para el usuario no forman parte del mismo. El siguiente diagrama lo ilustra un poco:

Mostrar el tooltip únicamente cuando el ratón está en determinadas partes del componente

Como sabemos la clase JComponent define el método setToolTipText(String tooltip) que permite establecer la tooltip, el ‘problema’ es que esta se establece para todo el componente. En mi ejemplo, yo sólo quiero que se muestre si el usuario posa el ratón en el diamante, ya que para él el resto del componente forma parte del fondo. Si no hacemos nada más, al poner el ratón en cualquier parte del componente se mostrará el tooltip.

La solución consiste en sobrescribir el método getToolTipText(MouseEvent event) para que devuelva null cuando las coordenadas del ratón (en el espacio de coordenadas del componente) están fuera del área para la que queremos mostrar el tooltip. El siguiendo snipet de código muestra la sobrescritura del método en mi componente personalizado: si estamos dentro del área definida por el rombo (calculado en un método auxiliar) entonces se muestra el tooltip establecido previamente con setToolTipText sino, devolvemos un null y por tanto no se renderizará el tooltip.

/**
* If the mouse is outside the diamond, don't show the tooltip.
*/
@Override
public String getToolTipText(MouseEvent event) {
    if (isInDiamond(event.getX(), event.getY())) {
        return getToolTipText();
    } else {
        return null;
    }
}

Tooltip multilínea

Aunque parezca sorprendente, la implementación por defecto del tooltip no soporta directamente multilíneas, así pues, si le pasamos un String que contenga retornos de carro en el método setToolTipText, éstos serán ignorados vilmente y se pintarán todas las líneas seguidas. Para solucionar ésto hay dos soluciones: una pesada y elegante y otra inmediata pero algo fea.

Empecemos por la segunda. Muchos componentes Swing tienen soporte para HTML. El tooltip también. Si asignamos un String que empiece por <html> el componente asumirá que le estamos pasando código HTML y lo renderizará como tal. El truco consiste pues, en sustituir todos los caracteres ‘\n’ por el String <br/>. Por ejemplo:

String strMultiLinea = ...
setToolTipText("<html>" + strMultiLinea.replaceAll("\n", "<br/>") + "</html>");

Rápido y funciona, pero es feo. La solución elegante consiste en implementar nuestro propio tooltip que soporte esta característica. Esto debemos hacerlo en dos pasos:

1. Implementar nuestra clase tooltip personalizada heredando de javax.swing.JToolTip,
2. Diciéndole al componente que debe usar nuestra propia implementación sobrescribiendo el método createToolTip para que devuelva una instancia de nuestra clase.

Los métodos que lanzan excepciones del primer tipo ( cheched ) fuerzan al cliente de dicho métodos a tratarlas con un bloque try/catch o a lanzarlas para que sea un antecesor en la pilla de llamadas quien las trate. En última instancia la excepción alcanza el método principal main, que si no la gestiona la ‘lanza’ al sistema operativo y la aplicación muere con el volcado de pila del lugar donde se produjo.

Las excepciones not-checked no tienen esta restricción: ni es obligatorio capturarlas, ni el método cliente tiene que declarar explícitamente su lanzamiento mediante una cláusula throws en su signatura.

Las excepciones not-checked son todas aquellas que heredan de la clase RuntimeException . Así pues, si un método puede lanzar NullPointerException o IllegalArgumentException (entre otras), no está obligado a declararlo en su signatura ni el cliente a gestionar la excepción. De todos modos, si se produce, su propagación sigue la misma política: van escalando la pila de llamadas hasta que alguien las trate.

A la hora de programar una aplicación somos muy conscientes de las excepciones checked porque su no gestión es un error en tiempo de compilación, sin embargo para las excepciones not checked no tenemos más remedio que prever su posibilidad y hacer la gestión correspondiente donde corresponda. No obstante es posible que mientras estamos desarrollando o depurando no hayamos previsto una situación que desencadene el lanzamiento de una excepción de este tipo (típicamente se nos puede escapar alguna NullPointerException ). En estos casos (y siempre en general) es útil tener un bloque catch que capture el ‘resto’ de excepciones que el programador no previó e intentar hacer algo útil y más elegante que acabar la aplicación abruptamente (como por ejemplo guardar información en los logs que nos permita depurar o hacer un diagnóstico del problema).

¿Cómo y dónde ponemos este bloque “ captura el resto de excepciones”? En aplicaciones con un solo hilo de ejecución es muy fácil: en el main como ilustra el siguiente ejemplo.

public static void main(String[] args) {
try {
	// mi super-programa
} catch (Throwable e) {
	logger.debug("Unexpected exception!", e);
}

¿Pero qué pasa en una aplicación multi-hilo? En este caso el main creará varios hilos que tendrán su propia pila de llamadas por lo que cualquier excepción producida y no capturada en cualquiera de esos hilos no podrá ser capturada por el catch del ejemplo anterior.

En particular, las aplicaciones Swing son siempre multi-hilo. El código de programación de todos los listeners de gestión de eventos producidos por los diferentes elementos de la GUI, se ejecuta dentro del event dispatch thread (el hilo de gestión de eventos) también conocido como “AWT” Thread y que no es el mismo en el que se ejecuta el main del programa.

¿Qué pasa si se produce una excepción not-checked en este hilo? Pues que si no lo hemos previsto en el código y no hay ningún catch que la capture, se pierde irremediablemente. Afortunadamente existe una solución que expondré a continuación y que también está explicada en este post.

La API estándar de Java ofrece la clase ThreadGroup . Cuando creamos un thread podemos hacer que pertenezca a una instancia de esta clase. Dicha clase tiene un método con la siguiente signatura:

void uncaughtException(Thread t, Throwable e)

que es llamado por la máquina virtual de forma automática cuando cualquiera de los threads que forman parte de ese grupo lanza una excepción que nadie captura. Cuando un hilo se crea dentro de un grupo, todos los hilos que pueda crear ese hilo también pertenecen al mismo grupo.

Ahora ya tenemos todos los elementos que solucionan nuestro problema:

1. Creamos una subclase de ThreadGroup que sobrescriba el método uncaughtException para que haga algo útil en nuestro programa.
2. En el main construimos una instancia de la clase que acabamos de construir.
3. Creamos un thread que se encarga de montar toda la GUI que forma parte del grupo recién instanciado.

Con esto conseguimos que todos los threads interesantes de nuestro programa pertenezcan al grupo que es capaz de gestionar las excepciones no capturadas.

Nuestro ThreadGroup podría tener el siguiente aspecto:

class HandleExceptionGroup extends ThreadGroup {
	private static Logger logger = Logger.getLogger(ExceptionGroup.class);

	public HandleExceptionGroup() {
		super("ExceptionGroup");
	}

	@Override
	public void uncaughtException(Thread t, Throwable e) {
		String msg =
			"GUI produced an unexpected exception (thread: " + t.getName() + ") ";

		logger.warn(msg, e);
	}
}

y el main de la clase principal:

public static void main(String[] args) {
        HandleExceptionGroup threadGroup = new HandleExceptionGroup();
	new Thread(threadGroup, "Main Thread"){
		@Override
		public void run() {
			// aquí construyo la GUI
		}
	}.start();
}

Introducción

Cuando tenemos una aplicación desplegada en producción o cuando estamos realizando pruebas de carga o de estrés, una de las cosas que necesitamos hacer es monitorizar diferentes parámetros de la misma y del servidor de aplicaciones que la contiene. Estos parámetros pueden incluir, por ejemplo, la evolución de la memoria, el número de sesiones, etcétera.

En este artículo explicaré cómo configurar JBoss para que comunique diferentes métricas que sean leídas y analizadas por la herramienta Cacti.

SNMP y JMX

SNMP y JMX son las siglas de dos protocolos de monitorización de recursos. El primero es un protocolo genérico, y bien conocido por nuestros queridos compañeros de sistemas, y el segundo es el protocolo propio de la tecnología Java.

Puesto que SNMP es un protocolo más antiguo, que aplica a todo tipo de componentes hardware (como un router) o servicios software (por ejemplo, un servidor web) y que es bien conocido por los profesionales que tienen que administrar estas infraestructuras, tiene una gran cantidad de herramientas y gestores que permiten trabajar con él. Estas herramientas en general sólo capturan información para ser analizada, pero el protocolo también permite la modificación de ciertos parámetros. JMX es algo parecido pero aplicado a la máquina virtual y a los servicios Java.

Puesto que tanto las herramientas como los profesionales que tienen que administrar recursos están más acostumbrados a trabajar con SNMP que con JMX (que pueden llegar a ignorarlo por completo), una posible solución pasa por poder exportar la información proporcionada mediante JMX al protocolo SNMP. El presente artículo intenta explicar básicamente esto: cómo una fuente JMX (nuestro querido JBoss) puede integrarse con una herramienta de gestión SNMP (Cacti).

No entraré a explicar los detalles de los dos protocolos porque, entro otras cosas, ni soy un experto en los mismos ni es relevante para el objetivo de este tutorial. Si queréis más información sólo hay que seguir los enlaces que voy proporcionando. Aquello que vayamos necesitando lo iré explicando a lo largo del tutorial.

A modo de resumen ( y extraído de la wikipedia):

“Una red administrada a través de SNMP consiste de tres componentes claves:

• dispositivos administrados;

• agentes;

• sistemas administradores de red (NMS’s).

Un dispositivo administrado es un nodo de red que contiene un agente SNMP y reside en una red administrada. Estos recogen y almacenan información de administración, la cual es puesta a disposición de los NMS’s usando SNMP. Los dispositivos administrados, a veces llamados elementos de red, pueden ser routers, servidores de acceso, switches, bridges, hubs, computadores o impresoras.

Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Un agente posee un conocimiento local de información de administración (memoria libre, número de paquetes IP recibidos, rutas, etcétera), la cual es traducida a un formato compatible con SNMP y organizada en jerarquías.

Un NMS ejecuta aplicaciones que supervisan y controlan a los dispositivos administrados. Los NMS’s proporcionan el volumen de recursos de procesamiento y memoria requeridos para la administración de la red. Uno o más NMS’s deben existir en cualquier red administrada.”

Entorno y herramientas

Partiendo de la descripción anterior de infraestructura SNMP, nuestro dispositivo administrado será JBoss, nuestro agente una aplicación desplegada en JBoss que se llama “SNMP adaptor” y nuestro NMS será Cacti.

Los lectores de este blog sin duda conocen qué es JBoss, uno de los servidores de aplicaciones JEE open source más conocidos, sin embargo, es más posible que no estén tan familiarizados con el resto de herramientas ni en tareas de monitorización. Esto último suele pasar porque es muy habitual que este tipo de tareas las realicen perfiles técnicos más orientados a sistemas (lo cual me parece correcto); un desarrollador no debería preocuparse de mirar si los logs del Apache tienen cosas raras o de si una máquina debería ampliar su sistema de ficheros porque en los últimos meses se ha aumentado mucho su necesidad de espacio.

El problema suele ser que los perfiles de sistemas dan un trato ‘especial’ a los servidores Java. Esto se debe a que la administración de estos servicios es un poco diferente al resto de cosas a las que están acostumbrados (archivos de configuración XML vs. texto plano, máquina virtual vs. ejecución nativa, JMX vs. SNMP, etc.). Consecuencia de esta realidad, que yo me he encontrado en más de un sitio, los desarrolladores hemos tenido que aprender algunas cosas de sistemas.

En este artículo trabajaré con una versión virgen de Ubuntu 9.10 y explicaré paso a paso lo siguiente:

• cómo instalar JBoss,
• cómo instalar Cacti,
• configurar JBoss para exportar métricas mediante SNMP y
• configurar Cacti para monitorizar estas métricas.

Instalar JBoss

Aquí no dedicaremos mucho tiempo (entiendo que todo el mundo tiene esta fase superada). Primero instalamos el JDK de Sun con el gestor de paquetes:

apt-get install sun-java6-jdk

A continuación descargamos el JBoss AS de http://www.jboss.org/jbossas/downloads/ (en el momento de escribir este tutorial la última versión estable, y que yo voy a usar, es la 5.1.0-GA).

La instalación es sencilla y básicamente consiste en descomprimir el bundle, establecer los permisos adecuados y, opcionalmente, configurar el script de arranque en init.d . En mi caso instalo el servidor en /opt/jboss pero no es demasiado relevante. Me referiré al directorio raíz de JBoss como JBOSS_HOME.

Recordemos que para poner en marcha el servidor se hace mediante el script JBOSS_HOME/bin/run.sh y que si no le pasamos ningún parámetro por defecto arranca la configuración default .

Pongamoslo en marcha para ver si todo funciona correctamente. En el log debería aparecer una línea del tipo

15:50:56,747 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 1m:41s:932ms

y deberíamos poder acceder a la consola de administración del mismo en el puerto 8080 de la máquina:

Instalar Cacti

En un entorno productivo, si se está usando Cacti para monitorizar los sistemas (como es el caso en mi empresa), obviamente serán los chicos de sistemas los que lo tendrán montado y configurado. En nuestra prueba de concepto lo instalaremos en la misma máquina desde cero y con la inestimable ayuda de nuestro querido gestor de paquetes de Ubuntu.

apt-get install cacti

Cacti es una aplicación PHP que almacena la información que necesita en una base de datos MySQL por lo que tiene como dependencias importantes: el servidor MySQL, el Apache y, obviamente, el PHP. Si tenemos una instalación limpia, el gestor de paquetes nos pedirá datos de configuración de estos componentes (como por ejemplo el passwor de root del MySQL).

A continuación el script de instalación nos irá haciendo una serie de preguntas y como no queremos pelearnos con la configuración avanzada de Cacti, cogeremos el camino fácil:

• ¿Qué servidor web quieres?

  • Apache 2 .

• Configure database for cacti with dbconfig-common? (que traducido sería, ¿quieres que te configure yo automáticamente la base de datos o prefieres hacerlo tú a mano)

  • Sí .

• Dame la contraseña de root de MySQL parara que te pueda crear la base de datos.

• Dame la contraseña que quieres que utilice para el usuario de Cacti en la base de datos.

  • DATABASE_CACTI_PASSWORD (obviamente, aquí ponemos el que estimemos oportuno).

Aún no ha acabado la instalación pero el resto lo haremos directamente desde la aplicación web. Si todo ha ido bien, tendremos un Apache 2 corriendo con un flamante Cacti instalado en la ruta http://localhost/cacti que nos llevará al asistente de configuración:

El asistente es muy sencillo y básicamente no requiere explicación: la siguiente pantalla nos pregunta el tipo de instalación (nueva) y la última nos muestra las rutas a la diferentes herramientas que necesita preguntándonos confirmación (configuración que nos parecerá estupenda, por supuesto).

Si todo ha ido bien, al finalizar el asistente, seremos redirigidos a la pantalla de login de Cacti, sin embargo, en ningún punto anterior hemos sido preguntados por usuario o contraseña administrativa (las contraseñas que hemos introducido anteriormente se referían al usuario en la base de datos pero no a la aplicación propiamente dicha). Para entrar utilizaremos los valores por defecto que tanto para el usuario como para la contraseña son “ admin” y seremos redirigidos a otra pantalla que nos obliga a decidir una contraseña algo más segura. Nos referiremos a esta contraseña como ADMIN_CACTI_PASSWORD.

En este punto ya hemos acabado de configurar Cacti y por fin entramos en la página principal de la aplicación.

Cacti es una herramienta muy poderosa, pero no es el propósito de este artículo explicar todo lo que puede hacer, así que sólo explicaré unas nociones. La interfaz se divide en dos secciones principales representadas por las dos pestañas del margen superior izquierdo: la consola y los gráficos. La consola permite lleva a cabo todas las tareas de configuración (añadir dispositivos SNMP, crear nuevos informes, etc.). La sección gráficos muestra los informes. Efectivamente, Cacti presenta la información como gráficos a lo largo del tiempo (por ejemplo, uso de la memoria a lo largo de la última media hora).

Una única instancia de Cacti puede monitorizar toda la infraestructura de una red. Sólo hay que añadir los agentes en cada uno de los dispositivos y luego configurar Cacti para que los escuche. Los diferentes dispositivos se ven en el árbol de la izquierda. En la configuración básica que tenemos montada sólo estamos monitorizando algunos parámetros básicos de la máquina local.

El marco superior nos permite seleccionar el marco temporal de los gráficos que estamos visualizando. Por defecto Cacti nos muestra algunos parámetros locales interesantes, el uso de memoria, de CPU, etc. Nuestro objetivo es añadir nuevos gráficos como: tamaño del heap del JBoss o número de sesiones de la aplicación X.

Los gráficos, además, son elementos interactivos que permiten redefinir el periodo temporal que están mostrando a golpe de ratón (zoom-in y zoom-out) o exportar los datos en formato CSV para trabajar con ellos en cualquier herramienta que nos interese (como por ejemplo OpenOffice Calc o Microsoft Excel).

Configurar JBoss para exportar datos por SMMP

En este punto ya tenemos una configuración básica de JBoss y de Cacti. El siguiente paso es hacer que JBoss sea capaz de producir métricas en el protocolo SNMP. Por suerte, va a ser bastante sencillo.

La manera de hacerlo será convertir los datos que de forma nativa ya está generando en JMX a SNMP. Pero, ¿qué información está exportando por JMX? Muy sencillo, lo podemos ver directamente en la consola JMX de JBoss que está accesible en http://localhost:8080/jmx-console/

Para más información sobre la API JMX de JBoss, podéis ir al propio manual o echarle un ojo a este interesante tutorial que propone otras alternativas de monitorización con herramientas Java.

Ahora que sabemos qué podemos monitorizar, ¿cómo lo exportamos a SNMP? Fácil, desplegaremos una aplicación que viene con el propio JBoss: el SNMP Adaptor.

Esta aplicación viene desplegada únicamente en la configuración de servidor all , así que si estamos utilizando otra (como la default o una personalizada), tendremos que desplegarla donde corresponda. En mi caso, que estoy usando la configuración default, haría lo siguiente:

cp -fR JBOSS_HOME/server/all/deploy/snmp-adaptor.sar JBOSS_HOME/server/default/deploy

Desde este mismo momento ya estamos produciendo datos SNMP para algunos parámetros que vienen configurados por defecto, como por ejemplo, la cantidad de memoria libre. Para comprobar que está funcionando usaremos un cliente SNMP de línea de comandos:

snmpwalk -v 1 -c public localhost:1161 .1.2.3.4.1

a lo que JBoss debería responder con algo parecido a:

iso.2.3.4.1.1 = INTEGER: 60
iso.2.3.4.1.2 = Gauge32: 97540696
iso.2.3.4.1.3 = Gauge32: 530907136
iso.2.3.4.1.4 = INTEGER: 0
End of MIB

El snmpwalk es un cliente simple, que recibe los parámetros de dónde buscar el agente (en localhost en el puerto 1161) y qué información buscar, la identificada por .1.2.3.4.1. Los identificadores SNMP ( oid ‘s) son un acuerdo entre el agente y los clientes SNMP y tienen estructurar jerárquica. La respuesta que nos ha dado el servidor es el conjunto de todos los parámetros que está produciendo que ‘cuelgan’ del identificador.1.2.3.4.1.

Cada uno de estos parámetros y su mapeo con el identificador SNMP lo podemos encontrar en archivo de configuración del SNMP Adaptor que se encuentra en el fichero XML siguiente: JBOSS_HOME/server/all/deploy/snmp-adaptor.sar/attributes.xml. Básicamente sirve para configurar un parámetro JMX con un identificador SNMP. Por ejemplo, los cuatro parámetros que hemos visto en el ejemplo se corresponden con esta entrada:

<attribute-mappings>
  <!-- basic system information -->
  <mbean name="jboss.system:type=ServerInfo" oid-prefix=".1.2.3.4.1">
    <attribute name="ActiveThreadCount" oid=".1"/>
    <attribute name="FreeMemory" oid=".2"/>
    <attribute name="MaxMemory" oid=".3"/>
  </mbean>
../..
</attribute-mappings>

Como vemos por un lado estamos identificando el bean JMX y los atributos del mismo que producen la información y por otro el identificador SNMP que queremos vincularle. En la siguiente captura de pantalla del cliente, podemos ver parte de este bean:

Obviamente podemos modificar libremente el fichero para quitar o añadir los bean y atributos que queramos.

Exportar información de sesión para una aplicación web por SNMP

Un ejemplo de información interesante a monitorizar es la asociada a las sesiones de las aplicaciones desplegadas en el servidor. Estos parámetros no están configurados por defecto porque el bean JMX que los exporta depende del nombre del contexto de la aplicación desplegada.

Con la configuración por defecto de JBoss tenemos desplegadas una serie de aplicaciones web, una de ellas es la propia consola JMX. La usaremos como ejemplo. Así pues, para monitorizar una selección de parámetros relacionados con la sesión para la aplicación jmx-console añadiríamos el siguiente fragmento XML al archivo de configuración del SNMP Adaptor. En negrita he marcado el nombre del bean, que, como vemos, incluye el nombre del la aplicación (del contexto) cuyos parámetros queremos exportar. Los oid elegidos son arbitrarios.

<mbean name=" jboss.web:host=localhost,path=/jmx-console,type=Manager" oid-prefix=".1.2.3.4.5">
  <!-- Number of active sessions at this moment -->
  <attribute name="activeSessions" oid=".1"/>

  <!-- Average time an expired session had been alive -->
  <attribute name="sessionAverageAliveTime" oid=".2"/>

  <!-- longest time an expired session had been alive -->
  <attribute name="sessionMaxAliveTime" oid=".3"/>

  <!-- Total number of sessions created by this manager -->
  <attribute name="sessionCounter" oid=".4"/>

  <!-- Number of sessions that expired ( doesn't include explicit invalidations ) -->
  <attribute name="expiredSessions" oid=".5"/>

  <!-- Number of sessions we rejected due to maxActive beeing reached -->
  <attribute name="rejectedSessions" oid=".6"/>

  <!-- Maximum number of active sessions so far -->
  <attribute name="maxActive" oid=".7"/>

  <!-- Number of duplicated session ids generated -->
  <attribute name="duplicates" oid=".8"/>

  <!-- Time spent doing housekeeping and expiration -->
  <attribute name="processingTime" oid=".9"/>
</mbean>

Al igual que antes, hacemos una petición desde la línea de comandos para ver si todo ha ido bien:

snmpwalk -v 1 -c public localhost:1161 .1.2.3.4.5

para lo que deberíamos obtener una respuesta similar a lo siguiente:

iso.2.3.4.5.1 = INTEGER: 1
iso.2.3.4.5.2 = INTEGER: 92
iso.2.3.4.5.3 = INTEGER: 92
iso.2.3.4.5.4 = INTEGER: 2
iso.2.3.4.5.5 = INTEGER: 1
iso.2.3.4.5.6 = INTEGER: 0
iso.2.3.4.5.7 = INTEGER: 1
iso.2.3.4.5.8 = INTEGER: 0
iso.2.3.4.5.9 = Gauge32: 0
End of MIB

Configurar el Cacti para monitorizar el JBoss

Cacti es capaz de monitorizar cualquier fuente SNMP. Básicamente hay que añadir los diferentes hosts y dispositivos con la consola administrativa de la interfaz web y luego definir las las gráficas que se quieren graficar sobre los diferentes servicios SNMP que tengan cada uno de esos dispositivos.

La tarea anterior puede ser más o menos tediosa (que no complicada), afortunadamente el propio Cacti viene con una serie de gráficas que permiten configurar a golpe de ratón servicios típicos. Por ejemplo, la siguiente captura de pantalla muestra alguna de las posibilidades: Console → New Graphs → Create.

Además de los informes que vienen incluidos con esta distribución en Internet pueden encontrarse para cualquier tipo de dispositivo que se nos pueda ocurrir. La distribución de estos informes se hace mediante lo que Cacti denomina templates (plantillas). Estas plantillas son unos ficheros XML que llevan la configuración SNMP de los diferentes dispositivos y además la información para que Cacti pueda crear los gráficos prediseñados. Así pues, si tenemos un router de la marca Acme modelo Roadrunner, sólo tenemos que buscar un poco en la página de Cacti o googlear un poco porque seguro que alguien ha creado la plantilla.

Como podéis ver en la captura de pantalla anterior, la propia interfaz administrativa tiene dos enlaces que nos permiten importar y exportar plantillas respectivamente.

JBoss no iba a ser menos, así que existen al menos un par de plantillas proporcionadas por la comunidad. Una de ellas puede descargarse desde directamente desde desde este hilo en los foros de Cacti. El autor ha proporcionado una plantilla que grafica directamente los parámetros que vienen en la configuración por defecto del “SNMP Adaptor” de JBoss.

Para instalarla sólo tenemos que descargarla e importarla mediante la interfaz gráfica. Si todo va bien, Cacti nos muestra un informe con todas las entidades procesadas que ha podido importar de la plantilla tal y como se muestra en la siguiente captura.

No hace falta entrar en los detalles, pero básicamente se ha configurado un nuevo agente SNMP, diferentes parámetros producidos por el mismo y tres definiciones de gráficas construidas a partir de estos parámetros. Ahora sólo faltaría construir nuevas gráficas usando estas definiciones para poder monitorizar el JBoss. Para ello deberemos:

1. Construir un nuevo dispositivo administrado que se corresponda con el JBoss.
2. Configurar las gráficas asociadas.

Para construir un nuevo dispositivo administrado, hacemos click en “Devices” y en el frame superior del área central (que actúa como filtro de los dispositivos listados) hacemos click en “Add” que nos lleva una pantalla de configuración de dispositivo.

En la pantalla de configuración del dispositivo seleccionamos los siguientes parámetros:

• Configuración general

  • Description: un nombre significativo para identificar el servidor JBoss.
  • Hostname: el nombre de la máquina o su IP.
  • Host template : aquí es donde tenemos que seleccionar el “JBoss SNMP Adaptor” que acabamos de importar.
• La siguiente sección “ Availability / Reachibility options” se refiere al mecanismo que debe usar Cacti para determinar que el host sigue vivo. Cuando el mecanismo seleccionado le indica que el host no está ahí, el poller de Cacti (el subsistema que interroga al agente SNMP en el dispositivo) deja de recoger datos para ese dispositivo. Los parámetros por defecto basados en ping ya me parecen correctos para esta prueba de concepto, pero sentíos libres de adaptarlos a vuestro entorno.
• Configuración SNMP que debe coincidir con la configurada en el SNMP Adaptor
  • SNMP version : 1
  • SNMP community : public
  • SNMP Port : 1161 (¡ojo el puerto por defecto es 161!)
  • Y el resto de parámetros tal y como estén o prefiráis.

Los botones están ahí, pero no funcionan, es decir al hacer click sobre ellos la acción asociada no se ejecuta. Yo tengo el Eclipse instalado descargándolo directamente de su web y no de los paquetes de la distribución. Los compañeros que están usando el Eclipse de la distribución no han experimentado problemas.

Googleando un poco he encontrado rápidamente la solución en este post. Aparentemente es un bug de Eclipse en la biblioteca de gestión de ventanas GTK que será resuelto en próximas versiones. Por el momento tenemos un workaround para seguir trabajando con la versión actual arrancando Eclipse mediante el siguiente scrtipt:

#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/PATH_AL_ECLIPSE/eclipse

Personalmente soy usuario de log4j por varios motivos: estuvo disponible antes, es el logging nativo de mi servidor de aplicaciones habitual (JBoss) y me gusta más

Por otro lado, mi manera habitual de desarrollo es TDD, así que el IDE pasa una parte importante del tiempo ejecutando suites de tests JUnit.

Cualquiera de los frameworks de logging que utilicemos tiene el concepto de appender que es el destino en el que se escriben los mensajes. Destinos habituales suelen ser la consola o un fichero, por ejemplo. La configuración de los appenders de una aplicación se suele hacer durante el bootstrap (o la inicialización, si lo preferís) de la misma. Sin embargo cuando estamos corriendo tests, dicha inicialización no se produce así que perdemos todos los mensajes de logging que, si alguien se molestó en escribirlos, seguro que son muy útiles (especialmente cuando estamos desarrollando).

En “modo desarrollo” seguramente tenemos suficiente con una configuración básica en el que todos los mensajes se redirijan a la consola (que obviamente puede estar integrada en nuestro IDE). En el caso de log4j existe el método estático

org.apache.log4j.BasicConfigurator.configure()

que hace precisamente eso (creo recordar que java.util.logging tiene un mecanismo análogo). Ahora sólo resta saber dónde hacer la llamada al método. Obviamente no tiene sentido que lo pongamos en cada TestCase. Como en general agrupamos los diferentes tests en suites, parece que este es un buen lugar para configurarlo. Por ejemplo:

@RunWith(Suite.class)
@Suite.SuiteClasses(value={
    nq.quota.QuotaTest.class,
    nq.quota.FrequencyTest.class,
    })
public class AllTests {
    @BeforeClass
    public static void startup() {
        BasicConfigurator.configure();
    }
}

En el código precedente se ve la configuración de una test suite con JUnit 4 y etiquetamos un método de inicialización como @BeforeClass para asegurarnos que se ejecuta una única vez y antes de que la suite lance todos los tests configurados.

Esta misma idea puede utilizarse para configurar todos aquellos compartidos por los diferentes tests: variables de entorno, conexiones a bases de datos, etc.

Hace poco se lanzó la versió Ubuntu 9.04 (alias Jaunty Jackalope) e hice el upgrade hace unas semanas. Los upgrades de Ubuntu también dan gusto: todo se hace de manera automática, no pierdes el control sobre tus cofiguraciones propias (ficheros de configuración de servicios como MySQL, Samba, etc.) y todo funciona correctamente.

No obstante venía observando que a la que la máquina llevaba un rato encendida, se me disparaba el uso de una de las CPU, el ordenador no paraba de rascar disco duro y se recalentaba que daba gusto, de hecho hasta incluso llegar a colgarse en alguna ocasión. La verdad es que hace unos meses le metí mano al hardware del portátil y le metí un disco mucho mayor (como estaba metido en temas de formación necesitaba tener instaladas unas cuantas máquinas virtuales simultáneamente) y mucho más rápido y, que por tanto, se calentaba más y pensé que a lo mejor no había sido muy buena idea… Pero no tenía sentido, porque no había tenido ningún problema antes con el Ubuntu 8.10 y al arrancarlo ahora en modo Windows (sí, soy culpable, tengo una partición nativa Windows para casos de urgencia) tampoco había problema.

Tirando de top en un momento que se disparaba el uso vi que había un proceso comiéndose una CPU entera y accediendo sospechosamente al disco: tracker-indexer. Este proceso se corresponde con la utilidad tracker que es algo parecido al locate de toda la vida, un proceso que analiza el disco, e indexa su contenido para tener un acceso rápido en las búsquedas. Me sorprendió un poco porque creía haberlo desinstalarlo hace mucho tiempo (desde luego no aperecía como antes en la interfaz gnome) y además había instalado el Google Desktop que es un software análogo pero que personalmente me gusta más.

En cualquier caso, el tracker no debería comerse una CPU y llevar el portátil hasta la extenuación por calor del disco duro. Googleando un poco se ve que es un bug conocido en la nueva versión de Ubuntu. La verdad es que no me he molestado mucho en mirar si tiene solución, porque, como he dicho, es un software que no utilizo, así que simplemente he abierto el Synaptic, he buscado el paquete asociado y lo he desinstalado efectivamente y todo solucionado.

Por cierto, con una instalación “limpia” deJaunty Jackalope, el tracker no vien pre-instalado.

De todos modos para algunas herramientas muy concretas todavía no he podido librarme al 100% del Windows. Para no tener que estar reiniciando la máquina continuamente, tengo una máquina virtual con una imagen de XP que arranco cuando me hace falta usar alguna de estas herramientas. También utilizo máquinas virtuales para hacer pruebas varias y para poder poder provisionar rápidamente máquinas.

En su momento evalué varias máquinas virtuales, incluyendo VirtualBox (un proyecto open source muy interesante) y VMware. Finalmente, por facilidad de instalación y mantenimiento y por estabilidad en huéspedes Windows me decanté por la segunda.

Todo perfecto. El 95% del trabajo en Linux y cuando necesitaba sin remedio Windows, arrancaba la máquina virtual y listo.

El problema surgió tras una actualización de Ubuntu (aunque no sabría decir cuál concreta causó el problema): cuando arrancaba las máquinas virtuales, habían dejado de funcionar las teclas especiales, teclas tales como las flechas, el pad numérico, Inicio, Fin, etc.

Tras googlear un poco, ha resultado que la solución es bastante sencilla. Sólo hay que modificar el fichero de configuración del VMware, que en Ubuntu está en /etc/vmware/config para añadir la línea siguiente:

xkeymap.nokeycodeMap = "true"

Me ha funcionado tanto con huéspedes Windows como Ubuntu.

ACTUALIZACIÓN:

La solución anterior aparentemente funcionaba bien pero la tecla ALT GR seguía sin funcionar. Investigando un poco más he encontrado la siguiente solución que sí que ha funcionado para todas las teclas. Consiste en establecer un mapeo manual de todas las teclas. Así pues, en el mismo fichero de configuración, borramos la línea anterior y añadimos las siguientes:

xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu