Size: a a a

Церковь метрик

2020 February 13

ЕО

Евгений Омельченко in Церковь метрик
Aleksey Shirokikh
предположим так.
я собираю данные прометеем. в нем храню 28 часов.
у меня есть виктория.
я бекаплю ёё каждые 24 часа.
алертинг работает на прометееях.
есть бизнес метрики расчитанные на vm. исходя из данных в виктории.
где мне должно быть больно?
Во время падения прометея
источник

S

Stas in Церковь метрик
Stas
у меня в проде именно так. 2 прома со своими VM, отдельно promxy + grafana. У промов 5 дней retention, и на каждом по alertmanager в кластер (для дедупликации). При падении одного из промов есть доступ к tsdb, есть алерты. t3.large - прометеи+vm (3-4% cpu util), 17K точек в секунду, 0.5М активных ts
4 месяца в проде, 40gb used (ebs gp2 на 300gb)
источник

ЕО

Евгений Омельченко in Церковь метрик
Aleksey Shirokikh
что эффективно говорит нам что мы можем сделать не так.
мы можем сделать 2 кластера. каждый из которых будет иметь полный набор данных.
в каждый будет писать прометей. тоесть на каждом проме по 2 remote_write. это будет стоить +60% mem per prometheus
Шторм в сети и у тебя два прома и две вм с 15-20% дырок в метриках.

И вот, чтобы построить график, ты выжовываешь из виктории 20 гигов метрик в толщущий промкси, где уже нужный запрос посчитается
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Roman Khavronenko
а где здесь проблемы с масштабированием?
Тут возможно фундаментальная разница в подходах. Для стартапа важна стоимость владения, в первую очередь технически-инфраструктурная. В больших организациях имеет смысл вложится сразу в инфраструктуру и сэкономить на обслуживании (в том числе в смысле человеческих ресурсов и планировании).
Возьмём  ситуацию выше - мне нужен лонгтерм хранилище для прома с консолидацией и алертами.
Подход ВМ - типично стартапный - берём две ноды, костылим алертинг - и вуаля, все работает! Для большинства стартапов - будем честны - момент масштабирования может никогда не наступить вообще. Туда же и надёжность - ну поваляется мониторинг несколько минут - да всем насрать.
Теперь представим что я захочу развернуть такой сетап в более менее большой конторе (не берём даже корпорации). Так, берём две ноды. Стоп, а если кончится место на диске или цпу? Тогда поставим кластер. Кто будет ставить кластер? Есть ли для этого доступный в данный момент инженер? Сколько это займёт времени? Как продакшн будет в это время работать? Есть ли у нас железо на кластер? Хрен с ним, давайте облако. Стоп, а есть ли у нас бюджет на это? И ещё миллион вопросов. Поэтому берётся Cortex, изначально вхерачивается в кубер, вместе с хранилищем, планируется рост с запасом, расширение делается простым нажатием кнопки. И это мы ещё мультитенанси не касались.
Как то так. Ситуация утрирована конечно и все совпадения с реальностью случайны. У нас вообще Танос в проде, нормально живем.
источник

RK

Roman Khavronenko in Церковь метрик
Denys 💛📈 💫 Zhdanov
Тут возможно фундаментальная разница в подходах. Для стартапа важна стоимость владения, в первую очередь технически-инфраструктурная. В больших организациях имеет смысл вложится сразу в инфраструктуру и сэкономить на обслуживании (в том числе в смысле человеческих ресурсов и планировании).
Возьмём  ситуацию выше - мне нужен лонгтерм хранилище для прома с консолидацией и алертами.
Подход ВМ - типично стартапный - берём две ноды, костылим алертинг - и вуаля, все работает! Для большинства стартапов - будем честны - момент масштабирования может никогда не наступить вообще. Туда же и надёжность - ну поваляется мониторинг несколько минут - да всем насрать.
Теперь представим что я захочу развернуть такой сетап в более менее большой конторе (не берём даже корпорации). Так, берём две ноды. Стоп, а если кончится место на диске или цпу? Тогда поставим кластер. Кто будет ставить кластер? Есть ли для этого доступный в данный момент инженер? Сколько это займёт времени? Как продакшн будет в это время работать? Есть ли у нас железо на кластер? Хрен с ним, давайте облако. Стоп, а есть ли у нас бюджет на это? И ещё миллион вопросов. Поэтому берётся Cortex, изначально вхерачивается в кубер, вместе с хранилищем, планируется рост с запасом, расширение делается простым нажатием кнопки. И это мы ещё мультитенанси не касались.
Как то так. Ситуация утрирована конечно и все совпадения с реальностью случайны. У нас вообще Танос в проде, нормально живем.
> если кончится место на диске или цпу? Тогда поставим кластер. Кто будет ставить кластер? Есть ли для этого доступный в данный момент инженер? Сколько это займёт времени? Как продакшн будет в это время работать? Есть ли у нас железо на кластер?

но ведь все это в равной степени относится и к кортексу, и к таносу. Капасити планнинг в больших конторах, если мы уж о них говорим, проходит через platform team(или любое другое важное название) и вы получаете лимитированные ресурсы для своих приложений.

И не стоит думать, что танос/кортекс не требуют поддержки или не испытывают проблем со скейлом. Из компаний использующих танос и имеющих публичный трекер я знаю только Gitlab - и у них достаточно issues связанных с поддержкой.

Наверное под "простым нажатием кнопки" имелось в виду использование облачного хранилища, которое поддерживается таносом/кортексом, но отсуствует в VM. Это правда, такой поддержки нет и пока не понятно когда появится. Но использование облачного хранилища не освобождает от "Хрен с ним, давайте облако. Стоп, а есть ли у нас бюджет на это? И ещё миллион вопросов".  А для разворачивания одной кнопкой у VM тоже есть helm chart.

Ну и если уж хранить данные в object storage, то тут уже тяжело "полагаться" на такую систему для алертов или бизнес метрик. В случае с таносом за последние 2ч вам все равно нужно "сходить" во все прометеусы. А за более длительные периоды придется немного "подождать" ответа от querier'ов, пока они прочтут и дедуплицируют данные. Думаю очевидно, что скорость доступа к hdd (а VM позиционируется для использования hdd) будет лучше.

А для построения более надежного и быстрого решения на основе Кортекс все равно придется возиться с настройкой кластера кассандры. Но здесь у меня опыта нет, поправьте если не так.

На мой взгляд, большие компании во многом полагаются на популярность технологии при выборе. Танос/кортекс/графана-лабс - намного дольше на слуху, у них больше комьюнити, и они много сил вкладывают в свой "имидж". И это здорово, они очень много привнесли в oss и решили кучу проблем для всех нас(в какой-то мере создав "монополию", на мой взгляд). В то же время VM меньше года в oss и практически нет промоушена. Мне кажется, это основная причина недоверия к продукту и должно пройти время чтобы это поменялось и больше людей дали шанс продукту.

Для меня это выглядит очень похожим на ситуацию с КХ. К нему тоже было много недоверия вначале и только русскоязычные чаты поддерживали КХ. Я знаю как миниум два случая, когда инженеры в больших компаниях "давали шанс" КХ на lab-кластере и в итоге заменяли всю аналитику. Посмотрите сейчас на адопшн КХ, на развитие по сравнению с 2016 годом. И при этом есть еще большое кол-во людей не доверяющих хранение данных этой БД и они всегда находят кучу причин так считать. Но часто возможность процессить все данные на одном инстансе вместо кластера из 83 (см. clickhouse/vm billy benchmark) перевешивает боязнь нового.
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Тьфу ты, опять «я им про Фому, они мне про Ярему».  Если б у КХ в требованиях был GCP president disk то у него и сейчас был бы адопшен как в 2016. Непробиваемые. :)
источник

vk

vladimir kolobaev in Церковь метрик
Что там насчёт "солюшена аза сервис" от мира опенсорса то.
Графана панельку с логами разработала, это супер, но это чуть меньше чем "воу воу, я поставил эту хреновину и кайфонул"
источник

vk

vladimir kolobaev in Церковь метрик
Кстати насчёт Графаны, они в прошлом релизе выкатили фичу: панелька как датасорс, но эта штука работает только в пределах одной борды, и в моем случае совершенно бесполезная. Нет ли там инициатив про то, чтобы эту фичу и на другие борды расширить?
Пойду это ещё и в канале Графаны спрошу.
источник

AS

Aleksey Shirokikh in Церковь метрик
Denys 💛📈 💫 Zhdanov
Тут возможно фундаментальная разница в подходах. Для стартапа важна стоимость владения, в первую очередь технически-инфраструктурная. В больших организациях имеет смысл вложится сразу в инфраструктуру и сэкономить на обслуживании (в том числе в смысле человеческих ресурсов и планировании).
Возьмём  ситуацию выше - мне нужен лонгтерм хранилище для прома с консолидацией и алертами.
Подход ВМ - типично стартапный - берём две ноды, костылим алертинг - и вуаля, все работает! Для большинства стартапов - будем честны - момент масштабирования может никогда не наступить вообще. Туда же и надёжность - ну поваляется мониторинг несколько минут - да всем насрать.
Теперь представим что я захочу развернуть такой сетап в более менее большой конторе (не берём даже корпорации). Так, берём две ноды. Стоп, а если кончится место на диске или цпу? Тогда поставим кластер. Кто будет ставить кластер? Есть ли для этого доступный в данный момент инженер? Сколько это займёт времени? Как продакшн будет в это время работать? Есть ли у нас железо на кластер? Хрен с ним, давайте облако. Стоп, а есть ли у нас бюджет на это? И ещё миллион вопросов. Поэтому берётся Cortex, изначально вхерачивается в кубер, вместе с хранилищем, планируется рост с запасом, расширение делается простым нажатием кнопки. И это мы ещё мультитенанси не касались.
Как то так. Ситуация утрирована конечно и все совпадения с реальностью случайны. У нас вообще Танос в проде, нормально живем.
кажется по кругу бегаем
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Aleksey Shirokikh
кажется по кругу бегаем
Да, надо завязывать. Сорри за оффтоп ещё раз
источник

НА

Наталья Александровна in Церковь метрик
есть ли схемы или примеры использования carbon-c-relay допустим связку для примера docker compose
источник

DZ

Denys 💛📈 💫 Zhdanov in Церковь метрик
Наталья Александровна
есть ли схемы или примеры использования carbon-c-relay допустим связку для примера docker compose
источник

НА

Наталья Александровна in Церковь метрик
спасибо)
источник

DM

Dmitriy Miroshnichenko in Церковь метрик
Есть:
- группа проектов на GCP
- отдельный инстанс прома для каждого проекта с gce_sd_configs
- правила для фаервола
- для 4 проектов SD работает
- для 5ого - нет
- из прома для 5го проекта, могу тыкаться в /metrics инстансов
- --log.level=debug, не показал ничего, что могло бы понять причину "невидимости"

Ideas?
источник

BG

Bogdan (SirEdvin) Gladyshev in Церковь метрик
Может регионы или датацентры разные?
источник

BG

Bogdan (SirEdvin) Gladyshev in Церковь метрик
Если именно sd не работает, то файрволл не причем, по идее
источник

DM

Dmitriy Miroshnichenko in Церковь метрик
Bogdan (SirEdvin) Gladyshev
Может регионы или датацентры разные?
один регион, разные зоны
источник

DM

Dmitriy Miroshnichenko in Церковь метрик
Bogdan (SirEdvin) Gladyshev
Может регионы или датацентры разные?
спасибо, проблема была в этом :)
у меня шаблон, вчера уперся в лимит по ресурсам, поправил руками и не закоммитил (временно перевез в другую зонну)
источник

AS

Aleksey Shirokikh in Церковь метрик
Aleksey Shirokikh
Коллеги, сообщество Monhouse анонсировало календарь мероприятий по мониторингу на 20-ый год (весь календарь тут https://monhouse.tech/events). Всего будет 7 митапов, 2 круглых стола и 1 конфа в два потока.

Сейчас сообщество ищет спикеров на:
1) митап по CI/CD процессам (19 марта);
2) Big Monitoring Meetup(BMM) 5 Conf (15 апреля).
обратите внимание что дата BMM5 перенесена на 15 апреля.
источник

AS

Aleksey Shirokikh in Церковь метрик
тут про метрики. остальное не приветствуется.
источник