BG
face palm
думаю, Бразил в ответ просто репостнет свой многолетний коммент: все это не нужно, нам всегда достаточно было ставить по независимому прому на регион
Без lts оно и правдо не очень то и надо.
Size: a a a
2020 January 16
BG
Учитывая, что у нас временные ряди и для них мастер-мастер или даже мастер-слейв немного оверхед ... Правда не у всех временные ряды)
IL
Что то телега подтормаживает
A
На метрику
я даже не очень смеюсь, по-моему норм идея делать по прометею на условную команду, тот же prometheus-operator позвляет это делать легко и непринуждённо
IL
У вас тоже ?
IL
Сервера, видать, ддосят)
A
нет
AS
На метрику
я склоняюсь к namespace. или даже к а app env
GG
я даже не очень смеюсь, по-моему норм идея делать по прометею на условную команду, тот же prometheus-operator позвляет это делать легко и непринуждённо
++++
GG
я склоняюсь к namespace. или даже к а app env
Тоже
ЕО
я даже не очень смеюсь, по-моему норм идея делать по прометею на условную команду, тот же prometheus-operator позвляет это делать легко и непринуждённо
Ну, если под приложением законченную сеть микросервисов понимать, то нормально
ЕО
А если микросервис, то без ремоут стораджа бесмысленно
A
ну очевидно что с викторией :)
A
Ну, если под приложением законченную сеть микросервисов понимать, то нормально
мне кстати всё ещё нравится модель децентрализации разработки у заландо
GG
/только они цаландо
GG
Зануда моде офф
AV
я тут наверно уже всем надоел с описанием :) задача такая: начать собирать SLO/SLA с максимально близкого к клиенту балансировщика
есть AWS loadbalancer с которого я могу брать логи и преобразовывать в метрики (нужны более гранулированые метрики чем cloudwatch предоставляет, и единственный способ это брать их из логов)
проблема в том что существует только один способ получения этих логов - забирать из файлов генерируемых каждые 5 минут в s3 bucket
соответственно, получаются диапазоны в 5 минут при вставке метрик что не очень хорошо для гранулированости
выглядит так что пром не совсем подходящее решение в таком случае, но я не отчаиваюсь и хочу найти best practice для этой задачи в рамках prom/vm
велком если есть варианты, потому что я неопытный собиральщик метрик пока и могу не видеть то что другому бросается в глаза :)
есть AWS loadbalancer с которого я могу брать логи и преобразовывать в метрики (нужны более гранулированые метрики чем cloudwatch предоставляет, и единственный способ это брать их из логов)
проблема в том что существует только один способ получения этих логов - забирать из файлов генерируемых каждые 5 минут в s3 bucket
соответственно, получаются диапазоны в 5 минут при вставке метрик что не очень хорошо для гранулированости
выглядит так что пром не совсем подходящее решение в таком случае, но я не отчаиваюсь и хочу найти best practice для этой задачи в рамках prom/vm
велком если есть варианты, потому что я неопытный собиральщик метрик пока и могу не видеть то что другому бросается в глаза :)
Тут нормально подходят вм-овские гистограммы. Пишем сервис, который раз в пять минут выкачивает новые логи из s3, парсит их и обновляет гистограммы по времени выполнения каждого запроса. При этом записывает в вм счетчики по гистограммам для каждых 10 секунд логов. При записи в вм счетчики не сбрасываются, а продолжают накапливать новые значения. Это позволяет потом строить гистограммы по произвольным интервалам времени с гранулярностью 10 секунд.
IT
Гайз, я вот глянул фак этого канала, из которого можно сделать вывод, что Прометей это прям наиболее православное. Пушить в него уже можно? Это имхо один из главных косяков в старых версиях
A
"косяков"?
AS
Гайз, я вот глянул фак этого канала, из которого можно сделать вывод, что Прометей это прям наиболее православное. Пушить в него уже можно? Это имхо один из главных косяков в старых версиях
пушить нельзя. для пуша есть statsd