A rendszerünk használ egy 3rd party video streaming szolgáltatást. A felhasználók néha jelzik, hogy akadozik a lejátszás. Jó lenne biztosan, logok alapján tudni, hogy a hálózat akadozik-e, ahogy sejtjük.
Kellene nekünk valami desktop szoftver (Win és Mac), amit odaadnánk pár ügyesebb felhasználónak, hogy futtassa a gépén a háttérben és utána küldje el a logot. Valami olyasmire gondoltam, hogy egy programot elindítanak, majd minimalizálják és az meg 5-10 másodpercenként megnézne néhány általunk beállított DNS lekérdezést, pinget pár IP-re és TCP-n kapcsolódna pár szerver 443-as portjára és lejegyezné, hogy sikeresek voltak-e ezek.
Nyilván tudunk írni egy ilyen szoftvert, de gondolom, hogy másnál is felmerült már ilyen igény... Lehetőleg ne olyanokat ajánljatok, mint Zabbix, Nagios vagy Icinga. Ezeknek a telepítése egy felhasználó gépére nem életszerű. Ideális lenne ha egy binárisból és egy konfigból állna vagy valami kicsi és egyszerűen telepíthető cucc. Van valakinek ötlete?
Hozzászólások
> ügyesebb felhasználónak, hogy futtassa a gépén
wireshark? mondjuk nem pont erre valo es a log is nagy lenne...
> megnézne néhány általunk beállított DNS lekérdezést, pinget pár IP-re és TCP-n kapcsolódna
ilyenrol nem tudok, hogy letezne, de tenyleg nem nehez megirni se.
1x debuggoltunk haosnlo hibajelenseget ott wifis ipari pda-k szakadoztak le a szerverrol, nem volt opcio a pda-hoz nyulni igy a switchen (port mirror) logoltam a forgalmat es ahhoz irtam programot ami kielemezte a tcp kapcsolatokat, valasz nelkuli / retransmittelt csomagokat kerestem foleg, ami biztonyitotta hogy nem a wifi/halo volt a ludas, hanem szar a szerver (eldobalta a kapcsolatokat).
Meglepve látom, hogy van beépített megoldás hozzá:
https://learn.microsoft.com/en-us/windows-server/networking/technologie…
Sok minden került bele a windowsba az elmúlt 15 évben (is), amiről nem születtek sem hangos sajtócikkek, sem látvànyos demonstrációs ismertetők. Egyszerűen csak ott vannak és teszik a dolgukat (csendben) ha az ember megtalálta őket és használja.
Pl. Vista (2006) óta van Snipping tool, amivel lehet tetszőleges területet kivágni a screenshotból, és megjelölni. Ehhez képest az átlagemberek windows10 környékén (10 évvel később) kezdték csak el nagyobb körben megtalálni és használni. Aztán pár éve a MS már kis is nyírta (jószokásuk szerint), h. állítólag valami sokkal ócskább és funkciószegényebb vacakkal helyettesítse win11 alatt.
Vagy hasonló királyság volt a PSR (Problem Step Reporter), ami szintén Vista óta beépítetten ott bújkált minden azóta megjelent Windows-ban. A "hogy történt a hiba, PONTOSAN mit csinált Józsi hogy sikerült neki előhoznia" témakörét mindenki ismeri: fél óráig kell elmagyarázni, pontosan milyen körülményekre kíváncsi az informatikus, aztán a hibát bejelentő Józsi vagy megértette mit várnak tőle, vagy sem. Vagy jól elmagyarázta a körülményeket vagy nem. Na ehhez képest elindítja a PSR-t, rányom a start gombra. Ezután kattintgat 3-4-et, majd miután megtörtént a hiba, rányom PSR-ben a stop gombra, és az elkészült fájlt átküldi az IT-nak, semmi dumát nem kell hozzáfűznie. A legnagyobb találmány a melegvíz feltalálása óta, de szerintem 10-ból jó ha 1 IT-s ismeri.
snip él és virul win11-en, nincs semmi baja, ráadásul tud késleltetéssel indulni (3 vagy 5 sec), ami szerintem nem volt benne az előző verzióban, és hasznos, ha ablakot kell váltani...
Ezt a PSR-t én se ismertem. A Snipping Toolt igen. Mondjuk nem lesz emiatt lelkiismeret-furdalásom, régóta nem windows-ozok.
A topikindító helyében én csak a lejátszóval együtt indítanék egy batch/bash fájlt, ami a pingeket kitolja logba, végtelen ciklusban, és bezáródik a fő alkalmazással, mint szülővel együtt. Valami ilyesmi: ping IP_vagy_host >> /path/log.txt vagy Win-en kell a pingnek a /t kapcsoló.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
WinMTR
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
https://uptime.kuma.pet/
Van opciod, milyen modon akarod lekerni, nem csak ping van.
https://i.ibb.co/NyQXFLw/2024-11-29-18-56-22-Clipboard.png
Beallitotok valami notify-t (en pl ntfy-t ajanlom) es akkor a kuldessel sem kell foglalkozni a usernek.
https://ntfy.sh/
Kombinalhatod meg egy winsw-vel es akkor tenyleg nincs dolga a usernek.
https://github.com/winsw/winsw
HPE-ARUBA-nak van ilyen user experience vizsgáló dobozos megoldása. Kapsz egy dobozt, felkonfigolod és az eszköz folyamatosan mér. Nem csodaszer, de szerintem adnak ingyenes tesztre eszközt.
https://www.pingplotter.com/
Bár alapvetően fizetős, de 14 nap trial után vált csak át az ingyenes módba. Addig is tetszőleges számú hostot pingelhetsz, akár másodpercenként is, ebből készít adatexportot, és grafikont is. Az ingyenes verzióban már csak 1 hostot tudsz pingelni. De nem drága egyébként, szóval ne PRTG szintű árazásra készülj :D
Hoppá, PRTG... az is jó lehet erre, de hasonlóan macerás a telepítés-használat a végfelhasználóknak, mint a Nagios-Zabbix-Icinga.
Én évekkel ezelőtt ezt használtam:
https://www.elifulkerson.com/projects/tcping.php
Tudja naplózni a pontos timestamp-et amikor a packetloss van. Ha jó az időszinkron a gépeken, akkor talán korellálni fog az eredmény a sok gépen párhuzamosan futtatva.
Csak néhány megjegyzés az elmúlt 15 év távlatából, amikor ilyenekkel kellett kínlódnom:
- a LAN-t kell troubleshootolni, vagy a WAN-t is? Mert ha utóbbit (3rd videó streaming platform), akkor az már húzósabb lesz. Mivel ugye az interneten nincs QoS... Akár (extrém példa) még az ISPd is belenyúlhat a forgalmadba, ha észreveszik h. a forgalmad olyan típusú amit ők nem szeretnek és a "net-neutrality" égisze alatt arra hajtanak h. inkább tőlük vegyél ilyen streaming szolgáltatást
- volt az egyik magyar biztosítónál (N....sk) olyan esetem, hogy a lerakott voice gateway időnként elvesztette a kapcsolatot a hálózattal. Így a callcenter-ük is meghülyült. A hálózathoz külsős bedolgozó cégként persze semennyire nem fértünk hozzá, csak megkaptuk a switchportot, UTP drótvéget meg az IP-t az eszközünkhöz. Aztán sok sikert, ilyen körülmények között troubleshootoljunk és bizonyítsuk be h. nem miattunk van. Mert másik oldalról meg persze BIZTOSAN mi vagyunk a hibásak (hülyék). Erre futtattam én is ilyen tcppinget az ottani callcenter szerverünkön, h. lássam mikor és miért tűnik el a voice gateway a hálózaton, van-e bármi csomagvesztés.
Mondanom sem kell, nem mutatott ki hibát, volt 1-2 csomagvesztés 24-48 óra alatt, de amúgy meg a ping riport szép folyamatos és gyors kapcsolatot mutatott. Viszont utána is volt hibabejelentés h. 1x-1x megszakadt a kapcsolat. Long story short, jött a helyi nagypofájú IT-s hálózatos rendszergazda (külsős volt ha jól emlékszem, így normál esetben nem volt a helyszínen elérhető csak külön kérésre külön kiszállásért), hogy mi milyen IP címet használunk a voice gateway-en, és hogy ki adta nekünk ezt az infót? Nyilván nem a szerencsétlen mérnökgyerek szopta ki az ujjából azt a konkrét IP-t. Valószínűleg szóban kapta pont ettől a faszitól (aki a leghangosabban ócsárolt minket az ügyfél előtt), mert írásos nyoma nem volt utána sehol, mikor nyomztunk erről is. Lelövöm a poént: kiosztotta az egyik saját desktop/szerver/VM gépük IP-jét a mi eszközünknek, ami saját gépük az idő nagy részében pont NEM volt bekapcsolva. Statikusan kellett beállítanunk a mi voice gateway-en az IP-t, dhcp-ről szó sem volt. Mivel pedig az induláskor kiadott gratious ARP-ra nem jött reklamáció a hálózaton senkitől, így a mi eszközünk vidáman használta a neki adott static IP-t. És működött az idő nagy részében hibátlanul. Aztán mikor időnként ők bekapcsolták azt a másik saját gépüket, ami szintén static IP-s volt, gondolom ott helyben jött is egy warning h. IP ütközést detektált. De arról nyilván mi nem tudtunk, és ez a gép volt ami belepiszkított időnként a forgalmunkba. Switch-en logból elég hamar kiderült volna az ARP-IP összerendelés ugrálása, de ugye a network-höz se volt hozzáférésünk.
Aztán persze mi lettünk hülyének elkönyvelve, hogy miaz h. a voice gateway (appliance, nem windows, és monitoring amúgy sem volt rá beállítva mert kedves ügyfél nem kérte ill. nem is fizetett volna érte plusszban) nem szólt azonnal h. IP ütközése van, mekkora szar eszközzel dolgozunk mi itt nekik. Szóval tanulság: IP ütközés is okoz(hat) furcsa hálózatos galibákat.