Применение шаблона элемента к asticsearch
Я пытаюсь применить шаблон элемента к моему кластеру эластичного поиска, чтобы решить проблему наличия полей с содержимым длиннее 32 КБ. Я использую версию 2.4.4, так как это самая высокая поддерживаемая версия в graylog.
Смотрите: https://github.com/Graylog2/graylog2-server/issues/873
Конкретно решение здесь: https://github.com/Graylog2/graylog2-server/issues/873
Я также столкнулся с другой проблемой, которую я пытаюсь исправить с помощью шаблона элемента. Одно из полей может содержать либо число, либо строку. Но так как asticsearch отображает поле на основе первого вхождения значения в него, иногда это дает мне исключение MapperParsingException для активного индекса.
На основе решения, предложенного в связанной проблеме github, я создал свой собственный шаблон элемента и при поддержке из документации эластичного поиска добавил динамический шаблон.
Это результат:
{
"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
1 ответ
По некоторым причинам мое динамическое отображение не было выполнено.
Вместо этого, чтобы решить проблему, мне пришлось создать собственное отображение индекса для всех моих наборов индексов. На мой взгляд, это грязное решение, так как теперь мне нужно скопировать и вставить конфигурацию для всех наборов индексов. Забывание этого приведет к ошибкам индексации и потере сообщений - в случае, если структура наших сообщений журнала изменится в будущем.
Подробности здесь: http://docs.graylog.org/en/2.2/pages/configuration/elasticsearch.html
Это отображение, которое я создал для наших наборов индексов. В конкретном примере я применяю его к набору индексов "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"
}
}
}
}
}
Чтобы добавить его в asticsearch, я бы использовал следующую команду.
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, чтобы убедиться, что вы не потеряете ни одного сообщения.