Комментарии 38
Хороший рассказ, а также подача материала. Спасибо.
Никак. Все зависит от конкретного случая, требований к проекту, архитектурной карты и.т.д…
А как вы себе видите идеальную инфраструктуру?
Никак. Все зависит от конкретного случая, требований к проекту, архитектурной карты и.т.д…
Ой, мне есть что сказать.
Первое. Не Capacitor, а Kapacitor. Это часть стека TICK, который состоит из telegraf+influxdb+chronograf+kapacitor. Кратко. Хронограф — это менеджмент influxdb + графики типа grafana. Заодно в нем можно писать скрипты для kapacitor, который выполняет роль реалтайм процессинга. По-пррстому говоря — на нем можно скользить алертинг. Примеры скриптов есть в гитхабе. Плюсы: законсенная платформа, богатый язык скриптов. Скрипты позволяют все алерты описать как текст и положить в контроль версий. МинусыHA для influxdb, kapacitor. Странноватый язык скриптов. Со всего решения по сути годен только агент телеграфа. Он реально прекрасен. Его, кстати, можно приделать к прометеусу, но есть нюанс — все метрики будут в прометей-формате, но названия не матчатся с такими же методиками в node exporter. И это подстава, т.к. готовых дашборд для той же графаны нет. Придется делать руками. Я думал, что осилю, но нет. Проще раскатать node exporter + prometheus + grafana
Первое. Не Capacitor, а Kapacitor. Это часть стека TICK, который состоит из telegraf+influxdb+chronograf+kapacitor. Кратко. Хронограф — это менеджмент influxdb + графики типа grafana. Заодно в нем можно писать скрипты для kapacitor, который выполняет роль реалтайм процессинга. По-пррстому говоря — на нем можно скользить алертинг. Примеры скриптов есть в гитхабе. Плюсы: законсенная платформа, богатый язык скриптов. Скрипты позволяют все алерты описать как текст и положить в контроль версий. МинусыHA для influxdb, kapacitor. Странноватый язык скриптов. Со всего решения по сути годен только агент телеграфа. Он реально прекрасен. Его, кстати, можно приделать к прометеусу, но есть нюанс — все метрики будут в прометей-формате, но названия не матчатся с такими же методиками в node exporter. И это подстава, т.к. готовых дашборд для той же графаны нет. Придется делать руками. Я думал, что осилю, но нет. Проще раскатать node exporter + prometheus + grafana
Далее. Если речь идёт про мониторинг докера, то штатным вариантом является установка cadvisor. Он прекрасно интегрируется с прометеусом, но, как всегда, есть нюанс. То ли я его не так готовил, то ли сам по себе cadvisor глючное поделие, но жрет он ресурсы годы, где запущен, как не в себя. Телеграф гораздо более щадяш к ресурсам, но см.выше. Короче, нужно решить каким образом снимать метрики докер-контейнеров. В общем, здесь prometheus + cadvisor = прокол.
Едем дальше.
Агрегация логов. Самый оптимум — graylog. Считай, тот же эластик, но с человеческим лицом. Для системного логгирования можно использовать в качестве цели для rsyslog или все логгирование сделать вокруг journald и, например, передавать его gelf. Кстати, docker умеет и напрямую в gelf, и в journald. А с последним ещё и команда docker logs работает, т.к. логи есть на роде, что удобно разработчикам.
Поэтому у меня есть стойкие сомнения в необходимости fluentd/fluent-beat
Едем дальше.
Агрегация логов. Самый оптимум — graylog. Считай, тот же эластик, но с человеческим лицом. Для системного логгирования можно использовать в качестве цели для rsyslog или все логгирование сделать вокруг journald и, например, передавать его gelf. Кстати, docker умеет и напрямую в gelf, и в journald. А с последним ещё и команда docker logs работает, т.к. логи есть на роде, что удобно разработчикам.
Поэтому у меня есть стойкие сомнения в необходимости fluentd/fluent-beat
Но при любом раскладе, мне fluentd, и его производные, нравятся больше, чем elastic'овский beats / logstash. Уж, извините.
Про алертинг из логов — тоже интересная тема. Сейчас реализуется промежуточными самописными сервисами, которые дёргают эластик определенным запросом и пишут в базу результат. Можно было обойтись алертинг из кибаны (но он платный!!!) или алертингом из графаны ( а он ущербный и по нескольким критериям/граничным значениям плохо работает, а ещё вопросы с темплейтингом и т.п ). Поэтому интересно было бы почитать про ElastAlert — возможно, узнаю что-то новое для себя.
Хочется подчеркнуть, что в масштабах энтерпрайза — платформа для мониторинга — это не единый продукт, а платформа, состоящая из нескольких законченных продуктов и прослоек между ними. Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
Про алертинг из логов — тоже интересная тема. Сейчас реализуется промежуточными самописными сервисами, которые дёргают эластик определенным запросом и пишут в базу результат. Можно было обойтись алертинг из кибаны (но он платный!!!) или алертингом из графаны ( а он ущербный и по нескольким критериям/граничным значениям плохо работает, а ещё вопросы с темплейтингом и т.п ). Поэтому интересно было бы почитать про ElastAlert — возможно, узнаю что-то новое для себя.
Хочется подчеркнуть, что в масштабах энтерпрайза — платформа для мониторинга — это не единый продукт, а платформа, состоящая из нескольких законченных продуктов и прослоек между ними. Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
>Но при любом раскладе, мне fluentd, и его производные, нравятся больше, чем elastic'овский beats / logstash. Уж, извините.
тут даже спорить не буду, сам того же мнения.
>Поэтому интересно было бы почитать про ElastAlert
Есть не нулевая вероятность, что в ближайшем будущем займусь им, и за одно по ходу дела напишу статью со всеми граблями
>Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
Постоянный ее поиск и доработка напильником, так можно описать рабочие задачи.
Спасибо за коментарии, было интересно услышать чужое мнение.
тут даже спорить не буду, сам того же мнения.
>Поэтому интересно было бы почитать про ElastAlert
Есть не нулевая вероятность, что в ближайшем будущем займусь им, и за одно по ходу дела напишу статью со всеми граблями
>Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
Постоянный ее поиск и доработка напильником, так можно описать рабочие задачи.
Спасибо за коментарии, было интересно услышать чужое мнение.
cadvisor
поставить, посмотреть, порадоваться и снети. По крайней мере тот же telegraf выдает те же метрики, но жрет ресурсов на порядок меньше.
graylog — не зашел. Может быть я просто не умею его готовить, но я не понял зачем он мне нужен.
gelf и rsyslog просто уступают fluent-bit и в надежности и в функциональности. И с тем и с другим были проблемы, кроме того возможность обогащения метаданными имеющим отношение именно к k8s с именами подов и прочего. Добавить сюда кучу плагинов и футпринтв в 450kb для меня выбор очевиден.
поставить, посмотреть, порадоваться и снети. По крайней мере тот же telegraf выдает те же метрики, но жрет ресурсов на порядок меньше.
graylog — не зашел. Может быть я просто не умею его готовить, но я не понял зачем он мне нужен.
gelf и rsyslog просто уступают fluent-bit и в надежности и в функциональности. И с тем и с другим были проблемы, кроме того возможность обогащения метаданными имеющим отношение именно к k8s с именами подов и прочего. Добавить сюда кучу плагинов и футпринтв в 450kb для меня выбор очевиден.
cadvisor
поставить, посмотреть, порадоваться и снети. По крайней мере тот же telegraf выдает те же метрики, но жрет ресурсов на порядок меньше.
да, я об этом же и говорю. Но, повторюсь, что те же дашборды для cadvisor/prometheus в графане лучше, чем дашборды для мониторинга docker для influxdb/telegraf.
Но дашборды доработать всегда можно )
Да, кстати, внезапно — fluent bit и fluent-beats (скорее даже fluent-plugin-beats) оказались разными (!) продуктами. Я малость удивлен. Аргх. Надо же было развести почти одинаковых названий )
>Kapacitor
да, спасибо, просто описка.
>Со всего решения по сути годен только агент телеграфа.
У меня тоже сложилось именно такое мнение, агент отличен, все остальное дальше песочницы не пошло. Хотя надо признать последний раз на это все смотрел примерно год назад, и тогда оно было просто недописано до приемлемого состояния, поэтому вариант Tergraf + Inluxdb + Grafana был выбран, как более функциональный и стабильный. Кроме того под ту же графану с телеграфом есть готовые дашборды которые пришлось совсем немного обрабатывать напильником под свои нужды.
да, спасибо, просто описка.
>Со всего решения по сути годен только агент телеграфа.
У меня тоже сложилось именно такое мнение, агент отличен, все остальное дальше песочницы не пошло. Хотя надо признать последний раз на это все смотрел примерно год назад, и тогда оно было просто недописано до приемлемого состояния, поэтому вариант Tergraf + Inluxdb + Grafana был выбран, как более функциональный и стабильный. Кроме того под ту же графану с телеграфом есть готовые дашборды которые пришлось совсем немного обрабатывать напильником под свои нужды.
Рекомендую обратить внимание на clickhouse вместо influxdb.
1) нормальная репликация данных между нодами
2) почти полноценный sql
3) с ним работает и телеграф и графана (плугин от vertamedia)
4) позволяет хранить данные столько, сколько есть места и работать с ними почти независимо от объёма оперативной памяти (в отличие от influxdb)
5) на большинстве запросов упирается в чтение колонок с диска, если вообще упирается
Перешли на него после того, как не смогли сделать так, чтоб influxdb работал устойчиво при попытке хранить сырые неагрегированные данные не за 3 последних дня, а за 7 — тупо переставало хватать памяти.
Сейчас данные хранятся за 6 месяцев.
Правда, у кх есть и недостатки:
1) настоятельно рекомендуется заливать данные большими кусками не чаще, чем примерно раз в секунду (если не получается большими кусками — можно инсертить в таблицу типа Buffer, которая соберёт всё в один кусок и засунет в таблицу-бекенд)
Из-за этого пункта мы слегка попатчили плугин для записи в кх, чтобы метрики улетали не напрямую в таблицы (напр. «cpu»), а в буферные («buff_cpu»). Можно было бы и со стороны БД переделать, конечно.
2) если нужен кластер с репликацией — обязательно требуется zookeeper
3) несмотря на то, что язык запросов более sql, чем в influxdb — это не совсем sql и кой-какие вещи там либо ещё не реализованы, либо даже не будут реализовываться.
1) нормальная репликация данных между нодами
2) почти полноценный sql
3) с ним работает и телеграф и графана (плугин от vertamedia)
4) позволяет хранить данные столько, сколько есть места и работать с ними почти независимо от объёма оперативной памяти (в отличие от influxdb)
5) на большинстве запросов упирается в чтение колонок с диска, если вообще упирается
Перешли на него после того, как не смогли сделать так, чтоб influxdb работал устойчиво при попытке хранить сырые неагрегированные данные не за 3 последних дня, а за 7 — тупо переставало хватать памяти.
Сейчас данные хранятся за 6 месяцев.
Правда, у кх есть и недостатки:
1) настоятельно рекомендуется заливать данные большими кусками не чаще, чем примерно раз в секунду (если не получается большими кусками — можно инсертить в таблицу типа Buffer, которая соберёт всё в один кусок и засунет в таблицу-бекенд)
Из-за этого пункта мы слегка попатчили плугин для записи в кх, чтобы метрики улетали не напрямую в таблицы (напр. «cpu»), а в буферные («buff_cpu»). Можно было бы и со стороны БД переделать, конечно.
2) если нужен кластер с репликацией — обязательно требуется zookeeper
3) несмотря на то, что язык запросов более sql, чем в influxdb — это не совсем sql и кой-какие вещи там либо ещё не реализованы, либо даже не будут реализовываться.
Мне кажется, что в качестве оперативного средства хранения — все-таки prometheus.
Т.е. цепочка такая
а) агент (telegraf или node_exporter+на каждый сервис своя статусная страница в формате прометея)
б) агрегатор (prometheus)
в) оповещалка (кластер из alertmanager)
г) визуализация (grafana)
д) ДОЛГОВРЕМЕННОЕ хранение метрик — вот вопрос. Решения есть вроде Timescaledb, m3db и федерации prometheus. Но никто не мешает писать и в clickhouse, причем пачками и тачками.
А еще можно поддаться на рекламу mail.ru и начать везде вставлять tarantool (в нем есть, кстати, позитивные моменты)
Т.е. цепочка такая
а) агент (telegraf или node_exporter+на каждый сервис своя статусная страница в формате прометея)
б) агрегатор (prometheus)
в) оповещалка (кластер из alertmanager)
г) визуализация (grafana)
д) ДОЛГОВРЕМЕННОЕ хранение метрик — вот вопрос. Решения есть вроде Timescaledb, m3db и федерации prometheus. Но никто не мешает писать и в clickhouse, причем пачками и тачками.
А еще можно поддаться на рекламу mail.ru и начать везде вставлять tarantool (в нем есть, кстати, позитивные моменты)
Слышал, что prometheus плох с push моделью, если сравнивать с telegraf + influex, может сталкивались?
Prometheus вообще не писался из расчета на push, из коробки там только pull. Есть несколько костылей типа pushgatway но у него совсем другие задачи, он скорее для лямбд или прочих коротко живущих сущностей. Еще есть StatsD exporter и Prometheus Aggregation Gateway, но они тоже немного для другого и даже по официальной документации больше похожи на временные решения «We recommend this only as an intermediate solution and recommend switching to native Prometheus instrumentation in the long term.»
Тогда возникает вопрос насколько хорошо он работает с мультипроцессорными приложениями и воркерами, запускаемыми либо по крону, либо по событиям в rabbit/kafka? Нужно ли ему говорить ручками, что появилась новая машина или есть механизм autodiscovery?
Если коротко то да. Есть лучший на рынке механизм autodiscovery потому что именно под такие задачи и писался изначально. Здесь можно загуглить про kubernetes annotations и уже упомянутый pushgatway. Кроме того он умеет подключатся например к CloudWatch и брать информацию о созданых/запущеных нодах или лямдах. Вобщем тяжело придумать ситуацию в которая не покрыта функционалом. Еще можно использовать Prometheus Operator в котором почти все, что может относиться к прометеусу настроена из коробки.
Меня очень волнует вопрос мониторинга ETL с помощью Прометеуса. То что я вижу — выглядит как костыли. Все-таки push-идеология лучше подходит для ETL'ей.
тут уже очень специфический вопрос, если например обработка данных идет секунды, то мониторить лучше принимающий сервис, сколько принято сколько обработано и отдельно длинну очереди. Дополнительно метрики обрабатывающего процесса можно отправлять в пуш гейтвей, но это уже зависит от логики вашего приложения. Если же обработка идет значительно дольше среднего скрап периода, то тогда смело можно просто к обработчику применять правило автодискавери. А вообще как тут уже упоминали в комментариях — серебряной пули не существует. Push проще для понимания, что-то произошло — ты это что-то отправил, но в прометеусе выбрали другую модель в факе даже есть такой вопрос з забавным ответом (Overall, we believe that pulling is slightly better than pushing, but it should not be considered a major point when considering a monitoring system). В том же забиксе тоже существуют как активные так и пассивные проверки (читай пуш и пул) для каждых задач надо выбирать наиболее подходящий инструмент, и именно муки выбора и сподвигли меня на написание этой статьи.
Очень актуальная для меня сейчас статья. Хочеться уже договориться однажды всем и не изобретать каждый раз новый велосипед, тем более, что ситуация на рынке продуктов начинает стабилизироваться.
Моя задача похожа, но в ней акцент на AWS инфраструктуру (по возможности без вендор-лока).
Развертывание: terraform в ASG на спот-инстансах.
Оркестратор: EKS (kubernetes) + minikube для локальных. Docker for Win/Mac имеет встроенный k8 режим тоже.
Релиз-менеждер: helm c надеждами на helm3. industry-standard, никуда не деться.
А вот дальше терзания. Хочеться остаться в ELK, т.к. он есть как SaaS и в AWS, и отдельно. Логи уходят туда. Вероятнее всего APM тоже туда.
Дальше большой соблазн не плодить и метрики слать туда же, благо есть всякие Beats. Но стандарт у нас Prometheus с возможностью pull, Grafana, которая удобнее.
Ошибки — в ELK или в Sentry? Sentry опять таки стандарт.
Не слишком ли много всего получится? ELK, Prometheus+Grafana, и что-то для Alerting. Что можно с чем объединить?
Моя задача похожа, но в ней акцент на AWS инфраструктуру (по возможности без вендор-лока).
Развертывание: terraform в ASG на спот-инстансах.
Оркестратор: EKS (kubernetes) + minikube для локальных. Docker for Win/Mac имеет встроенный k8 режим тоже.
Релиз-менеждер: helm c надеждами на helm3. industry-standard, никуда не деться.
А вот дальше терзания. Хочеться остаться в ELK, т.к. он есть как SaaS и в AWS, и отдельно. Логи уходят туда. Вероятнее всего APM тоже туда.
Дальше большой соблазн не плодить и метрики слать туда же, благо есть всякие Beats. Но стандарт у нас Prometheus с возможностью pull, Grafana, которая удобнее.
Ошибки — в ELK или в Sentry? Sentry опять таки стандарт.
Не слишком ли много всего получится? ELK, Prometheus+Grafana, и что-то для Alerting. Что можно с чем объединить?
Слишком много всего получается, но меньше тоже никак. От метрик в ELK отказались по целому ряду причин, медленно, неэффективно по месту и памяти, сырая система алармов в бесплатной версии, родные биты очень капризные иногда просто переставали собирать данные. Логи в ELK для общего разбора что происходит и некоторых очень специфических метрик, которые берутся из логов приложения. Параллельно логи так же уходят в Sentry, уже дублирование, но так просто удобнее. Что тут можно оптимизировать просто не вижу, кроме того что logspout + logstash заменим на fluent-bit.
Дальше все еще хуже, метрики это Telegraf + InfluxDB + Grafana тут же базовые алармы, все это крутится естественно внутри докеров. А потом опять начинается дублирование: Zabbix на котором крутятся веб скрипы, метрики типа реальная скорость подключения от одного дата центра к другому и еще пару штук метрик, просто потому что можем и потому что все проблемы видеть на одном дашборде удобнее и еще потому, что хорошая система нотификации. Вот большую часть этого может на себя взять Prometheus за исключением внешних проверок доступности. Alerts тоже очень хорошо реализованы в Prometheus.
Хочется объединить и так же хочется, но при этом не хочется терять удобство, вот и мучаемся.
Дальше все еще хуже, метрики это Telegraf + InfluxDB + Grafana тут же базовые алармы, все это крутится естественно внутри докеров. А потом опять начинается дублирование: Zabbix на котором крутятся веб скрипы, метрики типа реальная скорость подключения от одного дата центра к другому и еще пару штук метрик, просто потому что можем и потому что все проблемы видеть на одном дашборде удобнее и еще потому, что хорошая система нотификации. Вот большую часть этого может на себя взять Prometheus за исключением внешних проверок доступности. Alerts тоже очень хорошо реализованы в Prometheus.
Хочется объединить и так же хочется, но при этом не хочется терять удобство, вот и мучаемся.
Т.е. пытаться заменить Telegraf+InfluxDB+Grafana+Zabbix на Telegraf+Prometheus+Grafana?
нет, скорее всего просто выкинуть Telegraf+InfluxDB. А вот что делать с забиксом еще не решили, хочется сначала потестировать новые плюшки типа «pull lprometheus metrix to zabbix» а еще есть странный вариант zabbix-exporter для прометеуса, но вот он пожалуй совсем не нужен. Пока что склоняемся от забикса оставить только внешние тесты и веб скрипты, просто потому, что это тоже надо где-то делать, а забикс все равно используется для внутренней инфраструктуры.
Sentry он немного для другого, чем ELK. ELK — это общее решение, универсальное. А sentry — специализированная штука, которая ловит эксепшены (т.е. это инструмент разработчика в первую очередь). Сделать из ELK подобие сентри можно, но я не видел хороших готовых коробочных решений. Я видел какое-то законченное решение для NPM на базе Эластика, но, к сожалению, название забыл.
Еще могу упомянуть такие страшные штуки как sensu — фреймворк для мониторинга (т.е. по сути аналог заббикс и Ко), но с широким распространением prometheus, sensu скорее всего канет в Лету.
Еще могу упомянуть такие страшные штуки как sensu — фреймворк для мониторинга (т.е. по сути аналог заббикс и Ко), но с широким распространением prometheus, sensu скорее всего канет в Лету.
Может кто знает, что нибудь адекватнее alertmanager для prometheus?
ну его надо один раз грокнуть и больше ничего не надо, функционал у него покрывает все. А если хочется что-то простое и сразу можно прикрутить графану, там есть базовая система алармов. Еще можно взять какое-нибудь готовое решение вроде kube-prometheus
и просто пользоваться им как примером.
и просто пользоваться им как примером.
еще раз повторюсь, что в графане система алармов убогая. Совсем для нищих.
Из плюсов, что графана умеет алертить через веб-хуки или через тот же alertmanager, что может дать возможность построить интересную систему. Но при этом алерты будут приходить из разных источников (прометеус, графана и что там еще в инфраструктуре есть).
Из плюсов, что графана умеет алертить через веб-хуки или через тот же alertmanager, что может дать возможность построить интересную систему. Но при этом алерты будут приходить из разных источников (прометеус, графана и что там еще в инфраструктуре есть).
Она умеет) но даже синглстат не запилили, я пытался скостылить, не вышло… Эх работала бы moira с prometheus… мечты мечты…
Чисто в порядке бреда не пробовали moria + Graphite Exporter. Собирать и в графите отправлять их в морию, а паралельно через экспортер в прометеус. Я понимаю, что конструкция странная, но например можно node-exporter + alertmanager заменить на collectd + moria + Graphite Exporter. Хотя бы ради эксперимента.
я moira попробовал, но, во-первых, их уже две версии. Во-вторых, там даже нет внятной инструкции по установке. Все как-то через одно место. А вообще, конечно, проект перспективный был (или есть!?)
Вот тут не подскажу, у себя в голове похоронил графит и все что с ним связно, как-то не выглядит он как современный фреймворк, хотя его сейчас местами на golang переписывают, все модно молодежно.
Есть. Мойрой вроде как пользуются в довольно крупных проектах, да и Контур с неё никогда не слезет и будет развивать.
Контур пускай пользует. Это их внутренний продукт, который они опенсорснули.
Я говорил о том, что документация на грани фантастики.
Репозиторий находится с полтычка: github.com/moira-alert
А дальше начинаются чудеса.
hub.docker.com/r/kontur/moira — описания нет, а есть еще и такое — hub.docker.com/r/skbkontur/moira-web
github.com/moira-alert/doc — здесь докер-компоуз (очень логично, т.к. doc обычно называют документацию) — эти файлы у меня и не взлетели. Образы, кстати, указаны другие, чем kontur/moira
и т.д.
короче, нужен нормальный гайд для новичков. Вот запустить graylog какой-нибудь или prometheus можно вообще за пять минут. А здесь какой-то мрак.
Я уж не говорю о том, что заточка на Графит — такое себе. Хотя я бы даже его прицепил, при условии, что moira взлетит и ее можно будет оценить для использования.
Я говорил о том, что документация на грани фантастики.
Репозиторий находится с полтычка: github.com/moira-alert
А дальше начинаются чудеса.
hub.docker.com/r/kontur/moira — описания нет, а есть еще и такое — hub.docker.com/r/skbkontur/moira-web
github.com/moira-alert/doc — здесь докер-компоуз (очень логично, т.к. doc обычно называют документацию) — эти файлы у меня и не взлетели. Образы, кстати, указаны другие, чем kontur/moira
и т.д.
короче, нужен нормальный гайд для новичков. Вот запустить graylog какой-нибудь или prometheus можно вообще за пять минут. А здесь какой-то мрак.
Я уж не говорю о том, что заточка на Графит — такое себе. Хотя я бы даже его прицепил, при условии, что moira взлетит и ее можно будет оценить для использования.
Я взял из документации (раздел Installation → Docker) такие команды:
git clone https://github.com/moira-alert/doc.git
cd doc
docker-compose upЗашел на localhost:8080, создал триггер на выражение local.random.diceroll, отправил метрику:
echo "local.random.diceroll 42 `date +%s`" | nc localhost 2003… и увидел в веб-морде, что статус триггера изменился. Понятно, чтобы получить реальные уведомления в Телеграм или Слак, надо там токены поднастроить, конфиги написать. Но базовая функциональность заводится за пять минут.
Расскажи, что у тебя не завелось?
Есть, кстати, чат разработчиков, где могут быстро на вопросы ответить: t.me/moira_alert
Во-первых, эксперимент я проводил уже достаточно давно (полгода или даже ещё раньше)
Во-вторых, moira у меня не завелась.
В третьих, я попробовал ее напрямую из Dockerfile собрать, но понял, что там поехали версии компонентов и мне этот попросту было не очень интересно.
Кстати, мне буквально на днях один из владельцев репозитория написал, что он deprecated: github.com/warmfusion/moira-docker
Да, несомненно, что ориентироваться на 3rd party репозиторий, а не официальный — не показательно.
Но тем не менее
И ещё. А пробовали moira прикручивать к influxdb или prometheus? Ну, тогда ой. Я чего-то графит не готов тащить…
Во-вторых, moira у меня не завелась.
В третьих, я попробовал ее напрямую из Dockerfile собрать, но понял, что там поехали версии компонентов и мне этот попросту было не очень интересно.
Кстати, мне буквально на днях один из владельцев репозитория написал, что он deprecated: github.com/warmfusion/moira-docker
Да, несомненно, что ориентироваться на 3rd party репозиторий, а не официальный — не показательно.
Но тем не менее
И ещё. А пробовали moira прикручивать к influxdb или prometheus? Ну, тогда ой. Я чего-то графит не готов тащить…
К InfluxDB — не пробовали.
К Prometheus успешно подключают ребята из Авито, и регулярно рассказывают об этом на конференциях и в статьях. Ближайший рассказ будет на Хайлоаде, от vkolobaev: www.highload.ru/moscow/2018/abstracts/4161
К Prometheus успешно подключают ребята из Авито, и регулярно рассказывают об этом на конференциях и в статьях. Ближайший рассказ будет на Хайлоаде, от vkolobaev: www.highload.ru/moscow/2018/abstracts/4161
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инфраструктура для микросервисов. K8s и все-все-все