ECK macht es einfach

Natives Elasticsearch auf Kubernetes

Dimitri Marx

©Shutterstock / Elnur

Vor nicht langer Zeit war es undenkbar, persistente Daten auf Kubernetes zu stellen. Kluge Ops-Teams hätten eher auf einen vergleichbaren Cloud-Service gesetzt und die Funktionalität für Simplizität und ein ruhiges Gewissen geopfert. In den letzten Jahren ist Kubernetes aber gereift und in Bereiche vorgestoßen, die zuvor nicht annähernd als geeignet für die Containerorchestrierung angesehen wurden.

Kubernetes hat an Stabilität und Funktionsumfang zugenommen und sich von einem Tool zu einer richtigen Plattform entwickelt. Eines der mächtigsten Features der letzten Releases ist die Kombination von Custom Resource Definitions (CRDs) und dem Operator Pattern.

Das Operator Pattern (oder einfach Operators) stellt ein sehr mächtiges Konzept dar, mit dem Softwareanbieter Betriebsmuster in Kubernetes abstrahieren können. Der Einsatz des Operator Patterns kann die notwendige Menge an Tools, Skripten und manueller Arbeit zum Betreiben komplexer Software massiv reduzieren. Operators erlauben es, innerhalb eines Dokuments – in einem sogenannten Kubernetes-Manifest – das gesamte Deployment zu beschreiben, nicht nur die Artefakte, die deployt werden. Auch wenn man eine Datenbank sehr schnell auf Kubernetes deployen kann, wenn man Helm oder ein Kubernetes-Manifest verwendet, ist es doch meist Aufgabe des Endnutzers, für Sicherheit, Back-ups und Nutzerverwaltung zu sorgen.

Im Gegensatz dazu können viele dieser Aufgaben in einem System, das via CRDs und Operators deployt wird, automatisiert und mit der Kubernetes Configuration Language definiert werden. Diese Herangehensweise macht es leichter, bestehende Cluster und deren Zustand bzw. Verhalten zu durchblicken, die Konfiguration zu zentralisieren und Best Practices bestimmter Anbieter anzuwenden. Obwohl das Operator Pattern noch relativ neu ist, wird es bereits bei vielen Anbietern (inkl. Elastic) eingesetzt, um einen Betrieb der eigenen Programme auf Kubernetes zu ermöglichen.


Für Fans von Elasticsearch und dem wachsenden Elastic Stack bietet sich so die Möglichkeit, die Vorteile der Standarddistribution nativ auf Kubernetes zu nutzen. Elastic hat hierfür kürzlich Elastic Cloud on Kubernetes (ECK) veröffentlicht, es soll zum offiziellen Weg werden, Elastic Cloud auf Kubernetes auszuführen. Ein recht großer Funktionsumfang ist im Operator bereits enthalten (Kasten: „Fünf Vorteile des nativen Betreibens von Elasticsearch auf Kubernetes via ECK“).

Fünf Vorteile des nativen Betreibens von Elasticsearch auf Kubernetes via ECK

  • Sicherheit von Beginn an: ECK [1] konfiguriert die Sicherheitseinstellungen, Node to Node TLS, Zertifikate und einen Defaultuser für jeden Cluster automatisch.

  • Kubernetes-native Elasticsearch-Ressourcen: Elasticsearch kann genau wie jede andere Kubernetes-Ressource genutzt werden. Es gibt keine Notwendigkeit, endlose Kubernetes Pods, Services und Secrets zu konfigurieren.

  • Best Practices von Elastic: ECK funktioniert im täglichen Elasticsearch-Betrieb nach den etablierten Prinzipien – von der Skalierung bis zum Versionswechsel.

  • Exklusive Elastic-Features: Zugang zu allen Funktionen von Elastic, inklusive Elastic SIEM [2], Observability [3], Logs [4], Infrastruktur [5] und mehr.

  • Fortschrittliche Topologie: Nutzer können die Vielseitigkeit der eigenen Kubernetes-Infrastruktur auf das Elasticsearch Deployment anwenden. So können etwa auch Hot-Warm-Cold-Architekturen [6] genutzt werden, um die Kosten zu reduzieren.

Bis vor Kurzem lief die Installation eines produktionsfertigen Elastic Stack ziemlich standardmäßig ab. Man erstellt ein Set von Masters, um den Cluster zu managen, dann werden Nodes hinzugefügt und konfiguriert, sie können verschiedene Rollen einnehmen. Je nach Automatisierung war das Management des Elastic Clusters sehr umfangreich, und eine gewisse Orchestrierung wurde nötig, um sicherzugehen, dass der Cluster aktiv und bereit für Traffic ist.

Das Erstellen einer produktionsfertigen Elastic-Umgebung ist nicht annähernd so kompliziert wie das anderer Enterprise-Software. Doch es ist komplex genug, dass ein gewisses Maß an Planung, Wissen, Automatisierung und Ressourcen unabdinglich ist, um dessen Bereitschaft zur Nutzung sicherzustellen. Mit ECK existiert eine gute Alternative für das Deployment von Elastic, mit der die Vorteile von Kubernetes und des Operator Patterns genutzt werden können. Auch wenn dies das generelle Cluster-Management nicht komplett obsolet macht, werden so einige Arbeitsschritte obsolet und einige Aufgaben erleichtert. Elemente wie Cluster-Upgrades, das Absichern des Clusters und dynamische Cluster-Skalierung sind in ECK out of the box verfügbar, Gleiches gilt für eine vereinfachte Automatisierung.

Als Beispiel einer ECK-Installation wollen wir einen produktionsreifen Elastic Stack auf einem existierenden Kubernetes Cluster installieren. Dieser kann entweder lokal via Minikube oder K3s erstellt werden, oder man deployt ihn auf einem verwalteten Cluster in der Cloud (etwa GCP oder EKS). Um zu starten, müssen wir die Custom Resource Definitions und die Operators auf dem Cluster installieren: kubectl apply -f https://download.elastic.co/downloads/eck/1.0.0-beta1/all-in-one.yaml. Der Befehl wendet alle Ressourcen an, aus denen sich die verschiedenen Komponenten-ECK zusammensetzen.

Jetzt haben wir die ECK-Komponenten installiert und können unsere Elastic-Konfiguration erstellen. In diesem Beispiel werden wir ein robustes Layout mit mehreren Mastern, separaten Daten-Nodes und dedizierten Ingress-Servern erstellen. Wir beginnen mit der Erstellung der Master-Nodes. Erstellen Sie eine neue Datei elastic.yaml und fügen den Code aus Listing 1 ein.


apiVersion: elasticsearch.k8s.elastic.co/v1beta1
kind: Elasticsearch
metadata:
  name: monitoring
  namespace: monitoring
spec:
  version: 7.4.0
  nodeSets:
  - name: master
    count: 1
    config:
      node.master: true
      node.data: false
      node.ingest: false
      node.store.allow_mmap: false
    resources:
          requests:
            memory: 4Gi
            cpu: 2
          limits:
            memory: 4Gi
            cpu: 2
    env:
      - name: ES_JAVA_OPTS
        value: "-Xms3g -Xmx3g"
    volumeClaimTemplates:
        - metadata:
            name: elasticsearch-data
          spec:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
            storageClassName: standard

Die ersten beiden Zeilen definieren, welches Kubernetes-API wir für die Erstellung der neuen Ressourcen verwenden werden; in diesem Fall ein API, das über das Elastic CRD und eine Ressourcenart von Elasticsearch bereitgestellt wird. Dieses Beispiel zeigt die Vorteile von CRDs als System zur Erweiterung von Kubernetes, das es Produkten erlaubt, Funktionalität in einem bestimmten Namespace hinzuzufügen.

Als Nächstes definieren wir einige Metadaten: Den Namen des Elastic Stack und den Namespace, in dem wir ihn erstellen werden. Das Hinzufügen eines Namespace ilft dabei, den ECK-Stack zu organisieren, sodass Sie Ihre Monitoring-Workload einfach von Ihren anderen Workloads trennen können. Das ermöglicht eine granularere Sicherheit innerhalb Ihres Kubernetes-Clusters. Wird der Namespace weggelassen, erstellt das ECK CRD alle Ressourcen im Standard-Namespace.

Wir kommen zum Kern der Konfiguration, der Spezifikation. Das ist im Wesentlichen der einzige Ort, an dem Konfigurationselemente für ECK-Komponenten abgelegt werden. In diesem Beispiel spezifizieren wir nodeSet:, eine Menge von Elastic Nodes, seien es Master, Daten oder Ingests. Es ist eine Option, die in die Nodeset-Konfiguration übertragen wird. Die Nodes werden generiert und der zu erstellenden Elastic-Konfiguration hinzugefügt. Für unsere Konfiguration setzen wir dieses spezielle Nodeset als Master Nodes ein und stellen sicher, dass wir drei haben. Das wird im Allgemeinen als Best Practice angesehen, da es (Quorum-basierte) Entscheidungsfindung innerhalb des Stacks ermöglicht. Im Allgemeinen sollten Sie immer eine ungerade Anzahl von Master Nodes haben.

Jetzt übermitteln wir die Konfigurationselemente. ECK unterstützt die meisten der gleichen Optionen wie Nicht-ECK-Installationen. Besonders hervorzuheben ist in diesem Beispiel die Option node.store.allow_mmap:. Dieses Konfigurationselement ist in manchen Fällen für Kubernetes-Nodes notwendig, die eine niedrige Kerneleinstellung für vm.max_map_count: besitzen. Diese Einstellung hat jedoch Auswirkungen auf die Leistung bei Stacks mit hohem Durchsatz, sodass sie nicht für stark ausgelastete Cluster empfohlen wird. Stattdessen sollte die Konfiguration aus Listing 2 zum Manifest innerhalb des Nodeset Trees hinzugefügt werden.


podTemplate:
  spec:
    initContainers:
    - name: sysctl
      securityContext:
        privileged: true
      command: ['sh', '-c', 'sysctl -w vm.max_map_count=262144']

Diese Einstellung gibt die Kerneloptionen an den darunterliegenden Node weiter. Sie setzt jedoch voraus, dass Sie in der Lage sind, privilegierte Container auszuführen. Da die Privilegierung keineswegs sicher ist, insbesondere auf hochsicheren Kubernetes-Clustern, lohnt es sich, bei der Planung Ihres Elastic ECK Rollouts zu prüfen, ob sie verfügbar ist.

Wir kehren zu Listing 1 zurück und schauen uns das Festlegen von Ressourcenzuweisungen auf verschiedenen Ebenen innerhalb des Stacks an. Werden diese Einstellungen nicht vorgenommen, verwendet das CRD die Standardeinstellungen, was die Gesamtleistung des Clusters erheblich beeinflussen kann.

Die ersten beiden Elemente in diesem Teil, resources: und env:, setzen die Limitierungen des Volumens der verschiedenen Ressourcen, die das Nodeset verbrauchen darf. In unserem Beispiel darf jeder unserer drei Master Nodes 4 GB RAM und zwei CPU-Kerne aus dem Kubernetes-Cluster nutzen. Ohne diese Konfiguration können die Elastic Instances ein weitaus größeres Volumen an Ressourcen verbrauchen, als Sie vielleicht wünschen, was das Planen von Arbeitslasten innerhalb des Clusters beeinträchtigen kann. env setzt eine Umgebungsvariable, um die Limitierung an die JVM zu übergeben. Ohne diese Einstellung sind die JVM-Optionen auf 1 GB RAM voreingestellt, d. h. unabhängig davon, wie viel Sie im Kubernetes-Cluster zulassen, kann die JVM sie nicht effektiv nutzen.

Schließlich richten wir das volumeclaimTemplate: ein. Es ist entscheidend, da es definiert, wie und wo die Daten für Elastic gespeichert werden. Standardmäßig setzt ECK einen Speicheranspruch von 1 GB innerhalb des Clusters. Diese Vorgabe stellt sicher, dass Daten von den Nodes getrennt gehalten werden, sodass die Informationen bei einem Node Replacement oder einer Löschung nicht verloren gehen. Er stellt jedoch nicht sicher, dass auf diesem Volumenanspruch genügend Platz oder Performance für eine Produktionslast vorhanden ist.

Stattdessen setzen wir, wie in diesem Beispiel, ein explizites volumeclaimTemplate: und verwenden eine storageClassName:-Einstellung, um sicherzustellen, dass der richtige Laufwerkstyp verwendet wird. Der Typ und die Größe des Laufwerks hängen von Ihrem Kubernetes-Anbieter ab. Meist wird ein Standard (plattenbasierte Speicherung oder langsame SSD) und eine Form von schnellerem Speicher (wie schnelle SSD oder auch exotischere schnelle Speicherung) angeboten. Auch hier ist die Abstimmung des Speichers auf die Workload einer der wichtigsten Aspekte von Elastic Deployments. ECK macht es leicht, den richtigen Speicher dem richtigen Node zur Verfügung zu stellen.

Nun, da wir unseren Master definiert haben, können wir einige Ingest Nodes definieren, indem wir die Konfiguration aus Listing 3 in unsere elastic.yaml-Datei hinzufügen.


- name: ingest
  count: 2
  config:
    node.master: false
    node.data: false
    node.ingest: true
    node.store.allow_mmap: false
  resources:
    limits:
      memory: 4Gi
      cpu: 4
  env:
    - name: ES_JAVA_OPTS
      value: "-Xms3g -Xmx3g"
  volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: ssd

Wie Sie erkennen können, sieht dies dem vorherigen Beispiel sehr ähnlich, da die gleiche CRD sie erstellt hat. In diesem Fall ändern wir drei Dinge, um dieses Nodeset für die Aufnahme bereit zu machen: count:, Grenzen für die cpu:-Limits und storageclassName:. Dieser Unterschied in den Einstellungen soll die besondere Rolle der Ingest Nodes berücksichtigen, da sie genug CPU zum Parsen eingehender Anfragen, eine schnelle Festplatte, um sie zu puffern, und kein Quorum benötigen.

Um unsere Daten-Nodes mit der gleichen Vorlage zu erstellen, fügen wir den Code aus Listing 4 in die Datei elastic.yaml ein.


- name: data
  count: 2
  config:
    node.master: false
    node.data: true
    node.ingest: true
    node.store.allow_mmap: false
  resources:
      limits:
        memory: 3Gi
        cpu: 4
  env:
    - name: ES_JAVA_OPTS
      value: "-Xms3g -Xmx3g"
  volumeClaimTemplates:
  - metadata:
      name: elasticsearch-data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: ssd

Auch hier haben wir einige kleinere Änderungen vorgenommen: die Anzahl auf vier Nodes geändert, die CPU auf vier Cores erhöht und eine große Menge an High-Speed-Disks konfiguriert.

Wir haben jetzt alles, was wir brauchen, um Elastic in unserem Kubernetes-Cluster einzusetzen. Zunächst ist es jedoch sinnvoll, auf das Konzept der Pod Affinity einzugehen. Dieses erlaubt es Kubernetes, die Pods so zu planen, dass sie entweder auf dem gleichen Node eingeplant werden oder, im Fall der Anti-Affinity, getrennt gehalten werden, wo immer es möglich ist. Diese Eigenschaft ist besonders relevant im Fall von Elastic, wo man bestimmte Nodes sowohl aus Performance- als auch aus Zuverlässigkeitsgründen auseinanderhalten möchte.

Das Scheduling ist besonders für die Master relevant, da der Ausfall eines Kubernetes Node mit mehreren Mastern die Funktionsfähigkeit des Elastic Stack gefährden kann. Standardmäßig legt ECK eine Standard-Policy der Pod Anti-Affinity für alle von ihm erstellten Ressourcen fest, um sicherzustellen, dass Kubernetes versucht, sie auseinanderzuhalten. Diese Voreinstellung ist in den meisten Fällen problemlos, kann aber bei Bedarf mit der üblichen Kubernetes-Konfiguration überschrieben werden: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity. Es ist erwähnenswert, dass man, um die Elastic-Komponenten korrekt getrennt zu halten, genügend Kubernetes Nodes benötigt, um dies zu unterstützen. Zum Beispiel braucht man bei drei Master-, zwei Daten- und zwei Ingest Nodes mindestens sieben Nodes, um sie getrennt zu halten, und diese Nodes müssen in der Lage sein, die Elastic Pods zu planen. Beim Ausführen des Stacks ist es sinnvoll, das Ausmaß der Co-Lokalisierung von Pods zu überwachen. Falls dies geschieht, sollte dem entweder durch das Festlegen von eindeutigen Richtlinien für die Anti-Affinity oder durch das Erhöhen der Anzahl der Kubernetes-Nodes entgegengewirkt werden.

ECK legt auch ein Standard-Pod-Disruption-Budget (pdb) für den Elastic Stack fest. Standardmäßig ist es auf 1 gesetzt, was bedeutet, dass immer nur ein Pod außer Betrieb sein kann. Diese Voreinstellung stellt sicher, dass Kubernetes bei der Umplanung der Elastic Pods versucht, diese auf jeweils einen Pod zu begrenzen. Diese Begrenzung ist bei der Aktualisierung des Stacks relevant, da sie sicherstellt, dass ein rolling Update erzwungen wird. Bei größeren Stapeln, bei denen mehr Pods gleichzeitig sicher außer Betrieb sein können, können Sie diese Grenze explizit höher setzen. Jetzt haben wir einige der Elemente, die ECK zur Gewährleistung der Stabilität hinzufügt, abgedeckt, sodass wir unseren Elastic Cluster einsetzen können: kubectl apply -f elastic.yaml. Das wendet die Konfiguration auf Ihren Cluster an. Innerhalb weniger Minuten sollten Sie einen neuen Cluster eingerichtet haben, was Sie mit dem folgenden Befehl überprüfen können: kubectl get pods -n elastic-cluster. Sie sollten Folgendes erhalten:

monitor-es-mdi-0                      1/1     Running   0          6m21s
monitor-es-mdi-1                      1/1     Running   0          6m21s
monitor-es-mdi-2                      1/1     Running   0          6m21s
monitor-kb-56bdd68b65-97wnz   1/1     Running   0          6m21s

Schließlich müssen wir Kibana zu unserer Installation hinzufügen. Kibana wird mit einem separaten CRD zum Elastic Cluster definiert. Fügen Sie den Code aus Listing 5 zu Ihrer elastic.yaml-Datei hinzu (oder sogar eine separate yaml-Datei, wenn Sie es vorziehen, sie getrennt zu halten).


apiVersion: kibana.k8s.elastic.co/v1beta1
kind: Kibana
metadata:
  name: monitoring
  namespace: monitoring
spec:
  version: 7.4.0
  count: 2
  elasticsearchRef:
    name: monitoring
  secureSettings:
    - secretName: kibana-enc-key

Das sollte Ihnen mittlerweile ziemlich bekannt vorkommen. Wie bei den Elastic-Komponenten beginnen wir damit, dass wir am Anfang des Dokuments erklären, dass wir die ECK CRDs verwenden, und fragen nach einem Ressourcentyp Kibana. Wie beim Elastic Stack geben wir ihm dann sowohl einen Namen als auch einen Namespace. Die Spezifikationsversion ist wieder sehr ähnlich. Hier geben wir die Version von Kibana an, die wir installieren möchten, plus die Anzahl der Nodes, die wir haben wollen. Da wir ein Production Deployment anstreben, sind zwei die minimale Anzahl, die wir benötigen, da sie einen kontinuierlichen Service ermöglicht, wenn ein Pod außer Betrieb ist (je nach Umfang und SLAs, unter denen Sie arbeiten, können sogar mehr als zwei gewünscht werden). Die Einführung mehrerer Nodes führt zu einem zusätzlichen manuellen Schritt, da jeder Node im Cluster den gleichen Encryption Key verwenden muss. Um ihn zu ergänzen, fügen Sie mit dem folgenden Terminalbefehl ein neues Secret zu Ihrem Kube Cluster hinzu:

kubectl create secret generic kibana-enc-key --from-
literal=xpack.security.encryptionKey=94d2263b1ead716ae228277049f19975aff8644b4fcfe429c95143c1e90938md

Der xpack.security.encryptionKey kann alles sein, was Sie möchten, solange er mindestens 32 Zeichen lang ist. Weitere Details zu dieser Einstellung finden sich im Bereich der Sicherheitseinstellungen in Kibana [7].

Jetzt haben wir einen Security Key festgelegt, wir können damit den Rest dieses Teils der Konfiguration abschließen. Das nächste Element, elasticsearchRef:, ist der Name des Elasticsearch Clusters, mit dem wir diese Kibana-Instanz verbinden wollen. Dies sollte so eingestellt werden, dass es mit name: übereinstimmt, der in den Metadaten des Elastic-Cluster-Dokuments eingestellt ist, in diesem Fall Monitoring. Schließlich teilen wir den Kibana-Instanzen mit, wo der Security Key zu finden ist, den wir mit dem vorherigen Terminalbefehl mit dem secureSettings-Key eingerichtet haben. Das definiert das Grundlayout unseres Kibana-Clusters. Allerdings sollten wir, ähnlich wie beim Elastic Stack, gewisse Bedingungen für die Ressourcennutzung festlegen. Es kann auch sein, dass wir den Kibana-Dienst über einen Load Balancer verfügbar machen wollen, entweder intern oder extern. Dazu fügen Sie das Code-Snippet aus Listing 6 zu Ihrer kibana.yaml-Datei hinzu.


config:
  console.enabled: false
podTemplate:
  spec:
    containers:
    - name: kibana
      resources:
        requests:
          memory: 1Gi
          cpu: 0.5
        limits:
          memory: 2Gi
          cpu: 2
http:
  service:
    spec:
      type: LoadBalancer
  tls:
    selfSignedCertificate:
      subjectAltNames:
      - dns: monitoring.example.com

Dieser Code gibt unserem Kibana Cluster den letzten Schliff. Zu Beginn fügen wir ein Konfigurationselement hinzu, das an Kibana übergeben wird. Diese spezielle Einstellung console.enabled: schaltet die Entwicklerkonsole in Kibana aus und kann in sichereren Einstellungen wünschenswert sein. Der nächste Teil des Dokuments (podTemplate) ist im Wesentlichen das Gleiche wie das, was wir im Elastic Cluster einstellen, und definiert, wie viele Ressourcen Kibana mindestens benötigt. Die http:-Einstellung ist der Ort, an dem wir den Benutzern unseren Kibana-Cluster präsentieren können, ohne dass sie einen Kube Proxy oder andere, eher manuelle Methoden verwenden müssen, um in das Kubernetes-Cluster-Netzwerk zu gelangen. Das erlaubt uns, zwei wichtige Elemente zu definieren: die Art und Weise, wie der Kubernetes-Dienst definiert wird, und zusätzliche DNS-Namen innerhalb des generierten Zertifikats. Standardmäßig erstellt das ECK CRD Dienste als NodePorts. Das stellt sicher, dass der Zugriff nur von innerhalb des Clusters kommen kann, und bedeutet im Allgemeinen, dass Sie sich in den jeweiligen Node einloggen müssen, um Kibana zu sehen. Durch das Überschreiben dieser Vorgabe zu einem LoadBalancer-Typ wird der Dienst von außerhalb des Clusters zugänglich gemacht. Die letzte Einstellung tls: ermöglicht es, den vom Dienst erstellten Zertifikaten zusätzliche DNS-Namen hinzuzufügen. Das sollte etwaige Zertifikatsfehler bei der externen Verbindung verhindern.

Wenn Sie mit den Einstellungen zufrieden sind, speichern und wenden Sie diese mit dem Befehl kubectl -f kibana.yaml an. Dadurch werden die Einstellungen auf Ihren Kubernetes Cluster angewendet. Wenn Sie keinen Load Balancer verwendet haben, sollten Sie innerhalb weniger Minuten in der Lage sein, sich mittels eines Kube-Proxys mit dem Nodeport zu verbinden. Oder mit der Load-Balancer-Adresse, wenn Sie den Kibana-Log-in-Bildschirm angezeigt bekommen. Um sich einzuloggen, benutzen Sie den Benutzernamen von Elastic und rufen mit folgendem Terminalbefehl das automatisch gesetzte Passwort ab: kubectl get secret -n monitoring monitoring-es-elastic-user -o=jsonpath='{.data.admin-password}‘ | base64 –decode; echo. Beachten Sie besonders -n, um sicherzugehen, den richtigen Namespace anzuwählen, der in der Cluster-Erstellung generiert wurde. Das sollte Ihnen ein Passwort liefern, um sich in Kibana einzuloggen.

Hoffentlich haben Sie jetzt einen laufenden, produktionsbereiten Elastic Cluster mit einer Kibana-Konsole, mit der Sie ihn abfragen können. Dieser Artikel hat die Benutzerfreundlichkeit und Leistungsfähigkeit des ECK-Produkts untersucht und gezeigt, wo es konfiguriert werden kann, um es widerstandsfähig und bereit für Benutzer zu machen. In einem nächsten Artikel werden wir untersuchen, wie wir mit Hilfe von Metricbeat und Filebeat Daten in unserem neuen Cluster bekommen können.

Geschrieben von
Dimitri Marx
Dimitri Marx
Dimitri Marx ist Solutions Architect bei Elastic. Er hat Informatik studiert und arbeitet seit seinem Abschluss an Open-Source-Projekten. Dimitri unterstützt Kunden dabei, den Wert von Suchtechnologien zu verstehen und wie man diese im Enterprise-Kontext einsetzen kann. Logging, Security und Analysemetriken gehören zu seinen Tätigkeitsfeldern, genau wie die Lösung der größten Herausforderungen auf dem Gebiet der strukturierten und unstrukturierten Daten.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: