Comments 40
Получилось просто отлично. Отрисовывает мгновенно даже за месяц.
обнаружил раньше, чем увидел пост. приятное нововведение.
Странно, что в пункте сеть отображается только размер канала. Интересно было бы видеть еще кол-во ГБ отправленных/полученных, раз уж я плачу за них.
Ну и слетающие значения периоды тоже не самая приятная штука (перебрасывает на последний при изменении параметра мониторинга).
А так все круто.
Ну и слетающие значения периоды тоже не самая приятная штука (перебрасывает на последний при изменении параметра мониторинга).
А так все круто.
Общее потребление вы можете посмотреть во вкладке «Потребление».
Это понятно, но ведь, согласитесь, для этого и делают графики, чтобы красиво было и наглядно. Вот я и предположил, что отображение тоже было информативно и полезно.
Я не думаю, что такое расширение функционала займет много времени и ресурсов — ведь достаточно умножить время на пропускную способность, которая уже в статистике есть.
Я не думаю, что такое расширение функционала займет много времени и ресурсов — ведь достаточно умножить время на пропускную способность, которая уже в статистике есть.
Мы подумали и решили послушать пожелания пользователей, а после этого делать удобства.
P.S. Будет экспорт в CSV и сохранение картинок.
P.S. Будет экспорт в CSV и сохранение картинок.
Собственно, вам показывается производная от отправленных гигабайт, которая и есть Гб/с, усреднённая за интервал. То есть если было два мелких мегабитных пика в начале и конце часа, то на часовом графике оно есть, а на суточном оно будет усреднено к (например) 100кб/с.
График списания денег нарисовать не можем, т.к. деньги у нас счётчик, состояние которого фиксируется для актов ежесуточно. (то есть сможем показать только месячный график с посуточными отсчётами).
График списания денег нарисовать не можем, т.к. деньги у нас счётчик, состояние которого фиксируется для актов ежесуточно. (то есть сможем показать только месячный график с посуточными отсчётами).
Наконец! Спасибо!
Супер! Получилось здОрово! Теперь надо наложение всех графиков друг на друга (просто разноцветные кривые, без фона), с возможностью включения/отключения любого из них по клику на цветной квадратик легенды.
И конечно же показ статистики за любой период и экспорт этого периода в PDF… можно и без графиков, но с какой-нибудь вашей фирменной «шапкой», чтобы видно было, что это официальный отчет, а не на коленке слеплено.
И таблеток от жадности, да побольше, побольше :-)
И конечно же показ статистики за любой период и экспорт этого периода в PDF… можно и без графиков, но с какой-нибудь вашей фирменной «шапкой», чтобы видно было, что это официальный отчет, а не на коленке слеплено.
И таблеток от жадности, да побольше, побольше :-)
Думали, опасно. Представьте себе наложение исходящего трафика (в Мб/с) и входящего (в кб/с). А рядом гигабайты памяти. Будет сбивать с толку.
Не, не будет. Надо просто легенду снизу в виде квадратик цвета — название графика (единицы измерения). Ну и при наведении на ключевые точки по-прежнему же должна всплывать подсказка с цифрой с единицами измерения.
И на всплывающих подсказках надо бы цифры с десятыми долями для процессора. А то график красивый, а на подсказках везде 1%.
У меня в Опере не раскрывается вкладка «Память»
Насколько меньше ресурсов стал брать расчёт статистики после комплекса всех мер?
(Были слова «при буквально нескольких сотнях машин 8-ядерного Xeon'а недостаточно », но нет слов, сколько стало).
(Были слова «при буквально нескольких сотнях машин 8-ядерного Xeon'а недостаточно », но нет слов, сколько стало).
12% сервис сбора, 8% редис, около 1% сервис на хосте. Сейчас в истории atop'а глянул, фиксированное потребление.
Очень интересный опыт.
Можно немного подробностей?
Какая архитектура: сервис сбора опрашивает сервис на хосте или сервис на хосте отсылает данные?
Какая частота сбора данных? (судя по расчетам в «Истории создания» — каждая переменная собирается раз в секунду)
Данные сразу записываются во все «ведра» или сначала в «ведра» с наименьшим интервалом (секунда?), а потом работает процесс агрегации на более длинные интервалы (час, день, месяц)?
Как я понял, данные для биллинга и для статистики собираются раздельно.
Совпадают ли данные собранные системой статистики, с данными собранными биллингом?
Можно немного подробностей?
Какая архитектура: сервис сбора опрашивает сервис на хосте или сервис на хосте отсылает данные?
Какая частота сбора данных? (судя по расчетам в «Истории создания» — каждая переменная собирается раз в секунду)
Данные сразу записываются во все «ведра» или сначала в «ведра» с наименьшим интервалом (секунда?), а потом работает процесс агрегации на более длинные интервалы (час, день, месяц)?
Как я понял, данные для биллинга и для статистики собираются раздельно.
Совпадают ли данные собранные системой статистики, с данными собранными биллингом?
> Почему же мы не выбрали RRD? Ответ прост и печален: RRD не поддерживает
> bulk insertion — вы не можете за одну операцию сохранить несколько значений.
> Это означает, что вам придётся делать тысячи раздельных транзакций,
> каждая из которых больно бъёт по диску.
на сколько мне известно, во избежания дискового bottleneck-а
на примере cacti (RRDTool), есть удачные костыли:
опрощенные данные кидают в кэш, (база в RAM-е),
потом данные периодически (~раз в час) синхронизируют с базами RRD (на дисках) асинхронно.
результат более чем приличный.
интересно, такой вариант не рассматривался?
> bulk insertion — вы не можете за одну операцию сохранить несколько значений.
> Это означает, что вам придётся делать тысячи раздельных транзакций,
> каждая из которых больно бъёт по диску.
на сколько мне известно, во избежания дискового bottleneck-а
на примере cacti (RRDTool), есть удачные костыли:
опрощенные данные кидают в кэш, (база в RAM-е),
потом данные периодически (~раз в час) синхронизируют с базами RRD (на дисках) асинхронно.
результат более чем приличный.
интересно, такой вариант не рассматривался?
Прошу прощения, пост чуть ниже на самом деле ответ на ваш комментарий.
Если честно, нет. С учётом, что лаги в записи всё равно вызывают нехорошее дрожание (см. ссылку на «наивные» графики раньше), RRD был забракован как алгоритм.
Вспомнил второй аргумент против RRD: мы не можем вставить в него опоздавшие на пару тиков данные. В нашей схеме можем, и оно будет правильно посчитано (актуально при миграции машин — даунтайм машины при миграции — от 0.005с до 0.45с, а реальная миграция занимает до пары минут — и всё это время данные «тупят»).
Вспомнил второй аргумент против RRD: мы не можем вставить в него опоздавшие на пару тиков данные. В нашей схеме можем, и оно будет правильно посчитано (актуально при миграции машин — даунтайм машины при миграции — от 0.005с до 0.45с, а реальная миграция занимает до пары минут — и всё это время данные «тупят»).
Ну не знаю, RRDTool написал умный человек, зависит и от конфигурации.
Мы после перевода базы в RAM (меньше Гига при >300k RRD update-ов в минуту) и разборки причин появления «дырок», вполне довольны.
Но дело ваше конечно, zabbix к примеру тоже свой алгоритм имеет и работает на ура.
Eще: трафик сети обычно отображают К/От интерфейса, у Вас общий?
и где можно посмотреть демку?
Мы после перевода базы в RAM (меньше Гига при >300k RRD update-ов в минуту) и разборки причин появления «дырок», вполне довольны.
Но дело ваше конечно, zabbix к примеру тоже свой алгоритм имеет и работает на ура.
Eще: трафик сети обычно отображают К/От интерфейса, у Вас общий?
и где можно посмотреть демку?
RRD не позволяет достаточно гибко настраивать механизм агрегации данных. Сейчас у нас используется сумма с усреднением по времени (в топике amarao упомянул это как причину минимизации дрожания), сейчас разрабатывается версия со средними/минимальными/максимальными вместо суммы, например. Плюс, в отличие от RRD, наш костыль будет нормально кластеризоваться (спасибо Erlang'у с его простотой межнодного взаимодействия) после отказа от redis, чем я сейчас и занят.
Очень нравится ваш стиль написания статей. Просто и доступно о сложном.
По графикам хочу сказать, что они тяжело читаются. Плотная сетка, отсутствие линий-группировок. В итоге все расплывается, сложно ориентироваться. Хорошо читаются графики в Google Analytics и munin. Обратите на них внимание, я думаю там хорошо продумано все. Особенно munin.
По графикам хочу сказать, что они тяжело читаются. Плотная сетка, отсутствие линий-группировок. В итоге все расплывается, сложно ориентироваться. Хорошо читаются графики в Google Analytics и munin. Обратите на них внимание, я думаю там хорошо продумано все. Особенно munin.
… вы бы знали, сколько я воевал даже за эту сеточку. Вначале оно было на сером фоне (цвета панели) и без сетки.
Сетка — это хорошо. Но такая сетка — плохо*. Я не хочу сказать, что без сетки было бы лучше. Наверное, было бы хуже. Но сетка не должна мешать… Очень все-таки советую обратить внимание на опытных в этом вопросе товарищей (munin и другие никсовые графические статистики), они на этом собаку съели.
* Имхо.
* Имхо.
Кстати, хабр картинку отмасштабировал, оригинал вот: selectel.ru/photo/selectel-graphs.png
Sign up to leave a comment.
Графики в облаке