Канал: https://t.me/metrics_ru

Всё, сказанное ниже, сказано с целью уберечь инженера от неправильного или плохого выбора. Каждая из описанных систем обсуждалась на канале неоднократно и тут совершена попытка сделать выжимку частых вопросов. Шлите ваши PR.

Про Zabbix

В церкви запрещено использовать сравнительные эпитеты к заббиксу. По нашему опыту это рождает холивары в которых нет неправых, но и истины тоже немного.

Если очень хочется поговорить про заббикс - https://t.me/ZabbixPro

Q: Почему Zabbix говно? Я вот пользуюсь и мне норм

A: По множеству причин:

• Реляционные базы данных не подходят для time-series. Когда даже плохие системы тянут сотни тысяч точек в секунду, заббиксу становится уже плохо.
• Zabbix отвратительно масштабируется.
• Он не вписывается в современные концепции мониторинга (многомерные метрики, точнее теги, мониторинг по метрикам в первую очередь).
• Он не подходит для работы с короткоживущими метриками, например из докера.
• См. его bugtracker и список Feature Request'ов. Все важное из него давно реализуется другими системами мониторинга, но не заббиксом.
• Как вишенка на торте - особо отвратительный интерфейс в духе "привет 90ые"

Q: Что использовать вместо InfluxDB и Zabbix?

A: Graphite + Moira/Bosun/баш скрипты или Prometheus

Про InfluxDB

Q: Я хочу взять InfluxDB чтобы запилить X

A: Не надо.

Q: Но он же такой хороший, вот про него сколько сказано крутого

A: Это маркетинг. Не ведитесь.

Q: А какие у него проблемы? Вот я в него начал отправлять 20 метрик в секунду и он отлично работает!

A: Вот краткий и неполный список проблем на момент версии 1.7 (применимо и к более младшим и скорее всего к старшим, CORE team не поменялась):

• Хороший доклад со списком косяков и решений для них от августа 2020 -> https://youtu.be/-3dDD4KmCAM
• Стабильность. Периодически падает и теряет данные или ломает данные на диске. В последнем случае не может подняться или не может сделать компакшен, от чего количество открытых файлов улетает в космос. Лечится полной остановкой DB и выполнением команд в надежде, что хоть одна поможет.
• Скорость. Заявленное в маркетинговых бумажках касается не постоянного рейта, а спайков.
• Не работают внутренние лимиты на запросы вида SHOW TAG KEYS FROM ALL или SHOW EXACT SERIES CARDINALITY и на средней базе может положить все.
• Потребление ресурсов. Сожрать 256ГБ RAM, закусить 320GB свопа и все равно упасть по OOMу -- легко (в момент 6-ти часового запуска, который обусловлен тем, что при старте он читает с диска все индексы в память(InMem)).
• Платная кластеризация (была представлена как часть OSS в версии 0.9 (December 8, 2014) и исчезла в 1.0 (September 26, 2014), став привилегией Enterprise версии).
• Частые breaking changes. За 3 года сменили 5+ движков (закончили это делать на версии 0.9 (December 8, 2014)). Следующий Breaking Changes - это Influx 2.0, где они ушли от База Данных\Ретеншн полиси в сторону Buckets, поменяли язык запросов на Flux.
• Периодически выкатывают фичи непонятно зачем сделанные, например сделали ifql (Flux) или Continuous Queries (последние выпилили в пользу task, по факту те же яйца только с Flux-ом) или Chronograf(буква C в TICK), при живой то графане.
• Безалаберность при подготовке релизов.
• Не самосогласованные утилиты экспорта и импорта из базы - если вы что-то экспортировали через cli, то импортировать обратно файлик не прокатит. restore из backup полностью заменяет всю метаинформацию о базах. Селективности и merge не завезли.
• Телеграф как часть платформы TICK(буква T), например, они ломали поддержку Прометея в телеграфе 1.3.2 (замена символов не попадающих под [a-z]). Или, например, невозможность оверрайдить Retention Policy в (input,output).kafka, т.е. организовать полноценную связку metrics -> telegraf -> kafka -> telegraf -> influx у вас не получится.
• Капаситор(бука K в TICK), очень неадекватно себя ведет, подстать InfluxDB. Выжирает RAM как не в себя, может говорить, что всё "ок", когда данных нет. Требует нежного обращения и ухода.

Про Graphite

Q: Раз Graphite такой клевый, почему его все не используют?

A: Потому что он тоже говно. А все потому что:

• Он очень любит I/O, делает много мелких IOPS при работе с диском.
• Он не очень приспособлен под мониторинг короткоживущих сущностностей (нет адекватной поддержки тегов), нет метаданных.
• Тяжел в плане администрирования (single-server решение с кластеризацией где-то сбоку и набором странных скриптов для управления всем)
• Оригинальный написан на питоне, поэтому еще и адски медленный (пользуйтесь по возможности https://github.com/go-graphite и https://github.com/lomik/go-carbon или https://github.com/lomik/carbon-clickhouse)
• Слишком многое есть в альтернативной реализации, включая несколько видов совместимых хранилищ, но из которых почти все работает не очень хорошо.

Про Prometheus

Q: Может тогда Prometheus - серебряная пуля?

A: И тоже нет. У него несколько существенных недостатков:

• ~~Нет возможность вешать Action на Alarm'ы. ~~
• Из коробки нет долговременного хранилища. Есть множественные попытки сделать их через remote read/write.
• Плохо подходит для новичков. Предполагает, что git и merge request являются большей ценностью чем возможность управлять системой через веб интерфейс.

Action на Alarm'ы

В прочем не всё так плохо.

• https://gitlab.com/yakshaving.art/chief-alert-executor
• https://github.com/mayuresh82/auto_remediation
• https://github.com/prometheus/alertmanager/issues/2046
• https://github.com/StackStorm-Exchange/stackstorm-prometheus
• https://groups.google.com/forum/#!topic/prometheus-users/ThmiD2DeyXc

Но вообще да, всё плохо.

Про Экспортеры метрик в формате Prometheus

Можно найти аггрегированный списки различных экспортеров и их дефолтных портов в следующих местах:

• https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exporters.md
• https://github.com/prometheus/prometheus/wiki/Default-port-allocations

Про Cacti

Q: Почему Cacti говно?

A: Краткий список собственно почему:

• rrd под капотом
• как следствие первого пункта, невозможность самому, внятно, управлять аггрегацией метрик
• нулевая масштабируемость
• pooler модель сбора метрик
• околонулевая возможность автоматизации (т.е. она есть, но чтобы ее настроить до вменяемого состояния нужно потратить уйму времени)
• прожорливость до iops, даже со всякими boost плагинами
• нет вменяемых дашбордов
• заточен в основном под сетевые девайсы - мониторить им сервера клауды и прочие контейнеры мазохизм

Q: Почему тогда ее еще не закопали?

A: Потому что все еще торт! Ну а на самом деле все-таки неплохо мониторит сетевые девайсы, многое для сети есть из коробки, логика отображения устройств в виде дерева хорошо ложиться в голову менеджеров и прочего руководящего состава и они ее любят.

Не про мониторинги, а про чат

Q: А можно в чат слать спам?

A: Спасибо, что спросили. Конечно нет.

Q: Можно ли в чате вакансии?

A: В цервки таки про метрики. Однако для постоянно отвечающих на вопросы можно сделать исключение. В этом случае формат такой вакансии нужно максимально сократить. Сложившийся вариант сейчас выглядит так "Мы в <company_name> ищем человека для <то как вы назваете человека который помогает с мониторингом> . Денег <вилка>. По вопросам пишите в приват". Стоит воздержаться от обсуждения вакансии в чате.

Q: Можно ли в чате анонсы?

A: Да, приветсвуются аносы тематических митапов. Темы мониторинг, метрики, sre практики. Devops в общем виде оффтоп. Писать в случае аноса можно модераторам чата.

Q: А про логи тоже можно?

A: Метрики из логов да вполне. Привычные технологии

• https://github.com/google/mtail
• https://github.com/timberio/vector.
• Вы знаете ещё хорошие варианты? Поделитесь! По остальным вопросам лучше писать в @ru_logs @elasticsearch_ru