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

(Ian Seyer) #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 ""<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.

(Carlos PĂ©rez Aradros) #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

(Andrew Kroh) #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.

(Ian Seyer) #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:

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

- add_cloud_metadata:

  hosts: ['elasticsearch:9200']

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

setup.template.overwrite: true

And my prospectors:

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

- input_type: log
    - /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?

(Andrew Kroh) #5

So when you remove

- input_type: log
    - /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).

(system) #6

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