Статистика сетевого интерфейса

[d.kagarlickij]

Здравствуйте!

У меня есть сервер под управлением linux на ктором установлен zabbx агент.

Мне нужно собрать статистику с eth0 - скоько трафика было получено и отправлено за последний день-неделю-месяц.

Можно ли это сделать, и если да, то как?

Заранее благодарен!

[yukra]

Мне нужно собрать статистику с eth0 - скоько трафика было получено и отправлено за последний день-неделю-месяц.

Так нельзя. От слова "совсем". Можно мониторить "сколько сейчас трафика проходит" и через месяц получить результаты "за месяц". Сейчас взять и получить "за прошедний месяц" - нет. А вообще это в стандартных линукс-шаблонах и в доке есть, ключи net.if.* и ключ для дискаверинга net.if.discovery

[Jimson]

Нет.
Вы можете собрать данные "как дельта", при этом на графиках вы увидите не скорость, а объем за интервал опроса. Что бы далее с этим можно было работать нужно суммировать данные, например, сколько трафика было прокачано с начала текущего месяца. Соответственно "с начала текущего месяца" это кол-во секунд, которые разные в каждый момент времени (момент расчета вычисляемого элемента данных или выражения триггера или подписи к карте). Получить эти секунды возможно в Zabbix только добавив соответствующие простые макросы, в идеале их должно быть как минимум 6 штук: кол-во секунд с начала текущего/предыдущего дня/недели/месяца, эти макросы нужны для использования в качестве аргументов sum(), а так же могут быть полезны в качестве аргумента timeshift для всех остальных функций.

Мне понадобился такой функционал для статических ISG сессий поверх спутниковых каналов ПД. В итоге я использую данные по трафику за сутки/месяц только для визуализации на картах, а триггеры срабатывают в зависимости от того какие фактически активированы сервисы. Патч сделан для 2.0.6rc1

[Jimson]

От слова "совсем".

Задача логичная и достаточно проста, она не противоречит логике Zabbix, наоборот, она иллюстрирует что практические вопросы использования функции sum() и аргумента timeshift небыли продуманы. Так что нет оснований быть столь категоричным, тема скорее для ZBXNEXT.

[aib]

Вообще-то сбор количества трафика на интерфейсе не очень простое дело.
Тем более в Zabbix, где мы храним только моментальные значения прироста переданных данных с последнего отсчета.
А по истечении некоторого периода, округляем эти моментальные значения, практически полностью теряя реальные данные.

И как посчитать трафик? Складыванием скоростей в секунду? Умножением этого результата на секунды, часы и дни?

Непонятно...

[Jimson]

И как посчитать трафик? Складыванием скоростей в секунду? Умножением этого результата на секунды, часы и дни?
Непонятно...

Его надо хранить (элемент данных) как "дельта (простое изменение)", не как "дельта (скорость в секунду)" и не "как есть", а просто дельтой. Именно с обычной дельтой есть смысл работать через sum(). Вот на счет того как обычная дельта сохраняется в трендах вопрос интересных, надо смотреть код, но в моем случае период хранения history превышает 2 месяца, так что для текущего и прошлого месяца можно спокойно делать визуализацию и триггеры по sum().

[aib]

Его надо хранить (элемент данных) как "дельта (простое изменение)", не как "дельта (скорость в секунду)" и не "как есть", а просто дельтой. Именно с обычной дельтой есть смысл работать через sum(). Вот на счет того как обычная дельта сохраняется в трендах вопрос интересных, надо смотреть код, но в моем случае период хранения history превышает 2 месяца, так что для текущего и прошлого месяца можно спокойно делать визуализацию и триггеры по sum().

При хранении трафика в виде "дельты" никаких наглядных графиков текущего трафика не получается. Отдельные пики и провалы.
А делать два Элемента - значит, повышать вероятность несовпадения трафика с реальностью.

[Jimson]

А делать два Элемента - значит, повышать вероятность несовпадения трафика с реальностью.

Откуда может взяться несовпадение если источник данных Counter?? Это надо не просто потерять несколько интервалов, но еще и перегрузить железку чтобы счетчик сбросился. И вообще, это мониторинг а не биллинг, байты мало кого интересуют. А вот на счет трендов вы правы, по ним сумму "дельт" не вычислить, такое ощущение что sum() прилепили в код по чьей то просьбе не особо задумываясь, иначе никак не объяснить почему в trends есть поля для всех агрегатных функций кроме sum(), не говоря уже про то что по сумме и кол-ву, которое в трендах сохраняется, avg() можно вычислить налету и не держать его в базе (ну это если рассуждать на тему что ох и ах размер базы увеличится).

[aib]

Если существуют два разных Элемента, то никто не может гарантировать одновременное снятие значений для обоих этих элементов. Особенно в моменты загрузки интерфейса траффиком.

[Jimson]

Если существуют два разных Элемента, то никто не может гарантировать одновременное снятие значений для обоих этих элементов. Особенно в моменты загрузки интерфейса траффиком.

И что? Сумма нужна для оценки объема за день-неделю-месяц, я не понимаю зачем должны совпадать "дельта скорость в секунду" с "дельта простое изменение".
Вот я понимаю когда мы собираем данные с SLA тестера в виде кучи элементов данных, таких как сумма квадратов задержки, квадрат суммы задержек, кол-во тестовых пакетов и все это по in/out. При этом из этих данных нужно рассчитать среднеквадратичное отклонение и latency. Вот тут да, несинхронизированность элементов данных между собой приводит к тому что вычисляемые элементы данных могут насчитать откровенную пургу. Но вот к задаче поставленной автором треда это какое отношение имеет? И это уже не говоря о том что сырые данные "дельта простое изменение" вообще в данной задаче смысла не имеют, интересны только агрегатные данные sum() по относительно большому интервалу времени.