Hálózati hibaelhárítási útmutató

Ez az útmutató felvázolja a hálózati teljesítményproblémák diagnosztizálásához és megoldásához szükséges együttműködési lépéseket. Prioritások szerint rendezett folyamatábraként van felépítve, amely a legegyszerűbb, leggyakoribb problémákkal kezdődik, majd áttér a bonyolultabb vizsgálatokra.

Előfeltétel: Az alkalmazásokra vonatkozó bevált gyakorlatok áttekintése

Mielőtt mélyreható hálózati vizsgálatba kezdene, elengedhetetlenül fontos megbizonyosodni arról, hogy az alkalmazás optimális teljesítményre lett-e tervezve. Számos teljesítményprobléma megoldható az alkalmazás tervezésének átalakításával, például a gyakori API-hívások vagy a nem hatékony kiváltók kiküszöbölésével.

Olvassa el itt az alkalmazástervezésről szóló útmutatót.

Ha az alkalmazása már megfelel ezeknek az irányelveknek, folytassa a következő hálózati vizsgálati fázisokkal és az azokhoz tartozó lépésekkel:

1. szakasz: Alapvető ellenőrzések

Minimális erőfeszítéssel gyorsan zárja ki a helyi, kliensoldali és fizikai rétegbeli problémákat.

1. Futtassa az aktuális diagnosztikát az érintett állomásról

• Teendő: Futtassa a következő parancsokat mind a célszolgáltatásra, mind pedig egy stabil, nagy sávszélességű nyilvános végpontra (pl. google.com vagy cloudflare.com) összehasonlítás céljából.
• Hosszabb ping (50–100 ping vagy több) a minimális/átlagos/maximális késleltetés és a csomagvesztés megjelenítéséhez.
• ping 1.1.1.1 (Cloudflare)
• ping 8.8.8.8 (Google)
• pathping (ha Windows rendszeren fut)
• DNS-lekérdezések: nslookup, dig, drill
• A prioritás oka: Ezek az adatok gyűjthetők be a leggyorsabban. Az összehasonlító teszt kritikus fontosságú, és azonnal megmutatja, hogy a probléma a szolgáltatási útvonalra korlátozódik-e, vagy az adott állomásról származó általános internetes probléma.
• Teendő – Használja a Tulip „Hálózati ellenőrzés” funkcióját
  • 1. lehetőség – Egy böngészőablakban lépjen a https://{Az Ön Tulip Instance}.tulip.co/networkCheck oldalra
  • 2. lehetőség – A Tulip Player alkalmazásban kattintson az „Eszközök” menüre, majd a „Hálózati ellenőrzés” elemre.
  • Ellenőrizze az eredményeket
    • Ellenőrizze, hogy minden teszt sikeres-e. Ha nem, készítsen képernyőképet erről az oldalról, majd kattintson a „Diagnosztika letöltése” gombra. Küldje el a képernyőképet és a diagnosztikai fájlt a support.tulip.co címre, és a Tulip egyik képviselője segítséget nyújt majd Önnek.
    • Ezeket a fájlokat megoszthatja a vállalat belső IT-csapatával is, hogy ők is segíthessenek a probléma megoldásában.

2. Végezzen fizikai hardverellenőrzést

• Teendő: Végezzen alapos fizikai hardverellenőrzést az érintett állomásokon. Ellenőrizze, hogy nincsenek-e hibás Ethernet-kábelek, rosszul behelyezett hálózati kártyák vagy problémák a fizikai kapcsolóporttal.A prioritás oka: A fizikai réteg problémái alapvetőek, és bonyolultabb hálózati problémákat is utánozhatnak. Ha ezeket először kizárja, elkerülheti a szoftveres szintű diagnosztikával töltött felesleges időt.

3. Ellenőrizze a helyi állomás konfigurációját

• Teendő: Ellenőrizze a munkaállomás DNS-beállításait, a helyi proxy-konfigurációkat (esetleges átirányítások szempontjából), a helyi biztonsági/tűzfal-szoftvert, és vizsgálja meg a DHCP-kiszolgáló naplóit, hogy megbizonyosodjon arról, a munkaállomáson nem fordulnak elő gyakori DHCP-újratárgyalások.
• A prioritás oka: Ezek kliensspecifikus beállítások, amelyek egyetlen felhasználó számára okozhatnak problémákat anélkül, hogy a szélesebb hálózatot érintenék. Ez a következő logikus lépés a fizikai és általános internetes problémák kizárása után.

4. A helyi rendszernaplók áttekintése a legutóbbi események tekintetében

• Teendő: Az érintett állomásról ellenőrizze a rendszeresemény-naplókat (pl. Windows Eseménynapló, macOS Konzol vagy Linux journalctl/dmesg) a közelmúltbeli hálózati hibák, figyelmeztetések vagy jelentős változások felderítése érdekében, amelyek egybeesnek a teljesítményprobléma megjelenésével. Keresse meg a hálózati adapter állapotváltozásaival, a DHCP-bérlet meghiúsulásaival, a DNS-feloldási problémákkal vagy a tűzfal/biztonsági szoftver riasztásaival kapcsolatos eseményeket.
• A prioritás oka: Ez segít megállapítani, hogy a probléma új keletű-e, vagy összefüggésben áll-e egy közelmúltbeli konfigurációs változással, illetve egy korábbi, helyi hálózati problémával, amely nyomokat hagyhatott az ügyfélgépen.

2. fázis: Korrelált infrastruktúraelemzés

Használjon konkrét eseményadatokat a megosztott hálózati infrastruktúra vizsgálatához. Ehhez a fázishoz IT-hozzáférés és együttműködés szükséges.

5. Határozza meg az időbélyegeket, és vizsgálja át a belső naplókat

• Teendő: Hasonlítsa össze a felhasználók által jelentett lassulási időpontokat a belső hálózati eszközök naplóival. Keresse meg a következőket:
• Magas hálózati jitter
• Csomagvesztés vagy magas újraküldési arány
• Tekintse át a hálózati ábrát, és bocsássa rendelkezésre a naplókat
• A probléma időtartama alatti hálózati naplófájlok (szükség esetén a proxy-naplók is)
• Helyi hálózati torlódás vagy sávszélesség-telítődési események
• A prioritás oka: Ez a vizsgálatot pontos pillanatokra összpontosítja, így sokkal hatékonyabb, mint napoknyi napló átkutatása. Ezt külső felek bevonása előtt el kell végezni.

6. A tűzfal és a biztonsági eszköz teljesítményének áttekintése

• Teendő: A probléma időpontja alatt vizsgálja át a tűzfal/proxy naplóit a blokkolt TCP/UDP-kapcsolatok szempontjából, és ellenőrizze az eszköz erőforrásait (CPU, RAM, kapcsolatok). Kérjük, ellenőrizze azt is, hogy az összes szükséges Tulip IP-cím és domain szerepel-e a fehérlistán, és nem vetik-e alá őket túlzottan agresszív ellenőrzésnek, ami késleltetést okozhat. Fordítson figyelmet a proxy-specifikus mutatókra, mint például a kapcsolati korlátok, az egyidejű munkamenetek és a mélyreható csomagvizsgálat által okozott késleltetés.
• A prioritás oka: A biztonsági eszközök gyakori szűk keresztmetszetet jelentenek. Ezzel ellenőrizhetőek mind a kifejezett blokkolási szabályok, mind a túlterhelt hardver vagy a tolakodó ellenőrzési szabályzatok miatti teljesítményromlás.

7. Vizsgálja meg a szolgáltatásminőség (QoS) konfigurációját

• Tennivaló: Ha QoS-szabályokat alkalmaz, ellenőrizze, hogyan vannak kategorizálva az alkalmazás szolgáltatásaihoz érkező és onnan induló forgalom. Győződjön meg arról, hogy azok nem kerülnek véletlenül alacsonyabb prioritásúvá.
• A prioritás oka: A QoS helytelen konfigurálása az alkalmazás teljesítményproblémáinak egy konkrét és gyakran figyelmen kívül hagyott oka, különösen a magas hálózati forgalmú időszakokban.

8. Elemezze az általános sávszélességet és az SNMP-adatokat

• Teendő: Vizsgálja meg a teljes telephelyen a csúcs sávszélesség-használatot, és ellenőrizze a routerek/kapcsolók SNMP-adatait a problémás időszakokban fellépő magas kihasználtság vagy hibák szempontjából.
• A prioritás oka: Ez alapján megállapítható, hogy a probléma a hálózat teljes kapacitásával vagy a forgalmi torlódással kapcsolatos-e.

9. Elemezze az internetszolgáltató hálózati útvonalát

• Tennivaló: Vegye fel a kapcsolatot az internetszolgáltatójával, és adja meg nekik a magas késleltetés konkrét időpontjait.
• Az internetszolgáltatóval kapcsolatos részletek: Kérje meg őket, hogy vizsgálják meg a nem optimális útválasztást, a peering pontok torlódását, a csomagvesztést/megnövekedett késleltetést a szegmenseiken vagy tranzitútvonalain, illetve az adott időpontokban érvényben lévő releváns hálózati szabályzatokat.
• A prioritás oka: Ez egy külső felet érint, és akkor a leghatékonyabb, ha pontos adatokkal és időbélyegekkel tudja ellátni őket a belső vizsgálat eredményei alapján.

3. fázis: Fejlett, mélyreható vizsgálat

Használjon rendkívül technikai, erőforrás-igényes módszereket a legnehezebben felderíthető problémák felkutatásához.

10. Fejlett, csomagszintű mélyreható elemzés

• Teendő: Végezzen teljes csomag-rögzítést (pcap) az érintett gépen egy lassulási esemény alatt. A kulcs az, hogy kifejezetten összpontosítson az időbélyegek korrelációjára az elemzés minden rétegén. Elemezze a rögzített adatokat csomagmanipuláció (pl. TTL-változások), protokollhibák (TCP-újraküldések) vagy konkrét ICMP-hibajelentések szempontjából.
• A prioritás oka: Ez a legbonyolultabb lépés. A végső, objektív igazságot szolgáltatja, de csak akkor kerül sor rá, ha az összes többi vizsgálat kudarcot vallott az ok felderítésében.