Pinging @ elastic / kibana-Plattform

39288 Scheint mit dem gleichen Problem konfrontiert zu sein

Und noch ein Blogbeitrag:
https://discuss.elastic.co/t/not-possible-to-create-index-patterns-in-kibana/185591/2

Wo der Benutzer es entweder behoben durch:

• Setzen Sie fielddata = true manuell in das Typfeld des Index ".kibana"
• Manuelles Bearbeiten der Elasticsearch-Zuordnung für Kibana und erneutes Laden des .kibana-Index

Ich habe wieder ein anderes Cluster (4.) Problem erstellt

Ich habe versucht, Kibana zu stoppen, den .kibana-Index zu löschen und Kibana erneut zu starten. Hier sind die elastischen Protokolle:

• Index löschen

[2019-07-03T03:02:16,659][INFO ][o.e.c.m.MetaDataDeleteIndexService] [elastic01]
[.kibana/1Z8-n6nCSza4pm2HXtWG_Q] deleting index

• Kibana starten

[2019-07-03T03:03:15,155][INFO ][o.e.c.m.MetaDataIndexTemplateService] [elastic01]
 adding template [.management-beats] for index patterns [.management-beats]

[2019-07-03T03:03:15,820][INFO ][o.e.c.m.MetaDataCreateIndexService] [elastic01] 
[.kibana] creating index, cause [auto(bulk api)], templates [], shards [1]/[1], mappings []

[2019-07-03T03:03:15,944][INFO ][o.e.c.m.MetaDataMappingService] [elastic01] 
[.kibana/x0ymkiGpRxWJA_rMJ-T3Nw] create_mapping [_doc]

[2019-07-03T03:03:15,945][INFO ][o.e.c.m.MetaDataMappingService] [elastic01] 
[.kibana/x0ymkiGpRxWJA_rMJ-T3Nw] update_mapping [_doc]

[2019-07-03T03:03:16,021][INFO ][o.e.c.r.a.AllocationService] [elastic01] 
Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[.kibana][0]] ...]).

[2019-07-03T03:03:37,218][INFO ][o.e.c.m.MetaDataMappingService] [elastic01]
[.kibana/x0ymkiGpRxWJA_rMJ-T3Nw] update_mapping [_doc]

[2019-07-03T03:03:55,567][DEBUG][o.e.a.s.TransportSearchAction] [elastic01] [.kibana][0],
node[UKPhnQePR6-3EJMobt8mbw], [R], s[STARTED], a[id=oVInWbneRLicfKSIqL_uwA]: 
Failed to execute [SearchRequest{searchType=QUERY_THEN_FETCH, indices=[.kibana], 
indicesOptions=IndicesOptions[ignore_unavailable=false, allow_no_indices=true, 
expand_wildcards_open=true, expand_wildcards_closed=false, allow_aliases_to_multiple_indices=true, 
forbid_closed_indices=true, ignore_aliases=false, ignore_throttled=true], types=[], routing='null', 
preference='null', requestCache=null, scroll=null, maxConcurrentShardRequests=0, 
batchedReduceSize=512, preFilterShardSize=128, allowPartialSearchResults=true, localClusterAlias=null,
getOrCreateAbsoluteStartMillis=-1, ccsMinimizeRoundtrips=true, source={"from":0,"size":20,"query":
{"bool":{"filter":[{"bool":{"should":[{"bool":{"must":[{"term":{"type":{"value":"index-
pattern","boost":1.0}}}],"must_not":[{"exists":
{"field":"namespace","boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},{"bool":{"must":[{"term":
{"type":{"value":"visualization","boost":1.0}}}],"must_not":[{"exists":
{"field":"namespace","boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},{"bool":{"must":[{"term":
{"type":{"value":"dashboard","boost":1.0}}}],"must_not":[{"exists":
{"field":"namespace","boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},{"bool":{"must":[{"term":
{"type":{"value":"search","boost":1.0}}}],"must_not":[{"exists":
{"field":"namespace","boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}}],"adjust_pure_negative":true,"
minimum_should_match":"1","boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"seq_no_primary_ter
m":true,"_source":{"includes":["index-pattern","visualization","dashboard","search.title","index-
pattern","visualization","dashboard","search.id","namespace","type","references","migrationVersion",
"updated_at","title","id"],"excludes":[]},"sort":[{"type":
{"order":"asc","unmapped_type":"keyword"}}],"track_total_hits":2147483647}}]

org.elasticsearch.transport.RemoteTransportException: [elastic03][x.x.x.x:9300]
[indices:data/read/search[phase/query]]

Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default.
Set fielddata=true on [type] in order to load fielddata in memory by uninverting the inverted index.
Note that this can however use significant memory. Alternatively use a keyword field instead.

Bearbeiten:
Ich habe einen weiteren Cluster (5.) erstellt (dasselbe Skript von scatch, einschließlich VM-Erstellung) und diesmal keinen Fehler: Denken: Ich werde versuchen zu sehen, ob ein Wahlproblem dies verursachen kann.

Bearbeiten 2:
Cluster Nr. 6 hatte das Problem erneut (dasselbe Skript von scatch, einschließlich VM-Erstellung)

Auf Knoten 3 sehe ich interessante Protokolle:

Der Knoten hatte einige Fehler beim ersten Versuch bei der Hauptwahl / beim Beitritt, konnte dies jedoch weiterhin tun und booten. Anschließend meldete der Knoten einen Fehler beim Erstellen des .kibana-Indexalias:

Ich habe die Knoten-ID / {ml.machine_memory = ...., xpack.installed = true} aus den Protokollen entfernt, um Rauschen zu beseitigen und die Lesbarkeit zu verbessern

[2019-07-03T03:57:29,167][INFO ][o.e.c.c.JoinHelper] [elastic03] 
failed to join {elastic01} {x.x.x.x}{x.x.x.x:9300}
with JoinRequest{sourceNode={elastic03}{y.y.y.y} {y.y.y.y:9300}, 
optionalJoin=Optional[Join{term=1, lastAcceptedTerm=0, lastAcceptedVersion=0, sourceNode=
{elastic03}{y.y.y.y}{y.y.y.y:9300}, targetNode={elastic01}{x.x.x.x}{x.x.x.x:9300}}]}

org.elasticsearch.transport.NodeNotConnectedException: [elastic01][x.x.x.x:9300] Node not connected
        at org.elasticsearch.transport.ConnectionManager.getConnection(ConnectionManager.java:151) 
        ....

[2019-07-03T03:57:29,179][INFO ][o.e.c.c.Coordinator] [elastic03] 
setting initial configuration to VotingConfiguration{ID elastic01 ,{bootstrap-
placeholder}-elastic02,ID elastic03}

[2019-07-03T03:57:29,180][INFO ][o.e.c.c.JoinHelper] [elastic03] 
failed to join {elastic01}{x.x.x.x}{x.x.x.x:9300} 
with JoinRequest{sourceNode={elastic03}{y.y.y.y}{y.y.y.y:9300}, 
optionalJoin=Optional[Join{term=1, lastAcceptedTerm=0, lastAcceptedVersion=0, sourceNode=
{elastic03}{y.y.y.y}{y.y.y.y:9300}, targetNode={elastic01}{x.x.x.x}{x.x.x.x:9300}}]}

org.elasticsearch.transport.NodeNotConnectedException: [elastic01][x.x.x.x:9300] Node not connected
        at org.elasticsearch.transport.ConnectionManager.getConnection(ConnectionManager.java:151) 
        ....

[2019-07-03T03:57:29,318][INFO ][o.e.c.s.MasterService] [elastic03] 
elected-as-master ([2] nodes joined)[{elastic03}{y.y.y.y}{y.y.y.y:9300} elect leader,
{elastic01}{x.x.x.x}{x.x.x.x:9300} elect leader,
 _BECOME_MASTER_TASK_, _FINISH_ELECTION_], term: 2, version: 1, reason: master node changed
{previous [], current [{elastic03}{y.y.y.y}{y.y.y.y:9300}}]}, added {{elastic01}{x.x.x.x}{x.x.x.x:9300},}

[2019-07-03T03:57:29,410][INFO ][o.e.c.c.CoordinationState] [elastic03]
 cluster UUID set to [oQs2zr6XTM6spzQSvJ079w]

[2019-07-03T03:57:29,463][INFO ][o.e.c.s.ClusterApplierService] [elastic03]
 master node changed {previous [], current [{elastic03}{y.y.y.y}{y.y.y.y:9300}]}, 
added {{elastic01}{x.x.x.x}{x.x.x.x:9300},}, term: 2, version: 1, reason: Publication{term=2, version=1}

[2019-07-03T03:57:29,538][INFO ][o.e.h.AbstractHttpServerTransport] [elastic03]
publish_address {y.y.y.y:9200}, bound_addresses {[::1]:9200}, {127.0.0.1:9200}, {y.y.y.y:9200}

[2019-07-03T03:57:29,539][INFO ][o.e.n.Node] [elastic03] 
started

[2019-07-03T03:57:29,559][WARN ][o.e.x.s.a.s.m.NativeRoleMappingStore] [elastic03]
 Failed to clear cache for realms [[]]

[2019-07-03T03:57:29,618][INFO ][o.e.g.GatewayService] [elastic03] 
recovered [0] indices into cluster_state

...

[2019-07-03T03:57:30,255][INFO ][o.e.c.s.MasterService] [elastic03] 
node-join[{elastic02}{z.z.z.z}{z.z.z.z:9300} join existing leader], term: 2, version: 8, reason: added
{{elastic02}{z.z.z.z}{z.z.z.z:9300},}

[2019-07-03T03:57:30,543][INFO ][o.e.c.s.ClusterApplierService] [elastic03] 
added {{elastic02}{z.z.z.z}{z.z.z.z:9300},}, term: 2, version: 8, reason: Publication{term=2, version=8}

[2019-07-03T03:57:30,749][INFO ][o.e.l.LicenseService] [elastic03] 
license [] mode [basic] - valid

Der Cluster ist jetzt gebootet, aber .kibana gibt einen Fehler aus:

[2019-07-03T03:57:52,002][INFO ][o.e.c.m.MetaDataCreateIndexService] [elastic03]
 [.kibana_task_manager] creating index, cause [auto(bulk api)], templates [.kibana_task_manager], shards
[1]/[1], mappings [_doc]

[2019-07-03T03:57:53,018][INFO ][o.e.c.m.MetaDataCreateIndexService] [elastic03] 
[.kibana_1] creating index, cause [api], templates [], shards [1]/[1], mappings [_doc]

[2019-07-03T03:57:53,279][INFO ][o.e.c.m.MetaDataCreateIndexService] [elastic03]
 [.kibana] creating index, cause [auto(bulk api)], templates [], shards [1]/[1], mappings []

[2019-07-03T03:57:53,382][DEBUG][o.e.a.a.i.a.TransportIndicesAliasesAction] [elastic03]
 failed to perform aliases

org.elasticsearch.indices.InvalidAliasNameException: Invalid alias name [.kibana], 
an index exists with the same name as the alias
        at org.elasticsearch.cluster.metadata.AliasValidator.validateAlias(AliasValidator.java:93) 
       ...

@tbuchier vielen Dank für den detaillierten Fehlerbericht!

Ich möchte nur bestätigen, dass Sie einen Cluster von 3 ES-Knoten haben. Wie viele Kibana-Knoten führen Sie aus oder ist es nur ein einziger?

Wir booten den Cluster basierend auf einem goldenen Image mit Kibana + Elastic

Also 3 Kibana laufen (wir können einen deaktivieren und 2 für HA / Lastausgleich später behalten).

Der Datenordner von Elastic wird vor der Instanziierung vollständig bereinigt (für einen korrekten Bootstrap).
Aber vielleicht nicht die / var / lib / kibana, die die UUID enthält, so dass sie möglicherweise dieselbe haben. Aber es sollte nur die Überwachung beeinflussen, oder?

Könnten Sie die Protokolle aller drei Kibana-Instanzen für einen Cluster veröffentlichen, der sich in diesem Fehlerzustand befindet?

Ich werde erst am Montag Zugang zum env haben.
Ich erinnere mich, dass nichts protokolliert wurde (wie ich logging.quiet: true)
Ich werde Kibana Log Montag veröffentlichen.

Ich habe 3 andere Themen in elastischen Foren mit Benutzern gefunden, bei denen das gleiche Problem zu bestehen scheint:

Alle mit 7+ stecken in der unendlichen Erstellung von Indexmustern über die Benutzeroberfläche fest, da die Benutzeroberfläche das im Index gespeicherte Objekt nicht finden kann

https://discuss.elastic.co/t/created-index-pattern-is-not-visible-in-kibana-7-0-1/184098/

https://discuss.elastic.co/t/i-cant-create-indexes-patterns-with-eck/184194/

https://discuss.elastic.co/t/kibana-7-0-1-wont-lad-index-pattern/187934/

Es scheint, als ob eine Art Rennbedingung dazu führt, dass der .kibana-Index eine Zuordnung von {"type": {"type": "text"}} anstelle von {"type": {"type": "keyword"}}

Ich habe zahlreiche Versuche unternommen, einen ES + Kibana-Cluster mit 3 Knoten auf meinem lokalen Computer zu erstellen, konnte jedoch die Zuordnungen für die Eigenschaft "type", die auf "text" gesetzt ist, nicht reproduzieren.

Ich kann bestätigen, dass das manuelle Erstellen eines Mappings mit {"type": {"type": "text"}} die hier beschriebenen Symptome und die verknüpften Diskussionsthreads wie den Fehler "Felddaten sind standardmäßig für Textfelder deaktiviert" hervorruft.

Vielen Dank für die ausführliche Debugging-Hilfe @tbuchier! Lesen Sie den Kibana-Server in einer Schleife, um herauszufinden, ob er in Ihrem Skript gestartet wurde.

Ich habe das schon einmal gesehen und der Zufallsfaktor impliziert für mich, dass es sich um eine Art Rennbedingung handelt, aber was könnte Rennen sein? Ich gehe davon aus, dass es sich um den Abschluss der Migration handelt, der gegen eine Anfrage auf dem Kibana-Server antritt, der (wenn die Sicherheit aktiviert ist) versucht, den Dienst uiSettings zu laden, der das konfigurierte gespeicherte Objekt vor dem automatisch erstellt. Der Kibana-Index wird tatsächlich erstellt, wodurch der Index erstellt wird, indem die Eingabe automatisch zugeordnet und {"type": "text"} für das Feld type wird ...

Dies war früher nicht möglich, da wir erst nach Abschluss der Migrationen HTTP-Anforderungen akzeptiert haben. Mit dem Übergang zur neuen Plattform hat sich die Reihenfolge der Vorgänge jedoch geringfügig geändert, und jetzt werden die Migrationen nach dem Start von HTTP ausgeführt Routen können ausgelöst werden, bevor der savedObjects -Dienst tatsächlich verwendet werden kann, was möglicherweise zu zeitlichen Problemen führen kann.

Bearbeiten: Eine Möglichkeit, dies zu überprüfen, besteht darin, die Zuordnung und die Dokumente im .kibana-Index abzulegen, wenn dieser Fehler auftritt. Wenn der Index nichts von einem Konfigurationsdokument enthält, bin ich mir ziemlich sicher, dass dies der Fall ist.

Ich konnte dieses Problem in der 7.1.1-Umgebung reproduzieren. Clusterdetails:

• Elasticsearch 7.1.1 mit 6 Datenknoten + 3 dedizierten Mastern + 2 nur koordinierenden Knoten
• Kibana 7.1.1 ist so konfiguriert, dass es nur mit 2 koordinierenden Knoten kommuniziert (Einstellung elasticsearch.hosts). Kibana hat 4 Felder.
• Die Sicherheit ist im Cluster mit dem nativen und dem LDAP-Authentifizierungsbereich aktiviert. SSL ist sowohl für TCP als auch für HTTP im Elasticsearch-Cluster sowie in Kibana konfiguriert.

Dieses Problem trat zum ersten Mal auf, als wir aufgrund eines Hardwarefehlers alle Elasticsearch-Knoten stoppen mussten (Kibana wurde jedoch nicht gestoppt). Löschen Sie alle Inhalte im Datenverzeichnis aller Elasticserch-Knoten. Alle Elasticsearch-Knoten wurden erneut gestartet. Kibana wurde während des vollständigen Cluster-Neustarts nicht gestoppt.

Wir konnten dieses Problem reproduzieren, indem wir den Index .kibana* löschten, ohne den Kibana-Dienst zu beenden.

Um dieses Problem zu beheben, haben wir die folgenden Schritte ausgeführt:

• Kibana-Dienst herunterfahren
  -Gelöschte .kibana * -Indizes. Wir haben beschlossen, .kibana * -Indizes zu löschen, da die .kibana-Indizes keine Daten enthielten.
• Kibana-Dienst gestartet.

Hallo !!

Ich habe heute Morgen Cluster hervorgebracht, bis ich mich erneut dem Problem stellte (dem dritten):

@ Rudolf
Für die Kibana-Protokolle: Es scheint tatsächlich ein Rassenproblem zu sein:

kibana_1 und kibana_2 werden erstellt. Auf Kibana 1 habe ich einen Fehler bezüglich:

Ungültiger Aliasname [.kibana], ein Index existiert mit demselben Namen wie der Alias

und alle Kibana haben:

Eine andere Kibana-Instanz scheint den Index zu migrieren. Warten auf den Abschluss dieser Migration.

kibanalog.txt

@spalger
Für das .kibana-Mapping: Es scheint tatsächlich leer zu sein:

Mapping_Kibana.txt

Mapping_Kibana_1.txt

Mapping_Kibana_2.txt

Bearbeiten: Der von @ navneet83 erwähnte Schritt:

• alle Kibana stoppen
• Löschen des Index .kibana, .kibana_1, .kibana_2
• Dann erst 1 Kibana starten
  Beheben Sie das Problem.

Um dies in unserem Skript zu beheben, aktivieren wir nur 1 Kibana beim Bootstrap. Sobald .kibana_1 erfolgreich erstellt wurde, startet das Skript die anderen Instanzen.

@tbuchier Ich konnte das Problem reproduzieren und es ist in der Tat so, wie Spalger eine Rennbedingung mit dem Migrationssystem erraten hat. Wir blockieren alle Vorgänge gegen Elasticsearch, bis die Initialisierung der Indizes und Migrationen abgeschlossen ist. Durch einen logischen Fehler konnten Vorgänge fortgesetzt werden, auch wenn die Initialisierung und Migration noch nicht abgeschlossen war. Dies führte dazu, dass einige Plugins in den Index .kibana schrieben und Elasticsearch automatisch einen Index mit falschen Zuordnungen erstellte.

Die gute Nachricht ist, dass dies in 7.2.0 behoben und veröffentlicht wurde (https://github.com/elastic/kibana/pull/37674).

Vielen Dank für Ihre Hilfe beim Debuggen und für die Verknüpfung aller Diskussionsthemen mit diesem Problem!

@rudolf Hallo, ich bin auch in 7.2.0 mit diesem Problem konfrontiert. Kibana fragt wiederholt nach dem Indexmuster und es log gibt einen Felddatenfehler aus.
"Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default. Set fielddata=true on [process.name] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead.", "at org.elasticsearch.index.mapper.TextFieldMapper$TextFieldType.fielddataBuilder(TextFieldMapper.java:711) ~[elasticsearch-7.2.0.jar:7.2.0]", "at org.elasticsearch.index.fielddata.IndexFieldDataService.getForField(IndexFieldDataService.java:116) ~[elasticsearch-7.2.0.jar:7.2.0]",

@ ntsh999 Wir verwenden github nur für reproduzierbare Fehlerberichte. Wenn Sie dieses Verhalten unter 7.2 reproduzieren können, öffnen Sie bitte ein neues Problem auf github und teilen Sie die Schritte mit. Wenn Sie jedoch Hilfe suchen, beginnen Sie bitte ein neues Thema in unseren Diskussionsforen https://discuss.elastic.co/. Bitte fügen Sie alle Protokolle von elasticsearch und kibana sowie alle anderen relevanten Informationen bei, z. B. wie Sie das erstellt haben Cluster und wenn Sie Upgrades von früheren Versionen des ELK-Stacks durchgeführt haben.

Für diejenigen, die diesen Thread finden, was ich in meinem Cluster getan habe, damit er funktioniert:

1. Löschen Sie den Kibana-Index
2. Erstellen Sie es mit der richtigen Zuordnung neu

PUT /.kibana
{                                                            

    "aliases": {},
    "mappings": {
      "properties": {
        "config": {
          "properties": {
            "buildNum": {
              "type": "long"
            }
          }
        },
        "index-pattern": {
          "properties": {
            "fields": {
              "type": "text",
              "fields": {
                "keyword": {
                  "type": "keyword",
                  "ignore_above": 256
                }
              }
            },
            "timeFieldName": {
              "type": "text",
              "fields": {
                "keyword": {
                  "type": "keyword",
                  "ignore_above": 256
                }
              }
            },
            "title": {
              "type": "text",
              "fields": {
                "keyword": {
                  "type": "keyword",
                  "ignore_above": 256
                }
              }
            }
          }
        },
        "type": {
          "type": "keyword",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        },
        "updated_at": {
          "type": "date"
        }
      }
    },
    "settings": {
      "index": {
        "number_of_shards": "5",
        "number_of_replicas": "1"
      }
    }

}

(Stellen Sie sicher, dass die Anzahl der Shards und Replikate Ihren Anforderungen entspricht.)

@ Allan-Simon Fantastisch! Das hat bei mir super geklappt!

@ Allan-Simon Danke auch, du hast meinen Abend gerettet.

@ Allan-Simon Prost! Ich habe ewig damit verbracht, dies heute Abend im AWS Elasticsearch-Service herauszufinden, bevor ich Ihren Beitrag gefunden habe, der perfekt funktioniert hat!