Ich bin dabei, Elasticsearch und Kibana als zentralisierte Logging-Plattform in unserem Büro einzurichten.
Wir haben eine Reihe benutzerdefinierter Dienstprogramme und Plug-ins, denen ich die Verwendung von Benutzern nachverfolgen möchte und bei denen Fehler auftreten. Ganz zu schweigen von Servern und geplanten Jobs, die ich auch verfolgen möchte.
Wenn ich also mehrere verschiedene Quellen für Protokolldaten habe, die alle zum selben ElasticSearch-Cluster gehen, welche Konventionen oder Best Practices dafür, wie diese in Indizes und Dokumenttypen organisiert sind?
Der von Logstash verwendete Standardindexwert ist "logstash-%{+YYYY.MM.dd}" . Daher scheint es am besten zu sein, Indexnamen mit dem aktuellen Datum zu versehen, da dies das Löschen alter Daten vereinfacht.
Kibana erlaubt jedoch das Hinzufügen mehrerer "Indexmuster", die in der Benutzeroberfläche ausgewählt werden können. Aber alle Tutorials, die ich gelesen habe, erwähnen nur das Erstellen eines einzelnen Musters wie logstash-* .
Wie werden mehrere Indexmuster in der Praxis verwendet? Würde ich nur Namen für alle Quellen meiner Daten angeben? Wie:
%Vor%Ich verwende nLog in einer Reihe meiner Tools, die ein elastisches Suchziel . Die Konvention für nLog und andere ähnliche Logging-Frameworks besteht darin, für jede Klasse im Quellcode einen "Logger" zu haben. Sollten diese Logger zu Indizes in der elastischen Suche übersetzen?
%Vor%Oder ist das zu granular für ElasticSearch-Indexnamen, und es wäre besser, sich nur an einen einzelnen datierten Index für die Anwendung zu halten?
%Vor%In meiner Umgebung arbeiten wir eine ähnliche Frage durch. Wir haben eine Mischung aus Systemprotokollen, metrischen Alarmen von Prometheus und Anwendungsprotokollen von Client- und Serveranwendungen. Außerdem haben wir einige gemeinsam genutzte Variablen zwischen den Client- und Server-Apps, die uns die beiden korrelieren lassen (z. B. wissen wir, welche Serverprotokolle mit einem Vorgang auf dem Client übereinstimmen, der Anforderungen an den Server gestellt hat). Wir experimentieren mit dem folgenden Schema, um Kibana bei der Beantwortung von Fragen zu helfen:
%Vor%Wo:
{applicationName} ist der eindeutige Name einer Anwendung, die wir geschrieben haben (dies könnte Client- oder Server-Seite sein) {date} ist ein beliebiges datenbasiertes Schema, das Sie für Indizes Auf diese Weise können wir Kibana-Suchen gegen logs-app- * einrichten und schnell nach Protokollen in allen unseren Anwendungen suchen. Das ist noch neu für uns, aber wir haben ohne diese Art von Schema begonnen und bedauern es bereits. Es macht die Suche nach korrelierten Logs über Anwendungen hinweg viel schwieriger als es sein sollte.
Ich bin mir dieser Konventionen nicht bewusst, aber für meine Umgebung haben wir abhängig vom Schweregrad zwei verschiedene Arten von Indizes erstellt: logstash-* und logstash-shortlived-* . In meinem Fall erstelle ich das Indexmuster logstash-* , da es beide Arten von Indizes erfüllt.
Da diese Indizes bei Elasticsearch gespeichert werden und Kibana sie lesen wird, sollte es Ihnen die Möglichkeit geben, die Indizes verschiedener Muster zu erstellen.
Probieren Sie es auf Ihrem lokalen Rechner aus. Warum probierst du logstash-XYZ nicht, wenn du mehr Granularität willst, sonst kannst du immer Indizes mit deinem benutzerdefinierten Namen erstellen.
In meiner Firma haben wir viel über dieses Thema gearbeitet. Wir stimmen der folgenden Konvention zu:
In jedem Fall ist es notwendig, sowohl zu überprüfen, wie die Daten organisiert sind als auch, wie die Daten innerhalb der Organisation abgerufen werden.
Mit freundlichen Grüßen
Dario Rodriguez
Tags und Links elasticsearch kibana kibana-4 elk-stack