Monitorizando el sistema con Collectd+InfluxDB+Grafana (Debian)

Ya hace tiempo que lo tengo montado y tenía pendiente escribir el artículo a modo de wiki. Ya habíamos visto anteriormente cómo utilizar Grafana como capa de presentación con Glances e InfluxDB. Donde antes utilizaba Glances para recolectar métricas ahora tengo Collectd, utilidad más madura y con más opciones de configuración.

Los distintos componentes por tanto son:

  • Collectd como recolector de métricas de sistema.
  • InfluxDB será la Base de Datos para almacenar dichas métricas.
  • Grafana como capa de presentación (dashboard) de las métricas que se vayan almacenando en InfluxDB.

Sigue leyendo

Dockerizando Wildfly

Tenía pendiente desde hace un tiempo escribir sobre dockers y contenedores en general. Le ha llegado el turno a Wildfly, versión comunitaria de Jboss. Vamos a ver cómo crear una imagen personalizada, echarla a correr y mantener persistencia de datos del contenedor guardando los logs de la instancia en nuestro host.

Descarga de la imagen del docker Wildfly

Este paso es opcional ya que al construir nuestra imagen basada en el fichero Dockerfile se descargará la imagen base si no la tenemos en nuestro repositorio. Voy a descargar en concreto la versión 12.0.0.Final de la imagen oficial, por lo que utilizo el tag correspondiente:

sudo docker pull jboss/wildfly:12.0.0.Final

Ejemplo:

jota@mid-dockers:~/dockerfiles/wildfly-example-war$ sudo docker pull jboss/wildfly:12.0.0.Final
[sudo] password for jota: 
Using default tag: latest
latest: Pulling from jboss/wildfly:12.0.0.Final
469cfcc7a4b3: Pull complete 
05677e4d61f0: Pull complete 
a9520f492457: Pull complete 
4d201219d6b1: Pull complete 
01710aba802b: Pull complete 
Digest: sha256:01c15a87ea50a9e515af9b419491bd0f45e37fdedbd7bde33485d701a74783d2
Status: Downloaded newer image for jboss/wildfly:12.0.0.Final

Sigue leyendo

Simplificando los despliegues en Jboss con Ansible

Existen diversas maneras de organizar los despliegues en Jboss como habíamos visto: fabric, interactuando con la API REST o con scripts personalizados que nos montemos al uso. Ansible dispone de un módulo para Jboss que podemos añadir a la lista de métodos.

Su uso es muy sencillo, aunque la limitación que tiene al menos de momento es que no permite desplegar en dominios, por lo que sólo nos servirá para instancias standalone.

En el entorno dispongo de:

  • Nodo central (mi máquina) desde donde voy a lanzar el despliegue. Tengo una relación de confianza con clave pública con el nodo remoto para poder conectar por SSH sin contraseña.
  • Nodo remoto con IP 192.168.1.154 donde está la instancia de Jboss EAP 7.1 en la que se realizará el despliegue. Esta instancia se ejecuta con el usuario jota y tiene el deployment-scanner habilitado (necesario para que funcione el despliegue con Ansible)

Sigue leyendo

Cómo excluir reglas de fase 1 en mod_security

Existen diversas casuísticas en la exclusión de reglas de mod_security. Un procedimiento habitual suele ser limitar el ámbito de exclusión a un determinado contexto en el que por diversas razones estamos obteniendo falsos positivos de una serie de reglas problemáticas, ejemplo:

<Location /aplicacion>
    SecRuleRemoveById 920320 942200 942330 942430 980130
</Location>

Suponemos que dicha directiva excluiría las reglas 920320, 942200, 942330, 942430 y 980130 para el contexto /aplicacion. Pues bien, si estas reglas saltan en la fase 1 de procesado de mod_security la exclusión que pretendemos no va a funcionar, ya que dicha información de request aún no habrá llegado a Apache y por tanto no podrá aplicar la directiva Location para el contexto mencionado… ¡mod_security habrá bloqueado antes la request!

Sigue leyendo

Supervisión del sistema con psacct/acct y audit

Las herramientas audit y psacct/acct son de gran utilidad para tener controlado qué ocurre en nuestro sistema: qué usuarios han entrado a la máquina, acciones realizadas, procesos lanzados, etc… Aunque por el nombre puedan parecer lo mismo no lo son:

  • Audit mediante un componente integrado como subsistema del Kernel Linux se encarga de capturar las llamadas a sistema de las aplicaciones para posteriormente mandar la información de dichas llamadas al demonio auditd. Éste se encarga de procesar dicha información y generar los logs de auditoría que podemos consultar con comandos como aureport, ausearch, aulast…
  • La segunda herramienta tiene un nombre distinto según la distribución: psacct (Process Accounting) en RHEL/derivadas y acct (Accounting) en Debian/derivadas. Con esta herramienta podemos ver fácilmente qué usuarios entran a la máquina, qué comandos lanzan, etc… pudiendo detectar acciones u operaciones que comprometan la integridad del sistema.

Sigue leyendo