Как стать автором
Обновить

Комментарии 24

А вот расскажите мне, что вы делаете с ситуацией, когда по клику на строчку лога в кибане, она разворачивается, меняется размер колонок и текущая строчка (развёрнутая) улетает фиг знает куда? Сейчас это основное, что меня раздражает.
У меня такого, вроде бы, не происходит. Может, зависит от версии Кибаны и от размера экрана (там есть адаптивность). Скриншотом можете показать о чем речь?
Кроме того, когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные, и в это время они будут недоступны.

Если не ошибаюсь — можно настроить число потоков, которые обрабатывают данные при рестарте эластика, и запуск будет происходить в разы быстрее?
Не уверен, какие именно треды вы имеете ввиду, но недоутилизированности ядер при этом не наблюдали — все были в потолок. На сегодняшний день просто curator-ом закрываем всё что старше 2-х месяцев (делаем close) и ES поднимается в приемлемый срок (до 5 минут).
Я получил на поддержку ELK комплект, настроенный другими людьми. Там задействована кибана 3 (которая полностью живет на клиенте) и логсташ 1.0.1 (который не просто проапгрейдить, потому как завязан на версию логсташа из-за elasticsearch output-а). В этой системе используются индексы за день, так как при переключении на часовые индексы у кибаны начинаются проблемы с длиной урла. Логи хранятся за 2 недели. Из-за размера индекса перезагрузка инстанса elasticsearch занимает около суток (пока кластер опять не станет зеленым). В качестве входного буфера используется редис, емкости которого хватает минут на 40, потом начинаем терять логи. Я построил альтернативную систему: взял elasticsearch 1.74, kibana 4, переключился на часовые логи, стал хранить 3 дня логов и стал использовать кафку вместо редиса — стало лучше. Из-за сокращения времени хранения было решено сделать еще архивирование в хадуп кластер для доступа к старым данным. Последний пункт затянулся и вышел elasticksearch 2.x и вот тогда началось веселье. Для начала они поломали трайб ноды, а я их использовал для агрегации данных из разных датацентров. После некоторого общения худо-бедно починили. Потом оказалось, что новый elasticsearch не терпит конфликтов типов в отличие от 1.х. У меня приложений много, привести все к единообразию практически не возможно, стал писать лог каждого приложения в отдельный индекс — поплыла стабильность. Эмпирически выяснил, что критичным является количество шард. Количество документов влияет на стабильность гораздо меньше. После гугления и экспериментов выяснил, что ситуацию спасают выделенные elasticsearch master ноды. Стал поднимать, оказалось, что эти машины должны быть достаточно мощные, более-менее стабильных результатов удалось достичь с 3-мя мастерами 4 ядра 8 гб памяти, что обидно, потому как в каждый момент времени работает только один, остальные просто сидят на подхвате и тратят память. Ну и на сладкое наступил на грабли с точками в именах полей. Изменить это я не могу, попробовал использовать рекомендуемый фильтр de_dot — просела производительность. Пытался общаться с представителями elasticsearch, но они мне сразу сказали, что на мои вопросы будут отвечать если мы купим у них поддержку. Начал вести переговоры о покупке — ребята вообще пропали. В сухом остатке — очень много головной боли. Да, когда оно работает — очень удобно. Но уверенности в стабильности системы нет. Мы видимо будем переходить на систему, где elasticsearch будет держать только несколько последних часов логов плюс логи в хадупе, которые можно будет обработать при помощи map-reduce job-ов.
Во-первых, соболезную.
Во-вторых, наверное, у вас очень много логов и довольно-таки экономичное железо. Для сравнения, у нас ELK живет на 16 ядрах и 31 Гб памяти (индексы дневные).
В-третих, de_dot… Вообще, с ним всё заранее понятно, такое нельзя делать быстро. Ну и он умеет ровно один уровень вложенности, что нам не подходило сразу, хотя если бы умел это было бы еще в 100 раз медленнее, по-этому пришлось убирать саму вложенность ;-).
У меня кластер из 10 физических машин 24 ядра 48гб памяти плюс 3 мастера на витруалках 4 ядра 8гб. Сегодня, к слову прорезались ребята из elastic. Я попросил их оценить что нам нужно, чтобы обрабатывать 400к логов/с 130мб/с логов в пике (в среднем 250к логов/с и 80мб/с) при средней длине лога 1к и хранении 2-х недель логов. Они мне написали, что 500 машин с 64гб. Я уточнил, а что если логи храним 3 дня и у машин 128гб. Оказалось, что достаточно 15 нод на данные плюс 3 мастера. Они также мне объяснили, что исходят из 1гб памяти на 32 гб на диске. Все это звучит подозрительно, но получил добро от начальства на эксперимент, заказал дополнительную память для кластера — посмотрим, как оно себя поведет.
Все это звучит подозрительно

Да, уж. Интересно что из этого получится, было бы очень интересно узнать (спасибо заранее).

Мы, вот, буквально вчера обесточили логи (в смысле, точки убрали) и стали слать их в ES v2. По первым ощущениям — сильно меньше грузит CPU и память. Хотя, конечно, могло сильно повлиять еще то что убрали вложенность и то что данных пока мало.
Я использую похожую связку — rsyslog + graylog, и influxdb на подхвате. Генерацией uuid занимается первый из бэкэндов, куда попадает запрос. Логи nginx нигде не используются поэтому необходимости lua в nginx пока нет. Приложения пишут параллельно в файл и в rsyslog в разных форматах (и в файл уровень логирования выше). Далее rsyslog всё отправляет в graylog. Единственная пока проблема, по какой то причине так и не удалось настроить триггеры в graylog, они просто ни на что не реагируют.
Интересно. А из файла graylog не умеет? А (nested) json?
Насчет lua в nginx, на самом деле, это не первое грехопадение, давно мы уже… перешли на него. Есть ряд "мелких, файловых" вещей из-за которых не хотелось лишний раз трогать бакэнд. У нас вообще, проект скорее жив чем мертв при лежачем бакэнде.
Вероятно, об этом пойдет речь в следующих статьях (если интересно).
Спасибо за статью, интересно. Года полтора назад я собирал сервер логирования logstash+elasticsearch данные отправлял из rsyslog-а на прямую, а так же из apach-а перенаправлением вывода в nc. Logstash+elasticsearch работали не очень стабильно с течением времени и объёма логов. Так же строил различные счётчики и визуализировал с помощью graphite. Теперь судя по всему, проект сильно развился с тех пор, нужно будет взглянуть ещё раз.
Вам спасибо, за внимание.

Я примерно на тех же версиях начинал первые тесты. Развились Logstash и Elasticsearch, похоже сильно, но только с переходом на v2. На v.1 я особых улучшений не заметил. Кибана тоже полностью преобразилась в 4-й версии (причем в обе стороны), мы долго привыкали. Но самое приятное для меня что появилось с тех пор это filebeat. Сколько было мучений с logstash-forwader-ом, сначала Go поставь, собери бинарник, сертификат сделай, и он ему еще и не нравится. Были даже спец. утилиты на гитхабах которые генерировали сертификат специально "чтобы нравился lоgstash-forwarder-у". Потом его даже форкнули в "log-courier" и выпилили обязательность шифрования).

Другие "beats" кстати тоже пока не пробовали. Возможно, будем (и расскажем).
Товарищи, у кого-нибудь был опыт промышленной эксплуатации elasticsearh на винде? Есть ли какие-либо особенности?
P.S. В репозитарии Debian-а есть готовый пакет nginx-extras. Там сразу есть Lua и еще куча полезных модулей. Рекомендую, вместо того чтобы вкомпиливать модуль Lua руками

Только этот пакет собран с поддержкой стандартного Lua интерпретатора. Для использования LuaJIT компилятора придётся его пересобрать.
А можно поподробнее? Я наивно считал что раз nginx-extras тянет за собой libluajit, то jit всё-таки там используется. Это не так?
У меня выдало LuaJIT 2.0.4 на сервере с debian 7. Nginx-extras ставил с официального репа. В любом случае, спасибо за инфу.
Кажется вы переизобретаете graylog. Но в нем тоже не хватает части, которая будет следить за типами полей.

когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные

320Гб, 1 минута 13 секунд:

[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ du -sh /var/lib/elasticsearch 
320G    /var/lib/elasticsearch
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ docker kill compose_elasticsearch_1
compose_elasticsearch_1
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ docker start compose_elasticsearch_1
compose_elasticsearch_1
[ ei-grad@ei-grad ~/repos/deal/devops git:master* ]
→ time (while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do sleep 1; done)
( while [ `http :9200/_cluster/health | jq .status` != '"green"' ]; do; sleep)  12,67s user 0,94s system 18% cpu 1:12,43 total

Это с дефолтным "cluster.routing.allocation.node_initial_primaries_recoveries: 4". Если у вас SSD — можно увеличить хоть до 1000. Но лучше уменьшить количество индексов и шардов.
А это на каком (хотя бы примерно) железе? И какие индексы, дневные/месячные/… ?
Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?
Такое ощущение, что зря на 4ую перешел… визуализация ущербная или я не все изучил
Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?

https://www.elastic.co/guide/en/kibana/current/index.html

Такое ощущение, что зря на 4ую перешел…

У нас тоже так было. Что-то там было совсем нельзя, что-то частично, а что-то появлялось с новыми минорными релизами Кибаны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий