https://www.opennet.dev/openforum/vsluhforumID1/91350.html Помогите найти решение для статистики клиентов.<br>Есть сервер на дебиане(Intel(R) Xeon(R) CPU 3065 @ 2.33GHz) с двумя гигабитными картами через него идет поток(на данный момент 500мбит в пике) и клиенты(то есть ip) около 5000.<br>Нужно какимто(чудесным) образом рисовать графики по запросу на клиентов. <br>То есть нужно например узнать как работал ip например 10.1.1.44 в определенное время.<br>Все было хорошо пока поток был до 100мбит, сервер еще справлялся, собирал данные из iptable s(соответственно на каждый ip одно правило) и скармливал все rrdtool.<br>Но сейчас при таком потоке уже не справляется.<br>То есть точного количества мегабайтов скачанных не требуется а вот график показать клиенту "мол вот у вас загрузка в 10:30 была 3мбит" нужно.<br>В данный момент с него идет только сбор статистики первых соединений через fprobe для силовых структур(по закону хранить нужно 6 месяцев) и все. но по этим данным графики не сильно построишь.<br>У кого будут какие советы по данной теме?<br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#19 Fri, 15 Apr 2011 11:20:36 GMT мои координаты:<br>email: sm00th1980@mail.ru<br>skype: sm00th1980<br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#18 Fri, 15 Apr 2011 10:39:34 GMT &gt;[оверквотинг удален]<br>&gt; не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди <br>&gt; в телекомах вот с гигабитов собирают и ничего - потому как <br>&gt; требует государство хранить подробные данные для СОРМа какое-то время).<br>&gt; Далее уже с netflow уже может отдельный сервер парсить и делать срезы <br>&gt; по данным как нужно.<br>&gt; Т.е. задачу при таком трафике можно и нужно параллелить и разносить на <br>&gt; разные машины.<br>&gt; ps ради интереса - я могу чуть попозже привести данные сколько будет <br>&gt; в трафике. Снять с реальной сети(правда не такой большой - но <br>&gt; позволю себе экстраполировать чтобы оценить масштаб).<br><br>отпиши в личку свой email будь добр<br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#17 Fri, 15 Apr 2011 09:12:02 GMT netflow со свитча то и не предполагалось собирать.<br><br>Было предложено зеркалировать трафик на машину которая будет переводить его в netflow-поток(её уже можно сделать довольно мощной) более того можно зеркалировать не весь трафик - а разбить его по виланам(ряд свичтей это умеют - т.е. например 100 виланов пустить на один коллектор а другие 100 на другой - если они не выдержат - хотя это надо ещё проверять).<br><br>Теперь по поводу что netflow не переварит. Ещё как переварит - вы просто не знаете как оно работает.<br><br>Там происходит агрегация по сессиям и в итоге из 500Мбит трафика выйдет не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди в телекомах вот с гигабитов собирают и ничего - потому как требует государство хранить подробные данные для СОРМа какое-то время).<br><br>Далее уже с netflow уже может отдельный сервер парсить и делать срезы по данным как нужно.<br><br>Т.е. задачу при таком трафике можно и нужно параллелить и разносить на разные машины.<br><br>ps ради интереса - я могу чуть попозже привест https://www.opennet.dev/openforum/vsluhforumID1/91350.html#16 Fri, 15 Apr 2011 06:31:24 GMT &gt; netflow получится если написать нормальный парсер и загрузчик в БД со структурой <br>&gt; учитывающей такие объёмы(это и называется велосипед по вашим словам...) <br>&gt; а по моему мнению - решение учитывающее бизнес-особенности <br><br>но нетфлова то нету на свиче как понятия. а брать его с linuxa так загнется он. это сейчас полгигабита а через год будет гигабит. <br><br><br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#15 Thu, 14 Apr 2011 18:15:52 GMT &gt;[оверквотинг удален]<br>&gt; по iptables трафик считать - это бррр... хотя если клиенты терпят... <br>&gt; PSS <br>&gt; и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...<br>&gt; PSSS <br>&gt; не выдержал: <br>&gt; - поднимаешь pptpd <br>&gt; - поднимаешь RADIUS <br>&gt; - поднимаешь MySQL (например) <br>&gt; ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской <br>&gt; идеи потоков и последущей мороки с разбором данных из них.<br><br>интересная реакция <br>вы, молодой человек, наверное не много сетей в своей жизни повидали.<br>существует готовая сеть со сформированной годами инфраструктурой, которую обслуживали за все время разные люди. <br>а вы вспомните конец 90-х, и начало провайдерства, тогда никто не слышал ни о pptp ни о радиусе.<br>а сеть строилась и на данный момент только в ней 5000 конечных пользователей на АБСОЛЮТНО разном оборудовании. я тут повстречал еще airlan который потом циска выкупила и начала свое оборудование делать.<br>так что перевести такое колличество на vpn будет нереально, да и не нужно. https://www.opennet.dev/openforum/vsluhforumID1/91350.html#14 Thu, 14 Apr 2011 17:01:04 GMT netflow получится если написать нормальный парсер и загрузчик в БД со структурой учитывающей такие объёмы(это и называется велосипед по вашим словам...)<br>а по моему мнению - решение учитывающее бизнес-особенности<br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#13 Thu, 14 Apr 2011 16:12:21 GMT &gt;&gt; Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка <br>&gt;&gt; будет на него.<br>&gt; Меня например больше смущает, что эта софтина раз от разу (от версии <br>&gt; к версии), считала по разному. Правда я ее давно не смотрел. <br>&gt; Видимо если говоришь, что можно пользовать - наверное так и есть. <br><br>Поставил 9у версию ManageEngine netflow analyzera. ну что сказать, тула красивая, но так и не нашел рисования графиков для ip. <br>да и еще вот что, у меня свич поддерживает только sflow а netflow как я понял потихоньку уходит. как я уже писал что собираю в базу хедеры первых пакетов каждого соединения, так вот только их в сжатом виде в день у меня порядка 1гига то есть 6 месяцев это выходит порядка 180 гиг. так что netflow тут никак не получится, слишком уж большие потоки для него.<br>может кто сталкивался, возможно ли по данным sflow рисовать графики(хитрый больно алгоритм у него)?<br><br>заодно прикрутил sflow сенсор на самом серваке, и направил тоже в manageengine, интересный факт, за день свич es462 https://www.opennet.dev/openforum/vsluhforumID1/91350.html#12 Thu, 14 Apr 2011 13:30:15 GMT &gt; Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка <br>&gt; будет на него.<br><br>Меня например больше смущает, что эта софтина раз от разу (от версии к версии), считала по разному. Правда я ее давно не смотрел. Видимо если говоришь, что можно пользовать - наверное так и есть.<br> https://www.opennet.dev/openforum/vsluhforumID1/91350.html#11 Thu, 14 Apr 2011 13:20:32 GMT &gt; Если свитчи умные, снимать с портов на клиента по SNMP <br><br>статиску по snmp можно снимать не только с портов умного свича, но и с интерфейса того же софтогого роутера например. были бы клиенты по интерфейсам разделены (VPN, PPoE, VLAN). при реализации PPP-соединения так там вообще проще с радиуса всю информацию снимать и прочие штуки наворачивать.<br><br>PS<br>по iptables трафик считать - это бррр... хотя если клиенты терпят...<br><br>PSS<br>и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...<br><br>PSSS<br>не выдержал:<br><br>- поднимаешь pptpd<br>- поднимаешь RADIUS<br>- поднимаешь MySQL (например)<br>ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской идеи потоков и последущей мороки с разбором данных из них.<br><br><br><br><br>