Открыть список
Как стать автором
Обновить

Комментарии 8

А чем это лучше стандартных Graphite и Grafana?
Graphite (так же как SCOM или HP Operation Manager) это система сбора счетчиков.
Набор метрик для оценки счетчиков в системах такого рода сильно ограничен (среднее за период, возможно, медиана). В модельной ситуации по среднему за месяц вы сделаете ошибочный вывод об избыточности выделенных ресурсов.
Я в статье не рассматривал систему сбора, я рассматривал методологию оценки уже собранных счетчиков. Применение методологии помогает правильно оценить загруженность серверов в как сценариях равномерной загрузки, так и в сценарии, когда загрузка сильно неравномерно.

А кто мешает передавать туда просто cpu каждые n секунд и уже в Графане смотреть графики. Там достаточно возможностей для оценки.

В Графане таких возможностей нет. Смысл статьи — оценить загрузку сервера за период по нескольким числам (это называется интегральные метрики).
Если у вас десяток серверов — эта статья не для вашей ситуации. Если их 500 — тогда за день вы не сможете просмотреть графики и оценить нагрузку. Если серверов 16000, то для просмотра графиков нужно нанимать армию сисадминов.
Эта методология позволяет исключить этап разбора графиков.
Вы не умеете в Графане квантили считать?
Или фильтровать все неинтересное?

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

Нам интересна общая нагрузка, чтобы сопоставлять её с пользователями, рпс или что там у вас и оценивать планы сколько еще надо если нагрузка так то вырастет.
И нам интересны артефакты. Пошардировали плохо или что-то нетиповое произошло и у нас летит неравномерная нагрузка.
И то и другое можно смотреть с помощью Графаны и какого-нибудь событийного мониторинга по вкусу.
Внезапные 99% занятого места на диске хочется получать в Телеграмм, а не искать на графиках. А вот общий рост занятого места так что 99% на заметном проценте машин будет к НГ лучше на графиках видно.

Ваш сценарий когда нагрузка идет 3 часа в месяц как раз и означает что надо резать мощности. А на эти 3 часа поднимать еще контейнер или контейнеры. Экономия. Зачем платить за 31 день, когда можно заплатить за 0.2 дня?
Нам интересна общая нагрузка, чтобы сопоставлять её с пользователями,
— я не настаивая на использовании этого решения вами.
А на эти 3 часа поднимать еще контейнер или контейнеры.
— не все legacy приложения контейнеризируются. Описаный пример — это сервер отчетности, при недостатке вычислительной мощности приложение падает по таймауту, при недостатки памяти — memory error. Второй контейнер не поможет. А если приложение упало, то вас поднимут по звонку в 3 ночи в воскресенье и потребуют отчетов для топов по почте.
Из-за того, что у вас появилась технология контейнеризации никто не будет бросаться переписывать приложения. Работает — не трогай. Это типичная картина для многих крупных организаций.
Вы деньги из тумбочки берете?
a1.2xlarge 8 16 ГиБ 0,2328 USD за час или 171 бакс в месяц.
Если у вас таких десяток (что очень далеко даже от 500 из вашего прошлого комментария) это 1700 баксов в месяц. Вы уверены что выделить разработчика на месяц чтобы он адаптировал софт к контейнерам и экономил 80% от этой суммы обойдется дороже чем платить за простаивающие сервера?

Да-да Амазон дорогой. Пусть даже ваш хостинг раза в 2 дешевле. Все равно окупаемость адаптации это месяцы, а не годы. При паттерне нагрузки: 20% — типовая, 95% — 3 часа в месяц и размере кластера хотя бы от десятка серверов.
Вы деньги из тумбочки берете?
Не я, а работодатель и не из тумбочки, а из воздуха (банковский мультипликатор — это даже не воздух, а вакуум, полная пустота). Вы, видимо, не читали первый абзац статьи.
Поэтому разговоры про AWS (и даже про Яндекс.облако) бессмысленны. Есть законодательство, есть СБ банка, они определяют что и как делать. Без санкции СБ вы даже чихнуть не сможете.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.