martes, 26 de septiembre de 2017

Notas sobre journal / journalctl

Algunas notas que me resultan útiles casi a diario, sobre el uso de journalctl…

Por defecto es volátil y por lo tanto no persiste tras un reboot.

Tenemos en

/run/log/journal/$ID/system.journal

Los logs de cada arranque disponible, donde $ID es un id que asigna systemd al log.

/run/log/journal/d0c4a268300a404b9cbc7a39f31a47bd/system.journal

Consultar logs disponibles.

journalctl --list-boots 
 0 bf51a6d4b1a749dfb22eb955a2764e84 lun 2017-09-25 20:49:23 CEST

Podremos ver salidas del tipo:

-3 XXXXX3 fecha ….

-2 XXXXX2 fecha ….

-1 XXXXX1 fecha ….

0 XXXXX0 fecha ….

Consultar logs de un boot determinado.

journalctl -b -3
journalctl _BOOT_ID=-3

Consultar logs del kernel.

journalctl -k

Consultar últimas entradas.

journalctl -b -k -n 10 #(Ultimas 10 entradas de logs de kernel y boot)

Logs de un proceso.

journalctl /bin/xxxx #(Full path)
journalctl _PID=XXXX

Logs de un usuario.

journalctl _UID=XXXX

Logs de un servicio.

journalctl -u httpd.service
journalctl _SYSTEMD_UNIT=httpd.service

Logs de varios servicios.

journalctl _SYSTEMD_UNIT=XX.service + _SYSTEMD_UNIT=YY.service

Establecer rangos de fecha.

--since=09:30
--until=16:25
--since='30 min ago'
--until='2 days ago'

Logs por criticidades.

journalctl -p 2
journalctl -p err

0 emergency / 1 alert / 2 crit / 3 err / 4 warn / 5 notice / 6 info / 7 debug

Logs por disco.

journalctl /dev/sda
journalctl /dev/sda1

Check espacio usado de journal.

journalctl --disk-usage
Archived and active journals take up 8.0M on disk.

Permitir journal a usuarios.

El grupo ‘adm‘ tiene acceso a journal.

usermod -a -G adm USUARIO

Configurar persistencia de logs.

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
chown root:systemd-journal /var/log/journal
chmod 2775 /var/log/journal
systemctl restart systemd-journal

Configuración general.

En el fichero:

/etc/systemd/journald.conf

Storage=

volatile –> Es volatil en /run/systemd/journal/

Persistent –> Es persistente en /var/log/journal/

Auto –> Por defecto persistente, pero si no esta el path NO lo crea y pasa a volatil.

Nohe –> Logs a consola

Compress= –> Por defecto true

Seal= –> Se crean claves para asegurar la integridad de los logs.

SystemMaxUse= 50M #(Por defecto 10% de filesystem, tamaño al que rota)

Rotado manual.

journalctl --vacuum-size=2G #(Limpiar y retener 2G)
journalctl --vacuum-time=2years #(Limpiar y retener 2 años)

lunes, 25 de septiembre de 2017

Consideraciones sobre tuning para Graylog y ElasticSearch

Algunas consideraciones sobre rendimiento para Graylog y ElasticSearch, que he ido afinando ha base de leer, probar y volver a ajustar….

NOTA:

Todas las consideraciones están basadas en pruebas de carga, con estos criterios:

1.- Inserciones de un fichero de unas 3.000.000 lineas distintas de logs.

2.- Múltiples repeticiones para intentar eliminar desviaciones en las muestras.

2.- Usando como agente graylog_sidecar.

Consideraciones sobre HW…

Graylog.

CPU (8vCPU)

Testado con 4, 6, 8, 12 y 16 vCPU’s, reajustando valores de configuración que dependen de los cores, explicados más adelante.

Hasta los 8 cores el crecimiento es lineal y la sensación de uso mejora considerablemente. Llegados a este punto ya no se percibe mejora.

RAM (8Gb)

Testado con 4, 6, 8 y 16 Gb de RAM, siempre destinando el 50% a la JVM.

El funcionamiento ha ido mejorando, sobre todo en la sensación de uso, hasta llegar a 8Gb con 4Gb para graylog. Al subir a 16Gb, la mejora deja de ser significativa, usando dashboards y lanzando queries mientras se insertan datos.

HD (N.A)

No he podido detectar repercusión mencionable. He realizado pruebas pasando el journal que que usa como buffer, a memoria e incluso deshabilitándolo.

message_journal_enabled = true --> false
message_journal_dir = /var/lib/graylog-server/journal

Conclusión:

Con estas pruebas «8vCPU / 8Gb Ram» parece razonable, llegados a este punto y con las pruebas realizadas, si se necesita más rendimiento, lo más recomendable parece un crecimiento horizontal, usando algún tipo de balanceo.

ElasticSearch.

CPU (8vCPU)

Testado con 4, 6, 8, 12… Pasar de 4 a 8 vCPU ha supuesto un incremento de más del 20%. en inserciones. Seguir subiendo no parece lo mejor ya que desde los 8vCPU, se deja de notar mejoría y el uso del CPU del equipo, esta lejos de ser alto.

RAM

16Gb ha sido el único valor testado. En la documentación que he podido consultar por parte del fabricante, generalizan nodos con cerca de 64Gb Ram. Así que invertir aquí puede ser buena idea.

HD

Toda la documentación del fabricante indica que se recomiendan discos lo más rápidos posibles, y creo que es evidente el motivo, pero la verdad, es que he podido probar discos SATA, SAS 7200, SAS 10000 y SSD y no he sido capaz de cargar los discos, como para notar diferencias y detectar algún cuello de botella. Supongo que en entornos productivos con inserciones más grandes y queries exigentes, si debe existir impacto.

Conclusión:

Con las pruebas realizadas la máquina más optima, «Recursos/Rendimiento», parece «8vCPU / 16Gb Ram».

Según la documentación del fabricante, no parece que el crecimiento vertical (más recursos) sea el camino a seguir. Todo indica, que es preferible múltiples máquinas de pocos recursos que menos máquinas de más recursos.

También es cierto que en entornos productivos, como he dicho antes, elasticsearch hace recomendaciones con muchísimo más HW y los considera máquinas pequeñas … (16vCPU/64Gb RAM) por ejemplo.

Consideraciones sobre Software…

Graylog.

He probado diferentes parámetros e intentado ajustarlos en función del HW disponible. Los que han tenido repercusión sobre el rendimiento han sido los siguientes…

output_batch_size = 500 --> 5000
output_flush_interval = 1

Estos parámetros indican que los datos son enviados a ElasticSearch cada 5000 mensajes o cada segundo, lo que antes suceda. Para inserciones altas, 500 es un número demasiado bajo, lo que hace que intentemos insertar demasiadas veces, bajando así el rendimiento.

processbuffer_processors = 5 --> 8 --> 10 --> 20 --> 8
outputbuffer_processors = 3 --> 8 --> 10 --> 20 --> 8
inputbuffer_processors = 2 --> 6 --> 8 --> 10 --> 20 --> 8

He podido probar con la lista de valores indicada, sin detectar cambios una vez superado el umbral del número de cores disponibles en la máquina que corre graylog. Así que … No se recomienda pasar del número de cores disponibles.

ElasticSearch.

index.refresh_interval: 30s

curl -XPUT 'X.X.X.X:9200/graylog2_001/_settings' -d '{
    "index" : {
        "refresh_interval" : "30s"
    }
}'

Con este curl, podemos realizar el cambio de valor en caliente.

Este es el valor que más repercusión ha tenido en el rendimiento con mucha diferencia. En las guías de Graylog, se indica que es necesario y que tiene mucha repercusión en el rendimiento, y así es… Cambio obligado si se usa graylog

Notas:

Aquí simplemente unas observaciones que tienen repercusión sobre el rendimiento pero que dependen tanto de cada caso particular que no es posible dar números…

Más nodos de elasticsearch (con al menos un número de shards igual al número de nodos ), mejoran el rendimiento en queries.
Menos nodos (Por lo tanto menos menos shards, pero más grandes, mejoran la inserción).

miércoles, 13 de septiembre de 2017

Snapshots sobre ElasticSearch

ElasticSearch provee un mecanismos de snapshots, que podemos gestionar vía su api. No se trata de snapshots vivos al uso, sino más bien de dumps incrementales, ya que tendremos la información completa (todos los indices), más los diferenciales para cada snapshot. Cuando un dato no es usado por ningún snapshot, el indice respaldado se vacía pero no se elimina el directorio del repositorio de snapshots.

0.- Montar los paths

Elasticsearch, necesita que se le defina un path a nivel de filesystem, sobre el cual creará el repositorio para los snapshots y almacenará los datos. Todos los hosts de elasticsearrch de nuestro cluster, deben tener (rw) sobre el path.

ej.

mount -t nfs 10.X.X.X:/backupsElastic /mnt/snapshots/

vi /etc/fstab
...
10.X.X.X:/backupsElastic /mnt/snapshots nfs defaults 0 0

1.- Definición de paths

Tras tener el path disponible en los hosts, necesitamos que elasticsearch haga uso de ellos. Para esto se le define la variable «path.repo»

vi /etc/elasticsearch/elasticsearch.yml
path.repo: /mnt/snapshots/elastic

2.- Registrar paths.

Este proceso intenta acceder al path definido para escribir y eliminar unos ficheros temporales.

(Verificación del registro en el punto 6 )

Si alguno de los nodos no puede realizar la acción correctamente, indicará un error con el nodo implicado.

Preparado en el script:

#!/bin/bash
curl -XPUT 'http://X.X.X.X:9200/_snapshot/backups' -d '{
    "type": "fs",
        "settings": {
        "location": "/mnt/snapshots/elastic/"
        }
}'

3.- Creación y eliminación de snapshots.

Para la creacion / eliminación de snapshots se realizan invocaciones a la api.

curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false

curl -XDELETE http://X.X.X.X:9200/_snapshot/backups/$NAME

Ej.

Script sencillo para la creación de snapshot diarios, con retención semanal.

#!/bin/bash

DAY=`date +%u`
NAME="backup_$DAY"

if [ `ls -als /mnt/snapshots/elastic/|grep $NAME|wc -l` -gt 0 ]; then
 curl -XDELETE http://X.X.X.X:9200/_snapshot/backups/$NAME
 curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false
else
 curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false
fi

4.- Verificación de snapshots.

La verificación de los snapshots podemos realizarla con la siguiente invocación:

curl -XGET http://X.X.X.X:9200/_snapshot/backups/$NAME?pretty

Obteniendo el valor de «state» para crear nuestros script de monitorización.

5.- Restauración de snapshots.

La restauración la podemos realizar a nivel de indices, recuperando un indice en concreto de uno de nuestros snapshots o a niveld e snapshot, recuperando el snapshot full con todos los indices que lo componen.

Ambas acciones se realizan con invocaciones a la api:

Recuperación de indice concreto.

Esto restaura un indice concreto (index_1 y index_2) de un snapshot concreto ($NAME), este indice debe existir en ese snapshot, cambiando el nombre del indice restaurado. Para restaurar sin modificar nombres… en caso de desastre completo, se deben quitar las dos clausulas «rename«

curl -XPOST http://X.X.X.X:9200/_snapshot/backups/$NAME/_restore" -d '{
    "indices": "index_1,index_2",
    "ignore_unavailable": true,
    "include_global_state": false,
    "rename_pattern": "index_(.+)",
    "rename_replacement": "restored_index_$1"
}'

Recuperación de snapshot full.

Esto restaura todos los indices de un snapshot concreto.

curl -XPOST http://X.X.X.X:9200/_snapshot/backups/$NAME/_restore"

6.- Invocaciones útiles.

Obtener información del repositorio.

curl -XGET http://X.X.X.X:9200/_snapshot/$repositorio

Verificación del registro.

curl -XGET http://X.X.X.X:9200/_snapshot/$repositorio/_verify

Obtener información del snapshot.

curl -XGET http://X.X.X.X:9200/_snapshot/snapshots/$snapshot

Obtener información de todos los snapshots.

curl -XGET http://X.X.X.X:9200/_snapshot/snapshots/_all

Con esto es posible tener un mecanismo de backup bastante completo.