NikolaySivko Sep 10 2016 at 15:57

Мониторинг сетевого стека linux

5 min

49K

okmeter.io corporate blogSystem administration*DevOps*

+21

Comments 17

kelevra Sep 10 2016 at 17:53

было бы гораздо полезней, если бы в статье указали откуда берутся все мониторящиеся параметры. в частности, очень интересно, где взять SYN queue и Accept queue, в виде счётчиков для Linux и FreeBSD.

BlenderRU Sep 10 2016 at 18:13

я так понимаю, что эта статья по совместительству — реклама платного продукта (иного уже почти не встретишь), и не озвучивать все детали — осознанный шаг.

NikolaySivko Sep 10 2016 at 18:22

accept queue: можно смотреть в netstat/ss для LISTEN сокетов, текущий размер в колонке Recv-Q, лимит в колонке Send-Q, например:

$ ss -lnt
State       Recv-Q Send-Q                                                      Local Address:Port                                                        Peer Address:Port
LISTEN      0      128                                                         192.168.100.1:8012                                                                   *:*

для этого сокета текущий размер = 0, лимит 128

NikolaySivko Sep 10 2016 at 18:30

syn queue: насколько я понимаю нельзя посмотреть текущий размер, но при переполнении увеличивается счетчик netstat -st |grep TCPBacklogDrop. Я могу ошибаться, нужно повнимательнее почитать примерно тут

shushu Sep 10 2016 at 18:57

А какую базу вы используете для хранения метрик? По формату оных похоже на prometheus.

NikolaySivko Sep 10 2016 at 20:10

Мы используем самописное решение поверх cassandra. В плане метрик и выражений на prometheus похоже, да.

larrabee Sep 10 2016 at 18:59

Статья реклама, но благодаря ей я решил таки переделать забикс скрипты по мониторингу сети с bash (парсинг вывода ss и ip) на netlink и сходу нагуглил отличную статью по нему https://habrahabr.ru/post/121254/

chemtech Mar 10 2018 at 16:29

Добрый день, будете ли выкладывать ваши скрипты по мониторингу сети на netlink в opensource?

lexore Sep 10 2016 at 21:10

Еще одна распространенная проблема — переполнение таблицы ip_conntrack в linux (используется iptables), в этом случае linux начинает просто отбрасывать пакеты.

Кстати, поэтому лучше не использовать conntrack на серверах под нагрузкой.

swood Sep 11 2016 at 00:51

Лучше вообще его не использовать если трафик tcp. Условные nginx или haproxy отлично умеют проксировать намного эффективнее, а настройка выглядит намного комфортнее. Если же кто-то печется о создании ограничений, то есть iptables с правилами ACCEPT и DROP никто не отменял.

aml Sep 11 2016 at 03:49

И за что люди так любят stacked graphs? Их же читать сложно — тонкие полоски постоянно колбаски, и не поймёшь, они становятся тоньше или толще.

NikolaySivko Sep 11 2016 at 15:17

Stacked areas позволяют оценить сумму сразу и часто значительные изменения получаются нагляднее. Хотя конечно вкусовщина это все =)

shadowalone Sep 11 2016 at 15:39

Писатели намеренно вводят в заблуждение по ss и netstat чтоль?
по ss вывели только tcp (-ant), а по netstat всё (-an).
И да, на разных серверах сравнение ss и netstat не всегда дает преимущество ss, иногда совсем наоборот.

NikolaySivko Sep 11 2016 at 15:46

Да, это ошибка, но в целом результат будет примерно тот же. К сожалению сейчас нет под рукой сервера с большим количеством соединений.

Adnako Sep 21 2016 at 08:37

And on the seventh day there was tcp/ip

IP на третий, TCP на четвёртый.

tonymadbrain Sep 21 2016 at 17:44

А кто-нибудь может подсказать как выводить по отдельности входящие и исходящие сокеты в ss?

NikolaySivko Sep 21 2016 at 18:01

По-моему никак. Идеологически: нужно взять список своих listen сокетов и про все остальные вычислять, есть ли там хотя бы с одной стороны ваш listen. Если есть — сокет входящий, нет — исходящий