Con el trabajo realizado en la entrada anterior y con la vista puesta en herramientas existentes, como pueden ser VMware vRealize LogInsight o SexiLog, vamos a completar el servidor ELK para que pueda ser capaz de recolectar los logs de la infraestructura VMware vSphere (vCenter y servidores ESXi) y poder tener una forma sencilla y rápida de visualizarlos.

Los archivos de registro son un componente importante en una infraestructura ya que nos puede ayudar a obtener información sobre la misma, detectar problemas, anomalías, realizar auditorías… El guardar los registros de los diferentes componentes en un servidor centralizado nos ayuda a poder realizar búsquedas y análisis de una forma rápida y sencilla.

 

Servidores ESXi

Conceptos

Todos los host ESXi tienen un servicio Syslog (vmsyslogd) que escribe los mensajes de los diferentes componentes del sistema en diferentes archivos de registro.

En la siguiente tabla se muestran los archivos de las funcionalidades más importantes y su ubicación por defecto:

Componente	Ubicación	Propósito
VMkernel	/var/log/vmkernel.log	Registra las actividades relacionadas con máquinas virtuales y ESXi.
Advertencias de VMkernel	/var/log/vmkwarning.log	Registra las actividades relacionadas con máquinas virtuales.
Resumen de VMkernel	/var/log/vmksummary.log	Se utiliza para determinar las estadísticas de disponibilidad y tiempo de actividad de ESXi (valores separados por comas).
Registro del agente del host ESXi	/var/log/hostd.log	Contiene información sobre el agente que administra y configura el host ESXi y sus máquinas virtuales.
Registro del agente de vCenter	/var/log/vpxa.log	Contiene información sobre el agente que se comunica con vCenter Server (si el host es administrado por vCenter Server).
Registro del shell	/var/log/shell.log	Contiene un registro de todos los comandos introducidos en ESXi Shell y también de todos los eventos del shell (por ejemplo, el momento en que se habilitó el shell).
Autenticación	/var/log/auth.log	Contiene todos los eventos relacionados con la autenticación para el sistema local.
Mensajes del sistema	/var/log/syslog.log	Contiene todos los mensajes del registro general y puede usarse para solución de problemas. Esta información antes se encontraba en los mensajes del archivo de registro.
Actualizaciones	/var/log/esxupdate.log	Contiene información relacionada con la instalación de parches y actualización de versión de ESXi
Video	/var/log/Xorg.log	Aceleración de video
Rhttpproxy	/var/log/rhttpproxy.log	Contiene información sobre las conexiones HTTP de las que el servidor ESXi hace proxy
HA	/var/log/fdm.log	Contiene eventos relacionados con el agente de vSphere Hight Availiability (HA)
Máquinas virtuales	El mismo directorio en el que se encuentran los archivos de configuración de la máquina virtual afectada, denominados vmware.log y vmware*.log. Por ejemplo, /vmfs/volumes/datastore/virtual machine/vwmare.log	Contiene todos los eventos relacionados con el encendido de la máquina virtual, la información de errores del sistema, la actividad y el estado de las herramientas, la sincronización de hora, los cambios en el hardware virtual, las migraciones de vMotion, los clones de la máquina, etc.

 

Nivel de log

Podemos configurar diferentes niveles de log, de forma que definimos que tipo de información se registra y con ello la cantidad de registros que vamos a poder consultar.

La configuración de esta valor, se establece mediante el parámetro Config.HostAgent.log.level, que podemos editar desde las Configuración avanzada del sistema del servidor  ESXi

Existen los siguientes niveles:

• none
• quiet
• panic
• error
• warning
• info
• verbose
• trivia

Nota: No es recomendable poner un nivel de verbose o trivia durante un tiempo prolongado.

Hay casos excepcionales, como puede ser el registro Vpxa que permite establecer un valor específico del nivel de log desde un parámetro independiente, como es Vpx.Vpxa.config.log.level

También hay otros parámetros que permiten una mayor granularidad en la definicion del nivel de log, como puede ser para servicios concretos que se registran en el log del agente Hostd:

 

 

Configuración de Syslog remoto en ESXi

Configuración de Syslog en ESXi

Por cada uno de los servidores ESXi, realizamos estos pasos:

• Editamos la configuración avanzada e indicamos los siguientes valores:
  • Syslog.global.logHost: tcp://172.16.1.61:1514
  • Config.HostAgent.log.level: info
  • vpx.vpxa.config.log.level
• Habilitamos el puerto correspondiente en el cortafuegos

• Reiniciamos el servicio Syslog

 

Configuración de servicio ELK

Creación del pipeline en Logstash

Como vamos a utilizar la misma instancia que en la entrada anterior, vamos a crear un nuevo pipeline para recoger los logs de los servidores ESXi. Para ello, seguimos estos pasos:

• Creamos la carpeta /etc/logstash/conf.d/vsphere-syslog-esxi
• Dentro de esta carpeta creamos 3 archivos
  • 10-vsphere-syslog-esxi-input.conf
  • 20-vsphere-syslog-esxi-filter.conf
  • 30-vsphere-syslog-esxi-output.conf

 

10-vsphere-syslog-esxi-input.conf

input {
   tcp {
      port => 1514
      type => esxi
   }
}

20-vsphere-syslog-esxi-filter.conf

#En un primer paso lo dejamos vacío

30-vsphere-syslog-esxi-output.conf

output {
   elasticsearch {
      hosts => [ "172.16.1.61:9200" ]
      index => "logstash-vsphere-syslog-esxi-%{+YYYY.MM.dd}"
   }
}

 

• Editamos el archivo /etc/logstash/pipelines.yml y añadimos las siguientes líneas:

- pipeline.id: vsphere-netflow
  path.config: "/etc/logstash/conf.d/vsphere-netflow/*.conf"
- pipeline.id: vsphere-syslog-esxi
  path.config: "/etc/logstash/conf.d/vsphere-syslog-esxi/*.conf"

 

Comprobando la recepción de los datos

En este punto ya deberíamos de estar recibiendo los logs de los host ESXi. Comprobamos los logs de logstash y la creación del índice en Elasticsearch. Si no recibimos nada, podemos reiniciar el servicio Syslog en los servidores ESXi configurados.

Por ejemplo, si accedemos a los índices de ElasticSearch, podemos ver el nuevo índice creado

health status index                                   uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   logstash-vsphere-syslog-esxi-2017.11.30 dq8Yls-ITU2kOEe2EmoGaQ   5   1         33            0       466b           466b

Accedemos a Kibana y añadimos el nuevo índice para poder comenzar a visualizar la información

Accedemos a la sección Discover y comprobamos los datos recibidos

Vamos a analizar los datos que estamos recibiendo. Vemos los siguientes campos:

• timestamp: fecha con la que se ha marcado la recepción del log
• host: servidor ESXi de envío
• ip_address: dirección IP del servidor ESXi
• message: es el contenido de la información registrada en el log. Aquí se incluye, entre otros datos
  • Fecha de registro del log
  • Componente o programa que registra el log (hostd, vpxa …)
  • Nivel de log
  • Otros datos

Con estos datos veo lo siguiente:

• hay información en el campo message que podría ser interesante que estuviese clasificada en campos específicos, como puede ser el componente o el nivel de log, que ayudaría a un mejor análisis y búsqueda de información

 

Filtrado de los datos

Para mejorar la calidad de la información y clasificar en más campos la información que aparece en el mensaje, vamos a utilizar los filtros de Logstash y en este caso concreto vamos a trabajar con el filtro grok. Este filtro nos permite estructurar la información, generalmente con el uso de patrones de texto y expresiones regulares.

Como primer paso vamos a analizar los logs de los servidores ESXi recibidos y el contenido del campo message.

<167>2017-11-29T18:21:57.313Z srv-esx-002.lab.local Hostd: verbose hostd[12681B70] [Originator@6876 sub=PropertyProvider opID=d091033f-0080-412e-9987-4d9327028
<166>2017-11-29T18:21:57.313Z srv-esx-002.lab.local Hostd: info hostd[12681B70] [Originator@6876 sub=Vimsvc.TaskManager opID=d091033f-0080-412e-9987-4d93270288
<166>2017-11-29T18:21:57.313Z srv-esx-002.lab.local Hostd: info hostd[12A97B70] [Originator@6876 sub=Solo] Changed log.level to [N5Vmomi9PrimitiveISsEE:0x12150
<167>2017-11-29T18:21:57.313Z srv-esx-002.lab.local Hostd: verbose hostd[12681B70] [Originator@6876 sub=PropertyProvider opID=d091033f-0080-412e-9987-4d9327028
<167>2017-11-29T18:21:57.314Z srv-esx-002.lab.local Hostd: verbose hostd[12A97B70] [Originator@6876 sub=PropertyProvider] RecordOp ASSIGN: config.option, ha-ho
<167>2017-11-29T18:21:57.314Z srv-esx-002.lab.local Hostd: verbose hostd[12A97B70] [Originator@6876 sub=PropertyProvider] RecordOp ASSIGN: config.option, ha-ho
<167>2017-11-29T18:21:57.314Z srv-esx-002.lab.local Vpxa: verbose vpxa[B41EB70] [Originator@6876 sub=vpxaInvtHost opID=d091033f-0080-412e-9987-4d93270288be-410
<167>2017-11-29T18:21:57.315Z srv-esx-002.lab.local Vpxa: verbose vpxa[B41EB70] [Originator@6876 sub=vpxaInvtHost opID=d091033f-0080-412e-9987-4d93270288be-410
<166>2017-11-29T18:21:57.315Z srv-esx-002.lab.local Vpxa: info vpxa[B41EB70] [Originator@6876 sub=vpxLro opID=d091033f-0080-412e-9987-4d93270288be-4108-h5c:700
<167>2017-11-29T18:21:57.317Z srv-esx-002.lab.local Rhttpproxy: verbose rhttpproxy[4481B70] [Originator@6876 sub=Proxy Req 00185] Resolved endpoint : [N7Vmacor
<167>2017-11-29T18:21:57.317Z srv-esx-002.lab.local Rhttpproxy: verbose rhttpproxy[4481B70] [Originator@6876 sub=Proxy Req 00158] Resolved endpoint : [N7Vmacor
<167>2017-11-29T18:21:57.325Z srv-esx-002.lab.local Vpxa: verbose vpxa[B358B70] [Originator@6876 sub=PropertyProvider opID=d091033f-0080-412e-9987-4d93270288be
<167>2017-11-29T18:21:57.325Z srv-esx-002.lab.local Vpxa: verbose vpxa[B358B70] [Originator@6876 sub=PropertyProvider opID=d091033f-0080-412e-9987-4d93270288be
<167>2017-11-29T18:21:57.326Z srv-esx-002.lab.local Vpxa: verbose vpxa[B358B70] [Originator@6876 sub=PropertyProvider] RecordOp ASSIGN: info.cancelable, sessio

Podemos ver un patrón que se repite en la mayoría de los registros (en los del cuadro anterior se cumple en todos los casos, pero hay registros en los que no)

• <NUMERO>
• Fecha
• Servidor
• Componente:
• Nivel de log
• Componente[Código]
• [Originator@ xxxx]
• Mensaje

Vamos a intentar obtener estos campos con Grok.

De forma resumida, Grok funciona indicando los campos de la siguiente forma %{SYNTAX:SEMANTIC} donde SYNTAX es el nombre del patrón de texto que vamos a utilizar para realizar la úsqueday SEMANTIC es el nombre del identificador (o nombre del campo) que le vamos a dar a ese patrón de texto.

Grok ya tiene definidos varios patrones por defecto que podemos utilizar como SYNTAX, pero podemos definir nosotros mismos nuestros propios patrones

Si echamos un vistazo a los patrones por defecto, podemos ver que hay varios que nos sirven para nuestro caso particular

# Syslog Dates: Month Day HH:MM:SS
SYSLOGTIMESTAMP %{MONTH} +%{MONTHDAY} %{TIME}
PROG [\x21-\x5a\x5c\x5e-\x7e]+
SYSLOGPROG %{PROG:program}(?:\[%{POSINT:pid}\])?
SYSLOGHOST %{IPORHOST}
SYSLOGFACILITY <%{NONNEGINT:facility}.%{NONNEGINT:priority}>
HTTPDATE %{MONTHDAY}/%{MONTH}/%{YEAR}:%{TIME} %{INT}

# Shortcuts
QS %{QUOTEDSTRING}

# Log formats
SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:

# Log Levels
LOGLEVEL ([Aa]lert|ALERT|[Tt]race|TRACE|[Dd]ebug|DEBUG|[Nn]otice|NOTICE|[Ii]nfo|INFO|[Ww]arn?(?:ing)?|WARN?(?:ING)?|[Ee]rr?(?:or)?|ERR?(?:OR)?|[Cc]rit?(?:ical)?|CRIT?(?:ICAL)?|[Ff]atal|FATAL|[Ss]evere|SEVERE|EMERG(?:ENCY)?|[Ee]merg(?:ency)?)

Pero antes de continuar, revisando el patrón LOGLEVEl, vemos que busca los diferentes niveles que puede tener syslog, pero echo en falta el modo verbose, así que vamos a aprovechar esta definición y completarla nosotros mismos.

• Creamos la carpeta /etc/logstash/conf.d/vsphere-syslog-esxi/patterns
• Creamos el archivo /etc/logstash/conf.d/vsphere-syslog-esxi/patterns/vsphere-syslog-esxi con el siguiente contenido

 

# Extendemos el patrón LOGLEVEL para incluir el nivel Vervose
SYSLOGLEVEL ([Aa]lert|ALERT|[Vv]erbose|[Tt]rivia|[Tt]race|TRACE|[Dd]ebug|DEBUG|[Nn]otice|NOTICE|[Ii]nfo|INFO|[Ww]arn?(?:ing)?|WARN?(?:ING)?|[Ee]rr?(?:or)?|ERR?(?:OR)?|[Cc]rit?(?:ical)?|CRIT?(?:ICAL)?|[Ff]atal|FATAL|[Ss]evere|SEVERE|EMERG(?:ENCY)?|[Ee]merg(?:ency)?)
~

 

Ahora editamos el archivo /etc/logstash/conf.d/vsphere-syslog-esxi/20-vsphere-syslog-esxi-filter.conf y añadimos el siguiente contenido

filter {
  

 

Si volvemos a revisar la información obtenida en Kibana podemos comprobar que ahora tenemos más campos disponibles y tenemos mejor organizada la información

 

Podemos ver que tenemos nuevos campos:

• message_timestamp
• message_hostname
• message_program
• message_level

 

Vemos que tenemos también algunos registros que no se ajustan al patrón que estamos buscando, por lo que modificamos el archivo 20-vsphere-syslog-esxi-filter.conf para poder incluir el mayor tipo de patrones comunes en los registros y que haga la clasificación de los campos

De momento voy a trabajar con los siguientes filtros:

filter {
    grok {
        patterns_dir => ["/etc/logstash/conf.d/vsphere-syslog-esxi/patterns"]
        break_on_match => true
        match => [
            "message", "<%{POSINT:syslog_pri}>%{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program}: %{SYSLOGLEVEL:message_level} %{SYSLOGPROG:message_program_2}\[%{DATA:message_thread_id}\] \[%{DATA:message_originator}\] %{GREEDYDATA:message_content}",
            "message", "<%{POSINT:syslog_pri}>%{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program}: %{GREEDYDATA:message_content}",
            "message", "<%{POSINT:syslog_pri}>%{GREEDYDATA:message_content}"
        ]
        tag_on_failure => [ "grok_not_match" ]
    }
}

 

Y el siguiente paso es crear las visualizaciones correspondientes para crear los dashboards que nos permitan crear las diferentes visualizaciones, como por ejemplo:

 

 

Ejemplo práctico

Para ver una aplicación práctica de la información recopilada, revisando alguno de los gráficos que he creado, me he encontrado que los eventos con errores de uno de los servidores ESXi están muy por encima del resto.

Si hago una búsqueda en los logs, filtrando por host y por tipo de mesnaje (error), puedo obtener rápidamente los mensajes de error:

Veo que constantemente se está generando un error con el siguiente mensaje:

Unable to convert Vigor value 'freeBSD11-64' of type 'char const*' to VIM type 'Vim::Vm::GuestOsDescriptor::GuestOsIdentifier'

Al revisar las máquinas virtuales, compruebo que una de ellas es una máquina con PFsense que tiene como sistema operativo configurado a nivel de máquina «Other 2.6.x Linux (64-bit)

Pero el sistema operativo que indica las open-vm-tools que tiene instalado es diferente, FreeBSD 11.1-RELEASE-p4 (que corresponde con el mensaje del error «freeBSD11-64»)

Como esta cadena de texto representa un sistema operativo no soportado por ESXi aparece este mensaje de error. Si no hubiésemos revisado la información de los logs, no hubiésemos detectado este problema, ya que no aparece en los eventos de la máquina virtual ni del host.

 

Servidor vCenter (VCSA)

De forma similar a como hemos hecho con los servidores ESXi vamos a trabajar con el servidor vCenter (VCSA)

Al igual que los servidores ESXi, el servidor vCenter ejecuta diferentes procesos y componentes y cada uno de ellos genera registros que se guardan en diferentes archivos de log.

 

Además desde la versión 6.5 se han introducido 3 grandes mejores, respecto a los eventos de vCenter:

• Se pueden enviar los eventos a un servidor syslog remoto con la información de los eventos de vCenter de una forma estructurada y completa.
• Se ha mejorado la información de algunos de los eventos, como puede ser el típico mensaje «VM was reconfigured» que hasta ahora no permitía identificar cual había sido el cambio que había sufrido la máquina. A partir de ahora se podrá identificar el cambio concreto producido
• Los eventos no se guardan a nivel de archivos de logs de forma remota, ya que además de poder enviarse a un servidor remoto, se guardan en base de datos.

 

El listado de logs que se envían al servidor syslog remoto son:

• VC Events
• /var/log/messages
• /storage/log/vmware/applmgmt-audit/applmgmt-audit-syslog.log
• /storage/log/vmware/vmon/vmon-syslog.log
• /storage/log/vmware/vmdird/vmdird-syslog.log
• /storage/log/vmware/vmcad/vmcad-syslog.log
• /storage/log/vmware/rbd/rbd-syslog.log
• /storage/log/vmware/vmdnsd/vmdnsd-syslog.log
• /storage/log/vmware/vmafdd/vmafdd-syslog.log
• /storage/log/vmware/rsyslogd/rsyslogd-syslog.log

Además, mediante configuración especifica, es posible reenviar los eventos de vpxd.log, a través del parámetro config.log.outputToSyslog

 

Configuración del servidor vCenter

Para configurar el envío de logs remotos seguimos estos pasos:

• Accedemos al interfaz VAMI del servidor vCenter, sección Syslog Configuration

• Rellenamos los campos de configuración

• Common Log Level
  • *
  • info
  • notice
  • warn
  • error
  • crit
  • alert
  • emerg
• Remove Syslog Host
• Remove Syslog Port
• Remote Syslog Protocol
  • TCP
  • UDP
  • TLS
  • RELP
• Reiniciamos el servicio de Syslog

Configuración de servicio ELK

Creación del pipeline en Logstash

Creamos un nuevo pipeline para recoger los logs del servidor vCenter. Para ello, seguimos estos pasos:

• Creamos la carpeta /etc/logstash/conf.d/vsphere-syslog-vcenter
• Dentro de esta carpeta creamos 3 archivos
  • 10-vsphere-syslog-vcenter-input.conf
  • 20-vsphere-syslog-vcenter-filter.conf
  • 30-vsphere-syslog-vcenter-output.conf

 

10-vsphere-syslog-vcenter-input.conf

input {
   tcp {
      port => 1515
      type => esxi
   }
}

20-vsphere-syslog-vcenter-filter.conf (este punto puede ser el que más trabajo lleve, ya que hay múltiples patrones y es necesario intentar definir el mayor número posible) Estos son algunos con los que he trabajado:

filter {
    grok {
        patterns_dir => ["/etc/logstash/conf.d/vsphere-syslog-vcenter/patterns"]
        break_on_match => true
        match => [

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \- Event \[%{NUMBER:message_event_id}\] \[1-1\] \[%{TIMESTAMP_ISO8601:message_timestamp_2}\] \[%{DATA:message_event}\] \[%{LOGLEVEL:message_event_level}\] \[%{DOMAINUSER:message_domainuser}\] \[%{DATA:message_event_datacenter}\] \[%{NUMBER:message_event_id_2}\] \[%{GREEDYDATA:message_event_content}",

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \-  Event \[%{NUMBER:message_event_id}\] \[1-1\] \[%{TIMESTAMP_ISO8601:message_timestamp_2}\] \[%{DATA:message_event}\] \[%{LOGLEVEL:message_event_level}\] \[%{DOMAINUSER:message_domainuser}\] \[%{DATA:message_event_datacenter}\] \[%{NUMBER:message_event_id_2}\] %{GREEDYDATA:message_event_content}",

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \- Event \[%{NUMBER:message_event_id}\] \[1-1\] \[%{TIMESTAMP_ISO8601:message_timestamp_2}\] \[%{DATA:message_event}\] \[%{LOGLEVEL:message_event_level}\] \[%{DOMAINUSER:message_domainuser}\] \[\] \[%{NUMBER:message_event_id_2}\] \[%{GREEDYDATA:message_event_content}",

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \-  Event \[%{NUMBER:message_event_id}\] \[1-1\] \[%{TIMESTAMP_ISO8601:message_timestamp_2}\] \[%{DATA:message_event}\] \[%{LOGLEVEL:message_event_level}\] \[%{DOMAINUSER:message_domainuser}\] \[\] \[%{NUMBER:message_event_id_2}\] \[%{GREEDYDATA:message_event_content}",



            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \-  %{TIMESTAMP_ISO8601:message_timestamp_2} %{LOGLEVEL:message_level} %{SYSLOGPROG:message_program_2}\[%{DATA:message_thread_id}\] \[%{DATA:message_originator}\] %{GREEDYDATA:message_content}",

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \- %{TIMESTAMP_ISO8601:message_timestamp_2} %{LOGLEVEL:message_level} %{SYSLOGPROG:message_program_2}\[%{DATA:message_thread_id}\] \[%{DATA:message_originator}\] %{GREEDYDATA:message_content}",

            "message", "<%{POSINT:syslog_pri}>1 %{TIMESTAMP_ISO8601:message_timestamp} %{SYSLOGHOST:message_hostname} %{SYSLOGPROG:message_program} %{NUMBER:message_process_id} \- \-  %{TIMESTAMP_ISO8601:message_timestamp_2} %{LOGLEVEL:message_level} %{GREEDYDATA:message_content}",


            "message", "%{GREEDYDATA:message_content}"


        ]
        tag_on_failure => [ "grok_not_match" ]
    }
}

30-vsphere-syslog-vcenter-output.conf

output {
   elasticsearch {
      hosts => [ "172.16.1.61:9200" ]
      index => "logstash-vsphere-syslog-vcenter-%{+YYYY.MM.dd}"
   }
}

 

• Editamos el archivo /etc/logstash/pipelines.yml y añadimos las siguientes líneas:

- pipeline.id: vsphere-netflow
  path.config: "/etc/logstash/conf.d/vsphere-netflow/*.conf"
- pipeline.id: vsphere-syslog-esxi
  path.config: "/etc/logstash/conf.d/vsphere-syslog-esxi/*.conf"
- pipeline.id: vsphere-syslog-vcenter
  path.config: "/etc/logstash/conf.d/vsphere-syslog-vcenter/*.conf"

 

Comprobando la recepción de los datos

En este punto ya deberíamos de estar recibiendo los logs de los host ESXi. Comprobamos los logs de logstash y la creación del índice en Elasticsearch. Si no recibimos nada, podemos reiniciar el servicio Syslog en los servidores ESXi configurados.

Por ejemplo, si accedemos a los índices de ElasticSearch, podemos ver el nuevo índice creado

health status index                                      uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   logstash-vsphere-syslog-vcenter-2017.11.30 aXVi7R4WQfyvrxQVGY63rA   5   1       2386            0    841.5kb        841.5kb

Accedemos a Kibana y añadimos el nuevo índice para poder comenzar a visualizar la información

 

Accedemos a la sección Discover y comprobamos los datos recibidos

 

 

 

Creación de las visualizaciones y dashboards

Para la creación de las visualizaciones podemos mostrar datos como el volumen de eventos, o tipos de eventos (error, info…) pero es interesante el realizar filtros en Kibana para mostrar información sobre eventos en concreto, como por ejemplo:

• Inicios de sesión
• Problemas con almacenamiento
• Problemas con la red
• Encendido de máquinas virtuales
• …

Para ello es necesario conocer que cadenas de texto queremos buscar para cada uno de los casos.

Por ejemplo, un posible dashboards sería algo como este: