Failed to parse mapping [_default_]: Mapping definition for [error] has unsupported parameters

Elastic Stack Beats
1

I am using a lightly customized installation of all 6.0.0-beta1 beats.

However, When attempting to start them, they all spew this error:

 2017/08/22 19:58:16.455956 client.go:465: WARN Can not index event (status=400): {"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: Mapping definition for [error] has unsupported parameters:  [properties : {code={type=long}, message={norms=false, type=text}, type={ignore_above=1024, type=keyword}}]","caused_by":{"type":"mapper_parsing_exception","reason":"Mapping definition for [error] has unsupported parameters:  [properties : {code={type=long}, message={norms=false, type=text}, type={ignore_above=1024, type=keyword}}]"}}

I have set setup.template.overwrite: truein all of the config files, and I have also run docker run --add-host "elasticsearch:xxx.xxx.xx.xx" docker.elastic.co/beats/<beat>beat:6.0.0-beta1 setup --template

I am not sure how to interpret this error at all; I am trying to use defaults.

Running on amazonlinux, docker 17.03.1-ce, elasticsearch 5.

2

Hi @ianseyer,

Thank you for the report! I've tested several versions of Elasticsearch and didn't reproduce the issue, could you please share the exact version of Elasticsearch you are using?

Best regards

3

I also was unable to reproduce with Filebeat 6.0.0-beta1 and Elasticsearch 5.5.2. Can you please post the Filebeat config you are using too.

4

ElasticSearch version:

 "version": {
    "number": "5.5.1",
    "build_hash": "19c13d0",
    "build_date": "2017-07-18T20:44:24.823Z",
    "build_snapshot": false,
    "lucene_version": "6.6.0"
  },

My filebeat.yml:

filebeat.config:
  prospectors:
    path: ${path.config}/prospectors.d/*.yml
    reload.enabled: false
  modules:
    path: ${path.config}/modules.d/*.yml
    reload.enabled: false

processors:
- add_cloud_metadata:

output.elasticsearch:
  hosts: ['elasticsearch:9200']

name: "msgio-admin"
tags: ["msgio-admin"]

setup.template.overwrite: true

And my prospectors:

- input_type: log
  paths:
    - /mnt/log/httpd/access_log

- input_type: log
  paths:
    - /mnt/log/php/laravel.log

I have set elasticsearch to point to my actual es host via extra_hosts in docker compose.

I have also confirmed read/write abilities on the prospector paths, and tried disabling my apache module both to no avail. Nothing is getting written to the logs/ directory either.

UPDATE: I have since been able to nail this down to an issue with my laravel log file. Still no idea how to resolve it, though. Removing the laravel log from the prospectors file solves the problem. However, I need that file to be logged.

I have confirmed that can successfully read from the mounted directory by launching an alpine image with the same mounted volumes and cating their contents.

@andrewkroh @exekias any ideas?

5

So when you remove

- input_type: log
  paths:
    - /mnt/log/php/laravel.log

from your config file the mapper_parsing_exception stops?

If that's the case then I would disable the ES output temporarily and enable the file output to inspect the events being generated from the laravel.log file. Alternatively you could temporarily enable debug logging (that should log the events being sent to ES).

6

This topic was automatically closed after 21 days. New replies are no longer allowed.