Использую salt уже 3 года. На данный момент число машин (физических и виртуальных) превысило 7000. Сперва использовали стандартную конфигурацию с мастером и миньонами. Работало плохо, подвисали и мастера и миньоны. Перешли на salt-ssh. Стабильность сильно улучшилась, но, к сожалению, salt-ssh нелюбимое дитя saltstack и развивается по остаточному принципу. В процессе работы были обнаружены очень неприятные баги с race conditions. Зафайлил их на гитхабе, позже пофиксил локально через патчи, обновил issue на гитхабе, реакции нет.
Общие претензии к salt следующие:
1. Плохое тестирование, новые версии часто ломают обратную совместимость, каждое обновление до новой версии это боль.
2. Нет версионности для стейтов. Внес изменения, выкатил их, захотел откатить — и вот тут начинаются танцы с саблями, штатных средств нет.
3. Конкретно в salt-ssh очень сложна отладка.
4. salt не отслеживает, какие файлы он создал. Если вы создали файл в стейте, а в следующей версии этот файл должен отсутствовать вам надо добавить явную логику по удалению этого файла, salt не может этого сделать автоматически.
5. В общем и целом пользователи (разработчики) жалуются, что salt не удобен.
6. Код salt крайне сложен для понимания, использует очень много питоновской магии.
К сожалению мы увязли в salt достаточно глубоко, переключиться на что-то другое в данный момент невозможно. Если бы такая возможность была — я бы смотрел в сторону ansible.
Еще к недостаткам salt-ssh можно отнести сложность отладки. Для того, чтобы понять, что пошло не так на клиенте надо прогнать salt-ssh с высоким уровнем логирования, вычленить команду для запуска salt на клиенте, залогиниться на клиента, выполнить команду предварительно отредактировав ее и добавив логирования.
Я использую salt достаточно давно на большом парке серверов (сейчас больше 6000 машин). Сперва использовался режим master-minion. Работало очень не надежно, подвисали и мастера и миньоны. Я перевел все на salt-ssh, стало работать лучше. Тем не менее у меня к salt много претензий:
1. У них явно есть проблемы с тестированием и сохранением обратной совместимости. Каждое обновление версии это боль. Сейчас мы используем 2015.8.7.
2. У нас salt в частности используется для конфигурирования pam. Недавно столкнулись с ситуацией, когда некоторые конфигурационные файлы pam на отдельных машинах оказались пустыми. Залогиниться невозможно, крон не работает. Повторяемо воспроизвести не получается. Начал диалог с ребятами из saltstack-а, но они ожидаемо помочь не смогли (потому что не смогли воспроизвести). Мое доверие к salt сильно подорвано.
3. Для работы salt на клиенте должен стоять python, у которого есть свои проблемы. В результате пришлось собирать python-2.7.10, ставить его в /opt вне всех путей, чтобы никому не мешал и хачить salt, чтобы использовал этот python.
4. Общее мнение людей, которые используют у нас salt — не удобно.
Все свои проекты и деплою через пакеты. Это позволяет и откатить быстро если что не так (в salt откат мягко говоря не прост, версионирования стейтов нет, chef в этом смысле много удобнее), и сделать dpkg-divert чтобы обновление другого пакета не испортило кастомный конфиг.
Задача была поставлена именно искать по всем логам всех сервисов, чтобы в случае проблем можно было по session_id проследить как шел запрос и где именно возникли неполадки.
Напишите, пожалуйста, какие нагрузочные тесты вы проводили на вашей системе. Можете ли вы оценить какие ресурсы потребуются, чтобы обрабатывать 400к логов в секунду с трафиком порядка 130 мб/с и хранением данных за последние 7 дней?
Кратко подытоживая: причины отказа низкая производительность, плохое масштабирование и проблемы со стабильностью. На данный момент у меня кластер А 10 машин (каждая машина 24 ядра 48 гб памяти) с трудом тянет 15к логов в секунду. На кластере Б памяти 128 гб на машину, что дает порядка 50к логов в секунду. Это при дневных индексах, 7-ми дневно ретеншене и около 1000 шард на кластер А, около 3000 шард на кластер Б. Если переключится на часовые индексы и снизить ретеншен до 3-х дней количество шард на кластере Б поднимается до 25к и он начинает падать с завидной периодичностью. У всех машин стоит по 4 диска 1.8тб. На кластере А количество документов около 7г и диски заняты от 26% до 45%, на кластере Б документов около 3.5г, диски заняты от 9% до 14%. Полный траффик логов у меня 130 логов/с, что значит мне нужно кластер А расширить до как минимум 200 машин, что будет 2 миллиона долларов только на покупку железа, обслуживание встанет в отдельные деньги. Глядя на подобные суммы начинаешь уже задумываться о спланке, который безумно дорог, но тебе вообще не надо думать об инфраструктуре.
Real time log streaming пока в стадии обдумывания. Самое простое решение, которое на данный момент обсуждается, это логировать все в локальные файлы на лог сервере с очень короткой ротацией и tail-ом отдавать их по http возможно фильтруя grep-ом. Но это предварительно, возможно все будет сложнее.
Отвечая на ваш вопрос об ограничении трафика в ELK: да, на маленьких объемах все работает нормально. Только вот объяснить людям, что не надо лить в логи все подряд (у меня был прецедент, когда начали заливали целиком http ответы, каждый log entry был за 100к) задача крайне не простая. И опять же мое крайне субъективное мнение: когда кто-то требует ELK утверждая, что только так он может гарантировать нормальную работу своего сервиса скорее всего что-то сильно не так с самим сервисом.
Прежде чем строить ELK инфраструктуру настоятельно рекомендую оценить потянет ли она ваши объемы логирования и во что выльется поддержка. Я уже больше года пытаюсь приручить этого зверя (в частности для логирования из контейнеров) и на данный момент принято решение отказаться от ELK, использовать обычный syslog, логи загружать в hadoop и анализировать уже там. Для отслеживания ситуации в реальном времени использовать стриминг on demand возможно с минимальной фильтрацией. ELK не взлетел, хотя мы очень старались.
У меня кластер из 10 физических машин 24 ядра 48гб памяти плюс 3 мастера на витруалках 4 ядра 8гб. Сегодня, к слову прорезались ребята из elastic. Я попросил их оценить что нам нужно, чтобы обрабатывать 400к логов/с 130мб/с логов в пике (в среднем 250к логов/с и 80мб/с) при средней длине лога 1к и хранении 2-х недель логов. Они мне написали, что 500 машин с 64гб. Я уточнил, а что если логи храним 3 дня и у машин 128гб. Оказалось, что достаточно 15 нод на данные плюс 3 мастера. Они также мне объяснили, что исходят из 1гб памяти на 32 гб на диске. Все это звучит подозрительно, но получил добро от начальства на эксперимент, заказал дополнительную память для кластера — посмотрим, как оно себя поведет.
Я получил на поддержку 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-ов.
Буквально только что ставил эксперименты по производительности elasticsearch кластера. Сгенерировал логсташем файл с миллионом json логами и заливал их в кластер программой на си, которая читала данные со стандартного ввода и загружала в кластер через http bulk api (размер запроса ограничен 1мб). Экспериментировал на 2-х кластерах из 4-х и 10-ти машин (48гб, 24-х ядерный ксеон 2ггц). На 4-х машинном кластере удалось выжать 200к логов в секунду, на 10-ти машинном 170к. Я допускаю, что что-то делал не так и из конфигураций выше можно выжать больше, но предварительный вывод, что у elasticsearch кластера не все хорошо с масштабированием. С учетом того, что мне надо обрабатывать порядка 2м логов в секунду похоже придется искать нечто отличное от elasticsearch. Буду крайне признателен за наводки на работающие решения.
Общие претензии к salt следующие:
1. Плохое тестирование, новые версии часто ломают обратную совместимость, каждое обновление до новой версии это боль.
2. Нет версионности для стейтов. Внес изменения, выкатил их, захотел откатить — и вот тут начинаются танцы с саблями, штатных средств нет.
3. Конкретно в salt-ssh очень сложна отладка.
4. salt не отслеживает, какие файлы он создал. Если вы создали файл в стейте, а в следующей версии этот файл должен отсутствовать вам надо добавить явную логику по удалению этого файла, salt не может этого сделать автоматически.
5. В общем и целом пользователи (разработчики) жалуются, что salt не удобен.
6. Код salt крайне сложен для понимания, использует очень много питоновской магии.
К сожалению мы увязли в salt достаточно глубоко, переключиться на что-то другое в данный момент невозможно. Если бы такая возможность была — я бы смотрел в сторону ansible.
1. У них явно есть проблемы с тестированием и сохранением обратной совместимости. Каждое обновление версии это боль. Сейчас мы используем 2015.8.7.
2. У нас salt в частности используется для конфигурирования pam. Недавно столкнулись с ситуацией, когда некоторые конфигурационные файлы pam на отдельных машинах оказались пустыми. Залогиниться невозможно, крон не работает. Повторяемо воспроизвести не получается. Начал диалог с ребятами из saltstack-а, но они ожидаемо помочь не смогли (потому что не смогли воспроизвести). Мое доверие к salt сильно подорвано.
3. Для работы salt на клиенте должен стоять python, у которого есть свои проблемы. В результате пришлось собирать python-2.7.10, ставить его в /opt вне всех путей, чтобы никому не мешал и хачить salt, чтобы использовал этот python.
4. Общее мнение людей, которые используют у нас salt — не удобно.
Все свои проекты и деплою через пакеты. Это позволяет и откатить быстро если что не так (в salt откат мягко говоря не прост, версионирования стейтов нет, chef в этом смысле много удобнее), и сделать dpkg-divert чтобы обновление другого пакета не испортило кастомный конфиг.
Когда будет время буду смотреть на ansible.
Я давно и безуспешно пытаюсь построить инфрастркутуру для логирования на базе ELK, вот здесь детали:
https://habrahabr.ru/post/282866/#comment_8881108
https://habrahabr.ru/company/uteam/blog/278729/#comment_8799489
https://habrahabr.ru/post/275815/#comment_8751947
Задача была поставлена именно искать по всем логам всех сервисов, чтобы в случае проблем можно было по session_id проследить как шел запрос и где именно возникли неполадки.
https://habrahabr.ru/company/uteam/blog/278729/#comment_8799489
https://habrahabr.ru/post/275815/#comment_8751947
Кратко подытоживая: причины отказа низкая производительность, плохое масштабирование и проблемы со стабильностью. На данный момент у меня кластер А 10 машин (каждая машина 24 ядра 48 гб памяти) с трудом тянет 15к логов в секунду. На кластере Б памяти 128 гб на машину, что дает порядка 50к логов в секунду. Это при дневных индексах, 7-ми дневно ретеншене и около 1000 шард на кластер А, около 3000 шард на кластер Б. Если переключится на часовые индексы и снизить ретеншен до 3-х дней количество шард на кластере Б поднимается до 25к и он начинает падать с завидной периодичностью. У всех машин стоит по 4 диска 1.8тб. На кластере А количество документов около 7г и диски заняты от 26% до 45%, на кластере Б документов около 3.5г, диски заняты от 9% до 14%. Полный траффик логов у меня 130 логов/с, что значит мне нужно кластер А расширить до как минимум 200 машин, что будет 2 миллиона долларов только на покупку железа, обслуживание встанет в отдельные деньги. Глядя на подобные суммы начинаешь уже задумываться о спланке, который безумно дорог, но тебе вообще не надо думать об инфраструктуре.
Real time log streaming пока в стадии обдумывания. Самое простое решение, которое на данный момент обсуждается, это логировать все в локальные файлы на лог сервере с очень короткой ротацией и tail-ом отдавать их по http возможно фильтруя grep-ом. Но это предварительно, возможно все будет сложнее.
Отвечая на ваш вопрос об ограничении трафика в ELK: да, на маленьких объемах все работает нормально. Только вот объяснить людям, что не надо лить в логи все подряд (у меня был прецедент, когда начали заливали целиком http ответы, каждый log entry был за 100к) задача крайне не простая. И опять же мое крайне субъективное мнение: когда кто-то требует ELK утверждая, что только так он может гарантировать нормальную работу своего сервиса скорее всего что-то сильно не так с самим сервисом.