[slepnoga]

Mm, a вы какой именно "carbon" и какой именно графит юзали ?

1. Они не все одинаково полезны.

2. Основная нагрузка на нашине - I/O дисков ( ссд крайне рекомендуются ) и потом уже может быть проц.

3. Даю наколку - InfluxDB :)

[xcme]

Mm, a вы какой именно "carbon" и какой именно графит юзали ?

1. Они не все одинаково полезны.

А какие они бывают? Из портов во фре поставил graphite-web, он подтянул все остальное.

[Negator]

Я уже пару лет точно пытаюсь заниматься поиском проблем на ранней стадии-раньше звонка абонента. Получается не очень. Процент попадания в проблему низкий. Есть абоненты у которых медленно но верно растет счетчик crc. Многим звонили-жалобы у одного из 30. В итоге смотрим на большой рост ошибок за продолжительное время. С полууплексами тоже заморачивались-эффект тот же-люд довольны. При этом часто не попадаем в кабельные проблемы-решаем по звонку. Заббикс решает.

[slepnoga]

Mm, a вы какой именно "carbon" и какой именно графит юзали ?

1. Они не все одинаково полезны.

А какие они бывают? Из портов во фре поставил graphite-web, он подтянул все остальное.

Сорри, но дистрибутивные ( в независимости от дистра, если не патченные ) полное Г. Поставьте хотя бы яндексовский с гитхаба, ну и по п.3 поглядите.

Ну и надо понимать, что это не ПП мониторинга, а скорее фреймворк для его написания.

[slepnoga]

P.S

 

[21:50:01] <slepnoga> Civilian: кин плиз еще раз ссылку на правильный графит
[21:50:43] <Civilian> https://github.com/dkulikovsky/ оттуда ceres, carbon[megacarbon], graphite-web
[21:54:02] <slepnoga> спасибо

[21:54:15] <Civilian> slepnoga: я там тоже кое что подпатчиваю потихоньку )
[21:54:27] <Civilian> и вместо carbon-relay возьми https://github.com/graphite-ng/carbon-relay-ng
[21:54:52] <slepnoga> я скопипащу на наг пруфы ?
[21:54:59] <Civilian> какие именно?
[21:55:00] <Civilian> а
[21:55:02] <Civilian> ну копипасти
[21:55:06] <Civilian> ссылку на як 2013 дай
[21:55:13] <Civilian> https://tech.yandex.ru/events/yac/2013/talks/1122/

[xcme]

Спасибо. Мне Civil уже кинул ссылку на форк Дмитрия. Но вот чем он отличается пока не ясно.

[pchol]

С графитом в конце концов упретесь в скорость вычитки UDP сокета. Он будет забит, и вы будете терять "приходящие данные".

Я бы на Вашем месте посмотрел в сторону redis/memcache, раз уж Вы сами являетесь поставщиком данных.

2М метрик, каждая к примеру 4 байта - итого +8Мб каждые 5 минут, за час 240Мб, за сутки 5760Мб. Тоесть скорее всего машинки в 16Гб с учетом всех оверхедов (и потенциальных проблем) Вам хватит.

А раз в час к примеру читать данные из редиса, агрегировать их, и складывать в какой нибудь любимый mysql.

[Civil]

В Яндексе (см. доклад с Яка 2013) используется graphite-web (+патчи, назначение некоторых из которых я не знаю, но вроде все это было нужно) + свой форк ceres (апстрим слегка умер, а у Дмитрия Куликовского на его гитхабе лежат фиксы ceres-maintaince и еще каких-то мелких багов в самом ceres) + свой форк carbon (использеутся ветка megacarbon, она по тестам была быстрее чем просто карбон и в целом управляется легче).

 

К сожалению инструкция, которая была на Ярушке, недоступна больше. Из чего-то вменяемого я бы посоветовал http://anatolijd.blogspot.de/2013/06/graphitemegacarbonceres-multi-node.html (и вообще в том блоге о Ceres есть заметки, интересные и полезные), только брать форки от Дмитрия.

 

Почему Ceres а не Whisper расказано на докладе с яка 2013 (вкратце - церес быстрее).

 

 

Из особенностей:

1) carbon-writer любит ssd'шки, поэтому лучше держать базу графита на ssd (это в общем касается даже rrd).

2) carbon написан на питоне и, видимо, не самым лучшим образом, поэтому один инстанс writer'а (и relay'а) может прокачать примерно 250 тысяч точек в минуту (при условии что диск столько запишет).

3) carbon-relay призван делать роутинг (притом с consistent hashing'ом, чтобы одни и те же метрики всегда попадали одному и тому же writer'у), но у него те же проблемы что и у остальных carbon-демонов. Как решение - можно взять carbon-relay-ng (https://github.com/graphite-ng/carbon-relay-ng), он написан на Go и сильно быстрее (один инстанс может прокачать до 1.2млн метрик в минуту, что уже близко к разумному пределу на Ceres'е). Плюс еще есть места, где его можно оптимизировать и выжать больше. но у него нет consistent hashing'а (пока), поэтому прийдется или впиливать руками или ждать пока впилят за тебя (есть в ближайших планах)

4) Касательно морды - есть штатная морда, graphite-web, она довольно жирная (Django и все такое), есть альтернативная - graphite-api, но она не умеет ceres (нужно плагин портировать), сам церес нужно подпачить слегка (есть PR https://github.com/dkulikovsky/ceres/pull/2 на это), он на flask'е, тоньше, быстрее и чище (и у него очень адекватный апстрим, всегда можно поговорить с разработчиком и хорошие PRы разработчик быстро принимает).

 

Но вся эта штука очень любит CPU - что graphite-web/graphite-api, что carbon. И узкое место будет именно в процессоре (при наличии ссд дисков конечно же).

 

Как альтернативную базу данных для графита, можно взять influxdb (influxdb.com + https://github.com/vimeo/graphite-influxdb), на запись оно работает довольно адекватно (хотя возможно есть баги), но вот чтение данных лучше делать как можно реже (оно очень медленно данные читает, вот прям очень-очень).

 

Касателньо конкретных цифр - яндексовая схема вида: haproxy -> 8x carbon-relay -> 12x carbon-writer выжимает примерно 1-1.5млн точек в минуту на 2x e5-2660, 64GB Ram, Raid 10 из 4x300GB Intel 520 (SSD). Замена carbon-relay на carbon-relay-ng позволит пиково получать примерно 4-5 млн точек в минуту (примерно столько же и на influxdb), но постоянная скорость будет ограничена диском уже (примерно на уровне 2 млн, может даже меньше), у influx'а - 4млн точек в минуту легко будет писаться почти что сколь угодно долгое время (я сам тестировал на более слабом железе, примерно 12 часов записи по 4млн в минуту оно выдерживало). Только вот прочитать эти данные будет сложновато.

 

И еще небольшой UPD: graphite-api конечно быстрый, но с очень большим колличеством запросов тоже плохо справляется. Он прекрасно (с виду) работает с pypy-2.4, притом прекрасно = в несколько раз быстрее.

 

С графитом в конце концов упретесь в скорость вычитки UDP сокета. Он будет забит, и вы будете терять "приходящие данные".

У графита есть tcp + udp, и tcp работает постабильнее в данном случаи.

Изменено 4 ноября, 2014 пользователем Civil

[xcme]

Запустил сборщик для RX/TX с 640 устройств. Это 43358 метрик. В среднем они собираются за 15 секунд. В карбон передаются за 2,5 секунды. Интервал опроса 300 секунд.

Параметры карбона:

MAX_CACHE_SIZE = inf - чтобы не надо было дозировать метрики (иначе получается переполнение и соединение виснет)

MAX_UPDATES_PER_SECOND = 2000

MAX_CREATES_PER_MINUTE = 2000

 

Теперь посмотрим на графики. Синяя линия - создание файлов метрик. Зеленая - обновление. Красная - принятые метрики. Из-за способа отрисовки кажется, что данные передаются в течении двух минут, но на деле там 2-3 секунды.

С красной линией все понятно - всегда передается одинаковое кол-во метрик. А вот с двумя другими интересно. Судя по синей линии, карбон не спешит создавать все сразу. 2000 в минуту это где-то 33 в секунду, но на графиках линия падает до 0, а не идет параллельно горизонту. Обновление метрик (зеленая линия) происходит только для созданных файлов. Где то через 75 минут все файлы создаются, тогда красная и зеленая линии начинают совпадать.

Делаю снимки файлов раз в несколько секунд и смотрю что обновилось:

2014-11-04 18:12:47 - 0 - после запуска ничего не обновилось

2014-11-04 18:13:01 - 12 - 12 метрик самого карбона

2014-11-04 18:13:14 - 12 - // -

2014-11-04 18:13:26 - 3545 - пошло обновление

2014-11-04 18:13:40 - 25673

2014-11-04 18:13:53 - 43370 - все метрики обновлены. 43358 + 12 = 43370

2014-11-04 18:14:08 - 43370

2014-11-04 18:14:22 - 43370

 

Судя по замерам, обновление происходит как раз с заданной скоростью - 2000 метрик в секунду. А вот что с их созданием? Пока не очень понятно.

[Civil]

А с этим все просто:

https://github.com/graphite-project/carbon/blob/dec9dfed89ea19e756fd5a45ff6462874b03b904/lib/carbon/writer.py#L73

Читаем эту строку и коммент после нее. Если очень лениво, то процитирую коммит:

# dropping queued up datapoints for new metrics prevents filling up the entire cache

# when a bunch of new metrics are received.

 

У мегакарбона другое поведение, более логичное, но и более опасное (в карбоне обычном так сделано, чтобы не пришел ООМ если очень много данных запихнуть в графит).

[sexst]

Для анализа и записи графиков по куче портов курите riemann + influxdb. Графит потребует кучи серверов и сложной многослойной системы. Да и вообще неоптимизирован и ужасен. Единственный плюс - его дашборд с кучей функций.

[Civil]

Для анализа и записи графиков по куче портов курите riemann + influxdb. Графит потребует кучи серверов и сложной многослойной системы. Да и вообще неоптимизирован и ужасен. Единственный плюс - его дашборд с кучей функций.

У influx'а проблема со скоростью чтения и есть еще ряд нерешнных проблем: https://github.com/influxdb/influxdb/issues/884 + https://github.com/influxdb/influxdb/issues/1042 + https://github.com/influxdb/influxdb/issues/945 которые немного мешают его эксплуатации. Но в целом он выглядит неплохо, согласен. Скорее всего к 0.9 или 1.0 будет очень юзабельным.

 

Про графит - ну да, он многослойный, но на небольших объемах (до 1 млн точек в минуту) ему достаточно почти любого 4-х ядерного процессора + ссдшки десктопного класса. Да, прийдется слегка пошаманить подбирая конкретно под себя связку из relay + writer'ов и немного поковыряться в конфиге, но потом оно будет просто работать.

 

На текущем месте работы, графит у нас вообще живет на самой дешевой железке из hetzner'а с ссдшками (это i7-2600, 16GB Ram, 2x OCZ Vertex 3 120GB в mdadm raid 1), в него пишут примерно 0.5млн точек в минуту, la на сервере порядка 3 (и это при параллельном чтении), по диску тоже еще есть куда стремится. На тестах перед тем как вводить это дело в строй, удавалось писать стабильных 1млн точек (параллельно с чтением), пиковое до 4 с лишним. Да, influxdb (0.8.1, на момент тестов самый свежий) позволял писать стабильных 4 млн (или пиковые нагрузки до 5млн на короткое время), но не мог читать с нужной скоростью, к сожалению (на graphite-api приходится примерно 60 запросов в секунду в пике, каждый запрос - выборки вида groupByNode(server.somestat.*,"sumSeries") где * раскрывается в 30-40 линий). Правда чтобы добится такого низкого LA весь графит работает на pypy 2.4 сейчас (megacarbon и graphite-api) + как релей используется патченный carbon-relay-ng (патчем добавлена поддержка Consistent Hashing).

Изменено 5 ноября, 2014 пользователем Civil

[sexst]

Для анализа и записи графиков по куче портов курите riemann + influxdb. Графит потребует кучи серверов и сложной многослойной системы. Да и вообще неоптимизирован и ужасен. Единственный плюс - его дашборд с кучей функций.

У influx'а проблема со скоростью чтения и есть еще ряд нерешнных проблем: https://github.com/influxdb/influxdb/issues/884 + https://github.com/influxdb/influxdb/issues/1042 + https://github.com/influxdb/influxdb/issues/945 которые немного мешают его эксплуатации. Но в целом он выглядит неплохо, согласен. Скорее всего к 0.9 или 1.0 будет очень юзабельным.

riemann как раз таки позволяет сильно снизить чтение проводя анализ данных на лету. Ну если вам шашечки и ехать, пишите свое на key-value бд. Тот же RocksDB от инфлукса возьмите.

[xcme]

riemann как раз таки позволяет сильно снизить чтение проводя анализ данных на лету. Ну если вам шашечки и ехать, пишите свое на key-value бд. Тот же RocksDB от инфлукса возьмите.

А туда можно отдавать собранные мной метрики, чтобы он их обдумывал и дальше кидал в графит? Или он должен сам все собирать?

[Civil]

riemann как раз таки позволяет сильно снизить чтение проводя анализ данных на лету.

Тут проблема в том, что люди любят смотреть на дашборды с графиками и глазами анализировать. Им просто так нравится, а это создает довольно большое колличество запросов к базе на чтение. Грубо говоря у каждой команды свой "телевизор с графиками", плюс у каждого разработчика-менеджера-начальства свои любимые наборы графиков, которые они периодически смотрят (второй-третий монитор на котором на пол экрана ротируются заданные графики). Я сам честно не понимаю, как такое может быть удобным и юзабельным, но факт есть факт.

 

Ну если вам шашечки и ехать, пишите свое на key-value бд. Тот же RocksDB от инфлукса возьмите.

В текущий момент меня пока все устраивает. Я просто поделился граблями, на которые наступил, когда щупал InfluxDB, чтобы это было где-то записано. Я на него смотрю уже довольно давно (первый раз проверял еще в начале лета, на релизе 0.7, последний раз буквально в октябре на 0.8). Он выглядит интересно, многообещающе, но по скорости далек от идеала, также по стабильности тоже есть некоторые проблемы. Притом, похоже, проблемы со скоростью - фундаментальные для всех LevelDB-based движков. С переходом на RocksDB стабильность скорости чтения и записи сильно выросла, но меня не устраивает именно то, что чтение и удаление данных - очень дорогие операции в Influx'е. плюс ко всему, в Ceres можно симлинками довольно гибко поменять структуру метрик, а простым rm'ом удалить лишние данные (изменения имени также просто делается и с Whisper/RRD, с удалением правда чуть сложнее, как и с добавлением новых линий), а вот с Influx'ом такое не прокатит.

Изменено 7 ноября, 2014 пользователем Civil

[sexst]

А туда можно отдавать собранные мной метрики, чтобы он их обдумывал и дальше кидал в графит? Или он должен сам все собирать?

Riemann это пайп с прикрученным анализатором. Он сам ничего не собирает. Так же как и инфукс/графит и прочие.

[xcme]

Решил на днях некоторые проблемы со сборщиком метрик, теперь можно вернуться к теме. Изначально была цель находить проблемные подключения. Как справедливо заметили, TX-ошибки тут помогут мало, значит выкинем их из первоначального набора метрик. Потом была подсказка про анализ данных на лету. Действительно, нет смысла непрерывно писать те же состояния витой пары, когда лучше оперативно среагировать на short и т.д. Что тогда остается:

 

1. RX (ifHCInOctets)

2. TX (ifHCOutOctets)

3. RX CRC (etherStatsCRCAlignErrors)

4. Тип дуплекса (dot3StatsDuplexStatus)

5. Административно заданная скорость (swL2PortCtrlNwayState)

6. Статус 1-й пары (swEtherCableDiagPair1Status)

7. Статус 2-й пары (swEtherCableDiagPair2Status)

8. Длина 1-й пары (swEtherCableDiagPair1Length)

9. Длина 2-й пары (swEtherCableDiagPair2Length)

 

RX/TX показывают загрузку порта. Понадобится при разборе "задним числом" некоторых ситуаций. Эти 2 метрики надо писать, но анализатору они не нужны.

 

RX CRC - самая внятная статистика по ошибкам. Тоже лучше писать, может пригодиться потом. И в анализатор послать не помешает.

 

А вот тип дуплекса и административно заданная скорость нужны для диагностики неправильных настроек со стороны абонента (тип дуплекса) или со стороны оператора (заданная скорость вручную). Хранить эти данные смысла нет, а вот "подать сигнал" человеку на мониторинге вполне можно. Т.е. эти метрики собираем, но отправляем только в анализатор.

 

Статусы пар могут сигнализировать об замыкании на кабеле, но сами по себе значения не представляют ценности. Поэтому эти метрики отправляем только в анализатор.

 

А вот длины лучше записывать, поскольку отдельно взятое значение ни о чем не говорит, а длина при диагностике может быть определена не всегда. Копию отправляем в анализатор.

 

Таким образом, в карбон попадает 5 метрик (RX, TX, CRC, Длина1, Длина2), а в анализатор 7 (все, кроме RX/TX).

 

Сохранение метрик.

Длины и CRC - абсолютные значения, а вот RX/TX счетчики. Сборщику данных можно указать, что конкретное значение является счетчиком, так что тут проблем нет. В итоге метрик остается всего 5, т.е. дисковая система и процессор справятся, если судить по приведенным в теме цифрам. Получается, что с графит/карбон проблем мы не ожидаем.

 

Анализ.

RX CRC - Реагировать раз в сутки если счетчик увеличился X раз за интервал Y.

Тип дуплекса - Реагировать раз в сутки если значение счетчика равно 2.

Заданная скорость - Реагировать раз в сутки если значение отличается от Auto (как проверить? значение зависит от модели) и порт не магистральный (как проверить?)

Статусы пар - Реагировать раз в сутки, если значение в диапазоне [2,3,4].

Длины пар - Реагировать раз в сутки, если разница между 1 и 2 парой больше 4 либо если значение отличается от последнего не нулевого в меньшую сторону больше, чем на 10% (как это выяснить?).

 

Если это все реализовать, то практически все аномалии на абонентских линиях будут обнаружены. Теперь вопрос такой: Riemann - это то, что нужно для проведения вышеописанного анализа? Получается, что некоторые значения надо хранить в памяти какое то время. Посмотрел сайт, мне показалось, что функционал приложения избыточен, а настройка не так уж проста.

[xcme]

Посмотрел еще на Riemann, похоже он не может принимать данные как Graphite. Нужен специальный клиент, причем там все недостаточно прозрачно. Например для Riemann есть клиент riemann_wrapper, который использует bernhard, и т.д. Какой то громоздкий конструктор получается, с разбегу такую высоту не взять. :) Причем не понятно, может ли вообще Riemann решить описанные задачи.

[xcme]

Ну, в общем, я написал свой анализатор. Умеет:

• распознавать соответствие условию (равно/больше/меньше), уменьшение или увеличение значения
  
• поддерживает несколько условий для одного события
  
• может выжидать паузы после оповещения во избежание спама
  
• оповещать о событиях через джаббер
  

 

По задумке должен работать с такими типами событий (настраивается):

"Обнаружен рост ошибок RX CRC на порту {$key} устройства {$host} [{$device}]!"
"Порт {$key} на устройстве {$host} [{$device}] работает в режиме half-duplex!"
"Скорость порта {$key} на устройстве {$host} [{$device}] задана вручную!"
"Пара №1 порта {$key} на устройстве {$host} [{$device}] имеет повреждения!"
"Пара №2 порта {$key} на устройстве {$host} [{$device}] имеет повреждения!"
"Длина 1-й пары на порту {$key} устройства {$host} [{$device}] уменьшилась более чем на 10 метров!"
"Длина 2-й пары на порту {$key} устройства {$host} [{$device}] уменьшилась более чем на 10 метров!"

Пока тестил на дуплексе и скорости порта - сообщения прилетают, причем их больше, чем я ожидал. Опросил 100 свичиков, прилетело 17 сообщений об различных аномалиях.

 

Есть проблема - на больших объемах данных захлебывается. Тысячу свичей (58к метрик) не прожевал за разумное время. Думаю, это проблема алгоритма и я ее решу. Так что сдвиги по задаче есть! :)

 

p.s. Напомню задумку: опросчик собирает метрики со свичей, часть из которых отправляет в графит, а часть - в анализатор, который находит аномалии и пишет в лог. В графите, при желании, смотрим RX/TX и RX CRC.

[ThreeDHead]

Как часто повторяете сбор счетчиков на каждом коммутаторе?

Вычисление длинны кабеля является достаточно дорогой по времени операцией - сколько раз в сутки выполняете её?

[xcme]

Как часто повторяете сбор счетчиков на каждом коммутаторе?

Вычисление длинны кабеля является достаточно дорогой по времени операцией - сколько раз в сутки выполняете её?

Пока я запускаю сборщик только на время отладки. В дальнейшем хочу опрашивать всю сеть за 5 минут. Тут были сообщения, что частая диагностика приводит к глюку, но это вроде как только на 3526 (у меня их нет) да и то не до конца подтверждено. В общем, я по нарастающей запущу, 3 свичика, 30, 300, 3000. Если с диагностикой будут проблемы придется убирать ее или делать опрос раз в час, но на стенде с ней никаких проблем не видел.

[Negator]

Тема интересная, жду практики.

Мы пока анализируем только CRC ошибки.

Длину кабеля тоже можно, хотя результатам я не склонен точно верить.

Меня больше интересуют дальнейшие действия. У меня затык на этом пункте.

Почему?

Вот пример:

 

Увидели значительный рост CRC ошибок на порту, вручную проверили - иногда скачет дуплекс на порту. На одной из пар диагностика порой показывает short

- в общем явно кабельная проблема. Судя по длинне кабеля - вероятно в квартире абонента.

Позвонили абоненту - "Здравствуйте, мы обнаружили кабельную проблему на вашей линии. Вероятно у Вас наблюдаются проблемы со скоростью. Мы готовы прислать мастера для проверки линии...."

Ответ абонента "Никаких мастеров не надо! Вы меня пытаетесь развести на деньги! Я буду жаловаться! В квартиру не пущу! Если у Вас есть проблемы - сами ее и чините."

Даже письмо гневное прислали на имя директора - что их хотят развести на деньги.

И все в таком духе.

Через 3 дня - обращение абонента с проблемой и ремонт в квартире. При этом у абонента все равно остался негатив в итоге.

 

Другая проблема - аналогична.

Позвонили. Дома жена/теща. Жалоб нет. Ходить не надо.

Через 3 дня - заявка. на ремонт. То есть вроде как попали, но абонент доволен. А через некоторое время замечает проблему.

 

Третий пример. - в общем то же самое. Проблема явно в квартире.

Приходить не надо, ваши проблемы вы и чините.

Через месяц узнаем что отключился - т.к. мало того что интернет плохо работал, ему еще и позвонили сказали об этом.

Мол починить не могут - пойду к другим.

 

Сейчас думаем- стоит ли вообще звонить, т.к. 90% подобных проблем - на стороне клиента.

 

Я к чему - анализа проблемы мало, нужно еще понять что с ней делать, и стоит ли вообще делать.

И желательно тоже -в автоматическом или полуавтоматическом режиме.

Иначе все эти диагностики и не нужны вовсе.

[ThreeDHead]

Мы тупо ловим трапы, создаем вот такой ТОП, потом его отрабатываем:

 

Negator у нас ~40% абонентов из этого списка, отказываются от ремонта - "У нас все работает, отвалите". Остальные в основном даже не подозревают о проблеме, соглашаются на визит ремонтников, создаем наряд на ремонт. Но не все наряды выполняются, т.к. эти абоненты потом теряются. Ну стыковка с абонентом - это вообще самая большая проблема.

Но тем не менее, после ввода этого ТОП'а, стало заметно меньше жалоб.

 

Тут же определяются коммутаторы с выбитыми молнией портами, тысячи флапов порта - порт выбит грозой.

Точно так-же мониторим и магистрали, но это уже другой отдел занимается.

 

А что касается мониторинга трафика на портах, то тоже такое имеется, но только для магистралей, собираем и пишем в RRD, которые лежат на SSD.

[Natoshka]

Negator работаю в ТП провайдера. Мы часто звоним абонентам по аналогичным выявленным нами же проблемам (пришло письмо о ДДос атаке с ИП абонента, различные штормы на портах, петли на портах и т.п., в том числе и при росте ошибок на порту). В большинстве случаев, наверно процентов 80, абоненты соглашаются и на ремонт кабеля(у нас он бесплатный, о чем мы заранее предупреждаем абонента), и на перенастройку роутера, и на проверку на вирусы(рассказываем по телефону, что запустить и как все сделать). Некоторый процент абонентов делают все сами и только единицы отказываются от помощи и ремонта.

p.s. не исключаю и того, что многие соглашаются именно из-за бесплатности

[xcme]

Negator, вопрос "Что делать дальше?" хороший и ответа на него у меня пока нет. Видимо, действовать по ситуации.

Я починил проблему с производительностью и запустил тестовый прогон на 1000 свичиков. В ответ прилетело 220 сообщений о неправильном статусе порта. Разгребая это пришел к выводу, что ошибочную скорость может выставить биллинг. Будем разбираться когда и зачем он это делает. Нашел абонента, который сидит на 10half по крайней мере несколько месяцев. Другой сидит на 100Full видимо год или больше, ошибки растут, один раз он звонил в ТП. В общем, польза определенно есть. Как разберемся со скорость, займусь длиной кабеля и остальным. Может потом сделаем ТОП примерно как у ThreeDHead.