Pinging @ plateforme élastique / kibana

39288 semble être confronté au même problème

Et un autre article de blog:
https://discuss.elastic.co/t/not-possible-to-create-index-patterns-in-kibana/185591/2

Où l'utilisateur l'a corrigé soit par:

• définir manuellement fielddata = true sur le champ type de l'index ".kibana"
• édition manuelle du mappage elasticsearch pour Kibana et index .kibana rechargé

J'ai créé à nouveau un autre cluster (4e) même problème

J'ai essayé d'arrêter kibana, de supprimer l'index .kibana et de redémarrer Kibana voici les logs élastiques:

• Suppression de l'index

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

• Démarrage de Kibana

[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.

Éditer :
J'ai créé un autre cluster (5ème), (même script de scatch, création de VM incluse) et aucune erreur cette fois: en pensant: je vais essayer de voir si un problème d'élection peut provoquer cela?

Modifier 2:
Le cluster n ° 6 a de nouveau rencontré le problème (même script de scatch, création de VM incluse)

Sur le nœud 3, je peux voir des journaux intéressants:

Le nœud a eu quelques erreurs lors du premier essai lors de l'élection / de la jonction du maître, mais réussit toujours à le faire et à démarrer, puis le nœud a signalé une erreur lors de la création de l'alias d'index .kibana:

J'ai supprimé l'ID de nœud / {ml.machine_memory = ...., xpack.installed = true} des journaux pour effacer le bruit et le rendre plus lisible

[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

Le cluster est maintenant amorcé, mais .kibana générera une erreur:

[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 merci beaucoup pour le rapport de bogue détaillé!

Je veux juste confirmer, vous avez un cluster de 3 nœuds ES, combien de nœuds Kibana exécutez-vous ou s'agit-il d'un seul?

Nous bootstrapons le cluster sur la base d'une image dorée avec Kibana + Elastic

Donc, 3 Kibana en cours d'exécution (nous pouvons en désactiver un et en conserver 2 pour HA / équilibrage de charge plus tard).

Le dossier de données d'Elastic est complètement nettoyé avant l'instanciation (pour un bootstrap correct)
Mais peut-être pas le / var / lib / kibana qui contient l'UUID donc ils peuvent avoir le même. Mais cela ne devrait affecter que la surveillance, non?

Pourriez-vous publier les journaux des trois instances Kibana pour un cluster qui se trouve dans cet état d'erreur?

Je n'aurai pas accès à l'environnement avant lundi ..
Je me souviens que rien n'était enregistré (comme j'avais logging.quiet: true)
Je publierai le journal Kibana lundi.

J'ai trouvé 3 autres sujets sur les forums élastiques avec des utilisateurs qui semblent faire face au même problème:

Tous avec 7+, coincés dans la création infinie de modèle d'index via l'interface utilisateur car l'interface utilisateur ne peut pas trouver son objet enregistré dans l'index

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/

Il semble qu'une sorte de condition de concurrence conduise à ce que l'index .kibana ait un mappage de {"type": {"type": "text"}} au lieu de {"type": {"type": "keyword"}}

J'ai essayé de nombreuses exécutions de création d'un cluster à 3 nœuds ES + Kibana sur ma machine locale, mais je n'ai pas été en mesure de reproduire les mappages pour la propriété "type" définie sur "text".

Je peux confirmer que la création manuelle d'un mappage avec {"type": {"type": "text"}} produit les symptômes décrits dans ceci et les fils de discussion liés comme l'erreur "Les données de champ sont désactivées sur les champs de texte par défaut".

Merci beaucoup pour l'aide détaillée au débogage @tbuchier! Toujours en train de le lire, mais par curiosité, envoyez-vous un ping au serveur Kibana en boucle pour savoir s'il a démarré dans votre script?

J'ai vu cela se produire une fois auparavant, et le facteur aléatoire m'implique que c'est une sorte de condition de course, mais qu'est-ce qui pourrait être la course? Je suppose que c'est l'achèvement de la migration contre une requête entrant dans le serveur Kibana, qui (si la sécurité est activée) tente de charger le service uiSettings , qui créera automatiquement l'objet enregistré de configuration avant le. L'index kibana est en fait créé, provoquant la création de l'index en mappant automatiquement l'entrée et en utilisant {"type": "text"} pour le champ type ...

Cela n'était pas possible car nous n'acceptions même pas les requêtes HTTP avant la fin des migrations, mais avec la transition vers la nouvelle plate-forme, l'ordre des opérations a légèrement changé et maintenant les migrations sont exécutées après le démarrage de HTTP, ce qui signifie les routes peuvent être déclenchées avant que le service savedObjects ne soit réellement utilisable, ce qui peut causer des problèmes de synchronisation.

edit: une façon de vérifier cela est de vider le mappage et les documents dans l'index .kibana lorsque cette erreur est rencontrée. Si l'index ne contient rien par un document de configuration, je suis presque sûr que c'est ce qui se passe.

J'ai pu reproduire ce problème dans l'environnement 7.1.1. Détails du cluster:

• Elasticsearch 7.1.1 avec 6 nœuds de données + 3 maîtres dédiés + 2 nœuds de coordination uniquement
• Kibana 7.1.1 est configuré pour parler à 2 nœuds de coordination uniquement (paramètre elasticsearch.hosts). Kibana a 4 espaces.
• La sécurité est activée sur le cluster avec le domaine d'authentification natif et LDAP, SSL est configuré pour TCP et HTTP sur le cluster Elasticsearch ainsi que sur Kibana.

Nous avons rencontré ce problème pour la première fois lorsque, en raison d'une défaillance matérielle, nous avons dû arrêter tous les nœuds Elasticsearch (Kibana n'a cependant pas été arrêté). Supprimez tout le contenu du répertoire de données de tous les nœuds Elasticserch. J'ai redémarré tous les nœuds Elasticsearch. Kibana n'a pas été arrêté lors du redémarrage complet du cluster.

Nous avons pu reproduire ce problème en supprimant l'index .kibana* sans arrêter le service Kibana.

Pour résoudre ce problème, nous avons suivi les étapes suivantes:

• Arrêter le service Kibana
  - Index .kibana * supprimés. Nous avons décidé de supprimer les index .kibana * car il n'y avait pas de données dans les index .kibana.
• Démarrage du service Kibana.

Bonjour !!

J'ai engendré des grappes ce matin jusqu'à ce que je fasse à nouveau face au problème (le troisième):

@rudolf
Pour les logs kibana: cela semble être un problème de course:

kibana_1 et kibana_2 sont créés, sur Kibana 1, j'ai une erreur à propos de:

Nom d'alias non valide [.kibana], il existe un index portant le même nom que l'alias

et tous les kibana ont:

Une autre instance de Kibana semble migrer l'index. En attente de la fin de cette migration.

kibanalog.txt

@spalger
Pour le mappage .kibana: il semble en effet vide:

mapping_kibana.txt

mapping_kibana_1.txt

mapping_kibana_2.txt

Edit: L'étape mentionnée par @ navneet83 :

• arrêter tout kibana
• suppression de l'index .kibana, .kibana_1, .kibana_2
• Puis en commençant seulement 1 kibana
  résoudre le problème.

Pour résoudre ce problème dans notre script, nous n'activons qu'un seul Kibana au démarrage, et une fois que .kibana_1 est créé avec succès, le script lance les autres instances.

@tbuchier J'ai pu reproduire le problème et c'est en effet comme spalger a deviné une condition de concurrence avec le système de migration. Nous bloquons toutes les opérations sur Elasticsearch jusqu'à ce que l'initialisation des index et les migrations soient terminées. Un bogue logique permettait aux opérations de se poursuivre même si l'initialisation et la migration étaient toujours en cours. Cela a amené certains plugins à commencer à écrire dans l'index .kibana et Elasticsearch créait automatiquement un index avec des mappages incorrects.

La bonne nouvelle est que cela a été corrigé et publié dans la version 7.2.0 (https://github.com/elastic/kibana/pull/37674)

Merci pour votre aide dans le débogage et pour avoir lié tous les sujets de discussion à ce problème!

@rudolf Bonjour, je suis également confronté à ce problème dans la version 7.2.0. Kibana demande à plusieurs reprises un modèle d'index et es log donne une erreur de données de champ.
"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 Nous utilisons github uniquement pour les rapports de bogues reproductibles. Si vous pouvez reproduire ce comportement sur 7.2, veuillez ouvrir un nouveau problème sur github et partager les étapes. Cependant, si vous cherchez de l'aide, veuillez commencer un nouveau sujet sur nos forums de discussion https://discuss.elastic.co/ Veuillez inclure tous les journaux d'elasticsearch et de kibana ainsi que toute autre information pertinente telle que la façon dont vous avez créé le cluster et si vous avez effectué des mises à niveau à partir de versions antérieures de la pile ELK.

pour ceux qui trouvent ce fil, ce que j'ai fait sur mon cluster pour le faire fonctionner:

1. supprimer l'index kibana
2. recréez-le avec le mappage correct

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"
      }
    }

}

(assurez-vous que le nombre de fragments et de répliques correspond à vos besoins)

@ allan-simon Fantastique! Cela a très bien fonctionné pour moi!

@ allan-simon merci aussi, vous avez sauvé ma soirée.

@ allan-simon Cheers! J'ai passé des années à essayer de comprendre cela sur le service AWS Elasticsearch ce soir avant de trouver votre publication qui fonctionnait parfaitement!