j'obtiens ce genre d'erreur quand logstash (v2.1.1 sur RHEL 6.4) parse un trop grand nombre de fichiers :
failed to open /apps/logstash/input/sibr/crs/1/parv07416142.crs.160111.csv: Permission denied - /apps/logstash/input/sibr/crs/1/parv07416142.crs.160111.csv {:level=>:warn}
Il est dit que c'est lié à un trop grand nombre de fichiers en entrée pour LS, dans mon cas, +60000.
J'ai réduit par bloc de 10000 fichiers, mais j'ai toujours le même souci.
Quelle est la limite acceptable du nombre de fichiers à donner à LS pour ne pas avoir ce problème ? --> modification du ulimit (voir post 5)
Dorénavant, avec un trop grand nombre de fichiers, c'est cette erreur que j'obtiens :
IdentityMapCodec has reached 100% capacity {:current_size=>20000, :upper_limit=>20000, :level=>:error}
Pourriez vous partager la version de logstash que vous utilisez ainsi que votre configuration?
A priori ca semble relié à la limite du système d'exploitation sur le nombre maximum de fichiers ouverts. Nous avons justement découvert un problème avec le file input plugin lorsque le pattern de fichiers de l'option :path résulte dans la découverte de plus de fichiers que la limite permise par l'OS. Nous prévoyons sortir une nouvelle version du plugin d'ici peu (peut-être aujourd'hui) pour régler ce problème.
Si vous ne voulez que lire et traiter un ensemble de fichiers statiques de façon adhoc sans nécessairement surveiller les changements à ces fichiers (tailing) alors peut-être serait-il possible d'utiliser une autre stratégie temporairement avec le plugin stdin input et un script simple qui lit les fichier et les pipe dans logstash?
Je m'auto-réponds : j'ai changé la valeur dans /etc/security/limits.conf pour le user logstash :
logstash soft nofile 102400
logstash hard nofile 102400
Maintenant, plus de problème pour logstash, cependant je reste sur mes lotissements à 10.000 fichiers / lot.
Edit : j'ai quand même tenté l'expérience avec tous mes fichiers et j'ai une autre erreur :
IdentityMapCodec has reached 100% capacity {:current_size=>20000, :upper_limit=>20000, :level=>:error}
LogStash::Codecs::IdentityMapCodec::IdentityMapUpperLimitException: LogStash::Codecs::IdentityMapCodec::IdentityMapUpperLimitException
visit at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:36
check_map_limits at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:245
record_codec_usage at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:231
stream_codec at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:222
decode at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-codec-multiline-2.0.4/lib/logstash/codecs/identity_map_codec.rb:143
run at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-input-file-2.0.3/lib/logstash/inputs/file.rb:195
_read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:183
each at org/jruby/RubyArray.java:1613
_read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:182
loop at org/jruby/RubyKernel.java:1479
_read_file at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:178
subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:84
each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:92
each at org/jruby/RubyArray.java:1613
each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:89
call at org/jruby/RubyProc.java:281
synchronized at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:201
synchronize at org/jruby/ext/thread/Mutex.java:149
synchronized at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:201
each at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:87
subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/watch.rb:145
subscribe at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/filewatch-0.6.7/lib/filewatch/tail.rb:75
run at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-input-file-2.0.3/lib/logstash/inputs/file.rb:193
inputworker at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-core-2.1.1-java/lib/logstash/pipeline.rb:206
start_input at /apps/logstash/logstash-2.1.1/vendor/bundle/jruby/1.9/gems/logstash-core-2.1.1-java/lib/logstash/pipeline.rb:199
Pipeline shutdown complete. {:level=>:info}
Logstash shutdown completed
Oui, il y a en effet une limite de 20k "stream identities" dans le codec multiline. la logique actuelle fait une nettoyage périodique des identités non utilisées. mais dans votre cas, clairement le nombre de fichiers lus est trop rapide.
Il faut comprendre que le file input (avec le multiline codec) à été pensé et conçu, à l'origine, pour un modèle de suivi en continu de fichiers (tailing). Présentement ce combo ne fonctionne pas très bien dans une situation de traitement d'une très grande quantité simultanés de fichiers statiques.
Notez que nous venons de compléter un "refactor" de cette logique pour pouvoir mieux supporter ce type d'utilisation. Nous en sommes aux dernières étapes de validation avant de mettre en ligne une nouvelle version.
De mon côté je vais mettre en standby ce use-case, et je vais me concentrer sur une utilisation plus appropriée d'ELK pour faire du suivi en temps réel de log applicative
@C_H comme je disais dans mon premier message, dans l'interim peut-etre serait-il possible de tout simplement utiliser le stdin input avec quelque chose du genre:
for f in somefile.*; do cat $f; done | bin/logstash ...
oui c'est une façon de voir aussi les choses, plutôt que de partir sur de gros lotissements.
Malheureusement ou pas, mon use-case est aussi un cas pilote pour "Splunk", et comme c'est le produit que la maison a retenu, je mettrais mes efforts dessus en temps voulu.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.