ARCHIVADO

Este proyecto ya no se mantiene. Para experiencias alternativas de inicio, puedes probar una de estas opciones:

• Comienza una prueba gratuita en Elastic Cloud, nuestro servicio alojado.
• Echa un vistazo a Elastic Cloud en Kubernetes (ECK) para lanzar la pila a través de Kubernetes.
• Lee nuestra guía Ejecutando la Elastic Stack en Docker.
• Revisa el proveedor Terraform de Elastic Stack.

ansible-beats

Este rol proporciona un medio genérico para instalar Beats soportados por Elastic.

Beats probados

• Filebeat
• MetricBeat (TopBeat en 1.x)
• Packetbeat

Versiones probadas

• 7.x
• 6.x

Plataformas probadas

• Ubuntu 16.04
• Ubuntu 18.04
• Ubuntu 20.04
• Debian 8
• Debian 9
• Debian 10
• CentOS 7
• Amazon Linux 2

Uso

Crea tu playbook de Ansible con tus propias tareas e incluye el rol beats. Tendrás que tener este repositorio accesible dentro del contexto del playbook.

ansible-galaxy install elastic.beats,v7.17.0

Luego crea tu archivo yaml de playbook añadiendo el rol beats. La aplicación del rol beats resulta en la instalación de un nodo en un host.

La configuración más simple consiste en:

  hosts: localhost
  roles:
    - role: elastic.beats
  vars:
    beats_version: 7.17.0
    beat: filebeat
    beat_conf:
      filebeat:
        inputs:
          - type: log
            enabled: true
            paths:
              - /var/log/*.log

Lo anterior instala Filebeat 7.17.0 en el host 'localhost'.

Notas:

• La versión predeterminada de beats se describe en beats_version. Puedes sobrescribir esta variable en tu playbook para instalar otra versión. Aunque estamos probando este rol solo con una versión 7.x y una 6.x (respectivamente 7.17.0 y 6.8.23 en el momento de escribir), este rol debería funcionar con otras versiones también en la mayoría de los casos.
• El producto beat se describe en la variable beat. Aunque los Beats probados actualmente son Filebeat, Metricbeat y Packetbeat, este rol también debería funcionar con otros miembros de La Familia Beats en la mayoría de los casos.

Pruebas

Este playbook usa Kitchen para CI y pruebas locales.

Requisitos

• Ruby
• Bundler
• Docker
• Make

Ejecutando las pruebas

Para converger un host Ubuntu 18.04

$ make converge

Para ejecutar las pruebas

$ make verify

Para listar todos los diferentes conjuntos de pruebas

$ make list

El conjunto de pruebas predeterminado es Ubuntu 18.04. Si quieres probar otro conjunto, puedes sobrescribir esto con la variable PATTERN.

$ make converge PATTERN=standard-centos-7

El PATTERN es un patrón de cocina que puede coincidir con múltiples conjuntos. Para ejecutar todas las pruebas para CentOS:

$ make converge PATTERN=centos-7

Cuando termines de probar, puedes limpiar todo con:

$ make destroy-all

Configuración básica de Beats

Se admiten todos los parámetros de configuración de Beats. Esto se logra utilizando un mapa de configuración beat_conf que se serializa en el archivo ${beat}.yml. El uso de un mapa asegura que el playbook de Ansible no necesite ser actualizado para reflejar nuevos/parámetros de configuración obsoletos/plugin.

Además del mapa beat_conf, se admiten varios otros parámetros para funciones adicionales, p. ej., instalación de scripts. Estos se pueden encontrar en el archivo defaults/main.yml del rol.

Lo siguiente ilustra la aplicación de parámetros de configuración a la instancia de Packetbeat.

- name: Playbook de ejemplo para instalar packetbeat
  hosts: localhost
  roles:
    - { role: beats, beat: "packetbeat",
        beat_conf: {
          "interfaces": {"device":"any"},
          "protocols": {
            "dns": {
              "ports": [53],
              "include_authorities":true
            },
            "http": {
              "ports": [80, 8080, 8000, 5000, 8002]
            },
            "memcache": {
              "ports": [11211]
            },
            "mysql": {
              "ports": [3306]
            },
            "pgsql": {
              "ports": [5432]
            },
            "redis": {
              "ports": [6379]
            },
            "thrift": {
              "ports": [9090]
            },
            "mongodb": {
              "ports": [27017]
            }
          }
        },
        output_conf : {
          "elasticsearch": {
            "hosts": ["localhost:9200"]
          }
        }
    }
  vars:
    use_repository: "true"

Configuración adicional

Las variables soportadas son las siguientes:

• beat (OBLIGATORIO): Producto Beat. Los valores admitidos son: "filebeat", "metricbeat" y "packetbeat" (otros beats de La Familia Beats deberían funcionar en la mayoría de los casos, pero no se han probado actualmente).
• beat_conf (OBLIGATORIO): Configuración de Beat. Debe definirse como un mapa.
• beats_version (Predeterminado 7.17.0): Versión de Beats.
• version_lock (Predeterminado false): Bloquea la versión instalada si se establece en verdadero, evitando que otros procesos la actualicen. Esto no afectará la capacidad del rol para actualizar el beat en ejecuciones posteriores (se desbloquea y se vuelve a bloquear si es necesario).
• use_repository (Predeterminado true): Usa el repositorio de Elastic para yum o apt si es verdadero. Si es falso, se debe proporcionar un custom_package_url personalizado.
• beats_add_repository (Predeterminado {use_repository}): Instala el repositorio de Elastic para yum o apt si es verdadero. Si es falso, se usarán los repositorios actuales. Útil si ya tienes paquetes de beats en tu repositorio.
• start_service (Predeterminado true): El servicio se iniciará si es verdadero, falso en caso contrario.
• restart_on_change (Predeterminado true): Los cambios en la configuración o versiones instaladas resultarán en un reinicio si es verdadero.
• daemon_args (Aplicable a la versión 1.x de beats): Permite pasar parámetros de tiempo de ejecución a beats.
• logging_conf (Predeterminado {"files":{"rotateeverybytes":10485760}}): Configuración de registro. Debe definirse como un mapa. El mapa se serializa en la sección de registro de la configuración del beat.
• shipper_conf (Aplicable a la versión 1.x de beats): Configuración del transportador. Debe definirse como un mapa. El mapa se serializa en la sección del transportador de la configuración del beat.
• output_conf (Predeterminado {"elasticsearch":{"hosts":["localhost:9200"]}}): Configuración de salida. El mapa se serializa en la sección de salida de la configuración del beat.
• beats_pid_dir (Predeterminado /var/run): Ubicación del archivo pid de beats.
• beats_conf_dir (Predeterminado /etc/{beat}): Ubicación del directorio de configuración para el archivo de configuración de beats.
• default_ilm_policy (Predeterminado indefinido): Ruta local a la política predeterminada si se define alguna personalizada.

Enfoque en ILM

Por defecto, beat creará una política predeterminada definida como parte del beat que se está implementando. Puedes sobrescribir la configuración predeterminada de ILM definiendo la configuración de ILM como parte de beat_conf. Por ejemplo:

- role: ansible-beats
  beat: metricbeat
  beat_conf:
    setup:
      ilm:
        policy_file: /etc/filebeat/policies/my-default-metricbeat.json
        overwrite: true
      metricbeat.modules:
        ...
  default_ilm_policy: conf/my-default-metricbeat.json
  become: yes

Esto copiará conf/my-default-filebeat.json a /etc/filebeat/policies/my-default-filebeat.json. Esta política se usará como la predeterminada para este beat.

Licencia

Apache 2.0

Limitaciones

No se pueden instalar múltiples instancias del mismo beat en el mismo servidor objetivo.

Preguntas sobre el uso

Damos la bienvenida a preguntas sobre cómo usar el rol. Sin embargo, con el fin de mantener la lista de problemas de GitHub enfocada en "problemas", pedimos a la comunidad que plantee preguntas en https://discuss.elastic.co/c/beats. Esto es monitoreado por los mantenedores.

¡Las contribuciones de la comunidad son siempre apreciadas y bienvenidas! Asegúrate de que todas las contribuciones incluyan pruebas según sea apropiado.