MappingParserException with no custom extractor

Graylog Central (peer support)
,
1

We recently upgraded from 2.5 to 3.0.2
We have four inputs configured based on Syslog UDP, AWS CloudTrail Input, Beats, and Beats (deprecated)
We have no extractors configured for any of these. We are getting a message identical to that below every few seconds. Can anyone tell me how to dig further into what is generating these errors?
{“type”:“mapper_parsing_exception”,“reason”:“failed to parse [level]”,“caused_by”:{“type”:“number_format_exception”,“reason”:“For input string: “Information””}}

Thanks.

2

no - the only I can tell that you might want to rotate your indices to not loose any more messages.

plus create a processing pipeline that checks if the field level contains a number or a string and create a field called level_string if that happens (not storing the content in the field level after that you can see what source is sending now words and not numbers anymore.

3

I traced the source of the errors by shutting off all inputs and then collectors for the new Beats input. The messages are coming from winlogbeats which is just using the out-of-the box collector. I’ve kept the collector shutdown since it wasn’t logging any messages anyway.
Here is the configuration:

 # Needed for Graylog
fields_under_root: true
fields.collector_node_id: ${sidecar.nodeName}
fields.gl2_source_collector: ${sidecar.nodeId}

output.logstash:
   hosts: ["graylog.XXX.XXX:5045"]
path:
  data: C:\Program Files\Graylog\sidecar\cache\winlogbeat\data
  logs: C:\Program Files\Graylog\sidecar\logs
tags:
 - windows
winlogbeat:
  event_logs:
   - name: Application
   - name: System
   - name: Security

Can you give me some guidance as to where the parser is configured so I can modify it if necessary?

4

More information:
I have Collectors (legacy) running winlogbeat on the same system with no problem. The difference is how the messages are parsed. Here are the field mappings for the Level field on the legacy collector and the new sidecar:
{“graylog_40”:{“mappings”:{“message”:{“winlogbeat_level”:{“full_name”:“winlogbeat_level”,“mapping”:{“winlogbeat_level”:{“type”:“keyword”}}}}}}}

{“graylog_40”:{“mappings”:{“message”:{“level”:{“full_name”:“level”,“mapping”:{“level”:{“type”:“long”}}}}}}}

At this point I am totally unclear on where the mappings are set for winlogbeat on the new sidecar (or the legacy collector for that matter). Can anybody help me?
Thanks

5

what beats version did you use in one or the other setup? what input did you use?

The mapping is nowhere stored and Elasticsearch creates it based on the first ingested data. If you want to force something specific, create a custom mapping in elasticsearch.

6

The server is running newly upgraded graylog 3.0.2 with elastic search 5.6.16
winlogbeat.exe on the problem client running sidecar was installed by graylog_sidecar_installer_1.0.1-1.exe
It is version 6.4.2.

The winlogbeat version on systems successfully using collector-sidecar is 6.1.2

7

I just copied and ran winlogbeat 6.1.2 on the system using the new beats and get the same bad parsing results.
(BTW winlogbeat and graylog are working their little hearts out: In the couple of seconds winlogbeat was running before I stopped it 12,316 messages failed to index.)

8

did you use beats or beats (legacy) as your input?

9

Beats (not legacy). Here’s a copy of the input screen:

Beats for new Sidecar Beats RUNNING
On node [ cb767280 / Unknown]
bind_address: 0.0.0.0
no_beats_prefix: true
number_worker_threads: 4
override_source:
port: 5045
recv_buffer_size: 1048576
tcp_keepalive: false
tls_cert_file:
tls_client_auth: disabled
tls_client_auth_cert_file:
tls_enable: false
tls_key_file:
tls_key_password: **********

1 Like
10

Problem solved: I unchecked No Beats prefix and it’s working.

11

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