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
|
1 2 3 4 5 6 |
input { tcp { port => 1514 type => esxi } } |
20-vsphere-syslog-esxi-filter.conf
|
1 |
#En un primer paso lo dejamos vacío |
30-vsphere-syslog-esxi-output.conf
|
1 2 3 4 5 6 |
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:
|
1 2 3 4 5 |
- pipeline.id: vsphere-netflow path.config: "/etc/logstash/conf.d/vsphere-netflow/*.conf" <strong>- pipeline.id: vsphere-syslog-esxi path.config: "/etc/logstash/conf.d/vsphere-syslog-esxi/*.conf" </strong> |
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
|
1 2 |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# 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
|
1 2 3 |
# 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
|
1 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
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:
|
1 |
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
|
1 2 3 4 5 6 |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
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
|
1 2 3 4 5 6 |
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:
|
1 2 3 4 5 6 7 |
- 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" <strong>- pipeline.id: vsphere-syslog-vcenter path.config: "/etc/logstash/conf.d/vsphere-syslog-vcenter/*.conf" </strong> |
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
|
1 2 |
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:
Thanks for this comprehensive guide! Not much information out there about getting VMware logs into Elasticsearch…
I’m trying to get vCenter (VCSA 6.5) syslogs into Elasticsearch via Logstash.
Your Logstash grok filter looks great, however it seems that the Logstash grok pattern for vsphere-syslog-vcenter is missing in this post?
For example, there is no pattern for \[%{DOMAINUSER:message_domainuser}\] out-of-the-box, or mention of pattern that fits that in this post?
Would love to have that pattern!
Best regards,
Martin