Нет, не смотрели. За счет кафки мы хотели получить несколько плюсов:
— возможность накапливать логи какое-то продолжительное время в случае проблем с лог-кластером
— возможность повторно направить логи, если индекс по какой-то причине умер (ни разу не пользовались правда еще)
У нас сейчас 1.5Тб логово во временном хранилище. Нам это обходится в 3000 рублей в месяц (аренда серверов, дополнительные диски для кафки). Поэтому redis вообще не вариант.
Теперь по пунктам.
1. Аналогично. У нас на уровне платформы реализовано аналогично. И да, это очень удобно когда все логи в едином формате. У нас еще есть небольшие проблемы с логами монолита, но это временно.
2. У нас за логи отвечает Nomad, он их складывает в определенном месте, где их filebeat по маске отправляет в кафку
4. Тэги в зависимости от хоста или от контейнера?
5. А сколько у вас инстансов Redis? Какой объем памяти? Если падает редис, поток логов переключается на другой инстанс? Сколько логов (по времени) может 1 инстанс продержать и какая политика по удалению старых?
7. Elastalert так и не попробовали. Хватает Prometheus+AlertManager его родной + слерты из графаны бэкапом.
kafka+zookeeper это несколько часов гугление о технологии и потом еще несколько на написание роли в saltstack. Все. На этом обслуживание данного стэка заканчивается (в нашем узком случае с логами). В части дополнительных затрат это стоило нам +6 SATA дисков по 2Тб (суммарно на 3 сервера).
Кубера пока нет, смотрим на него, но пока Nomad закрывает 99% потребностей оркестрации.
Logstash — был изначально, на переправе решили коней не менять, так как на нем достаточно большой уровень логики в части обогащения и упрощения логов. Если съезжать, то это отдельный проект на несколько месяцев, профита от которого, с точки зрения бизнеса, не будет вообще.
На fluentd смотрели, когда начинали модернизацию, оценили трудозатраты на переделку всего и поняли, что овчинка выделки не стоит. Возможно пересмотрим еще в будущем, так как сейчас уже вернули rsyslog вместо filebeat по некоторым направлениям.
Не всегда возможно определить что работает под капотом у интернет-проекта. До прихода в ЦИАН я и не подозревал о том, как это все работает. Поэтому, как мне кажется, количество RPS (количество пользователей, количество запросов, etc) на фронты не единственный верный показатель, но с его помощью можно хоть что-то сравнить.
Мы используем логи в ML не для мониторинга, а как один из компонентов поведенческого анализа. То, что делает Data Dog, похоже на базовые модели предсказания временных рядов (ARIMA, например) и поиск аномалий.
Мы сейчас начинаем развивать направление по предсказания завершения капасити кластеров на основе метрик node_exporter'а.
Да, мы параллельно отправляем все access-логи в ML, которые потом используются, например, для работы внутреннего антибота. Это, конечно, не единственная цель :)
Запрос проходит через разные микросервисы и монолиты, и попадает в разные топики Kafka и, в результате, в разные индексы эластика. Каждый топик обрабатывает своя пачка Logstash со своим pipeline. Простой фильтр тут вряд ли выйдет, особенно если учесть, что это надо будет писать на встроенном Ruby. Мне кажется что положительный эффект будет сильно меньше, чем затраченное на разработку время. Было бы интересно почитать об опыте Cloudflare, поищу.
Logstash у нас раньше были «тюнингованные». В последствии перешли на докер-образы с базовыми настройками по количеству пакетов, и т.п. Кастомными остались только pipeline'ы, отвечающие за обработку и обогащение логов.
Тюнинг Elasticsearch не настолько крут, что бы об этом писать. Вся кастомизация заключается в настройке кластера и индексов под профиль нагрузки, с указанием удобный watermark'ов, threshold'ов и отключением автоматической балансировки.
Я их воспринимаю, в первую очередь, как трекер + телефон. Телефон я заряжаю каждую ночь, поэтому не вижу проблемы так же заряжать часы (точней дочь это сама делает). Можно сэкономить зарят уменьшив время обновления — но смысл трекера тогда теряется. Опять же, контролировать заряд сложней (можно пропустить зарядку).
А почему не используете docker? В вашем случае настройка сервера свелась бы к установке docker, docker-compose, ctop :) и пару ролей на деплой продукта…
Не хочу что бы показалось рекламой, но, как мне кажется, все то же самое (накладывать инструменты на график котировок) можно на ресурсе ru.investing.com или я упустил какую-то важную составляющую?
— возможность накапливать логи какое-то продолжительное время в случае проблем с лог-кластером
— возможность повторно направить логи, если индекс по какой-то причине умер (ни разу не пользовались правда еще)
У нас сейчас 1.5Тб логово во временном хранилище. Нам это обходится в 3000 рублей в месяц (аренда серверов, дополнительные диски для кафки). Поэтому redis вообще не вариант.
Теперь по пунктам.
1. Аналогично. У нас на уровне платформы реализовано аналогично. И да, это очень удобно когда все логи в едином формате. У нас еще есть небольшие проблемы с логами монолита, но это временно.
2. У нас за логи отвечает Nomad, он их складывает в определенном месте, где их filebeat по маске отправляет в кафку
4. Тэги в зависимости от хоста или от контейнера?
5. А сколько у вас инстансов Redis? Какой объем памяти? Если падает редис, поток логов переключается на другой инстанс? Сколько логов (по времени) может 1 инстанс продержать и какая политика по удалению старых?
7. Elastalert так и не попробовали. Хватает Prometheus+AlertManager его родной + слерты из графаны бэкапом.
Logstash — был изначально, на переправе решили коней не менять, так как на нем достаточно большой уровень логики в части обогащения и упрощения логов. Если съезжать, то это отдельный проект на несколько месяцев, профита от которого, с точки зрения бизнеса, не будет вообще.
На fluentd смотрели, когда начинали модернизацию, оценили трудозатраты на переделку всего и поняли, что овчинка выделки не стоит. Возможно пересмотрим еще в будущем, так как сейчас уже вернули rsyslog вместо filebeat по некоторым направлениям.
Мы сейчас начинаем развивать направление по предсказания завершения капасити кластеров на основе метрик node_exporter'а.
Тюнинг Elasticsearch не настолько крут, что бы об этом писать. Вся кастомизация заключается в настройке кластера и индексов под профиль нагрузки, с указанием удобный watermark'ов, threshold'ов и отключением автоматической балансировки.