добрый день!
столкнулся с проблемой на FreeBSD 8.0/var/db/flows/in # uname -a
FreeBSD gw.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386обновил порты - нужного порта не появилось
как установить /usr/ports/net-mgmt/flowscan если его исключили из основного дерева портов.
как это сделать правильно и просто
>[оверквотинг удален]
>
>/var/db/flows/in # uname -a
>FreeBSD gw.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
>
>обновил порты - нужного порта не появилось
>
>как установить /usr/ports/net-mgmt/flowscan если его исключили из основного дерева портов.
>
>как это сделать правильно и простоесли порт прошел процедуру удаления, значит он либо не собирается, либо содержит
ошибки, ну или просто не работает:portname: net-mgmt/flowscan
description: Processes IP flows recorded in cflowd-format raw flow
files
maintainer: po...@FreeBSD.org
status: BROKEN
deprecated because: has been broken for 5 months
expiration date: 2010-01-08
build errors: none.конкретно данный порт можно извлечь из 8.0-RELEASE/ports/ports.tgz
и ковырять-проверять-точить самостоятельно
>если порт прошел процедуру удаления, значит он либо не собирается, либо содержит
>ошибки, ну или просто не работает:Либо существуют альтернативные решения, концептуально более правильные и технически более чистые.
>>если порт прошел процедуру удаления, значит он либо не собирается, либо содержит
>>ошибки, ну или просто не работает:
>
>Либо существуют альтернативные решения, концептуально более правильные и технически более чистые.именно так
>>если порт прошел процедуру удаления, значит он либо не собирается, либо содержит
>>ошибки, ну или просто не работает:
>
>Либо существуют альтернативные решения, концептуально более правильные и технически более чистые.если не секрет то какие ?
>>>если порт прошел процедуру удаления, значит он либо не собирается, либо содержит
>>>ошибки, ну или просто не работает:
>>
>>Либо существуют альтернативные решения, концептуально более правильные и технически более чистые.
>
>если не секрет то какие ?Ну, например, я накапливаю в IPFW счетчики по интересующим меня критериям, затем снимаю эти данные в rrdtool, а потом rrdtool отрисовывает мне png-картинки с нужной мне периодичностью. У меня снимаются не только счетчики файрволла, но и нагрузка на систему (цпу/озу/хдд/сеть), состояние упсов и даже температуры кузовов. Вся музыка играется двумя вызовами - rrdtool update вбрасывает данные в базу, rrdtool graph - рисует картинку по данным из базы.
http://oss.oetiker.ch/rrdtool/doc/index.en.html
Низкоуровневый подход мало того, что каноничный unix-way, так еще и предельно гибок - раз научившись, можно мониторить все, что угодно.
Могу дать добрый совет: используйте rrdtool 1.2. В версии 1.3 Отикер для рендеринга шрифтов заюзал иксовый панго, и для примитивной задачи отрисовки легенды на графике ставится три с половиной десятка весьма тяжелых зависимостей.
>[оверквотинг удален]
>
>http://oss.oetiker.ch/rrdtool/doc/index.en.html
>
>Низкоуровневый подход мало того, что каноничный unix-way, так еще и предельно гибок
>- раз научившись, можно мониторить все, что угодно.
>
>
>Могу дать добрый совет: используйте rrdtool 1.2. В версии 1.3 Отикер для
>рендеринга шрифтов заюзал иксовый панго, и для примитивной задачи отрисовки легенды
>на графике ставится три с половиной десятка весьма тяжелых зависимостей.под словом низкоуровневый подход вы имеет в виду: ipfw и самописные скрипты по запихиванию данных в базу rrd
и вот еще один вопрос я смогу построить графики по ip intranet и увидеть на них кто сколько закачал из инета ?
>под словом низкоуровневый подход вы имеет в виду: ipfw и самописные скрипты
>по запихиванию данных в базу rrdДа. Вот пример одного из скриптов, которые раз в минуту стартуются из крона:
#!/bin/sh
DBNAME=/usr/local/etc/rrdtool/slow.rrd
TSTAMP=`date +%s`
ibt=`/sbin/ipfw show 00100 | awk '{ print $3 }'`
ipt=`/sbin/ipfw show 00100 | awk '{ print $2 }'`
.....
[куча однообразных строк]
.....
/usr/local/bin/rrdtool update $DBNAME $TSTAMP:$ibt:$obt:$ibw:$obw:$ibp:$obp:$ibm:$obm:$ipt:$opt:$ipw:$opw:$ipp:$opp>и вот еще один вопрос я смогу построить графики по ip intranet
>и увидеть на них кто сколько закачал из инета ?Отчего ж нет? На каждый айпи в локалке заводится два счетчика - для исходящего и входящего траффика. RRDtool умеет агрегировать данные за отображаемый период. Т.е. если вы строите график за час, то вы можете получить и суммарное, и среднее значение траффика за этот час. Аналогично, если период - сутки или неделя, или месяц.
ipfw vs netflowконцептуально более правильные и технически более чистые?!
>ipfw vs netflow
>
>концептуально более правильные и технически более чистые?!Вы не спутали netflow и flowscan?
Я ничего не имею против нетфлоу - но у меня нет цисок. Я лишь не понимаю, зачем для простого парсинга данных нетфлоу и забивки цифрей в RRD городить какой-то помороченный пакет.
я имела в виду, что для обработки при помощи flowscan генерятся данные netflow, т.е. постер получает данные netflow.
в то время как у меня вызвало удивление утверждение, что решение получать данные при помощи ipfw (ip_src, ip_dst, pkts, octets) "концептуально более правильное и технически более чистое" чем получать данные netflow?!
>я имела в виду, что для обработки при помощи flowscan генерятся данные
>netflow, т.е. постер получает данные netflow.
>в то время как у меня вызвало удивление утверждение, что решение получать
>данные при помощи ipfw (ip_src, ip_dst, pkts, octets) "концептуально более правильное
>и технически более чистое" чем получать данные netflow?!Ну, если у меня все равно используется IPFW, который по дефолту считает пакеты и октеты, проходящие через правила с прописанными срц/дст, то к чему умножать сущности? Я еще могу понять ситуацию, когда есть зоопарк активного оборудования, в т.ч. циски, где нетфлоу - родной, и ПК, где можно повесить нетфлоу-агент, и вся статистика собирается на едином узле-коллекторе. Это да.
Но если у нас одиночная машина, где необходимо подбивать траффик, то не вижу особого смысла вешать агент, с которого поток тут же заворачивать на локальный же коллектор. Избыточно как-то. Некузяво.
>Избыточно как-то. Некузяво.То есть то же самое - но с самописными скриптами - верх "кузявости"? Да ты болен слакваршиной! :)
PS: Ааа! Дошло! Ты просто не в курсе что фряха умеет генерить нетфлоу тулзами из в базовой системе и всё что нужно сделать - это их включить! Угадал?
>>Избыточно как-то. Некузяво.
>
>То есть то же самое - но с самописными скриптами - верх
>"кузявости"? Да ты болен слакваршиной! :)
>
>
>PS: Ааа! Дошло! Ты просто не в курсе что фряха умеет генерить
>нетфлоу тулзами из в базовой системе и всё что нужно сделать
>- это их включить! Угадал?Да. И где это включается?
а сколько таких строк
ibt=`/sbin/ipfw show 00100 | awk '{ print $3 }'`
ipt=`/sbin/ipfw show 00100 | awk '{ print $2 }'`понадобиться для 50 и более клиентов для входящего и исходяего трафика в ipfw и в скрипте? хотя конечтно это не более чем неудобство.
>а сколько таких строк
>ibt=`/sbin/ipfw show 00100 | awk '{ print $3 }'`
>ipt=`/sbin/ipfw show 00100 | awk '{ print $2 }'`
>
>понадобиться для 50 и более клиентов для входящего и исходяего трафика в
>ipfw и в скрипте? хотя конечтно это не более чем неудобство.
>IPFW умеет создавать пулы динамических очередей по src/dst - со всеми положенными счетчиками. В итоге сбор данных ложится в один цикл. Но это неважно.
счетчики в ipfw увеличиваются по нарастающей?
в rrd заносится разница между текущим и предыдущим показаниями?
если правила ipfw будет перегружены?
>счетчики в ipfw увеличиваются по нарастающей?
>в rrd заносится разница между текущим и предыдущим показаниями?
>если правила ipfw будет перегружены?В RRD есть разного типа поля данных - COUNT, DERIVE, GAUGE, которые интерпретируются каждый по своему. Скажем, для DERIVE предполагается, что значение накапливается нарастающим итогом, и каждое последующее должно быть больше предыдущего. Если вдруг происходит сброс счетчиков (ребут или просто обнуление IPFW), в результате чего текущий отсчет станет меньше предыдущего, он будет считаться ошибочным, и в корректные пойдет только следующий отсчет.
Это позволяет не напрягаясь писать в базу сырое текущее значение, а все остальные вычисления выполняются средствами RRD.
Вообще, весьма достойный софт, в т.ч. по причине фиксированного размера баз - есть пул слотов, которые по кольцу заполняются, а при заполнении последнего слота - повторно использует начальные слоты. Усредняя значения по пулу непосредственных данных, заполняются аггрегированые пулы более длинных периодов.
Скажем, первичные данные снимаются каждую минуту. Значит, чтобы держать данные за сутки, нужен пул минимум в 24х60=1440 слотов. Я обычно делаю с запасом - 3к слотов.
Данные, усредненные в скользящем окне в 10 минут, пишутся в пул из 1000 слотов - это неделя. Усредненные за час первичные данные пишутся в пул на 1000 слотов - это уже месяц.
Усредненные данные за 10 часов пишутся в годовой пул из 1000 слотов.База для 16 значений с четырьмя пулами имеет размер 400 кб.
>>PS: Ааа! Дошло! Ты просто не в курсе что фряха умеет генерить
>>нетфлоу тулзами из базовой системе и всё что нужно сделать
>>- это их включить! Угадал?
>Да. И где это включается?Если фряха относительно свежая - начни с man ng_netflow.
Ну и не брезгуй поисковиками, мне лично помогло :)