FSCrawler, qui crash elasticsearch

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

je suis un étudiant qui travaille sur l'indexation des docs.
En effet, j’ai une installation d’elastic avec 3 nœuds et auxquels j’ai tous donné une ram de 750 m,

Quand j’essaie d’indexer avec Fscrawler un file système qui pèse moins de 10 giga, ça se déroule normalement, mais avec une taille de File Système plus grand je me retrouve avec elasticsearch qui plante.
J’aimerais savoir d’où provient l’erreur s’il vous plait ( j’ai joint la copie de mon docker-compose,settings.json de fscrawler et ma log d’erreurs)

11:31:14,625 [33mWARN [m [f.p.e.c.f.FsParser] Full stacktrace
org.elasticsearch.ElasticsearchStatusException: Elasticsearch exception [type=search_phase_execution_exception, reason=all shards failed]
             at org.elasticsearch.rest.BytesRestResponse.errorFromXContent(BytesRestResponse.java:177) ~[elasticsearch-6.3.2.jar:6.3.2]
             at org.elasticsearch.client.RestHighLevelClient.parseEntity(RestHighLevelClient.java:653) ~[elasticsearch-rest-high-level-client-6.3.2.jar:6.3.2]
             at org.elasticsearch.client.RestHighLevelClient.parseResponseException(RestHighLevelClient.java:628) ~[elasticsearch-rest-high-level-client-6.3.2.jar:6.3.2]
             at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:535) ~[elasticsearch-rest-high-level-client-6.3.2.jar:6.3.2]
             at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:508) ~[elasticsearch-rest-high-level-client-6.3.2.jar:6.3.2]
             at org.elasticsearch.client.RestHighLevelClient.search(RestHighLevelClient.java:404) ~[elasticsearch-rest-high-level-client-6.3.2.jar:6.3.2]
             at fr.pilato.elasticsearch.crawler.fs.FsParser.getFileDirectory(FsParser.java:356) ~[fscrawler-core-2.5.jar:?]
             at java.lang.Thread.run(Unknown Source) [?:1.8.0_191]
             Suppressed: org.elasticsearch.client.ResponseException: method [POST], host [http://192.168.186.186:9200], URI [/bio06/_search?typed_keys=true&ignore_unavailable=false&expand_wildcards=open&allow_no_indices=true&search_type=query_then_fetch&batched_reduce_size=512], status line [HTTP/1.1 500 Internal Server Error]
{"error":{"root_cause":[{"type":"node_disconnected_exception","reason":"[mURR2UY][172.25.0.2:9300][indices:data/read/search[phase/query]] disconnected"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"bio06","node":"mURR2UYHSqiO7ldwfOLV7g","reason":{"type":"node_disconnected_exception","reason":"[mURR2UY][172.25.0.2:9300][indices:data/read/search[phase/query]] disconnected"}}]},"status":500}
Caused by: org.elasticsearch.client.ResponseException: method [POST], host [http://192.168.186.186:9200], URI [/bio06/_search?typed_keys=true&ignore_unavailable=false&expand_wildcards=open&allow_no_indices=true&search_type=query_then_fetch&batched_reduce_size=512], status line [HTTP/1.1 500 Internal Server Error]
{"error":{"root_cause":[{"type":"node_disconnected_exception","reason":"[mURR2UY][172.25.0.2:9300][indices:data/read/search[phase/query]] disconnected"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"bio06","node":"mURR2UYHSqiO7ldwfOLV7g","reason":{"type":"node_disconnected_exception","reason":"[mURR2UY][172.25.0.2:9300][indices:data/read/search[phase/query]] disconnected"}}]},"status":500}
                           at org.elasticsearch.client.RestClient$1.completed(RestClient.java:377) ~
2

Bonjour.

Essaye de formatter correctement tes logs/code la prochaine fois. Je l'ai fait pour toi pour cette fois.

Je vois que tu essayes d'indexer un répertoire .svn. C'est intentionnel ?
Tu devrais peut-être exclure ce type de répertoire.

Je vois que la réponse d'Elasticsearch est 500 Internal Server Error. Tu devrais donc avoir des logs côté elasticsearch. Peux-tu les partager STP ?

3

J'exclurai les fichier .svn alors
En parlant des logs côté elasticsearch, j'ai cherché à les mappers de /usr/share/elasticsearch/data vers un endroit /home/docker/elk/volume/dossier_name mais je les retrouve pas mes logs.

 
version: '2.2'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    container_name: elasticsearch
    environment:
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=false
      - "ES_JAVA_OPTS=-Xms750m -Xmx750m"
      - http.cors.enabled=true
      - http.cors.allow-origin=*
      - discovery.zen.minimum_master_nodes=2
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata1:/usr/share/elasticsearch/data
      - eslog1:/var/log/elasticsearch
    ports:
      - 9200:9200
    networks:
      - esnet
 
  elasticsearch2:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    container_name: elasticsearch2
    environment:
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=false
      - "ES_JAVA_OPTS=-Xms750m -Xmx750m"
      - "discovery.zen.ping.unicast.hosts=elasticsearch"
      - http.cors.enabled=true
      - http.cors.allow-origin=*
      - discovery.zen.minimum_master_nodes=2
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata2:/usr/share/elasticsearch/data
      - eslog2:/var/log/elasticsearch
 
    networks:
      - esnet
 
  elasticsearch3:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    container_name: elasticsearch3
    environment:
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=false
      - "ES_JAVA_OPTS=-Xms750m -Xmx750m"
      - "discovery.zen.ping.unicast.hosts=elasticsearch"
      - http.cors.enabled=true
      - http.cors.allow-origin=*
      - discovery.zen.minimum_master_nodes=2
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata3:/usr/share/elasticsearch/data
      - eslog3:/var/log/elasticsearch
    networks:
      - esnet
 
  kibana:
    image: 'docker.elastic.co/kibana/kibana:6.5.3'
    container_name: kibana
    ports:
      - '5601:5601'
    depends_on:
      - elasticsearch
    networks:
      - esnet
 
volumes:
  esdata1:
    driver_opts:
      type: none
      device: /home/docker/elk/volume/0
      o: bind
  esdata2:
    driver_opts:
      type: none
      device: /home/docker/elk/volume/1
      o: bind
  esdata3:
    driver_opts:
      type: none
      device: /home/docker/elk/volume/2
      o: bind
  eslog1:
    driver_opts:
      type: none
      device: /home/docker/elk/log/0
      o: bind
  eslog2:
    driver_opts:
      type: none
      device: /home/docker/elk/log/1
      o: bind
  eslog3:
    driver_opts:
      type: none
      device: /home/docker/elk/log/2
      o: bind
 
 
networks:
  esnet:
4

Ca doit être dans /home/docker/elk/log/... je suppose.

Sinon un docker logs devrait te donner ça?

Mais bon 750 mo par noeud, c'est pas un peu faible ?
Pourquoi si peu?

Pourquoi pas un seul noeud avec 2.5 go de HEAP par exemple?

5

J'ai fait un exclude des fichiers .svn et augmenté à 2.5 go de HEAP, j'ai puis indexé tout mon file système.
Merci à vous!
Par contre, FsCrawler permet d'indexer tous les fichiers supportés par Apache Tika mais je suis obligé de faire un exclude des fichiers .jar, .zip et .exe pour que elasticsearch ne plante pas alors que ces fichiers sont censés être supportés.

  "name" : "bio07",
  "fs" : {
    "url" : "/mnt/nas/",
    "update_rate" : "3m",
    "excludes" : [ "*/~*", "*/*.zip", "*/*.jar", "*/*.exe", "*/*.bz2", "*/*.svn-base" ],
    "json_support" : false,
    "filename_as_id" : false,
    "add_filesize" : true,
    "remove_deleted" : true,
    "add_as_inner_object" : false,
    "store_source" : false,
    "index_content" : true,
    "indexed_chars" : "-1",
    "attributes_support" : false,
    "raw_metadata" : true,
    "xml_support" : false,
    "index_folders" : true,
    "lang_detect" : false,
    "continue_on_error" : true,
    "pdf_ocr" : false
     },


  "elasticsearch" : {
    "nodes" : [ {
      "host" : "192.168.186.186",
      "port" : 9200,
      "scheme" : "HTTP"
    } ],
    "byte_size" : "90mb",
    "bulk_size" : 60,
    "flush_interval" : "360s"
    
  },
  "rest" : {
    "scheme" : "HTTP",
    "host" : "192.168.186.186",
    "port" : 8080,
    "endpoint" : "fscrawler"
  }
}```
6

Tu peux lire la discussion ici à propos des fichiers ZIP:

En gros, avoir des documents ZIP consomme énormément de mémoire pour des gros fichiers. Plutôt que d'exclure tous les ZIP, tu pourrais considérer n'exclure que les gros fichiers quelque soit leur format avec cette option https://fscrawler.readthedocs.io/en/latest/admin/fs/local-fs.html#ignore-above

7

Merci pour vos retours.
Je viens de me remettre dessus, étant donné que j'indexe un file system, il y'a plusieurs type de fichiers dedans.
Du coup j'ai créé un job fscrawler juste pour les fichiers de formats courants(pdf,excel,word, txt etc) et un autre job pour les fichiers ZIP, EXE etc...
Vu le retour sur https://github.com/dadoonet/fscrawler/issues/566 j'ai cru comprendre qu'avec un fichier de 100 Mo, une mémoire allouée de 2 giga suffira.
Etant donné que je suis sur sur 64 bits, je peux étendre la mémoire à plus de 2giga, donc j'ai passé ma mémoire HEAP à 8 giga pour l'indexation de mon second job (.Exe .zip etc) mais mon job se plante toujours sur un fichier zip de 12Mo qui contient juste quelque fichier excel a cause toujours de "Java Heap Space".

8

Te serait-il possible de m'envoyer le ZIP en question ? En le postant dans une issue fscrawler par exemple ?

9

Je viens de tester en ajoutant les 2 fichiers zip que tu m'as envoyé par email dans les tests d'intégration de FSCrawler.

J'ai lancé un elasticsearch avec ES_JAVA_OPTS=-Xms2g -Xmx2g.

Tout a fonctionné correctement:

GET fscrawler_test_all_documents/_search
{
  "query": {
    "term": {
      "file.extension": {
        "value": "zip"
      }
    }
  }
}

Donne (suppression du contenu trop gros):

{
  "took" : 28,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 2,
    "max_score" : 2.3795462,
    "hits" : [
      {
        "_index" : "fscrawler_test_all_documents",
        "_type" : "_doc",
        "_id" : "b74e1f445854672423e25e4672e909a",
        "_score" : 2.3795462,
        "_source" : {
          "content" : """

run 2/gedamm_apps_lav.csv...
""",
          "meta" : {
            "language" : "en",
            "raw" : {
              "X-Parsed-By" : "org.apache.tika.parser.DefaultParser",
              "resourceName" : "run2.zip",
              "Content-Type" : "application/zip"
            }
          },
          "file" : {
            "extension" : "zip",
            "content_type" : "application/zip",
            "created" : "2019-03-26T10:50:19.000+0000",
            "last_modified" : "2019-03-26T10:50:19.000+0000",
            "last_accessed" : "2019-03-26T10:50:19.000+0000",
            "indexing_date" : "2019-03-26T10:50:20.545+0000",
            "filesize" : 13563119,
            "filename" : "run2.zip",
            "url" : "file:///var/folders/r_/r14sy86n2zb91jyz1ptb5b4w0000gn/T/junit2697911435173724677/resources/documents/run2.zip"
          },
          "path" : {
            "root" : "aa5646b1d36b44e8a1845f20f848e5f1",
            "virtual" : "/run2.zip",
            "real" : "/var/folders/r_/r14sy86n2zb91jyz1ptb5b4w0000gn/T/junit2697911435173724677/resources/documents/run2.zip"
          }
        }
      },
      {
        "_index" : "fscrawler_test_all_documents",
        "_type" : "_doc",
        "_id" : "47b6d8f8d8bcbd8bdb02e3f9f96c4",
        "_score" : 2.3795462,
        "_source" : {
          "content" : """

run 1/imported 2017-06-22/gedamm_apps_lav.csv...
""",
          "meta" : {
            "language" : "en",
            "raw" : {
              "X-Parsed-By" : "org.apache.tika.parser.DefaultParser",
              "resourceName" : "run1.zip",
              "Content-Type" : "application/zip"
            }
          },
          "file" : {
            "extension" : "zip",
            "content_type" : "application/zip",
            "created" : "2019-03-26T10:50:19.000+0000",
            "last_modified" : "2019-03-26T10:50:19.000+0000",
            "last_accessed" : "2019-03-26T10:50:19.000+0000",
            "indexing_date" : "2019-03-26T10:50:23.419+0000",
            "filesize" : 12992089,
            "filename" : "run1.zip",
            "url" : "file:///var/folders/r_/r14sy86n2zb91jyz1ptb5b4w0000gn/T/junit2697911435173724677/resources/documents/run1.zip"
          },
          "path" : {
            "root" : "aa5646b1d36b44e8a1845f20f848e5f1",
            "virtual" : "/run1.zip",
            "real" : "/var/folders/r_/r14sy86n2zb91jyz1ptb5b4w0000gn/T/junit2697911435173724677/resources/documents/run1.zip"
          }
        }
      }
    ]
  }
}

Qu'est-ce qui plante de ton côté FSCrawler ou Elasticsearch?

10

Merci de m'avoir envoyé tes logs et tes settings.

A propos des settings, je vois cette ligne

"includes" : [ "*/~*", "*/*.bz2", "*/*.svn-base", "*/*.zip", "*/*.exe" ],

Est-ce bien ton intention d'indexer des fichiers *.exe, *.zip, *.bz2, *.svn-base et ~*?

Visiblement, le problème OOM vient du fait que tu lances en mode --debug et cela ne plait pas à FSCrawler à cet endroit du code.
Je viens donc de modifier le code:

Quand cela sera testé et mergé, tu pourras télécharger la dernière version SNAPSHOT depuis cette page: https://oss.sonatype.org/content/repositories/snapshots/fr/pilato/elasticsearch/crawler/fscrawler-es6/2.7-SNAPSHOT/

En attendant, je te conseille de ne pas lancer en mode debug.

11

Merci pour vos retours.
Oui mon intention est d'indexer que ces fichiers vue que ces eux que j'ai exclu dans mon job1, donc dans mon job2 j'essaie juste d'indexer que les zip, exe bz2 ...
Qu'entendez vous par <cela ne plait pas à FSCrawler à cet endroit du code>, car avec le mode --trace aussi j'ai le même retour d'erreur qu'avec le --debug, et vu qu'avec le --silent j'ai pas d'output mais je remarque juste l'erreur Java heap space dans ma console.
Donc en gros j'arrive pas à passer l'étape des deux zip que je vous ai envoyé

12

--trace et --debug passent par le même bout de code.
Je n'ai pas regardé comment est implémenté log4j mais il est possible qu'une vérification des objets passés soit aussi faite même si le logger ne va rien logger.

En tout cas, la modification que j'ai faite devrait te permettre de ne pas planter à cet endroit là en tout cas.

Essaye juste de lancer fscrawler sans option de debug, trace ou silent. Si il plante, peux-tu poster ici la trace complète ? (Pas en image STP).

D'autre part, as-tu essayé de donner plus de HEAP à FSCrawler avec ceci: https://fscrawler.readthedocs.io/en/latest/admin/jvm-settings.html ?

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.