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

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

НЛО прилетело и опубликовало эту надпись здесь
Да, есть такой фактор. Уровень издержек не на столько высок, что бы отказываться от перехода.
Вполне очевидное последствие для тех, у кого достаточно IQ, чтобы проанализировать переход на микросервисы.
НЛО прилетело и опубликовало эту надпись здесь
Дело не в ЧСВ. Да, комментарий немного токсичный, потому что я не люблю демагогию про очевидные вещи.
Про количество логов:
У вас монолит или SOA. 1-10 «юнитов» которые сыпят логи. Логично что при переходе на микросервисы уникальное количество «юнитов» — возрастёт, минимум в 3 раза. Плюс горизонтальное маштабирование каждого юнита. Плюс distributed(request) tracing.
Ну это реально очевидно, если просто подумать.
Не надо читать про «классные переходы» на микросервисы. Надо думать надо оно вам или нет, какая выгода для бизнеса и команды будет от этого перехода. И «рост издержек» от увеличения трафика логов — поверьте, это 1% от того, с чем можно столкнуться если не правильно провести анализ. Не надо работать по статьям. Надо работать головой.
По вашим комментариям сформировывается образ человека который отвергает новые технологии/альтернативные пути. Могу предположить что докер для вас был занозой в одном месте, а когда все заговорили про kubernetes и микросервисы — вообще наступила депрессия. «опять эти новые тренды и хипстеры». Вот по этому я и написал немного с токсичностью.
Кстати оценку IQ по комментариям я не провожу, Вам показалось.
НЛО прилетело и опубликовало эту надпись здесь
Извините, если мои высказывания слишком жёсткие для вас, я стараюсь говорить свои мысли искренне и по делу. Замес в комментах не планировал, интереса продолжать — нет.
Не понял из статьи. Кластер еластика и логстэш не «тюнили» что ли?
Logstash у нас раньше были «тюнингованные». В последствии перешли на докер-образы с базовыми настройками по количеству пакетов, и т.п. Кастомными остались только pipeline'ы, отвечающие за обработку и обогащение логов.

Тюнинг Elasticsearch не настолько крут, что бы об этом писать. Вся кастомизация заключается в настройке кластера и индексов под профиль нагрузки, с указанием удобный watermark'ов, threshold'ов и отключением автоматической балансировки.
Кубер есть? И почему Logstash? Fluentd не смотрели? Fluentbit — ещё быстрее чем fluentd.
Кубера пока нет, смотрим на него, но пока Nomad закрывает 99% потребностей оркестрации.

Logstash — был изначально, на переправе решили коней не менять, так как на нем достаточно большой уровень логики в части обогащения и упрощения логов. Если съезжать, то это отдельный проект на несколько месяцев, профита от которого, с точки зрения бизнеса, не будет вообще.

На fluentd смотрели, когда начинали модернизацию, оценили трудозатраты на переделку всего и поняли, что овчинка выделки не стоит. Возможно пересмотрим еще в будущем, так как сейчас уже вернули rsyslog вместо filebeat по некоторым направлениям.
Я к тому что kafka с zookeeper — скорее всего сложнее чем Fluentd.
Но раз нет кубера, я бы тоже не стал заморачиваться с переходом на Fluentd.
kafka+zookeeper это несколько часов гугление о технологии и потом еще несколько на написание роли в saltstack. Все. На этом обслуживание данного стэка заканчивается (в нашем узком случае с логами). В части дополнительных затрат это стоило нам +6 SATA дисков по 2Тб (суммарно на 3 сервера).
А Вы не смотрели в сторону 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).
Нет, не смотрели. За счет кафки мы хотели получить несколько плюсов:
— возможность накапливать логи какое-то продолжительное время в случае проблем с лог-кластером
— возможность повторно направить логи, если индекс по какой-то причине умер (ни разу не пользовались правда еще)

У нас сейчас 1.5Тб логово во временном хранилище. Нам это обходится в 3000 рублей в месяц (аренда серверов, дополнительные диски для кафки). Поэтому redis вообще не вариант.

Теперь по пунктам.

1. Аналогично. У нас на уровне платформы реализовано аналогично. И да, это очень удобно когда все логи в едином формате. У нас еще есть небольшие проблемы с логами монолита, но это временно.
2. У нас за логи отвечает Nomad, он их складывает в определенном месте, где их filebeat по маске отправляет в кафку
4. Тэги в зависимости от хоста или от контейнера?
5. А сколько у вас инстансов Redis? Какой объем памяти? Если падает редис, поток логов переключается на другой инстанс? Сколько логов (по времени) может 1 инстанс продержать и какая политика по удалению старых?
7. Elastalert так и не попробовали. Хватает Prometheus+AlertManager его родной + слерты из графаны бэкапом.
Спасибо за ответ.

4. Тэги в зависимости от хоста или от контейнера?

У нас в локальный Logstash (Shipper) данные входят не только от Docker демона, но и, к примеру, от HAProxy (он не умеет в stdout, так что наш Logstash слушает отдельный порт — Syslog/UDP). То есть, тэги присваиваются в зависимости от того, откуда пришел эвент.

А сколько у вас инстансов Redis?

В проде — 4. Средний объем входящих логов в день — 100-150ГБ. Храним в Эластике последний месяц, но индексы старше недели закрываем.

Какой объем памяти?

Redis контейнеры у нас запущены на тех же хостах, что и некоторые остальные компоненты логгинг платформы, так что им не вся память отдана. Но большую часть времени они пустые и в них задерживается не больше сотни эвентов — остальное выгребается Logstash.

Если падает редис, поток логов переключается на другой инстанс?

По умолчанию, Losgtash (Shipper) шлёт логи в Redis по принципу Round robin, так что нагрузка сразу распределяется. Если инстанс Redis отгнивает по какой-то причине, Logstash очень быстро это обнаруживает и перестает слать в этот инстанс логи.

Сколько логов (по времени) может 1 инстанс продержать?

Наш практический опыт — чуть более часа с недоступным Elasticsearch. Прошло всё нормально — после включения кластера, естественно, был большой всплеск нагрузки, но, насколько мы разобрались, мы ничего не потеряли.
у нас есть метрики для инфраструктурного кластера и скрипты для полуавтоматической починки типичных проблем.
Рассмешили. То есть действовать так, чтобы типичных проблем не возникало — это даже рассматривается. А вот чинить в полуручном режиме — к этому готовы.
Ну, в принципе понятно. Если админу не надо ничего периодически чинить, то он как бы и не нужен. Да и тысячи тонн логов в одной большой компостной куче тоже становятся не очень нужны.
В идеальном мире — вы правы. В реальном вы можете столкнуться с проблемами ПО, с которыми вы не можете справиться. И вам никто не поможет — даже разработчики самого ПО, потому что вы просто не можете им повторить конкретную проблему для баг репорта. К примеру, в rabbitmq при непонятных для нас обстоятельствах могут образоваться т.н. «мёртвые очереди» — вы с ними вообще ничего не можете сделать (даже удалить нормально не можете ни через UI, ни через cli). Но в этот момент отправка сообщений, которые роутятся в такие очереди начинают очень сильно тупить и это уже аффектит приложение. Всё это случается, к счастью, не регулярно, но единственным быстрым решением пока является выполнеие некой «магической» cli операции, которая через прямой eval в бэк rabbitmq убивает сломанную очередь.
Поэтому я бы не был бы так категоричен в своих высказываниях, потому что по моему опыту категоричные люди делятся на две категории: супер-боги-знающие-всё и те, кто просто ещё не встретил свой «пистолет с большой мушкой» на своём профессиональном пути.
Думаю, надо не закрывать доступ к Эластику снаружи, а потом при необходимости скачать логи из торрента
Отличный лайфхак, но нет ))
Судя по новостям — это новый тренд. Раньше монгу не закрывали, сейчас эластик.

А были какие-то мысли, как уменьшить количество записываемых и сохраняемых логов?
Первая мысль, которая приходит ко мне в голову — сэмплирование трассировок для проверки производительности. Раз логи проходят через кафку, то можно большую часть успешно выполненных запросов просто выкидывать (выкинуть всё межсервисное взаимодействие, логи БД итд, оставляя только запись на входящий nginx), не записывая никуда, они не очень нужны.

Хорошая идея, но при расследовании ошибок иногда очень нужно понять, что запрос дошёл до такого-то микросервиса. Логи БД и пр. мы пишем только очень выборочно (при превышении пороговых значений CPU, read, write, duration). Мы используем jaeger (вероятностный trace) и ещё свою систему автопрофилирования (trace по превышению длительности ответа), т.е. полностью прям всё мы, конечно, не пишем.

У меня идея такая, что если запрос успешно завершился, то это можно понять, вычитав логи по данному запросу из кафки максимум за минуту после запроса, ведь так? Соответственно можно написать относительно простой фильтр-консьюмер, который будет фильтровать логи трассировок из входящей очереди (фильтры можно легко пошардить по reqid, чтоб можно было масштабировать по числу ядер) и перекладывать уже в очередь из которой вычитывает логстеш. Если попало под паттерн семплирования (500я ошибка/время выполнения большое/req_id кратен 1000, итд) — оставляем весь трейс, не попало — выкидываем в мусорку. ЕМНИП Cloudflare про что-то подобное рассказывали.
С другой стороны — это лишнее копирование трейсов из очереди в очередь, и я не знаю, есть ли готовые кирпичики, чтоб это быстро сделать.

Запрос проходит через разные микросервисы и монолиты, и попадает в разные топики Kafka и, в результате, в разные индексы эластика. Каждый топик обрабатывает своя пачка Logstash со своим pipeline. Простой фильтр тут вряд ли выйдет, особенно если учесть, что это надо будет писать на встроенном Ruby. Мне кажется что положительный эффект будет сильно меньше, чем затраченное на разработку время. Было бы интересно почитать об опыте Cloudflare, поищу.

да, в таком разрезе задача становится сложнее. для подобного кейса действительно простой фильтр-перекладывалку не написать. А валить всё в один топик — неправильно, из-за разных пачек логстешей, им придётся читать много лишнего.

Да, годная идея. Но она будет работать только если можно гарантировать 100% прокидывание reqid абсолютно по всем микросервисам. Причём при любых ответах (даже при экстренно завершённых запросах на проксе).
Попробуйте еще укротить всплывающее окошко «Войдите в ЦИАН через почту Mail.ru». Надоело его КАЖДЫЙ раз закрывать при открытии сайта. Захочу войти — войду с логином и паролем.
Настройка ES — это хорошо, но у вас неоправданно большой объем логов при такой нагрузке, сдаётся мне, что разработчики логируют слишком много всего на всякий случай, возможно этим компенсируется низкое качество кода или процессов.
Не всегда возможно определить что работает под капотом у интернет-проекта. До прихода в ЦИАН я и не подозревал о том, как это все работает. Поэтому, как мне кажется, количество RPS (количество пользователей, количество запросов, etc) на фронты не единственный верный показатель, но с его помощью можно хоть что-то сравнить.
Микросервисная архитектура, как и любая другая, даёт плюсы, но требует за это ресурсы. В данном случае — увеличение количества запросов. Для бизнеса «развязать» руки и уметь быстро релизить и пробовать различные RnD проекты и эффективнее тратить время дорогостоющих сотрудников гораздо ценнее, чем лишние несколько тачек.
Используете ли логи для создания датасетов для машинного обучения?
По сути, имея такой объем, можно интересные штуки делать. К примеру, всевозможные штуки по юзерам считать, используя логи с фронта, или по логам внутренних сервисов отслеживать проблемы ранее, чем это покажет мониторинг по пороговым значениям?
Есть инстуремнты мониторинга, которые предсказывают выход контрольных значений за пороговые. Точно есть у решения от Data Dog, возможно и в других системах тоже. Хотя там особо нейронок и не надо, просто построение прогнозов изменения характеристик по прошлым значениям, там скорее всего что-то типа линейной функции будет.
Мы используем логи в ML не для мониторинга, а как один из компонентов поведенческого анализа. То, что делает Data Dog, похоже на базовые модели предсказания временных рядов (ARIMA, например) и поиск аномалий.

Мы сейчас начинаем развивать направление по предсказания завершения капасити кластеров на основе метрик node_exporter'а.
Да, мы параллельно отправляем все access-логи в ML, которые потом используются, например, для работы внутреннего антибота. Это, конечно, не единственная цель :)

А в чем сложность обрабатывать 50 мегабайт текстовых данных в секунду? Я в однопотоке парсю и валидирую (tsv) данные быстрее чем ссд (400МБ/с +-) может предоставить. Если замасштабировать на типичные 10-20 потоков то процессор уже не будет узким горлышком. Серверная часть тоже не должна вносить много оверхеда если даже на asio делать.

Так нужно хранить и фильтровать по запросу, а не просто при получении обрабатывать.
Хранение — бесплатная операция с точки зрения ЦПУ. Запись тоже околобесплатное если NVME и DMA + MM.
Обработка по запросу — оно и по-запросу, это запрос событие раз в неделю судя по статье, поэтому скоростью можно пренебречь (да и выборка скорее всего будет небольшая исходя из даты и времени).
Фильтрация — штука дешевая если все правила плюс одна сточка из лога помещаются в кэш L1 процессора, а они скорее всего поместятся, если не будет дополнительных фоновых процессов жадных к кэшу процессора.
Однопоточная архивация это около 1ГБ\с, в зависимости от данных, но можно поискать алгоритмы и побыстрее, например с предварительно обученными на логах словарями.

Вобщем можно свелосипедить экономически выгодное решение решение для замены 10 сетевых нод на 1 (Кажется подобный велосипед делал Антон Полухин antoshkka в яндексе для эффективной замены logstash, гдето в сети была презентация).
Как можно говорить про работу с логами не считая их хранение? Не все в мире измеряется быстрой обработкой на проце сразу при появлении данных.

Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).

Так и я о том же. Не ясно зачем нужен кластер на 10 нод (плюс сеть и балансер для них) уж лучше raid на 10 NVME.
А, если речь именно про число машин, то да. Я не так понял изначально.

Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
Ну, у нас там логи не только, которые легко представить в чём-то более эффективным для парзинга, чем JSON (к примеру в CSV), а и в виде stack trace-ов, которые уже могут сделать парзинг CSV не таким уж CPU оправданным.

Вообще, я в чём-то с вами согласен — мне тоже давно кажется, что logstash не сильно оптимально написан (хотя, опять же, у нас там кое-где скрипты предобработки выполняются — к примеру, для классификации страниц для просчёта SLA по их типам). Но elasitc corp пилять во всю новые версии со всякими улучшениями производительности и планы по обновлению на последние версии у нас есть.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий