Какую утилиту мониторинга стабильности сети выбрать?
Здравствуйте, есть наш продукт, установленный в приватном дата центре клиента, периодически соединения к базе данных зависают на минуты, но потом успешно отвисают. У других клиентов таких проблем не наблюдается с нашим продуктом.
Зависания происходят периодически, несколько раз в неделю. Клиенты при этом видят, что наш продукт плохо и медленно работает, и грешат на нас.
У нас большое подозрение, что что-то странное творится с сетью, и хотелось бы использовать какой-нибудь мониторинг состояния сети, чтобы составить красивые понятные графики и предложить клиенту сожрать их IT-отдел, а не нас.
Доступ к машинам в приватной сети клиента у нас есть, установить что-то сможем. Открыть порт наружу, или что-то послать наружу - не получится. Монитор должен работать внутри сети, можно на его UI, если он есть, посмотреть через туннель.
Что вы вкладываете в понятие - мониторинг стабильности сети?
Есть наверное какие то метрики, какие то параметры, которые вы бы хотели отслеживать и строить красивые графики?
Сформулируйте ТЗ (не обязательно здесь, возможно даже просто для себя) и посмотрите, как это реализуется.
Есть мониторинги - zabbix, nagios
Есть всякие рисовалки графиков - prometheus, grafana, cacti, smokeping....
Собственно, "ТЗ" это взять клиентских админов за яйца какой-то для всех очевидной тулзой, которая покажет, что их сеть нетривиально лажает. Т.е. упор на метрики сети, вывод тулзы может быть любой, хоть текстом. Главное, чтобы во время очередного нестабильного состояния в приложении, в тулзе было видно, что сеть вообще неадекватна (допуская, что если это реально сеть глючит).
Как отрисовать - это дело вообще десятое, главное чтобы числа были на временной шкале хоть какой-то в любом виде.
Snowindy, не думали ли вы, что логичнее начать диагностику с СУБД и только потом переходить к сети? Как вы себе представляете неполадку сети, приводящую к "периодически соединения к базе данных зависают на минуты, но потом успешно отвисают"?
взять клиентских админов за яйца какой-то для всех очевидной тулзой, которая покажет, что их сеть нетривиально лажает
Таких умников как вы у них в IT отделе тоже найдется не мало. Раз ваш продукт у кого-то нормально работает, то это не значит что проблема не у вас. С таким подходом как у вас их айтишник тоже может сказать, что у них всё в сети работает, кроме вашего продукта, а занчит выноваты вы. И как тут понять кто виноват? Поставьте себе цель помочь клиенту решить проблему, а не сразу тыкать в их ИТ отдел. Если окажется, что проблема была на их стороне, то можно уже тыкать и брать за яица.
ky0, так как я не сетевик, я никак ее не представляю. Я просто вижу что сеть очень странно себя ведет:
- соединения к БД в локальной сети зависают, как я описал
- соединение "загрузить файл на AWS S3 через стандартную AWS Java SDK" зависло минут на пять при мне, где-то на чтении из сокета, и потом отвисло само. На чем зависло я понял потому что снял тред стек дамп прямо на лету.
- наш админ жалуется, что простая печать в консоли периодически мега-медленная.
Может быть там не зависание, а скорость передача байт в секунду, что по факту - эквивалент..
Strabbo, Абсолютно верное замечание, естественно мы корректны в наших формулировках, и допускаем возможность ошибки на нашей стороне. Однако, к сожалению, специалисты на их стороне так себе, оборудование свое они знают слабо, хосты периодически уходят в LoadAverage несколько сотен, с неубиваемыми зомби-процессами, и рестартуют потом часами из-за странно подмонтированных сетевых папок. В общем, ада там хватает, чтобы не расчитывать на особую одаренность и хороших мониторинг ресурсов на их стороне, где это делать правильно и удобно.
Snowindy, стало понятнее. Тогда, наверное, я присоединюсь к комментаторам выше - было бы полезно мерять потери пакетов и пропускную способность сети, особенно в моменты зависаний. Другое дело, что раз, как вы говорите, специалисты у них не очень - есть шанс, что даже ткнув их носом в объективные данные быстро решить проблему не удастся.
Патери пакетов детектируются любой утилитой с соответствующим функционалом, например mtr или обычный пинг, пропускную способность - iperf. Можно запускать их периодически и писать вывод в файлы.
Беретёте zabbix и ставите на сервера/рабочие станции zabbix клиента в active mode - пробросы портов на стороне клиента не нужен.
Ну а там дальше уже мутите мониторинг чего душа пожелает.
Простой
Сложный
