Bloggers recientes

 

[ Blog ]
[ Wiki ]
[ Slideshare ]
[ Twitter ]
[ YouTube ]
Cesar Capillas Mensajes: 175
Estrellas: 8
Fecha: 18/05/15
Gustavo Fernandez Mensajes: 77
Estrellas: 7
Fecha: 16/05/15

Archivo

Tags

noBlogo - El blog de zylk.net

Entradas con etiqueta <em>jmx</em>.

La consola de admin de Alfresco EE y el modulo de Support Tools
La consola de administración de Alfresco Enterprise proporciona una administración gráfica del repositorio y de sus subsistemas principales. Está disponible desde la versión 4.2 (sólo para la versión Enterprise) y se divide en diferentes subpáginas:
  • Resumen del sistema (panel general con los servicios activos)
  • Información del repositorio y licencia.
  • Servicios de Email (Inbound y Outbound).
  • Servicios del repositorio (Actividades, BPM, Replicación, Búsqueda y Transformación)
  • Administración de directorio (Cadenas de autenticacion y sincronización LDAP).
  • Herramientas de soporte (JMX Dump)
  • Sistemas virtuales de ficheros (CIFS, FTP, Imap)
Es una alternativa gráfica (y en caliente) a los cambios de configuración en el alfresco-global.properties o a una consola JMX (como jmxterm o jconsole). Hay que tener en cuenta que los cambios realizados en la consola son a través de JMX, con lo que se materializan en la base de datos de Alfresco y se anteponen a los cambios de la configuración en el archivo alfresco-global.properties y demás configuración por defecto del repositorio. Cuando se usa la consola gráfica del repositorio o una JMX, uno de los principales peligros es que la configuración puede estar dispersa en dos lados, mezclada entre los properties y la base de datos (JMX), y no son facilmente visibles los cambios realizados por JMX.
 
La consola puede accederse a través de:
 
http://alfserver:8080/alfresco/service/enterprise/admin
 
 
 
Un complemento indispensable a esta consola es el módulo de herramientas de soporte de Antonio Soler:
Este módulo proporciona funcionalidades extra sobre la consola gráfica. Entre ellas:
  • Monitorizar las sesionas activas de los usuarios y el pool de conexiones.
  • Monitorizar el rendimiento del sistema, la carga y la memoria JVM.
  • Cambiar los loggers de Alfresco y visualizar los logs de Alfresco.
  • Visualizar y revertir los cambios JMX.
  • Ejecutar las tareas programadas en Alfresco.
  • Obtener información relevante sobre los hilos (threads) de Alfresco.
  • Ejecutar pruebas del subsistema de transformación.

Y de especial utilidad para la gestión de la configuración es la parte relativa a los settings JMX, que permite visualizar qué configuración se ha tocado via JMX y revertirla. Funciona además para cualquier configuración cambiada via otra consola JMX (no sólo la consola EE). Os dejo una captura de esto último:
 
 
 
Enlaces:
 
More about JMXTerm and Alfresco
One of the multiple possibilities for JMXTerm client is scripting for defined tasks in your Alfresco Enterprise Server (as pointed out in the previous post). Let's check it with some simple examples. Consider the next shell script called (run-jmx.sh) 
 
#!/bin/bash
java -jar jmxterm-1.0-alpha-4-uber.jar -l service:jmx:rmi:///jndi/rmi://localhost:50500/alfresco/jmxrmi -p change_asap -u controlRole -i $1
 
And then the following text file (show-users.jmx)
 
domain Alfresco
bean Alfresco:Name=RepoServerMgmt
get UserCountAll
run listUserNamesAll
close
 
The result is something like:
 
$ ./run-jmx.sh show-users.jmx
 
Welcome to JMX terminal. Type "help" for available commands.
#domain is set to Alfresco
#bean is set to Alfresco:Name=RepoServerMgmt
#mbean = Alfresco:Name=RepoServerMgmt:
UserCountAll = 3;
 
#calling operation listUserNamesAll of mbean Alfresco:Name=RepoServerMgmt
#operation returns: 
[ admin, zylk, alfresco ]
#disconnected
 
You can prepare then other useful jmx scripts such as (ldap-resync.jmx)
 
domain Alfresco
bean log4j:logger=org.alfresco.repo.security.sync
set priority DEBUG
bean Alfresco:Category=Synchronization,Type=Configuration,id1=default
run stop
run start
bean log4j:logger=org.alfresco.repo.security.sync
set priority INFO
close
 
Finally you also may use it for monitoring purposes, for example, for a nagios monitoring (in the same way that Alfresco Nagios Icinga plugin does it with check_jmx.jar).
 
Some references of this are:
JMX command line recipes for Alfresco revisited

I compiled here below some simple JMX recipes for Alfresco with the help of JMXTerm.

 
SETTING LOG4J LEVELS (FOR CIFS)

In many cases, we have to deal with problems in production environments (for example with CIFS). We can't reboot but we must take a look. For example, so:

zylk@scgd:~/jmxterm-1.0-alpha-4$ java -jar jmxterm-1.0-alpha-4-uber.jar

$>open service:jmx:rmi:///jndi/rmi://localhost:50500/alfresco/jmxrmi -p change_asap -u controlRole
$>domain Alfresco
$>bean log4j:logger=org.alfresco.smb.protocol
#bean is set to log4j:logger=org.alfresco.smb.protocol

$>info
#mbean = log4j:logger=org.alfresco.smb.protocol
#class name = org.apache.log4j.jmx.LoggerDynamicMBean
# attributes
  %0   - name (java.lang.String, r)
  %1   - priority (java.lang.String, rw)
# operations
  %0   - void addAppender(java.lang.String class name,java.lang.String appender name)
#there's no notifications

$>get priority
#mbean = log4j:logger=org.alfresco.smb.protocol:
priority = ERROR;

$>set priority DEBUG
#mbean = log4j:logger=org.alfresco.smb.protocol:
priority = DEBUG;


HINT: info provides the attributes to get and set, and operations to run

 
CHECK ALFRESCO GLOBAL PROPERTIES

We can not know all the properties of the repository (many of them in repository.properties file). We can get the "real" information and explore them with

$>bean Alfresco:Name=GlobalProperties    
#bean is set to Alfresco:Name=GlobalProperties
$>get authentication.chain          
#mbean = Alfresco:Name=GlobalProperties:
authentication.chain = external1:external,ldap1:ldap,alfrescoNtlm1:alfrescoNtlm;

HINT: Take advantage of the autocomplete option for beans and properties


CHECK SYSTEM PROPERTIES

Sometimes you may need to access to system properties too

$>bean Alfresco:Name=SystemProperties                                     
#bean is set to Alfresco:Name=SystemProperties
$>get file.encoding
#mbean = Alfresco:Name=SystemProperties:
file.encoding = UTF-8;
$>get user.language
#mbean = Alfresco:Name=SystemProperties:
user.language = es;


HINT: Other possibility for opening the connection is:

$>jvms
1435     (m) - org.apache.catalina.startup.Bootstrap start
3230     ( ) - jmxterm-1.0-alpha-4-uber.jar
$>open 1435 -u controlRole -p change_asap
#Connection to 1435 is opened

HINT: If you are connected to Alfresco server locally, you can type only open 1435

 
HOW TO KNOW WHO MANY PEOPLE IS CONNECTED TO THE REPOSITORY

Sometimes is useful:


$>bean Alfresco:Name=RepoServerMgmt
#bean is set to Alfresco:Name=RepoServerMgmt
$>get UserCountAll
#mbean = Alfresco:Name=RepoServerMgmt:
UserCountAll = 1;
$>run listUserNamesAll
#calling operation listUserNamesAll of mbean Alfresco:Name=RepoServerMgmt
#operation returns:
[ zylk ]

DISABLING FILESERVERS

For any reason, you may want to disable a subsystem temporally:

$>bean Alfresco:Category=fileServers,Type=Configuration,id1=default
#bean is set to Alfresco:Category=fileServers,Type=Configuration,id1=default
$>run stop

 
STOPPING AND RESTARTING SUBSYSTEMS (i.e: LDAP)

Or just maybe, disallow authentication LDAP user during a maintainance operation

$>bean Alfresco:Category=Authentication,Type=Configuration,id1=managed,id2=ldap1
$>run stop


and later, when all it's correct

$>run start

 
LDAP USER RESYNC

Other common task may be resync our LDAP:

$>bean log4j:logger=org.alfresco.repo.security.sync
$>set priority DEBUG
$>bean Alfresco:Category=Synchronization,Type=Configuration,id1=default
$>run stop
$>run start
$>bean log4j:logger=org.alfresco.repo.security.sync
$>set priority INFO


And for full LDAP resync:

$>bean Alfresco:Category=Synchronization,Type=Configuration,id1=default
$>set synchronization.synchronizeChangesOnly false
$>run stop
$>run start

 

SETTING ALFRESCO IN READ ONLY MODE

$>bean Alfresco:Name=RepoServerMgmt
#bean is set to Alfresco:Name=RepoServerMgmt
 
$>get ReadOnly
#mbean = Alfresco:Name=RepoServerMgmt:
ReadOnly = false;
 
$>bean Alfresco:Category=sysAdmin,Type=Configuration,id1=default
#bean is set to Alfresco:Category=sysAdmin,Type=Configuration,id1=default
 
$>set server.allowWrite false
#Value of attribute server.allowWrite is set to false
 
$>get server.allowWrite
#mbean = Alfresco:Category=sysAdmin,Type=Configuration,id1=default:
server.allowWrite = false;
 
$>bean Alfresco:Name=RepoServerMgmt
#bean is set to Alfresco:Name=RepoServerMgmt
 
$>get ReadOnly
#mbean = Alfresco:Name=RepoServerMgmt:
ReadOnly = true;
 

SETTING ALFRESCO IN READ ONLY MODE VIA JMX SCRIPT

From the command line, you can get or set values of the repository. For example, setting ReadOnly mode (maintenance mode - preparing a migration or a backup).

$ echo get -s -b Alfresco:Name=RepoServerMgmt ReadOnly | java -jar jmxterm-1.0-alpha-4-uber.jar -l service:jmx:rmi:///jndi/rmi://localhost:50500/alfresco/jmxrmi -p change_asap -u controlRole -v silent -n

$ echo set -b Alfresco:Category=sysAdmin,Type=Configuration,id1=default server.transaction.allow-writes false | java -jar jmxterm-1.0-alpha-4-uber.jar -l service:jmx:rmi:///jndi/rmi://localhost:50500/alfresco/jmxrmi -p change_asap -u controlRole -v silent -n



http://wiki.cyclopsgroup.org/jmxterm/embed

Monitorizando Liferay Portal con Nagios

Un aspecto fundamental en el mantenimiento y prevención de desastres en un sistema es la monitorización de los diferentes servicios que proporciona. Un herramienta muy popular es este campo dentro del mundo opensource es Nagios debido a la gran comunidad de usuarios y plugins existentes. Uno de ellos es check_jmx, que permite la monitorización de variables de un servidor de aplicaciones java, activando la consola jmx.

En primer lugar es necesario configurar el acceso via jmx en el servidor de aplicaciones a monitorizar, y reiniciarlo. Basicamente hay que localizar el punto del script de arranque de Jboss o Tomcat donde especificamos las opciones de java $JAVA_OPTS de modo:

JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote=true"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=9999"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.password.file=/opt/liferay/jmxremote.password"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.access.file=/opt/liferay/jmxremote.access"

También es necesario editar los archivos jmxremote.access:

admin readwrite
zylk readonly

y jmxremote.password:

admin secret1
zylk secret2

Podemos probar que el jmx está listo con jconsole, una vez reiniciado el servidor de aplicaciones:


Luego nos descargamos el plugin para Nagios, y configuramos los comandos y servicios correspondientes. Por cierto, es un script de shell que invoca a un jar, luego para ejecutarlo en el servidor de monitorización es necesario instalar java.

La configuración del comando (commands.cfg) en Nagios:

define command {
  command_name check_alfresco_HeapMemoryUsage_Used
  command_line    /usr/local/nagios/plugins/check_jmx -U service:jmx:rmi:///jndi/rmi://’$HOSTADDRESS$’:'$ARG1$’/jmxrmi -O java.lang:type=Memory -A HeapMemoryUsage -K used -username ‘$ARG2$’ -password ‘$ARG3$’ -w ‘$ARG4$’ -c ‘$ARG5$’
}

y la del servicio (services.cfg):

define service {
  host_name               baco
  service_description  heap memory used
  check_command     check_jmx_HeapMemoryUsage_Used!9999!zylk!secret1!750000000!800000000
  use                           generic-service
}

En el caso específico que nos ocupa, monitorizamos la memoria heap de un contenedor de servlets Tomcat con un gestor de portales Liferay, aunque podría ser cualquier aplicación java, como Alfresco ECM o Nuxeo. En el blog de Toni de la Fuente, hay un detallado artículo de monitorización de Alfresco a través de varios métodos, entre los que incluye Nagios.

Como complemento a este artículo en la parte que se refiere a Nagios, es posible graficar la evolución temporal de las variables java en PNP4Nagios mediante performance data. Para ello necesitamos modificar un poco el script el check_jmx, añadiéndole los datos de rendimiento, de modo que tendremos en Nagios gráficas diarias, semanales, mensuales tipo Cacti (rrdtool) en nuestro Nagios.

El cambio en la parte final del script es el siguiente:

DIR=`dirname $0`
JMX=`$JAVA_CMD -jar $DIR/check_jmx.jar "$@"`
JMXVAL=$?
VAL=`echo $JMX | awk '{print $5}'`
echo $JMX "|$6=$VAL;;;"
exit $JMXVAL

Y este sería el resultado para la memoria heap de java del servidor Liferay:

Y esto es todo.

Monitorizando Liferay Portal con Nagios II

Siguiendo con el artículo recientemente publicado por Cesar, vamos a dar los tips para monitorizar algun mbean específico de Liferay, en vez de monitorizar un atributo general de la maquina virtual. Para ello accedemos a jconsole y localizamos el mbean que queremos monitorizar,

En el caso que nos ocupa, hemos localizado el bean que tiene como atributo el número de páginas de publicadas en el wiki. Para ello nos hemos ayudado de la herramienta jconsole:

 

Una vez localizado el bean testamos el comando a ejecutar,  en este caso:

./check_jmx -U service:jmx:rmi:///jndi/rmi://192.168.94.115:9999/jmxrmi -O "JSPWiki:component=Core,name=Core bean" -A pages -K used -username zylk -password secret1 -w 1000 -c 2000

obtenemos el resultado del mismo
JMX OK -pages.used = 45 |pages=45;1000;2000;0

 

Ahora solo quedaría ajustar el máximo y el mínimo y añadirlo al nagios tal como se ha explicado en el anterior artículo. Con esto podremos monitorizar:

  • Número de usuarios
  • Páginas cacheadas
  • % de error en la búsqueda de paginas cacheadas
  • .....

 

Mostrando el intervalo 1 - 5 de 7 resultados.
Resultados por página 5
de 2