sping — TUI для пінгування сервісів

[Володимир Лісівка]

Допис був у тому що (1) - коливання краще дивитися по jitter (який можна надавати для аналізу як разом з затримками так і окремо), (2) - графіки більш інформативні ніж гістограми.

Увімкнув jitter у mtr (клавіша j) та trippy (в настройках) — згоден, це значно краще, ніж очима дивитися різниці пінґів. Відразу видно який вузол на шляху найбільш навантажений. Не знав, що вони вміють його міряти, думав треба nagios чи zabbix для цього.

[yvs115]

jitter у mtr (клавіша j) та trippy (в настройках)

Ще що додатково інформативно це ASN і екстра інфо такого типу (клавіші y чи z для mtr, l чи L для mtr085, у trippy треба шукати напевно теж має бути).

Відносно графиків, малось на увазі щось такого типу як нижче, де нп jitter area може допомогти і підсвітити геопереходи (4 гео і 12 по ttl) і таке подібне.

[BeSiDa]

Графік красиво виглядає, але треба не забувати що він є красивим тільки завдяки згладжуванню, а воно є не "дані", а "видумані значення яких не було" (що поєднують лінією без розривів ті реальні значення, що розділені часом). Тобто більша частина графіку то є тупо лажа )
Але так ... красиво.

А як щодо формату --displaymode 2 в мтр ? (в терміналах з кольором)

[BeSiDa]

Вже було таке, на попередній версії головної сторінки. Потім дописувачам це набридло, та і стільниці стали значно менш візуально привабливими, і воно заклякло, як зараз опитування.

Ааа.. ну то якщо обмежити себе стільницями лише. А як будь що (навіть всілякі візуалізація графів залежностей пакетів чи модулів в пакеті чи мов програмування відповідно до використання в софті (як на гітхаб, наприклад), чи покриття мовами перекладу, чи у розрізі займаного місця (скільки з того софт, скільки з того малюнки чи звук та ін)). Тобто будь що, що зробить більш повним сприйняття навіть того, що само по собі не має красивого інтерфейсу. І можна не змінювати часто. І до того ж створити якісь тулзи що швидко малюють такий аналіз для вказаного лінку (на той же гітхаб чи інші) чи пакету (сорців чи бінарного).

От прямо зараз мені trippy показує втрату 66% пакетів при проходженні через 77.75.151.21 на шляху до 1.1.1.1 по ICMP, тоді як ping (ICMP) та sping (http) показують що проблеми немає.

Так тсп ж повторює відправку пакетів при втраті? Це вже треба тулза що не або/або, а увесь нетворк стек аналізує. Наприклад, "час на встановлення тсп конекту" окремо.
Але то ми вже торкаємоереклад ся дивного питання "а що насправді є Інтернет", бо ... його не існує з технічної точки зору )))  Здавалося б "це те, що має глобальну АйПі адресу", але наразі більша частина пристроїв (і клієнтських, і серверних за реверс проксі різних видів), які вважають себе "частиною Інтернет" та "підключеними до Інтернет" не мають своєї особистої глобальної АйПі адреси. А от тсп конекти можуть мати.
(і це ще коли не торкатися "е-мейлів" що можуть взагалі передаватися зовсім різними типами девайсів та прококолів за межами АйПі, чи окремо "Вебу", що є "мережа УРЛів" які можуть і на листочку паперу бути надруковані і тому той папір є "частиною вебу" (чи коробка з їжею з магазину то теж веб, бо там є "посилання" )) хоч і не існує зворотнього посилання на ту коробку, але в стандартах є варіанти "зворотніх посилань" на обох сторонах лінків (особливо як брати стандарт х-лінк)) ).
Тобто що саме ми хочемо піінгати? Наше уявлення про те що таке "хост"? )))

Ми так і робимо. Я для цього використовую vmping, але воно під Віндовс. Я його навіть переклав українською і трохи підправив: https://github.com/vlisivka/vmPing-ukrainian

Круто!
Переклад завжди приємно.

[BeSiDa]

Допис був у тому що (1) - коливання краще дивитися по jitter (який можна надавати для аналізу як разом з затримками так і окремо), (2) - графіки більш інформативні ніж гістограми.

Сила форуму в тому, що дискусія може вільно пливти з теми в тему
Хоча іноді їх розділяють модератори, коли вже зовсім теми розійшлися ))
Це всілякі твітери (та мастодони) з хештегами можуть вказувати досить точно що саме є суттю допису та кожної відповіді окремо одна від одної. Там можна й без структури пов'язаних коментів спілкуватися (не так як це на форумі).

Форум то більше про "зловити деяку кількість людей" і вже з ними спілкуватися про різне (це ті люди що підписалися на гілку форуму та отримають сповіщення про відповідь). Але то вже застарілий вид спілкування. Тепер більше комбінація твітер+редід+чат+особисті дірект повідомлення+хостинг файлів та каналів розповсюдження файлів, софта та іншого (безвідносно софта та серверів що їх імплементують але з урахуванням "чи існує УРЛ" на те що треба "згадати у повідомленні" і на скільки той урл точний (на окремий комент, чи на всю велику сторінку з тисячма коментами тільки (хоча #ID допомагає))).

І ще в новому "медіумі" це #хештег то більше не "частина серверу", а "те що існує над всім тим" (без "володіння вендером та постачальником сервісу").
А от про "@людина" трохи поки не так... (замість застарілого "людна@сервер", тобто "кріпосний/прикріплений з такого-то серверу"). Тобто феодалізм змінються як для суті теми (хештаг), так і для людей (ет).
 
пс. а "як дивитися коливання", то спочатку розберемося "коливання чого саме" ))

[Володимир Лісівка]

От прямо зараз мені trippy показує втрату 66% пакетів при проходженні через 77.75.151.21 на шляху до 1.1.1.1 по ICMP, тоді як ping (ICMP) та sping (http) показують що проблеми немає.

Так тсп ж повторює відправку пакетів при втраті? Це вже треба тулза що не або/або, а увесь нетворк стек аналізує. Наприклад, "час на встановлення тсп конекту" окремо.

Маршрутизатор може ставити корисні пакети в чергу на відправлення, але пакети ICMP просто відкидати, як не пріоритетні. CloudFlare хвастався, 1-го вересня, що відбив найпотужнішу DDOS на протязі кількох тижнів, то це напевно їхній захист спрацьовує.

Cloudflare's defenses have been working overtime. Over the past few weeks, we've autonomously blocked hundreds of hyper-volumetric DDoS attacks, with the largest reaching peaks of 5.1 Bpps and 11.5 Tbps. The 11.5 Tbps attack was a UDP flood that mainly came from Google Cloud.

[BeSiDa]

От прямо зараз мені trippy показує втрату 66% пакетів при проходженні через 77.75.151.21 на шляху до 1.1.1.1 по ICMP, тоді як ping (ICMP) та sping (http) показують що проблеми немає.

Так тсп ж повторює відправку пакетів при втраті? Це вже треба тулза що не або/або, а увесь нетворк стек аналізує. Наприклад, "час на встановлення тсп конекту" окремо.

Маршрутизатор може ставити корисні пакети в чергу на відправлення, але пакети ICMP просто відкидати, як не пріоритетні. CloudFlare хвастався, 1-го вересня, що відбив найпотужнішу DDOS на протязі кількох тижнів, то це напевно їхній захист спрацьовує.

А чому з інформації "проміжний хост не відповів на 66% пакетів" ви зробили висновок що хоч один пакет до кінцевого хосту втрачений?
66 дуже красиве число і можне вказувати, наприклад, на лоад-балансінг через три різні проміжні хости тільки один з яких відповідає на ті варіанти запитів (а могло бути взагалі 100% пакетів без відповіді і при тому жодного втраченого пакета до кінцевого хосту).
Тобто "проблеми" то не показує.

І до того ж чому ви вважаєте, що протокол ІЦМП не корисний? Ви читали РФЦ? "Пінг" то не головне застосування.
Навпаки були випадки, коли саме для ІЦМП збільшували пріорітети задля того щоб обманути тих, хто дивиться пінг та трейсроут )

А ще є біти в пакетах, що можуть позначати "перевантаження" (і тріппі про них знає). Тому вже більше десятка років не має жодного сенсу використовувати старий алгоритм "відкидання пакетів" лише для того щоб повідомити кінцеві хости про "перевантаження" (колись відкидання було єдиним засобом інформування, але дуже давно).
Дивно, що ви вважаєте, що в мережі хтось може тільки через якісь забаганки щось викинути )  (боротьба з ДДоС то про інше, там спілкування з амінами Гугла, зміна роутингу та інші заходи)