Как узнать версию elasticsearch
Как узнать установленную версию эластичного поиска из кибаны?
В настоящее время я получаю следующие предупреждения:
Требуется обновление. Ваша версия Elasticsearch слишком старая. Для Kibana требуется Elasticsearch 0.90.9 или выше.
Может ли кто-нибудь сказать мне, есть ли способ найти точную установленную версию ELS?
10 ответов
Клиент отдыха: http: // localhost: 9200
Пользователь @manoj дал правильный ответ на вопрос. От хоста Kibana ответ на запрос к http: // localhost: 9200 / не будет, если также не запущен ElasticSearch. на том же узле. Kibana слушает порт 5601, а не 9200.
В большинстве случаев, за исключением DEV, ElasticSearch не будет находиться на том же узле, что и Kibana, по ряду причин. Поэтому, чтобы получить информацию о вашем ElasticSearch из Kibana, вы должны выбрать вкладку «Инструменты разработчика» слева и в консоли ввести команду: GET /
Чтобы проверить версию вашей беговой кибаны, попробуйте следующее:
Шаг 1. Запустите службу Kibana.
Шаг 2. Откройте браузер и введите строку ниже,
Шаг 3. Зайдите в настройки-> О программе
Вы можете проверить версию ElasticSearch с помощью следующей команды. Он также возвращает некоторую другую информацию:
Здесь вы можете увидеть номер версии: 2.3.4
Если вы установили x-pack для защиты elasticsearch, запрос должен содержать действительные учетные данные.
Фактически, если безопасность включена, все последующие запросы должны следовать одному и тому же шаблону (должны быть предоставлены встроенные учетные данные).
Вы можете попробовать это, после запуска службы elasticsearch Введите строку ниже в своем браузере.
Я хотел бы добавить то, что не упоминается в ответах выше.
На консоли разработчика kibana нажмите следующую команду:
Это похоже на доступ к localhost:9200 из браузера.
Надеюсь, это кому-то поможет.
Как узнать установленную версию elastic search от kibana?
В настоящее время я получаю эти предупреждения:
обновление требуется ваша версия Elasticsearch слишком стара. Kibana требует Elasticsearch 0.90.9 или выше.
может кто-нибудь сказать мне, есть ли способ найти точную установленную версию ELS?
7 ответов
где числовое поле обозначает elasticsearch версия. Вот!—2—> версия 2.3.4
Я хотел бы добавить, что не упомянутые выше ответы.
С консоли разработчика kibana нажмите следующую команду:
Это похоже на обращение localhost:9200 из браузера.
надеюсь, это поможет кому-то.
вы можете проверить версию ElasticSearch с помощью следующей команды. Он также возвращает некоторую другую информацию:
curl-XGET ‘localhost: 9200’
здесь вы можете увидеть номер версии: 2.3.4
чтобы проверить версию вашего запущенного Kibana, попробуйте следующее:
Шаг1. Начните обслуживание Kibana.
Шаг2. Откройте браузер и введите под строкой,
перейдите в папку, в которой вы установили свой платформы Kibana если вы использовали yum для установки платформы Kibana он будет размещен в следующем месте по умолчанию
затем используйте следующую команду
вы можете попробовать это, После запуска службы elasticsearch введите строку ниже в вашем браузере.
Если вы установили x-pack для защиты elasticseach, запрос должен содержать допустимые данные учетных данных.
Infact, если безопасность включена, все последующие запросы должны следовать тому же шаблону (должны быть предоставлены встроенные учетные данные).
Использование Elasticsearch
В сегодняшней статье мы поговорим про движок полнотекстового поиска и аналитики Elasticsearch. Программа очень быстро развивается, соответственно, увеличивается круг её применения. Изначально Elasticsearch использовался для поиска на сайтах, но сейчас он развился в полноценную базу данных и может применяться для аналитической обработки больших массивов данных, анализа логов серверов и многих других задач.
Тем не менее на русском языке не так много хороших инструкций, описывающих работу этой платформы. Дальше мы рассмотрим, как установить Elasticsearch, а также познакомимся с основами создания и использования индексов, управлением данными и группировкой. В общем, расскажу обо всём, что я узнал об этой программе за последние несколько недель работы с ней.
Системные требования Elasticsearch
От себя же могу сказать, что с обработкой 1 млрд строк данных Elasticsearch неплохо справляется и на машине с 2 Гб, не так быстро как хотелось бы, но там, где MySQL задумывалась на несколько минут, Elasticsearch выдаёт результат почти мгновенно. Однако для машин с небольшим количеством ОЗУ нужна дополнительная настройка.
К процессору особых требований нет, что касается дисков, то разработчики советуют использовать SSD, так как они позволят быстрее выполнять операции индексирования и чтения данных с диска.
Установка Elasticsearch в Ubuntu
sudo apt install openjdk-8-jre
Смотрим версию Java:
Если у вас уже установлена другая версия, то этот шаг можно пропустить. Затем добавляем репозиторий Elasticsearch:
И установка ElasticSearch:
sudo apt-get update && sudo apt-get install elasticsearch
В rpm дистрибутивах достаточно просто скачать и установить rpm пакет.
Настройка Elasticsearch
После завершения установки Elasticsearch нужно запустить и добавить в автозагрузку его службу, для этого выполните:
sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch
Теперь нужно перезапустить сервис:
sudo systemctl restart elasticsearch
Использование Elasticsearch
1. Просмотр версии Elasticsearch
Для общения с Elasticsearch используется RESTful API или, если говорить простым языком, обыкновенные HTTP-запросы. И работать с ним мы можем прямо из браузера. Но делать этого не будем, а будем использовать Linux-утилиту curl. Для просмотра информации о сервисе достаточно обратиться по адресу localhost:9200:
Если будете пытаться ей помешать, можете потерять уже проиндексированные данные. Просто убедитесь, что сервис уже запущен (active) командой:
sudo systemctl status elasticsearch
Когда платформа загрузиться, вы получите такой ответ:
2. Список индексов Elasticsearch
Точно так же, как MySQL может иметь несколько баз данных, Elastic может иметь несколько индексов. У каждого из них может быть несколько отдельных таблиц (type), каждая из которых будет содержать документы (doc), которые можно сравнить с записями в таблице MySQL.
Чтобы посмотреть текущий список индексов, используйте команду _cat:
Общий синтаксис использования глобальных команд такой:
Например, команда _cat также может отобразить общее «здоровье» индексов (health) или список активных узлов (nodes). Параметр v включает более подробный вывод, а pretty сообщает, что надо форматировать вывод в формате json (чтобы было красиво).
3. Индексация данных
Вообще, вам не обязательно создавать индекс. Вы можете просто начать записывать в него данные, как будто бы он и таблица уже существует. Программа создаст всё автоматически. Для записи данных используется команда _index. Вот только однострочной команды curl нам будет уже недостаточно, надо добавить ещ сами данные в формате json, поэтому создадим небольшой скрипт:
Здесь я записываю данные: индекс app, таблицу data. Так как они не существуют, система их создаст. Как видите, сами данные нам нужно передать в формате json. Передаём заголовок с помощью опции -H, будем отсылать json, а потом с помощью -d передаём сами данные. Данные представляют из себя четыре(точно?, а то я просто вижу 3) поля:
Нам следует ещё остановиться на синтаксисе формата json:
Теперь сохраняем скрипт и запускаем:
Если всё прошло успешно, то вы увидите такое сообщение:
Это значит, что документ добавлен в индекс. Теперь вы можете снова посмотреть список индексов.
4. Информация об индексе
Мы знаем список созданных индексов, но как посмотреть список типов (таблиц) в индексе и как узнать, какие и каких типов поля созданы в индексе? Для этого можно использовать команду _mapping. Но перед тем, как мы перейдём к ней, надо вернуться к синтаксису. Команды могут применяться как к глобально, так и для отдельного индекса или для отдельного типа. Синтаксис будет выглядеть так:
Чтобы посмотреть все индексы и их поля, можно применить команду глобально:
Или только для индекса app:
Только для типа data индекса app:
В результате программа вернула нам ответ, в котором показан индекс app, в нём есть тип data, а дальше в поле properties перечислены все поля, которые есть в этом типе: age, degree и name. Каждое поле имеет свои параметры.
5. Информация о поле и мультиполя
Каждое поле описывается таким списком параметров:
Но если вам нужно просто проверить точное вхождение фразы без её изменений, то с проанализированным таким образом полем у вас ничего не получиться. Поэтому разработчики придумали мультиполя. Они содержат те же данные, что и основное поле, но к ним можно применять другие анализаторы, или вообще их не применять. В нашем примере видно, что система автоматически создала подполе типа keyword, которое содержит неизмененный вариант текста.
Таким образом, если вы захотите проверить точное вхождение, то нужно обращаться именно к полю age.keyword а не к age. Или же отключить анализатор для age. Анализаторы выходят за рамки этой статьи, но именно эта информация нам ещё понадобится дальше.
6. Удаление индекса
Чтобы удалить индекс, достаточно использовать вместо GET протокол DELTE и передать имя индекса:
Теперь индекс удалён. Создадим ещё один такой же вручную.
7. Ручное создание индекса
Программа создала для цифр текстовые поля, к ним применяется анализ текста и индексация, а это потребляет дополнительные ресурсы и память. Поэтому лучше создавать индекс вручную и настраивать такие поля, какие нам надо. Первых два поля сделаем int без подполей, а третье оставим как есть. Запрос будет выглядеть так:
Как видите, здесь используется тот же синтаксис, который программа возвращает при вызове команды _mapping. Осталось запустить скрипт, чтобы создать индекс:
Чтобы всё прошло нормально, необходимо удалить индекс, который был создан автоматически, поэтому предыдущий пункт расположен там не зря. Вы можете менять mappings для существующего индекса, но в большинстве случаев для применения изменений к существующим данным индекс надо переиндексировать. Например, если вы добавляете новое мультиполе, то в нём можно будет работать только с новыми данными. Старые данные, которые были там до добавления, при поиске будут недоступны.
5. Массовая индексация данных
Дальше я хотел бы поговорить о поиске, условиях и фильтрации, но чтобы почувствовать полную мощьность всех этих инструментов нам, нужен полноценный индекс. В качестве индекса мы будем использовать один из демонстрационных индексов, в который разложены пьесы Шекспира. Для загрузки индекса наберите:
В файле находятся данные в формате json, которые надо проиндексировать. Это можно сделать с помощью команды _bluck:
Индексация работает так же, как и при ручном добавлении данных, но благодаря оптимизации команды _bluck, выдаёт результат намного быстрее.
6. Поиск по индексу
Для поиска или, другими словами, выборки данных в Elasticsearch используется команда _search. Если вызвать команду без параметров, то будут обрабатываться все документы. Но выведены будут только первые 10, потому что это ограничение по умолчанию:
Здесь мы выбрали первые десять документов из индекса shakespeare и таблицы doc. Чтобы выбрать больше, передайте параметр size со значением, например 10000:
Но как вы понимаете, всё это очень не точно и чаще всего надо искать по определённым полям. В Elasticsearch существует несколько типов поиска. Основные из них:
Синтаксис term такой:
» query » <
» term » <
» имя_поля «: » что искать «
>
>
Например, найдем записи, где говорит Эдгар с помощью term:
Мы нашли десять реплик, которые должен сказать Эдгар. Дальше испытаем неточный поиск с помощью match. Синтаксис такой же, поэтому я его приводить не буду. Найдём предложения, которые содержат слова of love:
С query_string и match_phrase разберётесь сами, если будет нужно.
8. Операторы AND и OR для поиска
Если вы хотите сделать выборку по нескольким полям и использовать для этого операторы AND и OR, то вам понадобится конструкция bool. Синтаксис её такой:
«query» : <
«bool» : <
«must» : [
< "поле1" : "условие" >,
< "поле2" : "условие" >,
],
«filter» : <>,
«must_not» : <>
«should» : <>
>
>
Обратите внимание на синтаксис. Поскольку у нас два элемента подряд, мы используем массив []. Но так как дальше нам снова нужно создавать пары ключ:значение, то в массиве открываются фигурные скобки. Конструкция bool объединяет в себе несколько параметров:
Например, отберём все записи, где Helen говорит про любовь:
Как видите, найдено только два результата.
9. Группировка
«aggregations» : <
«название» : <
«тип_группировки» : <
параметры
>,
дочерние_группировки
>
>
Разберём по порядку:
Давайте подсчитаем, сколько отдельных реплик для каждого человека. Для этого будем использовать группировку terms:
В результате запроса Еlasticsearch получим:
Сначала пойдут все найденные документы, а затем в разделе aggregations мы увидим наши значения. Для каждого имени есть doc_count, в котором содержится количество вхождений этого слова. Чтобы продемонстрировать работу вложенных группировок, давайте найдём сумму и среднее значение поля line_number для каждого участника:
В сумме у нас очень большие числа, поэтому они отображаются в экспоненциальном формате. А вот в среднем значении всё вполне понятно.
<
«key» : «DUKE VINCENTIO»,
«doc_count» : 909,
«total_number» : <
«value» : 5.4732683E7
>,
«avg_number» : <
«value» : 60211.97249724973
>
>
Выводы
Пожалуй это всё, статья и так очень сильно затянулась. Но и этого материала будет вполне достаточно, чтобы начать использование Elasticsearch в своих проектах. Понятно, что вы не будете там пользоваться curl, у программы есть библиотеки для различных языков программирования, в том числе и для php. Если вы нашили ошибки или неточности в описании работы Еlasticsearch, поправьте меня в комментариях!
Нет похожих записей
Оцените статью:
Об авторе
Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.
13 комментариев
Вода вода вода
Зачем писать как работает json?!
And и or если в примере только and
Можно ли cvs формат загрузить в еластик?
Спасибо за прекрасные примеры!
Хочется увидеть продолжение, желательно такое-же длинное, с большим количеством примеров.
Можно про анализаторы, можно про плагины, можно про более сложный поиск в elasticsearch-e.
В Интернете очень мало статьей по “Упругому поиску”. Как один из вариантов обучения – это читать unit-тесты автора elastica. Elatica – это php клиент Для elasticsearch https://github.com/ruflin/Elastica/tree/master/test
Спасибо! Материал действительно оказался очень полезным! В закладки.
Подскажите, если не зашло, как удалить elasticsearch с сервера? какой командой?
yum remove elasticsearch, а затем вручную удалите репозиторий /etc/yum.repos.d/elasticsearch.repo и удалите папку с индексами: /var/lib/elasticsearch
Большое спасибо. Уже месяц читаю ваш сайт, добавил в закладки, много полезного.
И сайт хороший и полезный и статья тоже. по ней и устанавливал, а критики покажите свой сайт и свои статьи, которые лучше этих. а если нет, то и не надо тут.
но я столкнулся с еще одной интересной задачей. стоит на сервере версия эластика 1.6, а хочется поставить хотя бы 6 серию, или 7ю. а у них совсем разный синтаксис и команды. пробовал просто механически на новой версии запустить. но посыпались ошибки. причем пемяю то на что жалуется, на то что само же и предлагает, а ошибки не прекращаются. долго не занимался, понял после очередного исправления, что тут без плана перехода не обойтись, а в инете все обрывочно и в основном тоже вопросы, а не ответы. если есть возможность и нужна тема для очередной статьи, прошу рассмотреть делать статью о переходе с версии 1 серии на относительно новую не менее 5й по Вашему выбору. пусть даже в основном переведенная, ибо лучшего я еще не нашел.
уточнение. содержимое индекса вообще не нужно сохранять. сайт так сконфигурирован, что через час даже не надо вспоминать что индекс был удален. а в основном все статьи как раз на сохранение индекса, а не сам перевод кода сайта, который у меня на пхп сделан.
У ELK’и иголки колки: минимизируем потерю сообщений в Logstash, следим за состоянием Elasticsearch
Стек от Elastic — одно из самых распространенных решений для сбора логов. А точнее — две его разновидности: ELK и EFK. В первом случае речь идет про Elasticsearch, Logstash, Kibana (а еще — Beats, который даже не участвует в аббревиатуре, о чем шутят сами создатели: «Do we call it BELK? BLEK? ELKB?»). Вторая связка — Elasticsearch, Fluentd и Kibana (уже без шуточек). У каждого элемента в этих стеках есть своя роль и выход из строя одного из них зачастую нарушает работу остальных. В этой статье поговорим об ELK-стеке, а в частности — о двух его элементах: Logstash и Elasticsearch.
Статья не является исчерпывающим руководством по тонкостям установки и настройки этих элементов. Это скорее обзор некоторых полезных фич и чек-лист по мониторингу не самых очевидных моментов, чтобы минимизировать потерю сообщений, проходящих через ELK. Также стоит упомянуть, что в статье мы не коснемся тем, связанных с программами-коллекторами (посредством чего сообщения попадают в Logstash) из-за их великого разнообразия: речь пойдет только о core-компонентах.
Logstash
Logstash, как правило, выступает для сообщений посредником, трансферной зоной. Он хранит эти сообщения в оперативной памяти, что является эффективным с точки зрения скорости их обработки, но чревато их потерей при перезапуске logstash. Также возможен сценарий, когда сообщений в очереди набирается настолько много (например, Elasticsearch перезапускается и недоступен), что Logstash начинает утекать по памяти, OOM-иться и перезапускается, поднимаясь уже «пустым».
Persistent Queue
Если через Logstash проходят важные сообщения, потеря которых критична (например, когда он выступает в роли consumer’а какого-либо брокера сообщений) или если нам необходимо переждать возможный большой даунтайм — например, во время тех. работ — со стороны получателя сообщений (обычно это Elasticsearch), можно прибегнуть к использованию persistent queue (документация). Это настройка Logstash, позволяющая хранить очереди на диске.
Также обратим внимание на queue.max_bytes — общая емкость очереди. Значение по умолчанию — 1 Гб. При его достижении (т.е. если у нас скопилось файлов очереди на 1 Гб) новые сообщения Logstash не принимает, пока очередь не начнет разбираться и в ней не появятся свободные места. Если мы настроили PV для persistent queue размером, например, 4 Гб, следует не забыть изменить эту переменную.
Еще из интересного: persistent queue хранит очереди в файлах, называемых страницами. Как только страница достигает определенного размера — queue.page_capacity (по умолчанию 64 Мб), — она становится неизменяемой, т.е. блокируется для записи (ждет, пока ее сообщения будут разобраны). После этого создается новая активная страница, которая аналогично ждет, пока не вырастет до размера queue.page_capacity … Каждая страница хранит какое-то количество сообщений и, если хотя бы одно сообщение из этой страницы не было отправлено, страница не будет удалена с диска (и будет занимать место, установленное в queue.max_bytes ). По этой причине выставлять большое значение для queue.page_capacity не рекомендуется.
Подведем краткий итог. Persistent queue отлично подойдет, если вам важно минимизировать потерю сообщений, однако желательно протестировать его перед эксплуатацией в production-окружении, т.к. сохранение сообщений на диске (вместо оперативной памяти) может повлечь за собой небольшую потерю в производительности. Пример теста производительности можно найти в официальном блоге Elastic.
Dead Letter Queue
Раз уж мы заговорили о persistent queue, что позволяет добиться минимизации потери сообщений, стоит рассказать и про dead letter queue (документация). Эта функция позволяет сохранять сообщения с ошибкой маппинга. Часто их оказывается больше, чем ожидалось. Начнем с нескольких «но»:
DLQ работает только с сообщениями, которые изначально адресовались в Elasticsearch, т.е. DLQ будет собирать сообщения с неудачным маппингом только у тех пайплайнов, output которых был настроен на Elasticsearch.
Сообщения с ошибкой маппинга Logstash складывает локально на диск в файлы. Он умеет отправлять эти сообщения в Elasticsearch при помощи input-плагина DLQ, но файлы эти с диска после отправки он не удалит.
1. Мы создаем новый пайплайн dead-letter-queue-main.conf :
2. Мы создали пайплайн, но DLQ еще не включили. Для этого в pipelines.yml для main-пайплайна включаем DLQ и добавляем в список пайплайнов наш dead-letter-queue-main.conf :
Однако стоит обратить внимание на то, что сами сообщения DLQ с диска не удаляются — это еще не реализовано. Есть разные способы того, как с этим справляются пользователи, однако официально решения пока нет.
DLQ будет полезен, если вы стали замечать, что какие-то сообщения не доходят до Elasticsearch или просто хотите обезопаситься от этого. Подобное возможно, если структура сообщений меняется и Elasticsearch не может их обработать. В этом случае DLQ пригодится, однако помните, что эта функция еще не доведена до совершенства и некоторые аспекты применения приходится додумывать самостоятельно (как для случая с удалением DLQ с диска).
Elasticsearch
Elasticsearch можно назвать центром системы — он хранит наши сообщения. В этой части хочется упомянуть несколько моментов, которые позволят следить за его здоровьем.
Мониторинг
Начнем с того, что у Elastic-стека есть расширение X-Pack, которое содержит в себе много дополнительного функционала, платного и бесплатного. Начиная с версии 6.3 бесплатный функционал поставляется в стандартных сборках стека (basic-версия включена по умолчанию).
Весь список функций, предоставляемых X-Pack, можно посмотреть на официальном сайте. В столбце «BASIC — FREE AND OPEN» перечислено то, что доступно бесплатно.
NB. Что касается платных подписок — какой-то конкретной цены нет, она индивидуальна для каждого проекта и строится относительно задействованных ресурсов. Если открыть страницу с ценами, то для кластеров self-hosted вместо цены мы увидим кнопку «Contact us».
Итак, вернемся к бесплатной версии: некоторые функции в ней включены по умолчанию, а некоторые необходимо включить самим.
Мониторинг состояния узла Elasticsearch Подробная информация по конкретному индексу
Аналогичным способом можно включить мониторинг для Logstash, добавив xpack.monitoring.enabled: true и xpack.monitoring.elasticsearch.hosts: «адрес_эластика:9200» (однако является legacy-решением начиная с релиза 7.9.0 от августа прошлого года).
Мониторинг состояния узла logstash
Также мы можем настроить авторизацию для своего кластера, включая окно авторизации для Kibana. Этому посвящен раздел Security. X-Pack содержит в себе много интересного функционала даже в бесплатной версии, однако часто случается так, что какие-то функции бесплатной фичи не работают с basic-лицензией.
Мониторинг, предоставляемый X-Pack’ом, — это просто красивая информативная панель, которая умеет показывать графики, что сможет нарисовать не каждый экспортер. Однако не стоит полностью на него полагаться, т.к. данные о мониторинге Elasticsearch хранятся в индексах, хранящихся в этом же Elasticsearch. Из-за этого система не кажется надежной (если у вас Elasticsearch из одного узла, то и вовсе таковой не является).
В связи с этим в официальной документации упоминается, что правильный подход — когда для production-контура у вас есть отдельный кластер для мониторинга. Для полноценного мониторинга узла необходимо настроить экспортер для самого Elasticsearch, чтобы следить за здоровьем кластера, unassigned-шардами, состоянием узлов. и еще экспортер для самой виртуальной машины для мониторинга нагрузки и свободного места на диске. Тут хочется обратить внимание на watermark.
Watermark
При настройке алертинга о заканчивающемся месте на диске стоит принимать во внимание watermark. Это настройка Elasticsearch, которая следит за свободным местом на диске, на который Elasticsearch складывает данные. В зависимости от объема оставшегося места разворачивается один из сценариев:
Последний вариант (flood_stage) может быть болезненным, т.к. при read_only_allow_delete удалять индексы можно, но документы из них — нет.
Менять настройки индекса, создавать шаблоны можно через запросы к Elasticsearch API прямо curl’ом (подробнее см. ниже) или через специальный UI — Cerebro.
При настройке мониторинга хоста, на котором установлен узел Elasticsearch, обязательно стоит учитывать параметры watermark. Также стоит обратить внимание, что значения у параметров watermark можно устанавливать не только в процентах свободного дискового объема, но и в единицах измерения этого самого объема. Это очень полезно, если используются большие диски: ведь не так критично, если у терабайтного диска занято 85% места, для таких случаев можно выставить и значения вроде 150 Гб.
Cheat sheet
… или просто прописать: NODE_IP=»ip_узла_эластика:9200″
Общие запросы
1. Посмотреть версию Elasticsearch:
2. Проверить здоровье кластера. Если статус green — все отлично. В противном случае, вероятнее всего, у нас есть unassigned shards:
3. Проверить здоровье узлов:
4. Список узлов, их роли и нагрузка на них:
В поле node.role можно увидеть «Поле Чудес» из букв. Расшифровка:
Master eligible node ( m );
5. Статистика по занимаемому месту на узлах и по количеству шардов на них:
6. Посмотреть список плагинов:
7. Посмотреть настройки кластера, включая дефолтные:
8. Проверить значения watermark:
Индексы, шарды
1. Посмотреть список индексов:
2. Список индексов, отсортированный по размеру:
3. Посмотреть настройки индекса:
4. Снять read-only с индекса:
6. Посмотреть список unassigned shards:
7. Проверить, почему не размещаются шарды:
8. Удалить реплика-шард для индекса:
9. Удалить индекс/шард:
Шаблоны
2. Смотреть настройки шаблона:
3. Пример создания шаблона:
Заключение
Logstash выступает посредником в трансфере сообщений. Основная его задача — правильно обработать сообщение ( filter ) и отправить его дальше ( output ). Persistent и Dead Letter Queue помогут эффективно решать эти задачи, однако в первом случае мы заплатим за это производительностью, а во втором — столкнемся с сыростью решения.
Elasticsearch — центр нашей системы. Не важно, собирает он логи или задействован в поисковой системе, — в любом случае необходимо следить за его состоянием. Даже в базовой версии X-Pack можно настроить неплохой сбор статистики о индексах и состоянии узлов. Также обязательно стоит обратить внимание на watermark: часто о нем забывают при настройке алертинга.