elastic.beats

ARCHIVIERT

Dieses Projekt wird nicht mehr gepflegt. Für alternative Startmöglichkeiten könnten Sie eine der folgenden Optionen ausprobieren:

ansible-beats

Build-Status Ansible Galaxy

Diese Rolle bietet eine allgemeine Möglichkeit zur Installation von Elastic unterstützten Beats.

Getestete Beats

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

Getestete Versionen

  • 7.x
  • 6.x

Getestete Plattformen

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

Verwendung

Erstellen Sie Ihr Ansible-Playbook mit Ihren eigenen Aufgaben und fügen Sie die Rolle beats hinzu. Sie müssen sicherstellen, dass dieses Repository im Kontext des Playbooks zugänglich ist.

ansible-galaxy install elastic.beats,v7.17.0

Erstellen Sie dann Ihre Playbook-YAML und fügen Sie die Rolle beats hinzu. Die Anwendung der Beats-Rolle führt zur Installation eines Nodes auf einem Host.

Die einfachste Konfiguration besteht also aus:

  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

Oben wird Filebeat 7.17.0 auf dem Host 'localhost' installiert.

Hinweise:

  • Die Standardversion von Beats ist in beats_version beschrieben. Sie können diese Variable in Ihrem Playbook überschreiben, um eine andere Version zu installieren. Während wir diese Rolle nur mit einer 7.x- und einer 6.x-Version (jeweils 7.17.0 und 6.8.23 zum Zeitpunkt des Schreibens getestet haben), sollte diese Rolle in den meisten Fällen auch mit anderen Versionen funktionieren.
  • Das Beat-Produkt wird in der Variable beat beschrieben. Während die derzeit getesteten Beats Filebeat, Metricbeat und Packetbeat sind, sollte diese Rolle in den meisten Fällen auch mit anderen Mitgliedern von The Beats Family funktionieren.

Tests

Dieses Playbook verwendet Kitchen für CI und lokale Tests.

Anforderungen

  • Ruby
  • Bundler
  • Docker
  • Make

Tests ausführen

Um einen Ubuntu 18.04-Host zu konvergieren

$ make converge

Um die Tests auszuführen

$ make verify

Um alle verschiedenen Test-Suiten aufzulisten

$ make list

Die Standard-Test-Suite ist Ubuntu 18.04. Wenn Sie eine andere Suite testen möchten, können Sie dies mit der Variable PATTERN überschreiben

$ make converge PATTERN=standard-centos-7

PATTERN ist ein Küchenmuster, das mehrere Suiten abgleichen kann. Um alle Tests für CentOS auszuführen

$ make converge PATTERN=centos-7

Wenn Sie mit dem Testen fertig sind, können Sie alles mit

$ make destroy-all

Grundlegende Beats-Konfiguration

Alle Beats-Konfigurationsparameter werden unterstützt. Dies wird mittels einer Konfigurations-Map-Parameter beat_conf erreicht, die in die Datei ${beat}.yml serialisiert wird. Die Verwendung einer Map gewährleistet, dass das Ansible-Playbook nicht aktualisiert werden muss, um neue/deprecated/Plugin-Konfigurationsparameter widerzuspiegeln.

Zusätzlich zur beat_conf-Map werden mehrere andere Parameter für zusätzliche Funktionen unterstützt, z.B. die Installation von Skripten. Diese finden Sie in der defaults/main.yml-Datei der Rolle.

Das folgende Beispiel zeigt die Anwendung von Konfigurationsparametern auf eine Packetbeat-Instanz.

- name: Beispiel-Playbook zur Installation von 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"

Weitere Konfiguration

Unterstützte Variablen sind:

  • beat (VERPFLICHTEND): Beat-Produkt. Unterstützte Werte sind: "filebeat", "metricbeat" & "packetbeat" (andere Beats aus The Beats Family sollten in den meisten Fällen funktionieren, sind aber derzeit nicht getestet).
  • beat_conf (VERPFLICHTEND): Beat-Konfiguration. Sollte als Map definiert werden.
  • beats_version (Standard auf 7.17.0): Beats-Version.
  • version_lock (Standard auf false): Sperrt die installierte Version, wenn auf true gesetzt, wodurch verhindert wird, dass andere Prozesse aktualisieren. Dies hat keinen Einfluss auf die Fähigkeit der Rollen, das Beat bei nachfolgenden Ausführungen zu aktualisieren (es wird entsperrt und erneut gesperrt, wenn erforderlich).
  • use_repository (Standard auf true): Verwendung des Elastic-Repositories für yum oder apt, wenn true. Wenn false, muss eine benutzerdefinierte custom_package_url bereitgestellt werden.
  • beats_add_repository (Standard auf {use_repository}): Installation des Elastic-Repositories für yum oder apt, wenn true. Wenn false, werden die vorhandenen Repositories verwendet. Nützlich, wenn Sie bereits Beats-Pakete in Ihrem Repository haben.
  • start_service (Standard auf true): Der Service wird gestartet, wenn true, andernfalls false.
  • restart_on_change (Standard auf true): Änderungen an Konfiguration oder installierten Versionen führen zu einem Neustart, wenn true.
  • daemon_args (Anwendbar auf Version 1.x von Beats): Ermöglicht es, zur Laufzeit Parameter an Beats zu übergeben.
  • logging_conf (Standard auf {"files":{"rotateeverybytes":10485760}}): Logging-Konfiguration. Sollte als Map definiert werden. Die Map wird in den Logging-Bereich der Beat-Konfiguration serialisiert.
  • shipper_conf (Anwendbar auf Version 1.x von Beats): Shipper-Konfiguration. Sollte als Map definiert werden. Die Map wird in den Shipper-Bereich der Beat-Konfiguration serialisiert.
  • output_conf (Standard auf {"elasticsearch":{"hosts":["localhost:9200"]}}): Ausgabe-konfiguration. Die Map wird in den Ausgabe-Bereich der Beat-Konfiguration serialisiert.
  • beats_pid_dir (Standard auf /var/run): Speicherort der Beats-PID-Datei.
  • beats_conf_dir (Standard auf /etc/{beat}): Speicherort des Konfigurationsverzeichnisses für die Beats-Konfigurationsdatei.
  • default_ilm_policy (Standard undefiniert): Lokaler Pfad zur Standardrichtlinie, falls eine benutzerdefinierte definiert ist.

Fokus auf ILM

Standardmäßig erstellt beat eine standardisierte Richtlinie, die Teil des bereitgestellten Beats ist. Sie können die standardmäßige ILM-Konfiguration überschreiben, indem Sie die ILM-Konfiguration als Teil von beat_conf definieren. Beispielsweise:

- 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

Dies kopiert conf/my-default-filebeat.json nach /etc/filebeat/policies/my-default-filebeat.json. Diese Richtlinie wird als Standardrichtlinie für dieses Beat verwendet.

Lizenz

Apache 2.0

Einschränkungen

Mehrere Instanzen des gleichen Beats können nicht auf demselben Zielserver installiert werden.

Fragen zur Nutzung

Wir begrüßen Fragen zur Nutzung der Rolle. Um die GitHub-Issues-Liste jedoch auf "Probleme" zu konzentrieren, bitten wir die Community, Fragen im Forum https://discuss.elastic.co/c/beats zu stellen. Dies wird von den Maintainer überwacht.

Gemeinschaftliche Beiträge werden immer geschätzt und sind willkommen! Bitte stellen Sie sicher, dass alle Beiträge geeignete Tests enthalten.

Installieren
ansible-galaxy install elastic.beats
Lizenz
other
Downloads
782.4k
Besitzer