В общем случае это не мониторится никак.

Как-то на непостоянной основе мониторил, гоняя трафик с помощью nuttcp. Триггеры вешал на просадку в пропускной способности и количество ретрансмитов.

А как измерять пропускную способность не убив канал полностью?

Сетевое железо бордерное без проблем стату отдает

Мерял не максимальную, а шейпил до мегабита и ожидал, что проседать не будет и ретрансмитов не будет. Ну, такой кейс был :)

кто ж мне до бордерного железа в ДЦ даст доступ?
servers.com разве дадут?

тут уж проще смотреть на трафик на интерфейсе сервера,

потери проверять пингом по ICMP/TCP кудато - опять же оч относительная метрика

ну вот да, я как раз считаю что простой какой нибудь ping, mtr и т.п. как то запускать периодически...

А что, у них потери пакетов?

да, не факт что у них, скорее где то "по дороге", у меня периодически packet loss до AWS в ирландии из MSK локации скачет до 5-15% и это немножечко напрягает до тех пор пока мы на rabbitmq не переехали

Стесняюсь спросить, какой packetloss можно увидеть на бордере...

Так это же известный кейс. У AWS вообще давно проблемы с каналами, лет семь уже

Ипонвеб кстати проводил сравнение AWS с GCP в одном докладе - там про AWS много эпичного было

есть прикольная тулза от анатоликса

но там на серваке можно увидеть у кого из юзеров лаги

А урл есть?

Я с мобилки - под рукой нет

По запросу померяем все что надо

Ладно, попробую поискать. Спасибо.

Надеюсь, будет чем аргументировать спрыгивание в gcp кроме внутреннего "aws говно"

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

последний раз когда мы писали запрос и приложили ping + tracerouut нас попросили сделать "обратный mtr" и мы на своей стороне сильно задумались "как сделать обратный mtr из SQS" ;) ... как сделать "обратный mtr из EC2" мы понимаем, но не уверены что оно будет эффективно....

в общем я просто думал что есть какие то средства которых я не знаю