Tema 8

Herramientas DevOps

Captura de logs y
telemetría mediante
Beats
 Índice
Esquema 3

Ideas clave 4
8.1. Introducción y objetivos 4
8.2. Arquitectura y topología de Beats y Logstash 5
© Universidad Internacional de La Rioja (UNIR)

8.3. La suite de Beats 7

8.4. Filebeat 14
8.5. Conclusiones 21
8.6. Referencias bibliográficas 22

A fondo 23

Test 25
 © Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
Tema 8. Esquema
Esquema

3
 Ideas clave

8.1. Introducción y objetivos

Para poder monitorizar nuestros sistemas es necesario capturar la mayor cantidad

de información posible y procesarla hasta que esté disponible en un lugar fácilmente
accesible.

En el tema anterior hemos visto cómo un buen almacén de esta información puede
ser ElasticSearch dadas sus capacidades para ingerir gran cantidad de información y
poder analizarla de forma sencilla y rápida.

En este tema vamos a ver algunas herramientas que podemos usar para resolver este
problema, centrándonos en las más populares y las que más sencillas son de operar
en los casos frecuentes.

Las herramientas más frecuentemente utilizadas para esto son la suite de

herramientas Beats. Estas son capaces de recopilar datos de diferentes procedencias
y enviarlos a ElasticSearch. En ocasiones, para hacer manipulaciones más avanzadas
estos datos se procesan mediante Logstash o incluso se recopilan mediante esta
herramienta. Hablaremos de donde se podría usar Logstash, pero no nos
centraremos en esta herramienta, ya que cada vez es menos necesaria según Beats
gana más funcionalidad y si no la necesitamos no suele convenir instalarla, ya que
cuesta más mantenerla con grandes flujos de datos.
© Universidad Internacional de La Rioja (UNIR)

Los objetivos que se pretenden conseguir en este tema son:

 Aprender qué tipo de topologías se suelen utilizar mediante Beats.

 Conocer los tipos más frecuentes de Beats.

Herramientas DevOps
4
Tema 8. Ideas clave
  Aprender en detalle Filebeat, la herramienta más frecuente para procesar
ficheros.

 Conocer cómo instalar Beats y cómo figurarlo.

 Saber dónde buscar si necesitamos monitorizar distinto tipo de componentes.

En el siguiente vídeo sobre Beats y Logstash: Casos de uso se estudian los casos de
uso para Beats y Logstash, cuando utilizar cada uno y sus principales características.

8.2. Arquitectura y topología de Beats y Logstash

Los Beats son remitentes de datos de código abierto que se instalan como agentes
en los servidores para enviar datos operativos a ElasticSearch. Beats puede enviar
datos directamente a ElasticSearch o a través de Logstash, donde estos datos se
procesan y mejoran, antes de ser visualizados en Kibana. Beats están escritos en Go
y permiten crear nuevos fácilmente mediante a la librería libbeat.

En la Figura 1 podemos ver cómo es posible usar en la misma solución tanto Beats
como Logstash.
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
5
Tema 8. Ideas clave
 Figura 1. Esquema de Elastic Stack con Beats y Logstash. Fuente: [Link].

Logstash es un motor de recopilación de datos de código abierto con capacidades

de procesamiento en tiempo real. Puede unificar dinámicamente datos de fuentes
dispares y normalizar los datos en los destinos que indique el usuario. Permite limpiar
y unificar todos los datos para casos de uso avanzados de análisis y visualización.

Logstash tiene capacidades para ingestar directamente algunas fuentes de datos

como pueden ser los ficheros o ciertas bases de datos. Para algunas aplicaciones es
posible utilizar Logstash exclusivamente, sin embargo, para aplicaciones de
monitorización como las que estamos analizando nosotros, las diferentes piezas de
Beats permiten la recolección y enriquecimiento de datos en las fuentes, y presentan
un menor consumo de recursos, por lo que suelen ser la solución preferida. Además
suele requerir muy poco mantenimiento frente a Logstash.
© Universidad Internacional de La Rioja (UNIR)

Si los Beats son utilizados como agentes para recopilar nuestras métricas y son
capaces de enviar datos directamente a ElasticSearch, ¿cuándo debemos usar
Logstash? La respuesta es simple: Logstash permite tratar y normalizar los datos y
soporta muchas fuentes de datos no soportadas por Beats. Por ejemplo, puede leer

Herramientas DevOps
6
Tema 8. Ideas clave
 datos de bases de datos que permitan realizar consultas complejas si son necesarias.
A su vez, Logstash permite manipular los datos mucho más lo que permite normalizar
entre distintos tipos de emisores y agentes.

Por último, Logstash permite escribir en diferentes almacenamientos de información

y no solo en ElasticSearch. Si tenemos datos que necesitamos persistir en otro
almacenamiento distinto podríamos requerir Logstash. Por ejemplo, por auditoría
podríamos almacenar los logs de accesos a cierta información en un almacenamiento
durable y separado de nuestra infraestructura y podría ser mejor usar Logstash para
enviar los datos tanto a ElasticSearch como a ese almacenamiento.

Al ser Beats más livianos en su consumo, esto los hace idóneos para recopilar la
información en los sistemas productivos y Logstash como una forma de consolidar la
información y de leer de sistemas no soportados por Beats.

8.3. La suite de Beats

Ya hemos visto que Beats son remitentes de datos de código abierto que instala como
agentes en sus servidores para enviar datos operativos a ElasticSearch.

Vamos a ir analizando los diferentes Beats que componen la solución. No es necesario

utilizarlos todos y deberemos incluirlos en función de nuestras necesidades.
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
7
Tema 8. Ideas clave
 Tabla 1. Tipos de beats según datos.

Estos son solo los Beats oficiales. Existen muchos más Beats desarrollados por la
comunidad y es posible desarrollarlos mediante una librería llamada libbeat en el
lenguaje Go.

Cada tipo de Beats requiere una documentación específica, pero tienen algunos
conceptos comunes que nos ayudarán a entender cómo funciona su configuración.

Ficheros de configuración de Beats

Los archivos de configuración de Beats se basan en YAML, un formato de archivo

que es más fácil de leer y escribir que otros formatos de datos comunes como XML o
JSON.
© Universidad Internacional de La Rioja (UNIR)

En Beats, todos los archivos YAML comienzan con un diccionario, una colección
desordenada de pares de nombre / valor. Además de los diccionarios, YAML también
admite listas, números, cadenas y muchos otros tipos de datos. Todos los miembros
de la misma lista o diccionario deben tener el mismo nivel de indentación.

Herramientas DevOps
8
Tema 8. Ideas clave
 Los diccionarios están representados por pares key: value simples, todos con el
mismo nivel de indentación. Después de la clave y los dos puntos, debe ir un espacio
seguido del valor.

nombre: John Doe

edad: 34
país: Canadá

Las listas se introducen con guiones `-`. Todos los miembros de la lista serán líneas
que comienzan con `-` en el mismo nivel de indentación.

- Rojo
- Verde
- Azul

Las listas y los diccionarios se usan conjuntamente para crear configuraciones

estructuradas fáciles de leer.

filebeat:
inputs:
- type: log
paths:
- /var/log/*.log
multiline:
pattern: '^['
match: after

Las listas y los diccionarios también se pueden representar en forma abreviada. La

forma abreviada es algo similar al uso de JSON {} para diccionarios y [] para listas:
© Universidad Internacional de La Rioja (UNIR)

person: {name: "John Doe", age: 34, country: "Canada"}

colors: ["Red", "Green", "Blue"]

Estos campos se almacenarán posteriormente unidos usando los campos como

espacio de nombre para poder referirnos a los campos anidados. Por ejemplo:

Herramientas DevOps
9
Tema 8. Ideas clave
 output:
elasticsearch:
index: 'beat-%{[[Link]]}-%{+[Link]}'

Será guardado como:

[Link]: 'beat-%{[[Link]]}-%{+[Link]}'

En el caso de listas:

filebeat:
inputs:
- type: log

Se almacena como:

[Link]: log

Podemos aprovechar esta característica para hacer ciertas partes de la configuración

más densas lo cual ayuda en ciertos casos. Por ejemplo:

[Link]:
- type: log
paths: ["/var/log/*.log"]
[Link]: '^['
[Link]: after

[Link]: ["[Link]
© Universidad Internacional de La Rioja (UNIR)

YAML soporta los datos Booleanos:

enabled: true
disabled: false

Herramientas DevOps
10
Tema 8. Ideas clave
 Como curiosidad, es posible utilizar yes y on como alternativas a true. Y es posible
utilizar no y off como alternativas a false. Esto en ocasiones hace que se lea algo
mejor, pero suele despistar a los que no lo conocen, así que evitad abusar de esto.

También soporta valores numéricos:

integer: 123
negative: -1
float: 5.4

En YAML los strings se soportan cerrados por comillas dobles (“string”), comillas
simples (‘string’) y sin poner comillas. Las comillas dobles permiten escapar
caracteres mediante la barra invertida: \. Es necesario tener cuidado si no utilizamos
comillas de que el texto no haga conflicto con ningún otro significado en YAML.

Es posible especificar duraciones con las siguientes unidades: ns, us, ms, s, m, h.

Frecuentemente duraciones negativas o cero apagan una función. Por ejemplo:

duration1: 2.5s
duration2: 6h
duration_disabled: -1s

Por último, es posible referenciar otras variables mediante los strings formateados
(sprintf). Se accede mediante “%{acceso:valor por defecto}”. Para acceder a campos
usamos “[campo]”. Es posible formatear los campos de tiempo mediante
“+FORMATO”. Por ejemplo:
© Universidad Internacional de La Rioja (UNIR)

constant-format-string: 'constant string'

field-format-string: '%{[fieldname]} string'
format-string-with-date: '%{[fieldname]}-%{+[Link]}'

Es posible referenciar variables de entorno mediante: “${VAR}”. Las variables de

entorno también soportan un valor por defecto: ${VAR:valor_por_defecto}.

Herramientas DevOps
11
Tema 8. Ideas clave
 Por último, es posible mostrar un error específico cuando la variable no está presente
como: ${VAR:?texto_de_error}.

Además de utilizar la funcionalidad de formateo de strings, es posible utilizar

referencias a variables. Esto se realiza accediendo con la misma sintaxis que las
variables de entorno. Por ejemplo:

[Link]: '${ES_HOST:localhost}'

[Link]:
hosts: ['[Link]

Y por último, es posible referenciar no solo variables específicas sino bloques de

configuración completos. Por ejemplo, si sabemos que los dos namespaces siempre
van a tener el mismo valor, en lugar de:

namespace1:
subnamespace:
host: localhost
sleep: 1s

namespace2:
subnamespace:
host: localhost
sleep: 1s

Es posible escribir:

namespace1: ${shared}
namespace2: ${shared}
© Universidad Internacional de La Rioja (UNIR)

shared:
subnamespace:
host: localhost
sleep: 1s

Herramientas DevOps
12
Tema 8. Ideas clave
 Esto puede ayudar con los problemas de mantenibilidad evitando que solo una de las
dos configuraciones reciba el cambio.

Si queremos sobrescribir valores desde la línea de comandos, esto es posible. Por

ejemplo, si tenemos:

[Link]:
hosts: ["[Link]
username: username
password: password

Es posible deshabilitar el output de ElasticSearch y sin embargo habilitar la salida por

consola mediante:

-E output='{[Link]: false, [Link]: true}'

El resultado final para Beats sería:

[Link]:
enabled: false
hosts: ["[Link]
username: username
password: password

[Link]:
pretty: true

A continuación, vamos a ir viendo cómo funcionan los Beats más comúnmente

utilizados en entornos de monitorización.
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
13
Tema 8. Ideas clave
 8.4. Filebeat

Filebeat es un recolector ligero para reenviar y centralizar datos de log en diferentes

ficheros. Instalado como un agente en los servidores, Filebeat supervisa los archivos
de logs u otras ubicaciones que especifique, recoge registro, y los envía ya sea a
ElasticSearch o Logstash para la indexación.

Así es como funciona Filebeat: cuando inicia Filebeat, inicia una o más entradas que
se leen en las ubicaciones que ha especificado. Para cada fichero o registro que
Filebeat localiza, Filebeat inicia un recolector. Cada recolector lee el contenido nuevo
de un único log y envía los nuevos datos de registro a libbeat, que agrega los eventos
y envía los datos agregados a la salida que ha configurado para Filebeat.
© Universidad Internacional de La Rioja (UNIR)

Figura 2. Arquitectura de Filebeat con posibles entradas y salidas.

Herramientas DevOps
14
Tema 8. Ideas clave
 Filebeat consta de dos componentes principales: entradas y recolectores. Estos
componentes trabajan juntos para crear una cola de registros y enviar datos de
eventos a la salida que especifique.

Un recolector es responsable de leer el contenido de un solo archivo. El recolector

lee cada archivo, línea por línea, y envía el contenido a la salida. Se inicia un recolector
para cada archivo. El recolector es responsable de abrir y cerrar el archivo, lo que
significa que el descriptor del archivo permanece abierto mientras el recolector se
está ejecutando. Si un archivo se elimina o cambia de nombre mientras se está
monitorizando, Filebeat continúa leyendo el archivo. Esto tiene el efecto secundario
de que el espacio en su disco está reservado hasta que la recolección se cierre. Por
defecto, Filebeat mantiene el archivo abierto hasta que close_inactive se alcanza.
Esto es útil ya que cuando rotamos un fichero de logs con alguna herramienta como
logrotate1 es posible terminar de leer las últimas líneas del fichero.

Cerrar un recolector tiene las siguientes consecuencias:

 El controlador de archivos está cerrado, liberando los recursos subyacentes si el

archivo se eliminó mientras el recolector todavía estaba leyendo el archivo.

 La recolección del archivo solo se iniciará nuevamente después de que

scan_frequency haya transcurrido.

 Si el archivo se mueve o se elimina mientras el recolector está cerrado, la

recolección del archivo no continuará. Esto es infrecuente, pero puede afectar
cuando haya ficheros de corta duración.
© Universidad Internacional de La Rioja (UNIR)

Una entrada es responsable de administrar los recolectores y encontrar todas las

fuentes para leer.

1 Véase [Link] para más información sobre logrotate.

Herramientas DevOps
15
Tema 8. Ideas clave
 Si el tipo de entrada es log, la entrada encuentra todos los archivos en la unidad que
coinciden con las rutas globales establecidas e inicia una cosechadora para cada
archivo. Cada entrada se ejecuta en su propia rutina Go.

El siguiente ejemplo configura Filebeat para recolectar líneas de todos los archivos
de registro que coinciden con los patrones globales especificados:

[Link]:
- type: log
paths:
- /var/log/*.log
- /var/path2/*.log

Filebeat actualmente admite varios tipos de entrada o input. Cada tipo de entrada
se puede definir varias veces. La entrada de log verifica cada archivo para ver si es
necesario iniciar un recolector, si ya se está ejecutando o si se puede ignorar el
archivo (ver ignore_older). Las nuevas líneas solo se recogen si el tamaño del archivo
ha cambiado desde que se cerró el recolector.

Es importante entender cómo mantiene el estado de cada archivo Filebeat

para poder entender qué está ocurriendo cuando un comportamiento nos
sorprende.

Filebeat mantiene el estado de cada archivo y frecuentemente guarda el estado en

el disco en el archivo de registro. El estado se utiliza para recordar el último offset o
lugar desde el que estaba leyendo para garantizar que se envíen todas las líneas del
fichero. Si no se puede acceder a la salida, como ElasticSearch o Logstash, Filebeat
realiza un seguimiento de las últimas líneas enviadas y continuará leyendo los
© Universidad Internacional de La Rioja (UNIR)

archivos tan pronto como la salida vuelva a estar disponible. Mientras Filebeat se está
ejecutando, la información de estado también se guarda en la memoria para cada
entrada. Cuando se reinicia Filebeat, los datos del archivo de registro se utilizan para
reconstruir el estado, y Filebeat continúa cada recolector en la última posición
conocida.

Herramientas DevOps
16
Tema 8. Ideas clave
 Para cada entrada, Filebeat mantiene un estado de cada archivo que encuentra.
Debido a que los archivos se pueden renombrar o mover, el nombre de archivo y la
ruta no son suficientes para identificar un archivo. Para cada archivo, Filebeat
almacena identificadores únicos para detectar si un archivo se cosechó
anteriormente.

Si su caso de uso implica la creación de una gran cantidad de archivos nuevos todos
los días, es posible que el archivo de registro sea demasiado grande. Esto no es un
problema salvo con programas que creen muchos ficheros de logs diversos por
cliente y casuísticas similares. Hay soluciones a este problema si lo encontramos, pero
no es frecuentes durante la monitorización de servidores.

Filebeat intenta garantizar que los eventos se entregarán a la salida configurada al

menos una vez y sin pérdida de datos. Filebeat puede lograr este comportamiento
porque almacena el estado de entrega de cada evento en el archivo de registro.

En situaciones en las que la salida definida está bloqueada y no ha confirmado todos

los eventos, Filebeat seguirá intentando enviar eventos hasta que la salida reconozca
que los ha recibido. Esto es muy útil durante pequeños cortes de red o durante
problemas en la infraestructura donde se guardan los logs, como pueden ser
problemas en ElasticSearch o Logstash.

Es posible que Filebeat se cierre mientras está en el proceso de enviar eventos, y no

se espere a que la salida confirme todos los eventos antes de apagarse. Todos los
eventos que se envían a la salida, pero que no se confirman antes de que Filebeat se
cierra, se envían nuevamente cuando se reinicia Filebeat. Esto garantiza que cada
© Universidad Internacional de La Rioja (UNIR)

evento se envíe al menos una vez, pero puede terminar con eventos duplicados que
se envían a la salida. Puede configurar Filebeat para esperar una cantidad de tiempo
específica antes de apagarse configurando la opción de shutdown_timeout.

Herramientas DevOps
17
Tema 8. Ideas clave
 Existe una limitación para la garantía de entrega de Filebeat al menos una vez que
implica la rotación de logs y la eliminación de archivos antiguos. Si los archivos de
registro se escriben en el disco y giran más rápido de lo que Filebeat puede procesar,
o si los archivos se eliminan mientras la salida no está disponible, los datos podrían
perderse. En general, esto es improbable y ocurre solo cuando tenemos una gran
cantidad de archivos rotando o cuando la salida está rota durante un tiempo y
reiniciamos Filebeat repetidamente durante ese período.

Filebeat es bastante estable y si tenemos problemas por no estar viendo parte de la

información deberemos comprobar primero que puede escribir en la salida antes de
reiniciarlo para reducir el riesgo a perder eventos.

La configuración de Filebeat se almacena en un lugar dependiente del sistema y

podemos buscar las configuraciones para nuestro sistema destino. Soporta múltiples
distribuciones Linux (Debian, RedHat), Windows, MacOs, Docker, Kubernetes y otros
sistemas. Al ser un ejecutable de Go suele ser muy portable entre sistemas y fácil de
instalar manualmente si lo necesitamos.

Para configurar Filebeat, solo deberemos editar el archivo de configuración. Por

defecto se llama [Link]. La ubicación del archivo dependerá de la plataforma.
También hay un archivo de configuración de ejemplo completo llamado
[Link], que muestra todas las opciones no obsoletas.

A continuación, vamos a mencionar las configuraciones más frecuentes.

La primera de las secciones es la de inputs. Los inputs son una lista de diferentes
configuraciones que vamos a leer desde Filebeat. Por ejemplo:
© Universidad Internacional de La Rioja (UNIR)

[Link]:
- type: log
enabled: true
paths:
- /var/log/*.log

Herramientas DevOps
18
Tema 8. Ideas clave
 #- c:\programdata\elasticsearch\logs\*

Como vemos, es posible leer ficheros de log de sistemas Linux y Windows.

Existen muchos tipos de entrada. El principal de ellos es el de fichero.

 Ficheros de log: Permiten analizar ficheros y realizar un filtrado preliminar sobre

esto. Es posible excluir o incluir líneas que cumplan algún tipo de patrón.

Una opción muy potente es unir líneas consecutivas. Hasta el momento todo el
análisis se ha realizado línea a línea. Pero hay ocasiones en que varias líneas
pertenecen al mismo evento. Para esto es necesario utilizar la opción multiline y
configurarla para que el tipo de patrón nos permita juntar las líneas cuando sean
parte del mismo evento. El ejemplo más clásico de esto son las trazas de excepción,
que frecuentemente se detallan con varias líneas, por ejemplo:

[beat-logstash-some-name-832-2015.11.28] IndexNotFoundException[no such

index]
at
[Link]$WildcardExp
[Link]([Link])
at
[Link]
ices([Link])
at
[Link]
ices([Link])
at
[Link].c
heckBlock([Link])
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
19
Tema 8. Ideas clave
 Se podría analizar como un único evento mediante:

[Link]: '^\['
[Link]: true
[Link]: after

También es muy útil utilizar la opción fields o campos, que permite incluir campos
adicionales a cada línea.

Existen otros tipos de procesamiento, como:

 Azure eventhub.

 Cloud Foundry.

 Container.

 Docker.

 Google Pub/Sub.

 HTTP JSON.

 Kafka.

 MQTT.
© Universidad Internacional de La Rioja (UNIR)

 NetFlow.

 Redis.

 s3.

Herramientas DevOps
20
Tema 8. Ideas clave
  Stdin.

 Syslog.

 TCP.

 UDP.

Estos son ocasionalmente utilizados, especialmente algunos como Docker, Container,

Syslog o Stdin. Es posible capturar datos mediante HTTP JSON o TCP si tenemos
comunicación entre procesos o en red u obtener información de diferentes sistemas
utilizados como colas de mensajes.

8.5. Conclusiones

Después de analizar con detalle varias de las herramientas de la suite Beats

deberíamos conocer como poder monitorizar gran variedad de sistemas. Hemos
hablado brevemente de otras herramientas como Logstash para conocer cómo
podríamos utilizarla si necesitáramos un comportamiento más avanzado al procesar
los datos.

Con este conocimiento, podemos extraer los datos operacionales de gran variedad
de sistemas, incluyendo su consumo de recursos, sus logs operacionales y otras
métricas avanzadas.
© Universidad Internacional de La Rioja (UNIR)

Todos estos datos pueden ser enviados a ElasticSearch para su posterior consumo y
procesamiento.

Herramientas DevOps
21
Tema 8. Ideas clave
 El siguiente paso es analizar esos datos de ElasticSearch para hacerlo más fáciles de
consumir. Veremos cómo en el siguiente tema.

8.6. Referencias bibliográficas

Documentación oficial de [Link] sobre Beats, Filebeats, Metricbeat y Logstash.

© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
22
Tema 8. Ideas clave
 A fondo
¿Cómo afinar la performance de Beats?

Hasan, I. (2018, 31 julio). How to Tune Elastic Beats Performance: A Practical Example
with Batch Size, Worker Count, and More. Elastic Blog.
[Link]
example-with-batch-size-worker-count-and-more

Beats suele ofrecer un buen rendimiento con la configuración por defecto y en

muchas ocasiones es mejor no dedicar tiempo a configurarlo.

Pero cuando tenemos un cierto volumen y el coste y la latencia empiezan a ser

considerables es conveniente medir su rendimiento para nuestro caso. Este artículo
nos explica no solo algunos valores a probar sino como extraer los mejores valores
para nuestro caso de uso (nuestra instalación y nuestra configuración de máquinas y
red). Muy recomendable leerlo.

Logstash

Documentación de Logstash
[Link]

Hemos hablado brevemente de Logstash en esta guía. Logstash es más

frecuentemente utilizado en procesamiento analítico de datos para aprendizaje
© Universidad Internacional de La Rioja (UNIR)

automático, especialmente como un paso de compilación de datos antes de un

procesamiento más avanzando mediante, por ejemplo, Spark. Aun así, en ciertos
casos Logstash es una buena herramienta para procesar datos de telemetría antes de
enviarlos a ElasticSearch o para moverlos a otro tipo de almacenamiento como puede
ser Hadoop. Aquí tenéis una guía sobre cómo gestionar esta información.

Herramientas DevOps
23
Tema 8. A fondo
 Prometheus

Documentación de Prometheus
[Link]

En el caso de contenedores y de información de telemetría, Prometheus es una

herramienta extraordinariamente utilizada en entornos con Kubernetes. Es
interesante conocer esta herramienta para conocer cuál es mejor usar. Es posible
combinar las herramientas vistas en este tema junto con Prometheus si lo
necesitamos por ejemplo: [Link]
embracing-prometheus-and-openmetrics-standards-for-metrics
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
24
Tema 8. A fondo
 Test
1. ¿Cuáles son las principales ventajas de Beats frente a Logstash?
A. Su mejor consumo de recursos y su fácil mantenimiento.
B. Su gran capacidad para procesar los datos en el propio proceso antes de
enviarlos.
C. Su capacidad para enviar a muchos más destinos que Logstash.
D. El estar escritos en Java frente a Go utilizado para Logstash.

2. ¿Cuál de los siguientes patrones de comunicación son comúnmente utilizados?

A. Filebeats -> Logstash -> ElasticSearch.
B. Logstash -> Metricbeats -> ElasticSearch.
C. Metricbeats -> ElasticSearch.
D. A y C son correctas.

3. AuditBeat:
A. C y D son correctas.
B. Permite obtener información de audio.
C. Permite auditar que los ficheros del sistema no han sido modificados.
D. Es frecuentemente utilizado para detectar intrusiones.

4. Algunos componentes de Beats son:

A. PacketBeat, que permite analizar el tráfico de red inspeccionando paquetes.
B. WinlogBeat, que permite capturar logs del sistema en equipos Windows.
C. HeartBeat, que permite enviar mensajes periódicamente para asegurarse de
que la conectividad es correcta.
© Universidad Internacional de La Rioja (UNIR)

D. Todos los anteriores son correctos.

Herramientas DevOps
25
Tema 8. Test
 5. Los beats se configuran mediante:
A. Una serie de ficheros en disco.
B. Un único fichero YAML.
C. Un único fichero XLM.
D. Un único fichero TOML.

6. El formato YAML:
A. B y C son correctas.
B. La indentación permite hacer más fácil de leer YAML, pero no es considerada
para parsear el formato.
C. Permite expresar todos los tipos de JSON como las listas y los objetos.
D. Es más fácil de leer y escribir por humanos que JSON.

7. En un fichero de YAML para beats:

A. off sin comillas es interpretado como el boolean false.
B. 6ms representa 6 milisegundos en muchos parámetros.
C. yes es interpretado como el boolean true.
D. Todas las respuestas son correctas.

8. Si necesitamos utilizar el valor de una variable de entorno en el fichero de

configuración de Beats:
A. B y D son correctas.
B. Podemos usar %{ENVIRONMENT_VARIABLE} para usar ese valor en strings.
C. Necesitaremos preprocesar el YAML con otro programa, ya que Beats no
soporta variables de entorno.
D. Es recomendable dar un valor por defecto dentro del fichero de
configuración mediante %{ENVIRONMENT_VARIABLE:valor por defecto}.
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
26
Tema 8. Test
 9. Si necesitamos cambiar el valor de una variable sin cambiar el fichero de
configuración:
A. Podemos modificar parte mediante el argumento -e.
B. Si utilizamos el nombre correcto de la variable de entorno podemos cambiar
cualquier valor de configuración.
C. Si utiliza interpolación de variables de entorno, podemos cambiarlo pasando
esa variable de entorno.
D. A y C son correctos.

10. ¿Cuál de las siguientes afirmaciones sobre Filebeats es más correcta?

A. Procesa los ficheros indicados enviando un mensaje por cada línea.
B. Procesa los ficheros indicados enviando un mensaje por cada línea, a no ser
que se utilice la opción multiline.
C. Procesa los ficheros indicados mediante el tipo log enviando un mensaje por
cada línea, a no ser que se utilice la opción multiline.
D. Procesa los ficheros por TCP indicados mediante el tipo de log enviando un
mensaje por cada línea, a no ser que se utilice la opción multiline.
© Universidad Internacional de La Rioja (UNIR)

Herramientas DevOps
27
Tema 8. Test