Комментарии 24
А вот расскажите мне, что вы делаете с ситуацией, когда по клику на строчку лога в кибане, она разворачивается, меняется размер колонок и текущая строчка (развёрнутая) улетает фиг знает куда? Сейчас это основное, что меня раздражает.
0
Кроме того, когда у вас относительно много данных (скажем, 500G), то ваш Elasticsearch после запуска будет еще около получаса просасывать эти данные, и в это время они будут недоступны.
Если не ошибаюсь — можно настроить число потоков, которые обрабатывают данные при рестарте эластика, и запуск будет происходить в разы быстрее?
0
Я получил на поддержку 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-ов.
+2
Во-первых, соболезную.
+3
Во-вторых, наверное, у вас очень много логов и довольно-таки экономичное железо. Для сравнения, у нас ELK живет на 16 ядрах и 31 Гб памяти (индексы дневные).
В-третих, de_dot… Вообще, с ним всё заранее понятно, такое нельзя делать быстро. Ну и он умеет ровно один уровень вложенности, что нам не подходило сразу, хотя если бы умел это было бы еще в 100 раз медленнее, по-этому пришлось убирать саму вложенность ;-).
В-третих, de_dot… Вообще, с ним всё заранее понятно, такое нельзя делать быстро. Ну и он умеет ровно один уровень вложенности, что нам не подходило сразу, хотя если бы умел это было бы еще в 100 раз медленнее, по-этому пришлось убирать саму вложенность ;-).
+2
У меня кластер из 10 физических машин 24 ядра 48гб памяти плюс 3 мастера на витруалках 4 ядра 8гб. Сегодня, к слову прорезались ребята из elastic. Я попросил их оценить что нам нужно, чтобы обрабатывать 400к логов/с 130мб/с логов в пике (в среднем 250к логов/с и 80мб/с) при средней длине лога 1к и хранении 2-х недель логов. Они мне написали, что 500 машин с 64гб. Я уточнил, а что если логи храним 3 дня и у машин 128гб. Оказалось, что достаточно 15 нод на данные плюс 3 мастера. Они также мне объяснили, что исходят из 1гб памяти на 32 гб на диске. Все это звучит подозрительно, но получил добро от начальства на эксперимент, заказал дополнительную память для кластера — посмотрим, как оно себя поведет.
0
Все это звучит подозрительно
Да, уж. Интересно что из этого получится, было бы очень интересно узнать (спасибо заранее).
Мы, вот, буквально вчера обесточили логи (в смысле, точки убрали) и стали слать их в ES v2. По первым ощущениям — сильно меньше грузит CPU и память. Хотя, конечно, могло сильно повлиять еще то что убрали вложенность и то что данных пока мало.
0
Я использую похожую связку — rsyslog + graylog, и influxdb на подхвате. Генерацией uuid занимается первый из бэкэндов, куда попадает запрос. Логи nginx нигде не используются поэтому необходимости lua в nginx пока нет. Приложения пишут параллельно в файл и в rsyslog в разных форматах (и в файл уровень логирования выше). Далее rsyslog всё отправляет в graylog. Единственная пока проблема, по какой то причине так и не удалось настроить триггеры в graylog, они просто ни на что не реагируют.
+1
Интересно. А из файла graylog не умеет? А (nested) json?
Насчет lua в nginx, на самом деле, это не первое грехопадение, давно мы уже… перешли на него. Есть ряд "мелких, файловых" вещей из-за которых не хотелось лишний раз трогать бакэнд. У нас вообще, проект скорее жив чем мертв при лежачем бакэнде.
Вероятно, об этом пойдет речь в следующих статьях (если интересно).
Насчет lua в nginx, на самом деле, это не первое грехопадение, давно мы уже… перешли на него. Есть ряд "мелких, файловых" вещей из-за которых не хотелось лишний раз трогать бакэнд. У нас вообще, проект скорее жив чем мертв при лежачем бакэнде.
Вероятно, об этом пойдет речь в следующих статьях (если интересно).
+2
Спасибо за статью, интересно. Года полтора назад я собирал сервер логирования logstash+elasticsearch данные отправлял из rsyslog-а на прямую, а так же из apach-а перенаправлением вывода в nc. Logstash+elasticsearch работали не очень стабильно с течением времени и объёма логов. Так же строил различные счётчики и визуализировал с помощью graphite. Теперь судя по всему, проект сильно развился с тех пор, нужно будет взглянуть ещё раз.
0
Вам спасибо, за внимание.
Я примерно на тех же версиях начинал первые тесты. Развились Logstash и Elasticsearch, похоже сильно, но только с переходом на v2. На v.1 я особых улучшений не заметил. Кибана тоже полностью преобразилась в 4-й версии (причем в обе стороны), мы долго привыкали. Но самое приятное для меня что появилось с тех пор это filebeat. Сколько было мучений с logstash-forwader-ом, сначала Go поставь, собери бинарник, сертификат сделай, и он ему еще и не нравится. Были даже спец. утилиты на гитхабах которые генерировали сертификат специально "чтобы нравился lоgstash-forwarder-у". Потом его даже форкнули в "log-courier" и выпилили обязательность шифрования).
Другие "beats" кстати тоже пока не пробовали. Возможно, будем (и расскажем).
Я примерно на тех же версиях начинал первые тесты. Развились Logstash и Elasticsearch, похоже сильно, но только с переходом на v2. На v.1 я особых улучшений не заметил. Кибана тоже полностью преобразилась в 4-й версии (причем в обе стороны), мы долго привыкали. Но самое приятное для меня что появилось с тех пор это filebeat. Сколько было мучений с logstash-forwader-ом, сначала Go поставь, собери бинарник, сертификат сделай, и он ему еще и не нравится. Были даже спец. утилиты на гитхабах которые генерировали сертификат специально "чтобы нравился lоgstash-forwarder-у". Потом его даже форкнули в "log-courier" и выпилили обязательность шифрования).
Другие "beats" кстати тоже пока не пробовали. Возможно, будем (и расскажем).
+1
За картинку — плюсик.
0
Товарищи, у кого-нибудь был опыт промышленной эксплуатации elasticsearh на винде? Есть ли какие-либо особенности?
0
P.S. В репозитарии Debian-а есть готовый пакет nginx-extras. Там сразу есть Lua и еще куча полезных модулей. Рекомендую, вместо того чтобы вкомпиливать модуль Lua руками
Только этот пакет собран с поддержкой стандартного Lua интерпретатора. Для использования LuaJIT компилятора придётся его пересобрать.
0
А можно поподробнее? Я наивно считал что раз nginx-extras тянет за собой libluajit, то jit всё-таки там используется. Это не так?
0
Можно проверить используется jit или нет http://stackoverflow.com/questions/19056429/how-to-check-if-nginx-uses-luajit-and-not-lua Мне пришлось пересобирать extras пакет для работы с LuaJIT.
0
Кажется вы переизобретаете graylog. Но в нем тоже не хватает части, которая будет следить за типами полей.
320Гб, 1 минута 13 секунд:
Это с дефолтным "cluster.routing.allocation.node_initial_primaries_recoveries: 4". Если у вас SSD — можно увеличить хоть до 1000. Но лучше уменьшить количество индексов и шардов.
когда у вас относительно много данных (скажем, 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. Но лучше уменьшить количество индексов и шардов.
0
Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?
Такое ощущение, что зря на 4ую перешел… визуализация ущербная или я не все изучил
Такое ощущение, что зря на 4ую перешел… визуализация ущербная или я не все изучил
0
Народ, кто-нить может дать ссылку на нормальный полный туториал по kibana 4?
https://www.elastic.co/guide/en/kibana/current/index.html
Такое ощущение, что зря на 4ую перешел…
У нас тоже так было. Что-то там было совсем нельзя, что-то частично, а что-то появлялось с новыми минорными релизами Кибаны.
+1
Написали статью на Хабре про машинное обучение в ELK. Может кому будет интересно.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kibana-мать или Зачем вам вообще нужны логи?