По-моему, в статье описан очень частный случай подготовки и проведения релиза какого-то очень большого монолита (понимаю, что это личный опыт и обстоятельства автора). В мире микросервисов, к примеру, обычно совсем всё не так — там задолбаешься по 20 раз в день назначать «ответственного» и «делать таблицы в вики». Такие глобальные релизы — не всегда хорошо. Мое мнение — надо стремиться к бОльшей частоте релизов, но ни в коем случае не жертвовать при этом качеством продукта.
Кстати, «Релиз одной кнопкой» — давно уже не миф, а вполне себе ожидаемая реальность на проектах, где действительно работает концепт «DevOps».
У нас в локальный Logstash (Shipper) данные входят не только от Docker демона, но и, к примеру, от HAProxy (он не умеет в stdout, так что наш Logstash слушает отдельный порт — Syslog/UDP). То есть, тэги присваиваются в зависимости от того, откуда пришел эвент.
А сколько у вас инстансов Redis?
В проде — 4. Средний объем входящих логов в день — 100-150ГБ. Храним в Эластике последний месяц, но индексы старше недели закрываем.
Какой объем памяти?
Redis контейнеры у нас запущены на тех же хостах, что и некоторые остальные компоненты логгинг платформы, так что им не вся память отдана. Но большую часть времени они пустые и в них задерживается не больше сотни эвентов — остальное выгребается Logstash.
Если падает редис, поток логов переключается на другой инстанс?
По умолчанию, Losgtash (Shipper) шлёт логи в Redis по принципу Round robin, так что нагрузка сразу распределяется. Если инстанс Redis отгнивает по какой-то причине, Logstash очень быстро это обнаруживает и перестает слать в этот инстанс логи.
Сколько логов (по времени) может 1 инстанс продержать?
Наш практический опыт — чуть более часа с недоступным Elasticsearch. Прошло всё нормально — после включения кластера, естественно, был большой всплеск нагрузки, но, насколько мы разобрались, мы ничего не потеряли.
А Вы не смотрели в сторону Redis вместо Kafka в качестве промежуточного буфера? Очень простой и невероятно производительный. Наша архитектура логгирования такая:
1. Микросервисы пишут логи в формате json в stdout (написана общая библиотека под наши платформы, которая занимается генерацией json, — Node.js, Java, Python, .NET Core).
2. Docker демон настроен слать логи в 172.17.0.1 по протоколу Gelf по UDP без сжатия (показал себя с лучшей стороны в части производительности).
3. На каждом сервере запущен Logstash (Shipper), который слушает Gelf/UDP трафик и принимает логи от Docker демона. Понимаю, что Logstash выглядит как оверкилл, но в нашем случае хосты достаточно большие (по 130+ контейнеров на хост, Nx64GB RAM), время его запуска мало, а буферизировать в себе он может достаточное для нас количество логов (это если логгинг кластер недоступен).
4. Эти инстансы Logstash (Shippers, из #3) никак логи не модифицируют, только добавляют пару тэгов и отправляют в кластер логгирования, в Redis в различные Redis Lists в зависимости от тегов.
5. На стороне логгинг кластера логи приезжают в Redis (используем standalone инстансы).
6. Далее инстансы Logstash (Indexer) забирают логи из Redis, обрабатывают их (фильтры Json, Grok) и складывают в различные индексы кластера Elasticsearch.
7. Дополнительно есть Elastalert, который имеет кучу правил и если что не так — шлет нам сообщения.
Несколько замечаний:
1. Идея писать логи сразу в формате Json оказалась очень удачной — с одной стороны, используя глобальные общие библиотеки для логгирования, мы можем достаточно хорошо стандартизировать основную часть логов (у нас более 550 различных микросервисов), а с другой стороны — дать гибкость в добавлении любого количества кастомных полей к лог-записям.
2. Через Redis мы также пропускаем логи из различных Filebeat.
3. Все компоненты системы логгирования (да и вообще всё у нас) запущены в Docker контейнерах
4. У нас нет Kubernetes/etc. Старый добрый (на самом деле нет) Swarm (это который ещё до Docker Swarm Mode).
Сообщаем докер демону, чтобы смотрел в новую директорию. Тут два пути: либо через флаг -g указать демону на новый путь, либо конфиги systemd
На самом деле, есть ещё как минимум два варианта:
1. Симлинк (мы его используем): ln -s /data/docker /var/lib/docker.
2. Монтировать большой раздел для докера сразу в /var/lib/docker.
А мне очень и очень понравилось. Прочитал на одном дыхании от начала до конца. Я являюсь поклонником фантастики и прочитал очень много разных фантастических произведений, но эта книга меня неожиданно сильно зацепила. Мне понравилось всё, без единого исключения.
Это не злость или враждебность, я не это имел в виду. Это скорее искренее удивление от того, что обычно в блогах компаний пишут интересные вещи. Если компания хочет заявить о себе, то можно было бы написать про то, какие они хорошие, какие у них интересные примеры внедрения/сопровождения и что вот именно эти 11 инструментов им сильно помогли.
NAnt — очень актуальная сейчас для меня тема. Я был бы невероятно признателен, если бы Вы прислали или опубликовали вторую часть статьи (эта написана очень доступно и вдруг многое для меня прояснила). Таже, возможно, у Вас есть подборка ссылок с хорошими статьями про NAnt?
Для UDPXY ставил на Микротик OpenWRT в MetaRouter. У них на сайте есть специально подготовленный образ. Проблем со стабильностью или производительностью пока не наблюдал.
Не хотелось бы спорить, но городить всё описанное в топике в рамках локальной сети, да ещё и на 4-5 серверов было бы по меньшей мере нелогично, поэтому я и не стал указывать расположение клиентов.
Но это только если сервера «личные», а у меня везде разные хозяева (включая иногда и рутовый доступ). А для себя — да, самый простой и действенный вариант.
Вы правы. Спасибо за уточнение. Я этот момент упустил, так как все сервера (так исторически сложилось) ходят через роутеры. Конечно, самый правильный вариант — дергать сервер только после перезагрузки клиента, либо после изменения состояния любого сетевого подключения (если сервер сам поднимает соединения с Интернетом и имеет «белый» IP адрес).
Если этот вопрос адресован мне, то отмечу, что все сервера территориально разнесены и ни в коем случае не находятся в рамках одной локальной сети. Кроме того, почти все они имеют динамический внешний IP адрес, получаемый от провайдера.
Кстати, «Релиз одной кнопкой» — давно уже не миф, а вполне себе ожидаемая реальность на проектах, где действительно работает концепт «DevOps».
У нас в локальный Logstash (Shipper) данные входят не только от Docker демона, но и, к примеру, от HAProxy (он не умеет в stdout, так что наш Logstash слушает отдельный порт — Syslog/UDP). То есть, тэги присваиваются в зависимости от того, откуда пришел эвент.
В проде — 4. Средний объем входящих логов в день — 100-150ГБ. Храним в Эластике последний месяц, но индексы старше недели закрываем.
Redis контейнеры у нас запущены на тех же хостах, что и некоторые остальные компоненты логгинг платформы, так что им не вся память отдана. Но большую часть времени они пустые и в них задерживается не больше сотни эвентов — остальное выгребается Logstash.
По умолчанию, Losgtash (Shipper) шлёт логи в Redis по принципу Round robin, так что нагрузка сразу распределяется. Если инстанс Redis отгнивает по какой-то причине, Logstash очень быстро это обнаруживает и перестает слать в этот инстанс логи.
Наш практический опыт — чуть более часа с недоступным Elasticsearch. Прошло всё нормально — после включения кластера, естественно, был большой всплеск нагрузки, но, насколько мы разобрались, мы ничего не потеряли.
1. Микросервисы пишут логи в формате json в stdout (написана общая библиотека под наши платформы, которая занимается генерацией json, — Node.js, Java, Python, .NET Core).
2. Docker демон настроен слать логи в 172.17.0.1 по протоколу Gelf по UDP без сжатия (показал себя с лучшей стороны в части производительности).
3. На каждом сервере запущен Logstash (Shipper), который слушает Gelf/UDP трафик и принимает логи от Docker демона. Понимаю, что Logstash выглядит как оверкилл, но в нашем случае хосты достаточно большие (по 130+ контейнеров на хост, Nx64GB RAM), время его запуска мало, а буферизировать в себе он может достаточное для нас количество логов (это если логгинг кластер недоступен).
4. Эти инстансы Logstash (Shippers, из #3) никак логи не модифицируют, только добавляют пару тэгов и отправляют в кластер логгирования, в Redis в различные Redis Lists в зависимости от тегов.
5. На стороне логгинг кластера логи приезжают в Redis (используем standalone инстансы).
6. Далее инстансы Logstash (Indexer) забирают логи из Redis, обрабатывают их (фильтры Json, Grok) и складывают в различные индексы кластера Elasticsearch.
7. Дополнительно есть Elastalert, который имеет кучу правил и если что не так — шлет нам сообщения.
Несколько замечаний:
1. Идея писать логи сразу в формате Json оказалась очень удачной — с одной стороны, используя глобальные общие библиотеки для логгирования, мы можем достаточно хорошо стандартизировать основную часть логов (у нас более 550 различных микросервисов), а с другой стороны — дать гибкость в добавлении любого количества кастомных полей к лог-записям.
2. Через Redis мы также пропускаем логи из различных Filebeat.
3. Все компоненты системы логгирования (да и вообще всё у нас) запущены в Docker контейнерах
4. У нас нет Kubernetes/etc. Старый добрый (на самом деле нет) Swarm (это который ещё до Docker Swarm Mode).
На самом деле, есть ещё как минимум два варианта:
1. Симлинк (мы его используем): ln -s /data/docker /var/lib/docker.
2. Монтировать большой раздел для докера сразу в /var/lib/docker.
Вы можете существенно уменьшить размер итогового образа, если вот эти две команды схлопнете в одну:
RUN apt-get update && apt-get install -y git \
wget \
...
zlib1g:i386
RUN apt-get clean && rm -rf /var/lib/apt/lists /var/cache/apt
А также вот эти 3 в одну:
RUN wget https://dl.google.com/android/repository/$sdk_tools_zip_file -P $android_home_dir -nv
RUN unzip $android_home_dir$sdk_tools_zip_file -d $android_home_dir
RUN rm $android_home_dir$sdk_tools_zip_file && chmod 777 -R $android_home_dir
Плюс это также уменьшит количество слоёв итогового образа.
</режим зануды>
А за статью спасибо — хороший гайд для тех, кто хочет начать делать правильно.
Насколько плох микрофон в PI? Насколько хорошо Алиса Вас понимает?
Ну почему же странно? На мой взгляд, вполне нормально:
А за статью — спасибо. Возможно, и правда пришло время переезжать на IPv6 на моих проектах…
мы получим строку с запятой в конце, что неприемлемо для многих приложений. У Вас есть рецепт, как этого избежать?
NAnt — очень актуальная сейчас для меня тема. Я был бы невероятно признателен, если бы Вы прислали или опубликовали вторую часть статьи (эта написана очень доступно и вдруг многое для меня прояснила). Таже, возможно, у Вас есть подборка ссылок с хорошими статьями про NAnt?