developerlover.com

Monitorización de logs con el stack ELK (Elasticsearch, Logstash y Kibana)

Hoy en día, nuestros proyectos pueden estar formados por múltiples herramientas (Apache, MySQL, Nginx, Sphinx, Symfony…), y lo más probable es que cada una de ellas genere una cantidad de logs considerable.

La gestión de todos los estos logs puede convertirse en una tarea complicada, confusa y aburrida, si no disponemos de alguna solución.

Y aquí entra en juego el stack ELK (Elasticsearch, Logstash y Kibana), y en esta entrada, que sólo pretende ser a modo introductorio, vamos a ver cómo funciona a través de un sencillo ejemplo.

Pero antes de nada veamos unos conceptos básicos.

¿Qué es el stack ELK?

El stack ELK es un paquete de tres herramientas open source de la empresa Elastic. Las herramientas son Elasticsearch, Logstash y Kibana.

Estas tres herramientas son proyectos independientes y pueden ser usadas por separado, pero juntas forman un gran equipo.

Entre ellas se van a encargar de leer y almacenar toda la información que necesitemos para posteriormente consultarla y monitorizarla.

¿Qué es Elasticsearch?

Elasticsearch es un servidor de búsqueda basado en Lucene. Provee un motor de búsqueda de texto completo (full-text), a través de una interfaz web RESTful.

Básicamente nos ofrece un servicio de búsquedas (al igual que vimos con Sphinx en la entrada Buscador con Sphinx y Mysql) a través de una API RESTful.

Mediante peticiones HTTP podemos almacenar información de forma estructurada en Elasticsearch para que éste la indexe, y posteriormente poder realizar búsquedas sobre ella.

¿Qué es Logstash?

Logstash es una herramienta para la administración de logs. Todo tipo de logs. Logs de sistema, de servidor, de errores, de aplicación… Básicamente es capaz de leer todo lo que le eches.

Se encarga de recolectar, parsear y filtrar los logs para posteriormente darles alguna salida como, almacenarlos en MongoDB, enviarlos por correo electrónico o, como vamos a ver más adelante, guardarlos en Elasticsearch.

Estos logs le pueden llegar a Losgstash desde el mismo servidor o desde un servidor externo, por lo que podríamos tener un servidor exclusivo para el stack ELK.

La aplicación se encuentra basada en jRuby y requiere de Java Virtual Machine para correr.

¿Qué es Kibana?

Kibana es una herramienta analítica open source (licencia Apache) que nos va a permitir interactuar con la información almacenada (por Logstash) en Elasticsearch y monitorizarla.

¿Cómo funciona el stack ELK?

Como ya algunos habréis deducido, el flujo de información/funcionamiento del stack es el siguiente:

  1. Logstash: Es realmente el protagonista de todo esto. Él se va a encargar de la recolección de logs, parsearlos y almacenarlos en Elasticsearch.
  2. Elasticsearch: Encargado de almacenar de forma estructurada e indexada toda la información enviada por Logstash.
  3. Kibana: Que leerá los datos almacenados por Logstash en Elasticsearch para posteriormente monitorizarlos.

Explicado en una imagen (que tomo prestada del blog de Raúl Cumplido):

ELK stack flow

Instalación del stack ELK en Ubuntu

En este punto, y para no extendernos demasiado, simplemente voy a escribir los comandos necesarios para realizar la instalación de las tres herramientas en Ubuntu.

Requerimientos

  • Actualizar los repositorios de Ubuntu:
    $ sudo apt-get update
  • Instalar OpenJDK:
    $ sudo apt-get install openjdk-7-jre

Instalación de Elasticsearch

  • Descarga de Elasticsearch:
    $ wget https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.5.2.deb -O elasticsearch.deb
  • Instalación de Elasticsearch:
    $ sudo dpkg -i elasticsearch.deb
  • Configuramos el servicio de Elasticsearch para que se inicie al arranque del sistema:
    $ sudo update-rc.d elasticsearch defaults 80 8
  • Iniciamos el servicio de Elasticsearch:
    $ sudo service elasticsearch start

Instalación de Logstash

  • Descarga de Logstash:
    $ wget https://download.elastic.co/logstash/logstash/packages/debian/logstash_1.5.1-1_all.deb -O logstash.deb
  • Instalación de Logstash:
    $ sudo dpkg -i logstash.deb
  • Para que Logstash pueda leer cualquier fichero debe tener permisos de root. Para conseguir esto vamos a editar el fichero /etc/default/logstash y cambiar la línea dónde pone #LS_USER=logstash por:

    LS_USER=root
  • Configuramos el servicio de Logstash para que se inicie al arranque del sistema:
    $ sudo update-rc.d logstash defaults 90 7
  • Iniciamos el servicio de Logstash:
    $ sudo service logstash start

Instalación de Kibana

  • Descarga de Kibana:
    $ wget https://download.elastic.co/kibana/kibana/kibana-4.0.2-linux-x64.tar.gz -O kibana.tar.gz
  • Descomprimir fichero descargado:
    $ tar -xvzf kibana.tar.gz
  • Movemos el directorio descomprimido a una localización más apropiada:
    $ sudo mv kibana-4.0.2-linux-x64 /opt/kibana
  • Descargamos el init script en el directorio /etc/init.d:
    $ cd /etc/init.d
    $ sudo wget https://gist.githubusercontent.com/thisismitch/8b15ac909aed214ad04a/raw/bce61d85643c2dcdfbc2728c55a41dab444dca20/kibana4
  • Damos permisos de ejecución al script descargado:
    $ sudo chmod +x /etc/init.d/kibana4
  • Configuramos el servicio de Kibana para que se inicie al arranque del sistema:
    $ sudo update-rc.d kibana4 defaults 96 6
  • Iniciamos el servicio de Kibana:
    $ sudo service kibana4 start

¿Y ahora qué?

Bien, ahora que tenemos todo instalado, y para comprender cómo funciona el stack ELK, vamos a realizar un sencillo ejemplo.

Siguiendo con el flujo que hemos comentado anteriormente, vamos a configurarlo de manera que:

  • Logstash lea del log de Apache access.log las peticiones al servidor y guarde la información en Elasticsearch.
  • Y posteriormente que Kibana lea ésta información y la monitorice.

Por lo tanto, vamos a realizar las siguientes acciones:

  1. Configurar Logstash para que lea del fichero access.log y cada vez que detecte cambios en él, leerlos, parsearlos y guardarlos en Elasticsearch.
  2. En Elasticsearch no vamos a configurar nada, vamos a utilizarlo de almacén de datos con las opciones por defecto.
  3. En Kibana vamos a configurarnos un Dashboard con un gráfico en el que veamos los accesos a nuestro site por minuto.

Y para los que no tienen Apache instalado (y quieran seguir con el ejemplo de éste post):
$ sudo apt-get install apache2

Si no queréis instalar Apache, también podéis crear el fichero access.log a mano en la ruta /var/log/apache2/access.log. Más adelante veremos como insertar líneas desde la línea de comandos.

Configuración de Logstash

Como hemos dicho más arriba, Logstash se va a encargar de recolectar, parsear y filtrar los logs. Por lo tanto, el fichero de configuración va a estar formado por tres bloques o fases (inputs → filters → outputs):

  • input: Entrada de logs. Estos logs pueden llegar desde múltiples fuentes, ya sean, ficheros, syslog, varnish o incluso otros servidores. En nuestro caso (en Ubuntu), va a ser el fichero /var/log/apache2/access.log.
  • filter: Filtro de logs. Aquí vamos a leer las líneas que nos llegan a través del bloque input, y podremos parsearlas, borrarlas, añadirles información, etc.
  • output: Donde se decide qué hacer con los datos leídos y parseados (por el bloque filter). Aquí podremos guardarlos en un fichero, mandarlos por email o, como vamos a hacer, almacenarlos en Elasticsearch.

Dicho esto, vamos a crear el fichero de configuración.

En mi caso, Ubuntu, lo voy a crear en /etc/logstash/conf.d/logstash.conf (por defecto, Logstash lee todos los ficheros que se encuentran en el directorio /etc/logstash/conf.d/*), con el siguiente contenido:

input {
    file {
        path => "/var/log/apache2/access.log"
        start_position => beginning
    }
}

filter {
    grok {
        match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
    date {
        match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
    }
}

output {
    elasticsearch { host => localhost }
}

Y reiniciamos el servicio de Logstash:
$ sudo service logstash restart

Como podéis ver, cada bloque está formado por otros “sub-bloques” o plugins. Estos plugins son propios de cada bloque, es decir, el plugin file es un tipo de entrada de datos (ficheros), por lo tanto pertenece al bloque input.

Los plugins son necesarios, por no decir obligatorios, para añadir acciones a cada bloque. Los necesitamos para indicar qué ficheros queremos leer, como queremos filtrarlos o a dónde queremos enviarlos.

A su vez, cada plugin tiene atributos, también obligatorios para indicar al plugin como realizar cada acción. Con ellos podremos indicar la ruta completa al fichero que queremos leer, añadir un campo con un valor determinado o a qué email enviar la información, etc.

Vamos a explicar más en detalle cada bloque:

input

Aquí le estamos indicando mediante el plugin file que queremos leer de un fichero (con el atributo path), en este caso /var/log/apache2/access.log, y que queremos que lea ese fichero desde el inicio (con el atributo start_position), es decir, que también tenga en cuenta las líneas previas a la fecha en la que entra en funcionamiento Logstash.

Otros plugins de tipo input muy usados son:

  • syslog: Escucha en el conocido puerto 514 para los mensajes de registro del sistema y los analiza de acuerdo con el formato RFC3164.
  • redis: Para leer de un servidor Redis.
  • lumberjack: Recibe datos utilizando el protocolo lumberjack. Este plugin es el usado para recibir datos de otros servidores.

Más información de los plugins de tipo input.

filter

Aquí estamos utilizando dos plugins.

  • grok: Es un plugin utilizado para parsear las líneas que nos llegan. Su forma de trabajar es buscar patrones (a través del atributo match) en cada línea y separarlas en campos.
    Por ejemplo, en nuestro caso le estamos indicando que busque en el campo message (que es un campo creado por Logstash y donde nos llega cada línea de cada log) el patrón %{COMBINEDAPACHELOG} (que es el patrón creado para buscar líneas de Apache), y las está dividiendo en campos como el agent de la petición, la IP, el host, etc.
    Esto nos será de gran ayuda más adelante en Kibana.
  • date: Con este plugin estamos buscando una fecha en cada línea leída, para ser usada por Logstash como timestamp del log.
    Y al igual que en el plugin anterior, mediante el atributo match, le estamos diciendo que busque fechas con formato timestamp o dd/MMM/yyyy:HH:mm:ss Z (que es el formato de fecha del log de Apache).
    Si el plugin no encuentra ninguna fecha, creará el timestamp con la fecha de lectura de dicha línea.
    Éste campo timestamp también nos vendrá muy bien en Kibana para mostrar los datos ordenados y organizados con fechas reales.

Más información de los plugins de tipo filter.

output

Poco que explicar en este bloque. Simplemente le estamos diciendo mediante el plugin elasticsearch que todos los datos leídos y parseados anteriormente los almacene en Elasticsearch.

Mediante el atributo host le decimos dónde se encuentra el host de Elasticsearch. Recordemos que funcionaba mediante una API RESTful.

Más información de los plugins de tipo output.

¿Qué hemos conseguido hasta ahora?

En este punto ya tenemos prácticamente el stack ELK funcionando. Hemos conseguido:

  • Leer cada nueva línea insertada en el log de Apache access.log
  • Dividir cada línea leída en campos para poder identificarlos y filtrar desde Kibana.
  • Agregar un campo timestamp a cada línea para poder mostrar de forma ordenada cada registro en Kibana.
  • Almacenar la información ya estructurada en Elasticsearch para que pueda ser consultada desde Kibana.

¿Qué nos queda?

Pues ya hemos hecho lo más difícil, sólo nos queda consultar y monitorizar la información desde Kibana.

Monitorización desde Kibana

Para entrar a Kibana, basta con acceder desde el navegador a la IP del servidor en el que hemos instalado el stack ELK a través del puerto 5601, que es el puerto por defecto de Kibana.

En mi caso, que lo he instalado en una máquina virtual, accedo con la URL http://10.0.0.101:5601/. Si lo has instalado en local prueba con http://localhost:5601/.

Una vez dentro nos encontraremos con la siguiente pantalla:

Kibana-configurar-índice

Aquí tenemos dos campos para rellenar:

  • Index name or pattern: Es el nombre del índice o patrón de Elasticsearch en el que se guardan los datos desde Logstash. Esto se define con el plugin de tipo output elasticsearch.
    Como no hemos cambiado nada, por defecto, el nombre de los índices de Elasticsearch tendrá el formato logstash-%{+YYYY.MM.dd}. Por lo tanto, vamos a dejar el campo como está: logstash-*.
  • Time-field name: Aquí tenemos que indicar el campo que hemos creado antes (@timestamp) con el plugin (de tipo filter) date, y Kibana lo usará para mostrarnos toda la información organizada y ordenada por fecha.

Con los dos campos rellenos, pulsamos en Create y nos lleva a la siguiente pantalla:

Kibana-listado-de-campos

Aquí tenemos el listado de campos que se han encontrado en el índice de Elasticsearch.

Vamos a seleccionar Discover en el menú de arriba y si todo ha ido bien veremos algo así:

Kibana-discover

Si no veis datos, probablemente necesitaréis añadir registros al fichero access.log de Apache (/var/log/apache2/access.log). Podéis probar accediendo a alguna página de vuestro servidor que tenga configurado ese mismo access.log.

Y si no tenéis el Apache instalado y no queréis hacerlo, o simplemente no tenéis forma de agregar registros al fichero, ejecutar los siguientes comandos para crear el fichero a mano e insertar líneas:

$ sudo su
$ touch /var/log/apache2/access.log
$ echo 10.0.0.1 - - [`date +%e/%b/%Y:%H:%M:%S` +0000] '"GET / HTTP/1.1" 200 3594 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36"' >> /var/log/apache2/access.log

Y volviendo a la imagen anterior, podemos ver un gráfico que muestra las líneas añadidas agrupadas por minuto y más abajo el listado de éstas líneas ordenadas por fecha y parseadas.

A partir de aquí ya consiste en jugar un poco con la herramienta y sus múltiples opciones.

Configurar un Dashboard con un gráfico en Kibana

Para seguir con el ejemplo de este post, vamos a realizar dos acciones:

  1. Crear un gráfico, o lo que Kibana llama una visualización.
  2. Añadir la visualización creada al Dashboard.

Crear una visualización/gráfico en Kibana

Seleccionamos Visualize en el menú de arriba y veremos la siguiente pantalla:

Kibana-crear-nueva-visualización

Seleccionamos por ejemplo Vertical bar chart y llegamos a:

Kibana-seleccionar-fuente

Como no tenemos ninguna búsqueda creada seleccionamos From a new search y veremos la pantalla de configuración del gráfico.

Kibana-edición-de-visualización

Aquí muestra todos los resultados por defecto y sin ningún tipo de agrupación.

Para poder ver los accesos por minuto a nuestro servidor necesitamos añadir un valor al Eje-X. Para ello pinchamos donde dice X-Axis y en Aggregation seleccionamos el tipo Date Histogram.

Y en los nuevos campos que se mostrarán:

  • Field: @timestamp
  • Interval: Minute

Y pulsamos en el botón Apply para aplicar los cambios.

Kibana-visualización-terminada

Para terminar sólo nos queda guardar el gráfico para posteriormente añadirlo al Dashboard. Así que pinchamos en el botón de guardar que aparece arriba a la derecha y le damos un nombre.

Kibana-guardar-visualización

Para finalizar el guardado pulsamos el botón Save.

Kibana-visualización-guardada

Añadir una visualización/gráfico al Dashboard en Kibana

Para esto vamos a pinchar en el menú de arriba a la izquierda donde dice Dashboard y lo veremos vacío, como es lógico.

Kibana-crear-dashboard

Para añadir un gráfico/visualización basta con pinchar en el icono que nos indica para añadir una nueva visualización:

Kibana-añadir-visualización

Y seleccionamos la visualización que acabamos de crear:

Kibana-visualización-añadida

Ya estaría todo. Sólo nos faltaría, al igual que antes, guardar el Dashboard creado pulsando en el botón de guardar arriba a la derecha:

Kibana-guardar-dashboard

Y finalizar el guardado pulsando Save:

Kibana-dashboard-guardado

Conclusión

Con esta entrada (a través de un ejemplo súper sencillo) sólo hemos raspado un poco la punta del iceberg, pero creo que puede venir muy bien como una primera toma de contacto.

Por otro lado, las posibilidades de del stack ELK son infinitas. Es capaz de leer y monitorizar todo lo que se nos ocurra, y las opciones de configuración y personalización son muchas.

Además no nos vamos a tener que preocupar (casi seguro) por la cantidad de logs que generen nuestras aplicaciones, ya que el stack ELK es capaz de manejar cantidades ingentes de datos.

Categorías: ELK

Crear backup de base de datos MySQL excluyendo tablas o su contenido » « Buscador con Sphinx y MySQL

12 Comentarios

  1. Muy buen articulo, lo voy a realizar…Me interesaria, saber como enviar desde Windows Event Logs…Como parsear ese syslog, transformado…

    • developerlover

      15 julio, 2015 — 16:38

      Hola Santiago,

      muchas gracias, me alegro que te haya gustado!

      No he trabajado con los Windows Event Logs, pero Logstash tiene un plugin de tipo input específico para leerlos.

      El plugin es eventlog.

      Espero que te ayude.
      Un saludo!

  2. Muy buen artículo, lo he seguido paso a paso. Estoy haciendo las pruebas para parsear el log de apache.

    “Index name or pattern: Es el nombre del índice o patrón de Elasticsearch en el que se guardan los datos desde Logstash. Esto se define con el plugin de tipo output elasticsearch.
    Como no hemos cambiado nada, por defecto, el nombre de los índices de Elasticsearch tendrá el formato logstash-%{+YYYY.MM.dd}. Por lo tanto, vamos a dejar el campo como está: logstash-*.
    Time-field name: Aquí tenemos que indicar el campo que hemos creado antes (@timestamp) con el plugin (de tipo filter) date, y Kibana lo usará para mostrarnos toda la información organizada y ordenada por fecha.”

    Hasta acá todo bien, pero cuando voy a Discover no me muestra los campos, solo aparece ?_source y el siguiente mensaje:

    “This field is present in your elasticsearch mapping but not in any documents in the search results. You may still be able to visualize or search on it.”

    De antemano gracias si me puedes ayudar.

    • developerlover

      15 octubre, 2015 — 20:20

      Hola Carlos!

      muchas gracias por escribir, me alegro de que te haya gustado.

      ¿Podrías comprobar si el fichero log de apache que estás usando contiene entradas? Si no es así, prueba a añadirlas con el comando que indico más arriba.

      Si las contiene, tal vez un pantallazo de lo que estás viendo me sirva de ayuda.

      Un saludo!
      Pablo.

      • Carlos Andres Beltrán Galindo

        27 octubre, 2015 — 17:35

        Hola Pablo, gracias por tu respuesta.

        Hace poco volví a retomar el tema, cuando ingreso a kibana me genera el error que puedes ver en la siguiente imagen:

        http://es.tinypic.com/r/14nfrsy/8

        Sabes que podría estar pasando. He realizado el paso a paso de tu post pero ya no me funciona el KIbana.

        Gracias

        • Carlos Andres Beltrán Galindo

          27 octubre, 2015 — 17:40

          Al iniciar el elasticsearch, luego logstash y por último kibana, cuando ingreso por el browser a http://localhost:5601 no aparece nada, pero si luego ejecuto la siguiente línea:

          curl -XDELETE http://localhost:9200/.kibana

          Es que ya luego aparece el error que genera en la imagen que te acabo de enviar en la respuesta anterior. Es muy raro porque antes si lograba ingresar al Kibana.

          Gracias

        • developerlover

          27 octubre, 2015 — 19:51

          Hola Carlos,

          normalmente esos errores no están relacionados con Kibana, tal vez esté pasando algo con Elasticsearch o Logstash.

          Puedes probar a revisar los logs a ver si alguno está dando problemas:

          • Logstash: /var/log/logstash
          • Elasticsearch: /var/log/elasticsearch

          Revisa también que tengas memoria suficiente (sobre todo si estás usando una máquina virtual) ya que entre los tres pueden consumir hasta 2 Gb.

          Un saludo!
          Pablo.

          • Carlos Andres Beltrán Galindo

            27 octubre, 2015 — 21:51

            Hola Pablo,

            el logstash.err

            oct 27, 2015 3:43:32 PM org.elasticsearch.node.internal.InternalNode
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] version[1.7.0], pid[4728], build[929b973/2015-07-16T14:31:07Z]
            oct 27, 2015 3:43:33 PM org.elasticsearch.node.internal.InternalNode
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] initializing …
            oct 27, 2015 3:43:33 PM org.elasticsearch.plugins.PluginsService
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] loaded [], sites []
            oct 27, 2015 3:43:36 PM org.elasticsearch.bootstrap.Natives
            ADVERTENCIA: JNA not found. native methods will be disabled.
            oct 27, 2015 3:43:36 PM org.elasticsearch.node.internal.InternalNode
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] initialized
            oct 27, 2015 3:43:36 PM org.elasticsearch.node.internal.InternalNode start
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] starting …
            oct 27, 2015 3:43:37 PM org.elasticsearch.transport.TransportService doStart
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] bound_address {inet[/0:0:0:0:0:0:0:0:9301]}, publish_address {inet[/192.168.16.52:9301]}
            oct 27, 2015 3:43:37 PM org.elasticsearch.discovery.DiscoveryService doStart
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] elasticsearch/izB4wcB_QfG7mCazGVdK0w
            oct 27, 2015 3:43:40 PM org.elasticsearch.cluster.service.InternalClusterService$UpdateTask run
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] detected_master [Crazy Eight][N_ImcUsEScCBxhSMrYCtCg][localhost.localdomain][inet[/127.0.0.1:9300]], added {[Crazy Eight][N_ImcUsEScCBxhSMrYCtCg][localhost.localdomain][inet[/127.0.0.1:9300]],}, reason: zen-disco-receive(from master [[Crazy Eight][N_ImcUsEScCBxhSMrYCtCg][localhost.localdomain][inet[/127.0.0.1:9300]]])
            oct 27, 2015 3:43:40 PM org.elasticsearch.node.internal.InternalNode start
            INFORMACIÓN: [logstash-localhost.localdomain-4728-13466] started

            y este el de elasticsearch:

            [2015-10-27 15:43:13,044][INFO ][node ] [Crazy Eight] version[1.7.0], pid[4686], build[929b973/2015-07-16T14:31:07Z]
            [2015-10-27 15:43:13,065][INFO ][node ] [Crazy Eight] initializing …
            [2015-10-27 15:43:13,244][INFO ][plugins ] [Crazy Eight] loaded [], sites []
            [2015-10-27 15:43:13,282][INFO ][env ] [Crazy Eight] using [1] data paths, mounts [[/ (/dev/mapper/vg_dspace-lv_root)]], net usable_space [1.4gb], net total_space [17.2gb], types [ext4]
            [2015-10-27 15:43:16,746][INFO ][node ] [Crazy Eight] initialized
            [2015-10-27 15:43:16,747][INFO ][node ] [Crazy Eight] starting …
            [2015-10-27 15:43:16,891][INFO ][transport ] [Crazy Eight] bound_address {inet[/127.0.0.1:9300]}, publish_address {inet[localhost/127.0.0.1:9300]}
            [2015-10-27 15:43:16,924][INFO ][discovery ] [Crazy Eight] elasticsearch/N_ImcUsEScCBxhSMrYCtCg
            [2015-10-27 15:43:20,710][INFO ][cluster.service ] [Crazy Eight] new_master [Crazy Eight][N_ImcUsEScCBxhSMrYCtCg][localhost.localdomain][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master)
            [2015-10-27 15:43:20,764][INFO ][http ] [Crazy Eight] bound_address {inet[/127.0.0.1:9200]}, publish_address {inet[localhost/127.0.0.1:9200]}
            [2015-10-27 15:43:20,765][INFO ][node ] [Crazy Eight] started
            [2015-10-27 15:43:20,790][INFO ][gateway ] [Crazy Eight] recovered [2] indices into cluster_state
            [2015-10-27 15:43:40,167][INFO ][cluster.service ] [Crazy Eight] added {[logstash-localhost.localdomain-4728-13466][izB4wcB_QfG7mCazGVdK0w][localhost.localdomain][inet[/192.168.16.52:9301]]{data=false, client=true},}, reason: zen-disco-receive(join from node[[logstash-localhost.localdomain-4728-13466][izB4wcB_QfG7mCazGVdK0w][localhost.localdomain][inet[/192.168.16.52:9301]]{data=false, client=true}])
            [2015-10-27 15:43:50,726][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.3%], shards will be relocated away from this node
            [2015-10-27 15:43:50,727][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:44:20,719][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.3%], shards will be relocated away from this node
            [2015-10-27 15:44:50,720][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:45:20,721][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:45:20,721][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:45:50,722][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:46:20,723][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:46:20,724][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:46:22,528][INFO ][cluster.metadata ] [Crazy Eight] [.kibana] deleting index
            [2015-10-27 15:46:29,185][DEBUG][action.admin.cluster.health] [Crazy Eight] observer: timeout notification from cluster service. timeout setting [5s], time since start [5s]
            [2015-10-27 15:46:32,822][INFO ][cluster.metadata ] [Crazy Eight] [.kibana] creating index, cause [api], templates [], shards [1]/[1], mappings []
            [2015-10-27 15:46:50,725][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:47:02,895][DEBUG][action.admin.cluster.health] [Crazy Eight] observer: timeout notification from cluster service. timeout setting [30s], time since start [30s]
            [2015-10-27 15:47:20,724][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:47:20,725][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:47:50,726][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:48:20,726][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:48:20,727][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:48:50,729][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:49:20,727][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:49:20,728][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards
            [2015-10-27 15:49:50,729][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:50:20,730][WARN ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark [90%] exceeded on [N_ImcUsEScCBxhSMrYCtCg][Crazy Eight] free: 1.4gb[8.4%], shards will be relocated away from this node
            [2015-10-27 15:50:20,731][INFO ][cluster.routing.allocation.decider] [Crazy Eight] high disk watermark exceeded on one or more nodes, rerouting shards

            Lo curioso del caso, es que me funcionaba perfecto, pero de un momento a otro falló. Hasta le aumente la memoria a la máquina virtual, pero aún así y nada.

  3. Buenas noches.

    Primero que nada, gracias por el tutorial y la explicación de los componentes, que a los novatos como yo aún nos cuesta pillar los conceptos.

    Quería hacer una consulta.
    Suelo ver esta estructura de componentes para usarlos en la recogida y procesamiento de logs ya sea con ELK o Graylog en distribuciones apt/yum ,es decir Debian, Ubuntu, CentOS… yo personalmente y por motivos de trabajo, estoy limitado a usar SUSE o en su variante libre y gemela OpenSUSE.

    Mi idea es montar un servidor de recogida de logs (en especial de tomcat) ya que trabajo como sysadmin y el equipo de desarrollo nos consulta continuamente por los errores o el estado de las aplicaciones.

    Es posible un “hilo” o existe alguien que consiga o tenga una forma 100% fiable de hacerlo funcionar bajo dicha plataforma?

    He probado loganalyzer pero me gustaría “ir más allá”
    Gracias tanto si podéis echar un cable, como sino por compartir vuestros conocimientos ;)

    • developerlover

      26 julio, 2016 — 10:22

      Hola Manuel y gracias por tu respuesta!

      La verdad, lamento no poder ayudarte pero no conozco el entorno de SUSE. Espero que consigas encontrar alguna solución.

      Un saludo!
      Pablo.

  4. Juan Quispe Reategui

    30 enero, 2017 — 22:45

    Estimado, tendra algún ejemplo de como monitorear los logs de aplicaciones que utilizan log4j

  5. Hola. excelente guia cuando tenga tiempo la voy a probar. solo tengo una consulta por lo que entendi en kibana mostras los hits por minuto que tiene el server apache. la pregunta es con kibana puedo verlo mas granular y ver los hits por segundo ?

    saludos

Deja un comentario

Your email address will not be published.

Copyright © 2017 developerlover.com

Up ↑