I am using filebeat to send log data in ELK kibana.
Log example:- error_log.log
{"type":"ERROR","errorType":"ERROR","message":"Error in add","others":{"error": "something went wrong","source":"/public/new/user"}}
{"type":"ERROR","errorType":"ERROR","message":"Error in update","others":{"error": "something went wrong","source":"/public/users/edit"}}
the decode_json_fields processor decodes JSON values from string fields. Looking at the example log lines you gave, the value assigned to the others key is not a string, but already an object. That means that the initial JSON parsing via json.keys_under_root should have parsed it already and the that the processor likely fails.
Have you tried removing the processor but leaving the json.keys_under_root in?
Unrelated to the indexing, but important for querying later, in order to properly search the resulting documents you will likely want to declare the others field as a nested-type field in your mapping.
I don't expect the file name extension to be of any significance. Could you check if there is anything in the Filebeat logs or Elasticsearch logs that correlates with the parsing failures?
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.