Я пытаюсь применить шаблон элемента к своему кластеру elasticsearch, чтобы решить проблему наличия полей с содержимым более 32 КБ. Я использую версию 2.4.4, так как это самая высокая поддерживаемая версия в сером журнале.
Видеть: https://github.com/Graylog2/graylog2-server/issues/873
В частности, решение здесь: https://github.com/Graylog2/graylog2-server/issues/873#issuecomment-199898314
У меня также возникла другая проблема, которую я пытаюсь исправить с помощью шаблона элемента. Одно из полей может содержать число или строку. Но поскольку elasticsearch отображает поле на основе первого появления в нем значения, он иногда дает мне исключение MapperParsingException в активном индексе.
На основе решения, предложенного в связанной проблеме github, я создал свой собственный шаблон элемента и с поддержкой документации elasticsearch добавил динамический шаблон.
Вот результат:
{
"template": "graylog*",
"mappings": {
"_default_": {
"_all": {
"enabled": false
},
"dynamic_templates": [{
"entityid_as_string": {
"match": "EntityId",
"mapping": {
"type": "string"
}
}
},
{
"notanalyzed_string": {
"match_mapping_type": "string",
"mapping": {
"ignore_above": 32766,
"type": "string",
"doc_values": true
}
}
}]
}
}
}
Я ожидаю, что поле EntityId всегда будет отображаться как строка. И что любые строковые поля в документе с содержимым более 32 КБ не будут индексироваться.
Но похоже, что это не так. Даже после ручного поворота активного индекса записи я все равно получаю те же ошибки. Я даже перезагрузил виртуальную машину и повернул активный индекс записи - безрезультатно.
Может ли кто-нибудь увидеть очевидную ошибку в моем шаблоне? В частности, я не уверен, должен ли там быть раздел _all.
Я использовал эту команду, чтобы добавить его:
curl -XPUT 'localhost:9200/_template/loggingtemplate?pretty' -H 'Content-Type: application/json' -d'<template here'
И эта команда для проверки того, что он был добавлен.
curl -XGET localhost:9200/_template/loggingtemplate
По какой-то причине мое динамическое отображение не было признано.
Вместо этого для решения проблемы мне пришлось создать настраиваемое отображение индекса для всех моих наборов индексов. На мой взгляд, это грязное решение, так как теперь мне нужно скопировать и вставить конфигурацию для всех наборов индексов. Если вы забудете об одном, это приведет к ошибкам индексации и потере сообщений - в случае, если структура наших сообщений журнала изменится в будущем.
Подробности здесь: http://docs.graylog.org/en/2.2/pages/configuration/elasticsearch.html#custom-index-mappings
Это сопоставление, которое я создал для наших наборов индексов. В конкретном примере я применяю его к набору индексов с именем «application_logs».
{
"template": "application_logs_*",
"mappings": {
"message": {
"properties": {
"Message": {
"type": "string",
"ignore_above": 32766
},
"EventEntities": {
"type": "string",
"ignore_above": 32766
},
"Severity": {
"type": "string"
},
"EntityId": {
"type": "string"
}
}
}
}
}
Чтобы добавить его в elasticsearch, я бы использовал следующую команду.
curl -XPUT 'localhost:9200/_template/logs_fields_as_strings?pretty' -H 'Content-Type: application/json' -d'{"template": "application_logs_*","mappings" : {"message" : {"properties" : {"Message" : {"type" : "string","ignore_above" : 32766},"EventEntities" : {"type" : "string","ignore_above": 32766},"Severity" : {"type" : "string"},"EntityId" : {"type" : "string"}}}}}'
Это создаст шаблон под названием «logs_fields_as_strings».
Затем для каждого имеющегося у нас набора индексов мне нужно будет изменить имя шаблона и цель шаблона.
Число 32766 - это максимальное количество байтов, которое может содержать поле, если оно должно быть проиндексировано. Имейте в виду, что некоторые символы UTF8 имеют размер 3 байта. Поэтому, если вы ожидаете, что они будут в ваших сообщениях, вам нужно будет разделить 32766 на 3, чтобы убедиться, что вы не потеряете ни одного сообщения.