Стек ELK для хранения данных измерения

Question

В нашем проекте мы используем стек ELK для хранения журналов в централизованном месте. Однако я заметил, что последние версии ElasticSearch поддерживают различные агрегации. Кроме того, Kibana 4 поддерживает отличные графические способы построения графиков. Даже последние версии grafana теперь могут работать с источником данных Elastic Search 2.

Итак, все это означает, что стек ELK теперь можно использовать для хранения информации о замерах, собранной внутри системы, или он по-прежнему не может считаться серьезным конкурентом существующим решениям: графит, приток db и т. Д. Если да, то кто-нибудь использует ELK для измерения в производстве? Не могли бы вы поделиться своим опытом?

Для уточнения понятий, я рассматриваю данные измерений как нечто, что можно агрегировать и показать в графике с течением времени, в отличие от обычного сообщения журнала, где выполняется основной прецедент.

спасибо заранее

Answer 1

Да, вы можете использовать Elasticsearch для хранения и анализа временных рядов данных.

Чтобы быть более точным - это зависит от вашего использования.. Для примера в моего варианта использования (исторический данные цены клеща финансового инструмента, в развитии) Я могу получить 40,000 документов вставленных/сек (~ 125 байт документов с 11 полей в каждом - 1 метку времени, строки и десятичные, а это означает 5МБЫ/с полезными данными) для 14 ч/сутки, на одном узле (большой современный сервер с 192GB RAM) при поддержке корпоративной сети SAN (который при поддержке прядильных дисков, а не SSD!). Я пошел хранить до 1TB данных, но я предсказываю, что 2-4TB также может работать на одном узле.

Все это с конфигурационными настройками по умолчанию, за исключением ES_HEAP_SIZE из 30 ГБ. Я подозреваю, что можно было бы значительно повысить производительность записи на этом оборудовании с некоторой настройкой (например, мне показалось странным, что устройство iostat сообщает устройство на 25-30%, как если бы Elastic ограничивал его/сохранял ввод/вывод полосы пропускания для чтения или слияния ... но также может быть, что% util является нереалистичным показателем для устройств SAN ..)

Производительность запроса также прекрасна - запросы/графики Kibana возвращаются быстро, пока вы ограничиваете набор данных результатов со временем и/или другие поля.

В этом случае вы бы не использовать Logstash, чтобы загрузить данные, но объемные вставки больших партий непосредственно в Elasticsearch. https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html

Вы также должны определить отображениеhttps://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html, чтобы убедиться, что упругими разбирают ваши данные, как вы хотите (номер, дату и т.д ..) создает разыскиваемый уровень индексации, и т.д ..

Другие рекомендуемые методы для этого случая использования должны использовать отдельный индекс для каждого дня (или месяц/неделю в зависимости от вашей скорости вставки), и убедитесь, что индекс создается с только достаточно черепков, чтобы держать 1 день данных (по умолчанию новые индексы создаются с 5 осколками, а производительность осколков начинает ухудшаться после того, как осколок растет на определенный размер - обычно несколько десятков ГБ, но может отличаться для вашего варианта использования - вам нужно измерить/эксперимент).

Использование Elasticsearch aliaseshttps://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html помогает справляться с несколькими индексами и является рекомендуемой в целом рекомендуемой практикой.