Я для разблокировки Huawei Honor View 10 отправил запрос в их британский твитер, код прислали через пару часов. На том же 4pda есть подробная интсрукция. Он кстати в списке официально поддреживаемых Los но на практите ничего кроме кирпича или гемороя от этой связке получить не получилось.
Вот тут не подскажу, у себя в голове похоронил графит и все что с ним связно, как-то не выглядит он как современный фреймворк, хотя его сейчас местами на golang переписывают, все модно молодежно.
Чисто в порядке бреда не пробовали moria + Graphite Exporter. Собирать и в графите отправлять их в морию, а паралельно через экспортер в прометеус. Я понимаю, что конструкция странная, но например можно node-exporter + alertmanager заменить на collectd + moria + Graphite Exporter. Хотя бы ради эксперимента.
ну его надо один раз грокнуть и больше ничего не надо, функционал у него покрывает все. А если хочется что-то простое и сразу можно прикрутить графану, там есть базовая система алармов. Еще можно взять какое-нибудь готовое решение вроде kube-prometheus
и просто пользоваться им как примером.
нет, скорее всего просто выкинуть Telegraf+InfluxDB. А вот что делать с забиксом еще не решили, хочется сначала потестировать новые плюшки типа «pull lprometheus metrix to zabbix» а еще есть странный вариант zabbix-exporter для прометеуса, но вот он пожалуй совсем не нужен. Пока что склоняемся от забикса оставить только внешние тесты и веб скрипты, просто потому, что это тоже надо где-то делать, а забикс все равно используется для внутренней инфраструктуры.
Слишком много всего получается, но меньше тоже никак. От метрик в ELK отказались по целому ряду причин, медленно, неэффективно по месту и памяти, сырая система алармов в бесплатной версии, родные биты очень капризные иногда просто переставали собирать данные. Логи в ELK для общего разбора что происходит и некоторых очень специфических метрик, которые берутся из логов приложения. Параллельно логи так же уходят в Sentry, уже дублирование, но так просто удобнее. Что тут можно оптимизировать просто не вижу, кроме того что logspout + logstash заменим на fluent-bit.
Дальше все еще хуже, метрики это Telegraf + InfluxDB + Grafana тут же базовые алармы, все это крутится естественно внутри докеров. А потом опять начинается дублирование: Zabbix на котором крутятся веб скрипы, метрики типа реальная скорость подключения от одного дата центра к другому и еще пару штук метрик, просто потому что можем и потому что все проблемы видеть на одном дашборде удобнее и еще потому, что хорошая система нотификации. Вот большую часть этого может на себя взять Prometheus за исключением внешних проверок доступности. Alerts тоже очень хорошо реализованы в Prometheus.
Хочется объединить и так же хочется, но при этом не хочется терять удобство, вот и мучаемся.
тут уже очень специфический вопрос, если например обработка данных идет секунды, то мониторить лучше принимающий сервис, сколько принято сколько обработано и отдельно длинну очереди. Дополнительно метрики обрабатывающего процесса можно отправлять в пуш гейтвей, но это уже зависит от логики вашего приложения. Если же обработка идет значительно дольше среднего скрап периода, то тогда смело можно просто к обработчику применять правило автодискавери. А вообще как тут уже упоминали в комментариях — серебряной пули не существует. 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). В том же забиксе тоже существуют как активные так и пассивные проверки (читай пуш и пул) для каждых задач надо выбирать наиболее подходящий инструмент, и именно муки выбора и сподвигли меня на написание этой статьи.
Если коротко то да. Есть лучший на рынке механизм autodiscovery потому что именно под такие задачи и писался изначально. Здесь можно загуглить про kubernetes annotations и уже упомянутый pushgatway. Кроме того он умеет подключатся например к CloudWatch и брать информацию о созданых/запущеных нодах или лямдах. Вобщем тяжело придумать ситуацию в которая не покрыта функционалом. Еще можно использовать Prometheus Operator в котором почти все, что может относиться к прометеусу настроена из коробки.
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.»
>Но при любом раскладе, мне fluentd, и его производные, нравятся больше, чем elastic'овский beats / logstash. Уж, извините.
тут даже спорить не буду, сам того же мнения.
>Поэтому интересно было бы почитать про ElastAlert
Есть не нулевая вероятность, что в ближайшем будущем займусь им, и за одно по ходу дела напишу статью со всеми граблями
>Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
Постоянный ее поиск и доработка напильником, так можно описать рабочие задачи.
Спасибо за коментарии, было интересно услышать чужое мнение.
cadvisor
поставить, посмотреть, порадоваться и снети. По крайней мере тот же telegraf выдает те же метрики, но жрет ресурсов на порядок меньше.
graylog — не зашел. Может быть я просто не умею его готовить, но я не понял зачем он мне нужен.
gelf и rsyslog просто уступают fluent-bit и в надежности и в функциональности. И с тем и с другим были проблемы, кроме того возможность обогащения метаданными имеющим отношение именно к k8s с именами подов и прочего. Добавить сюда кучу плагинов и футпринтв в 450kb для меня выбор очевиден.
>Kapacitor
да, спасибо, просто описка.
>Со всего решения по сути годен только агент телеграфа.
У меня тоже сложилось именно такое мнение, агент отличен, все остальное дальше песочницы не пошло. Хотя надо признать последний раз на это все смотрел примерно год назад, и тогда оно было просто недописано до приемлемого состояния, поэтому вариант Tergraf + Inluxdb + Grafana был выбран, как более функциональный и стабильный. Кроме того под ту же графану с телеграфом есть готовые дашборды которые пришлось совсем немного обрабатывать напильником под свои нужды.
>Никак. Все зависит от конкретного случая, требований к проекту, архитектурной карты и.т.д…
Это помнятно, просто интеремно было бы послушать еще что-то мнение.
1. Аналог синей карты есть, называется синяя карта
2. В силу аццкого недостатка рабочей силы, устрится по рабочей визе очень даже легко, без всяких своих человеков.
Остальное весьма субъективно и спорить с этим не могу, но в свое время в течении одной недели получил предложения в Польше, Германии и Чехии, остался в Праге и вполне доволен.
habr.com/ru/post/475992
P.S.
Так просто информации для: зато она умеет картинки отправлять =)
и просто пользоваться им как примером.
Дальше все еще хуже, метрики это Telegraf + InfluxDB + Grafana тут же базовые алармы, все это крутится естественно внутри докеров. А потом опять начинается дублирование: Zabbix на котором крутятся веб скрипы, метрики типа реальная скорость подключения от одного дата центра к другому и еще пару штук метрик, просто потому что можем и потому что все проблемы видеть на одном дашборде удобнее и еще потому, что хорошая система нотификации. Вот большую часть этого может на себя взять Prometheus за исключением внешних проверок доступности. Alerts тоже очень хорошо реализованы в Prometheus.
Хочется объединить и так же хочется, но при этом не хочется терять удобство, вот и мучаемся.
тут даже спорить не буду, сам того же мнения.
>Поэтому интересно было бы почитать про ElastAlert
Есть не нулевая вероятность, что в ближайшем будущем займусь им, и за одно по ходу дела напишу статью со всеми граблями
>Увы, поиски серебряной пули и единой коробки, которая закрывает все потребности, не увенчались успехом.
Постоянный ее поиск и доработка напильником, так можно описать рабочие задачи.
Спасибо за коментарии, было интересно услышать чужое мнение.
поставить, посмотреть, порадоваться и снети. По крайней мере тот же telegraf выдает те же метрики, но жрет ресурсов на порядок меньше.
graylog — не зашел. Может быть я просто не умею его готовить, но я не понял зачем он мне нужен.
gelf и rsyslog просто уступают fluent-bit и в надежности и в функциональности. И с тем и с другим были проблемы, кроме того возможность обогащения метаданными имеющим отношение именно к k8s с именами подов и прочего. Добавить сюда кучу плагинов и футпринтв в 450kb для меня выбор очевиден.
да, спасибо, просто описка.
>Со всего решения по сути годен только агент телеграфа.
У меня тоже сложилось именно такое мнение, агент отличен, все остальное дальше песочницы не пошло. Хотя надо признать последний раз на это все смотрел примерно год назад, и тогда оно было просто недописано до приемлемого состояния, поэтому вариант Tergraf + Inluxdb + Grafana был выбран, как более функциональный и стабильный. Кроме того под ту же графану с телеграфом есть готовые дашборды которые пришлось совсем немного обрабатывать напильником под свои нужды.
Это помнятно, просто интеремно было бы послушать еще что-то мнение.
2. В силу аццкого недостатка рабочей силы, устрится по рабочей визе очень даже легко, без всяких своих человеков.
Остальное весьма субъективно и спорить с этим не могу, но в свое время в течении одной недели получил предложения в Польше, Германии и Чехии, остался в Праге и вполне доволен.
О подробностях своего переезда писал тут https://geektimes.com/post/286266/