Graylog: Data mapping issues

How to solve Graylog index data mapping problems

👋 Welcome to the Stackhero documentation!

Stackhero offers a ready-to-use Graylog cloud solution that provides a host of benefits, including:

  • Unlimited and dedicated SMTP email server included.
  • Effortless updates with just a click.
  • Customizable domain name secured with HTTPS (for example, https://logs.your-company.com).
  • Optimal performance and robust security powered by a private and dedicated VM.

Save time and simplify your life: it only takes 5 minutes to try Stackhero's Graylog cloud hosting solution!

A common issue in Graylog is data mapping conflicts that can lead to failed indexing attempts. You might encounter this problem if you see logs like these:

ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse field [level] of type [long] in document with id '34fd4d11-36ed-11f0-afc9-0242ac140002'. Preview of field's value: 'error']]; nested: ElasticsearchException[Elasticsearch exception [type=illegal_argument_exception, reason=For input string: "error"]];

Reason for the issue

This issue arises from OpenSearch's dynamic mapping feature. Dynamic mapping automatically determines the data type of each field based on the first document written to an index. Once set, this data type is "locked in", and any future documents with a different data type for that field are rejected, causing a mapper parsing exception.

When a new index is created, the first document defines the index mapping. For instance, if the document contains a "level" field with a value of 3 (a numeric value), OpenSearch sets the data type for "level" to "long" (a numeric type). If a later document sent to Graylog contains the "level" field set to "error" (a string type), it will be rejected because the data type does not match the initially set type. This triggers a mapper_parsing_exception error with the reason failed to parse field [level] of type [long] in document with id 'xxx'.

This issue can happen with any field if the data types are inconsistent across documents.

How to resolve the issue

To resolve this issue, you have 2 options:

1. Ensure consistent data types across systems

The ideal solution is to standardize the data types used for fields across all systems sending data to Graylog. For example, ensure that the "level" field is always sent as either a string (like "error", "warn", etc.) or always as a number (3, 4, etc.). This consistency prevents mapping conflicts and ensures all documents are ingested correctly.

2. Use Graylog pipelines for data conversion

If standardizing data types across all systems is not feasible, you can use Graylog's pipelines to convert data types upon receipt. Pipelines allow you to define rules that transform data based on specific conditions.

To implement this solution:

  • Navigate to "System" > "Pipelines" in the Graylog web interface.
  • Click "Add new pipeline" to create a new pipeline.
  • Define rules to convert the "level" field (or other fields) to the desired data type. For example, you can convert numeric levels to their corresponding string representations (like 3 to "error", 4 to "warning", etc.).

This approach ensures that all incoming data conforms to the expected data types, preventing mapping conflicts.

Viewing and changing index mappings

For advanced users, Graylog provides the ability to view and manually adjust the mapping of indices:

  • Go to "System" > "Indices" in the Graylog web interface.
  • Select the relevant index.
  • Navigate to "Configuration" > "Configure index field types" to view or modify the field mappings.

However, manual adjustments should be approached with caution, as incorrect mappings can lead to further ingestion issues.

Other articles for Graylog