Биллинговая система Nodeny
22 Ноября 2024, 10:02:09 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
Новости: Прекращена поддержка версии Nodeny 49
 
   Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]
  Печать  
Автор Тема: netflow  (Прочитано 4231 раз)
Bars
Пользователь
**

Карма: 0
Offline Offline

Сообщений: 68


Просмотр профиля
« : 21 Сентября 2020, 12:48:31 »

Добрый день!

Возникла необходимость перенести сбор статистики netflow с Mikrotik непосредственно на сервера Nodeny.

Общая информация
Код:
OS: FreeBSD 12.1

Nodeny:
```
$ svn info
Path: .
Working Copy Root Path: /usr/local/nodeny
URL: svn://nodeny-plus.com.ua/release/next
Relative URL: ^/next
Repository Root: svn://nodeny-plus.com.ua/release
Repository UUID: 2dcad6c2-3daf-43f6-9252-ff095f4c085f
Revision: 604
Node Kind: directory
Schedule: normal
Last Changed Author: sv
Last Changed Rev: 604
Last Changed Date: 2020-02-14 18:24:42 +0200 (Fri, 14 Feb 2020)


# Успешно работающая конфигурация

* Две БД: отдельно основная, отдельно трафик, конфигурация на серверах Nodeny:
Код:

cat /usr/local/nodeny/sat.cfg
package cfg;

$Passwd_Key = '********';

$Db_server  = 'aaa.bbb.ccc.ddd';
$Db_name    = 'nodeny';
$Db_user    = '********';
$Db_pw      = '********';
$Db_connect_timeout = 5;

$Trf_Db_server  = 'aaa.bbb.ccc.eee';
$Trf_Db_name    = 'nodeny_traffic';
$Trf_Db_user    = '********';
$Trf_Db_pw      = '********';
$Trf_Db_connect_timeout = 5;



* Экспорт netflow с Mikrotik.

* Приём стандартным способом:
Код:
/usr/local/bin/flow-capture \
    -R /var/db/flows/netflow_8888.pl \
    -p /var/run/flowtools/flow-capture.pid \
    -w /var/db/flows \
    -n1 -N0 \
    0.0.0.0/0.0.0.0/8888
```

* Модуль `netflow`, `/usr/local/nodeny/kernel/_collectors.cfg`
```
# Сбор статистики трафика
Код:
run    => 0,
period => 60,
# detailed statistic
detail => 1,
# round when insert into DB; 0 - do not round
round_minutes => 5,

list   => [
  {
    type        => 'netflow',
    port        => '8888',
    flow_base   => '/var/db/flows/',
    capture_pid => '/var/run/flowtools/flow-capture.pid',
    ext_iface   => '24',
  },
],
```

# Попытка собирать с помощью ng_netflow

Конфигурация серверов Nodeny наливается строго из системы управления конфигурациями, поэтому можно утверждать, что строго идентична, за исключением следующих изменений:

`/boot/loader.conf`:
```
Код:
...
netgraph_load="YES"
ng_ipfw_load="YES"
ng_ksocket_load="YES"
ng_netflow_load="YES"
ng_socket_load="YES"
...


`/usr/local/etc/ng_netflow.conf`
```
Код:
mkpeer ipfw: netflow 100 iface0
name ipfw:100 netflow
msg netflow: setdlt { iface = 0 dlt = 12 }
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow:export connect inet/127.0.0.1:8888
msg netflow: settimeouts { inactive=20 active=40 }


`ipfw`:
Код:
...
00420 ngtee 100 ip from any to any
...
00510 ngtee 100 ip from any to any


`/usr/local/nodeny/kernel/_collectors.cfg`
Убрана строка фильтра по интерфейсу. Пробовал также вариант с установленной, интерфейс определял с помощью способа, найденного на просторах этого форума: `flow-stat -f 17 < /var/db/flows/8888.txt`.


# Проблема

В этом варианте очень странно (и неполно?) отображается трафик в Nodeny.

Было:
скрин 1

Стало:
скрин 2

# Диагностика

* Статистика netflow доходит до коллектора, в репорте вижу нечто, похожее на вменяемые данные:
Код:
flow-print < /var/db/flows/tmp-v05.*

...
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     38861    10044    216         4
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     56007    80       6173        141
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     56896    443      22302       63
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     51290    443      219         3
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     43713    16759    1126        5
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     52420    443      2887        17
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     43092    443      135         2
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     52419    443      2887        17
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     49365    10041    164         3
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  17    0        0        38412       49
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     37777    63212    7475        34
XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX  6     39048    10033    164         3


* В логах модуля `collector` вижу тоже вроде бы нормальную работу:
Код:
/usr/local/bin/flow-export: Exported 85128 records
Получили данные от netflow:
INSERT DELAYED INTO Z2020_9_21 (uid,time,bytes,class,direction,uip,ip,port,proto) VALUES ... (rows: 36)
UPDATE users_trf SET actual=0 , in1=in1+'4170', out1=out1+'0' WHERE uid='22637'
Строк: 1. Время выполнения sql: 0.0007 сек
UPDATE users_trf SET actual=0 , in1=in1+'1358', out1=out1+'0' WHERE uid='19243'
Строк: 1. Время выполнения sql: 0.0005 сек
UPDATE users_trf SET actual=0 , in1=in1+'4170', out1=out1+'0' WHERE uid='23749'
Строк: 1. Время выполнения sql: 0.0006 сек
UPDATE users_trf SET actual=0 , in1=in1+'432', out1=out1+'0' WHERE uid='24986'
Строк: 1. Время выполнения sql: 0.0006 сек
UPDATE users_trf SET actual=0 , in1=in1+'216', out1=out1+'0' WHERE uid='16387'
Строк: 1. Время выполнения sql: 0.0006 сек
INSERT INTO X2020_9_21 (uid,iface,class,time,`in`,`out`) VALUES ... (rows: 9)
UPDATE users_trf SET traf1=in1+out1
Строк: 24747. Время выполнения sql: 0.0188 сек
UPDATE users_trf SET traf2=in2+out2
Строк: 24747. Время выполнения sql: 0.0180 сек
UPDATE users_trf SET traf3=in3+out3
Строк: 24747. Время выполнения sql: 0.0178 сек
UPDATE users_trf SET traf4=in4+out4
Строк: 24747. Время выполнения sql: 0.0177 сек
Table 'nodeny_traffic.user_grp' doesn't exist
{
  'sql' => 'SELECT g.grp_maxflow, u.id FROM user_grp g LEFT JOIN users u ON g.grp_id=u.grp WHERE g.grp_maxflow>0 AND u.state<>\'off\'',
  'param' => []
};


За исключением сообщения "Table 'nodeny_traffic.user_grp' doesn't exist". Это выглядит странным, что модуль пытается искать эту таблицу в БД с трафиком, в то время, как она находится в основной БД (конфигурация sat.cfg приведена выше).

* Однако в БД вижу, что с момента переключения в таблице `X2020_9_21`, похоже, перестали появляться данные части пользователей, при том, что часть записей по прежнему есть:

Код:
MariaDB [nodeny_traffic]> select FROM_UNIXTIME(time),uid,`class`,`in`,`out` from X2020_9_21 order by time desc limit 10;
+---------------------+-------+-------+-------+-----+
| FROM_UNIXTIME(time) | uid   | class | in    | out |
+---------------------+-------+-------+-------+-----+
| 2020-09-21 12:50:00 | 18356 |     1 |  1390 |   0 |
| 2020-09-21 12:50:00 | 16387 |     1 |   216 |   0 |
| 2020-09-21 12:50:00 |   656 |     1 |   320 |   0 |
| 2020-09-21 12:50:00 | 24986 |     1 |  4290 |   0 |
| 2020-09-21 12:50:00 | 22637 |     1 | 12637 |   0 |
| 2020-09-21 12:50:00 | 19243 |     1 |  4074 |   0 |
| 2020-09-21 12:50:00 |     0 |     4 |     0 |   0 |
| 2020-09-21 12:50:00 |     0 |     3 |     0 |   0 |
| 2020-09-21 12:50:00 |     0 |     2 |     0 |   0 |
| 2020-09-21 12:50:00 |     0 |     1 |     0 |   0 |
+---------------------+-------+-------+-------+-----+

* В таблицу `Z2020_9_21` данные также поступают, однако консистентности оценить не могу:

Код:
[nodeny_traffic]> select uid,FROM_UNIXTIME(time),bytes,direction,class,INET_NTOA(uip),INET_NTOA(ip),port,proto from Z2020_9_21 order by time desc limit 100;

+-------+---------------------+-------+-----------+-------+-----------------+-----------------+------+-------+
| uid   | FROM_UNIXTIME(time) | bytes | direction | class | INET_NTOA(uip)  | INET_NTOA(ip)   | port | proto |
+-------+---------------------+-------+-----------+-------+-----------------+-----------------+------+-------+
| 24986 | 2020-09-21 12:50:00 |   643 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 22637 | 2020-09-21 12:50:00 |    52 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 22637 | 2020-09-21 12:50:00 |   643 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 24986 | 2020-09-21 12:50:00 |   643 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 24986 | 2020-09-21 12:50:00 |   216 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 24986 | 2020-09-21 12:50:00 |   707 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 22637 | 2020-09-21 12:50:00 |    52 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 24986 | 2020-09-21 12:50:00 |   164 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
| 24986 | 2020-09-21 12:50:00 |    52 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |   80 |     6 |
...
|   771 | 2020-09-21 11:40:00 |      60 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 59678 |    17 |
| 23602 | 2020-09-21 11:40:00 |     180 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 36558 |     6 |
|   771 | 2020-09-21 11:40:00 |      62 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 50678 |    17 |
| 22352 | 2020-09-21 11:40:00 |     448 |         1 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49373 |     6 |
| 13112 | 2020-09-21 11:40:00 |     448 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 |     6 |
| 13112 | 2020-09-21 11:40:00 |     448 |         1 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 |     6 |
| 13324 | 2020-09-21 11:40:00 |     448 |         2 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49356 |     6 |
| 22624 | 2020-09-21 11:40:00 |     448 |         2 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49371 |     6 |
| 13112 | 2020-09-21 11:40:00 |     448 |         1 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 37777 |     6 |
| 22352 | 2020-09-21 11:40:00 |     448 |         2 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49373 |     6 |
| 14409 | 2020-09-21 11:40:00 |     608 |         2 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 49361 |     6 |
| 13407 | 2020-09-21 11:40:00 |     304 |         2 |     2 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX |  8003 |     6 |
|   771 | 2020-09-21 11:40:00 |      65 |         2 |     1 | XXX.XXX.XXX.XXX | XXX.XXX.XXX.XXX | 26064 |    17 |
```

* На данный момент для чистоты эксперимента все экспортеры трафика, кроме тестируемой схемы, отключены.

# Вопросы

* Нормально ли появление сообщения "Table 'nodeny_traffic.user_grp' doesn't exist" в логах `collector`?
* Что может быть причиной, как устранить или как диагностировать далее?
Записан
Bars
Пользователь
**

Карма: 0
Offline Offline

Сообщений: 68


Просмотр профиля
« Ответ #1 : 29 Сентября 2020, 14:19:05 »

up
Записан
Pa4ka
Старожил
****

Карма: 4
Offline Offline

Сообщений: 281

591884591
Просмотр профиля Email
« Ответ #2 : 29 Сентября 2020, 14:37:18 »

up
ext_iface   => '24',
индекс интерфейса точно 24?
Записан
Efendy
Администратор
Спец
*****

Карма: 138
Offline Offline

Сообщений: 4790



Просмотр профиля
« Ответ #3 : 30 Сентября 2020, 15:31:17 »

отсутсвие таблицы user_grp не должно влиять на продстчет трафика, она задействована в куске кода блокировки пользователей по превышению потоков.

Насчет интерфейса с номером 24 правильное замечание, скорее всего проблема в неверном номере. Поможет понять ситуацию просмотр дампа нетфлоу (не в бд, а от коллектора)
Записан
Страниц: [1]
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!