TOPTHOR Get started
Ankieta #76270- test javascript

Ankieta zapotrzebowania na wtyczki do VCF Operations

Wstęp i instrukcja wypełniania

Serdecznie zapraszamy do udziału w krótkiej ankiecie dotyczącej infrastruktury IT. Celem niniejszego badania jest zebranie Państwa opinii oraz preferencji w zakresie rozwiązań technologicznych wykorzystywanych w Państwa organizacji.

Ankieta została podzielona na główne obszary tematyczne, w ramach których znajdują się szczegółowe podtematy.

W każdym z wymienionych podtematów prosimy o zaznaczenie maksymalnie 3 wyborów, które są dla Państwa najistotniejsze lub najlepiej odpowiadają Państwa potrzebom.

1. Serwery / Compute

Monitoring fizycznych serwerów obejmuje wszystkie warstwy sprzętu mogące wpłynąć na wydajność i stabilność aplikacji: obciążenie CPU (throttling, power capping, C-states, Turbo Boost), błędy i zużycie RAM (ECC correctable/uncorrectable errors — sygnał pogorszającej się pamięci), temperatury procesorów, chipsetów, dysków NVMe i PCIe — przegrzanie powoduje throttling i spowolnienie całego hosta. Stan dysków lokalnych (SMART, wear level, latencja NVMe), zasilacze i redundancja PSU, prędkości wentylatorów i progi alarmowe, logi zdarzeń SEL (System Event Log) — tu zapisują się błędy przed awarią, stan kart sieciowych i HBA (link up/down, błędy CRC), firmware i microcode. Kluczowe dla RCA: nagły wzrost temperatury → CPU throttling → wolniejsze VM; ECC uncorrectable error → kernel panic / BSOD na hoście; awaria PSU → failover lub utrata węzła klastra.

Serwery

2. Hyperkonwergencja (HCI) i konwergencja

Platformy HCI łączą compute, storage i sieć — monitoring musi korelować wszystkie trzy warstwy jednocześnie, bo problemy w jednej wpływają na pozostałe. Kluczowe metryki: CVM (Controller VM) health — CVM to serce HCI; awaria CVM = utrata dostępu do storage dla wszystkich VM na węźle; storage pool utilization i latencja (lokalny vs. zdalny I/O — im więcej I/O przez sieć, tym wyższa latencja); CPU i RAM dostępne dla VM po odjęciu zasobów infrastruktury (Nutanix CVM, VMware vSAN); rebuild i rebalance po awarii węzła — podczas rebuildingu wydajność spada o 20–40%; sieć wewnętrzna klastra (Storage Network) — nasycenie sieci klastra blokuje I/O; węzeł w degraded mode — brak pełnej redundancji = ryzyko utraty danych przy kolejnej awarii. Kluczowe dla RCA: CVM restart → przerwa dostępu do storage dla VM na węźle; pełny storage pool → zatrzymanie wszystkich zapisów; rebuild po awarii dysku → wzrost latencji i spadek IOPS.
Wgląd VM, storage pool, węzły, CVM, zdrowie, wydajność, pojemność

Hyperkonwergencja (HCI) i konwergencja

3. Wirtualizacja

Monitoring warstwy wirtualizacji obejmuje metryki niewidoczne z poziomu OS gościa, a bezpośrednio wpływające na wydajność aplikacji: CPU Ready (% czasu VM czeka na fizyczny CPU) — powyżej 5% aplikacja odczuwa spowolnienie; CPU Co-Stop (klastry NUMA); Memory Balloon i Swap — hypervisor odbiera RAM od VM → aplikacja używa swap = dramatyczny wzrost latencji; Memory Compression — CPU overhead dla kompresji pamięci; Storage Latency z perspektywy VM (vm.maxTotalLatency) — jeśli wysoka, problem jest w storage lub sieci storage; Network Dropped Packets na vSwitch/dvSwitch; vMotion i Storage vMotion — migracje powodują chwilowy wzrost latencji; HA/DRS eventy — failover VM lub balansowanie obciążenia; dla kontenerów: CPU throttling (limits vs. requests), OOMKill (zabicie kontenera = przerwa usługi), restart count podów. Kluczowe dla RCA: CPU Ready > 10% → aplikacja 'wolna' mimo niskiego CPU w OS; Memory Balloon → aplikacja działa ze swapem; OOMKill → kontener restarted → przerwa serwisu.

Wirtualizacja

4. Kontenery

Kontenery

5. Chmura publiczna

Monitoring chmur publicznych i usług na nich działających jest krytyczny z perspektywy dostępności, wydajności, bezpieczeństwa oraz kontroli kosztów: dostępność usług IaaS, PaaS i SaaS (VM, Kubernetes, bazy danych, storage, load balancery) — awaria jednej usługi może zatrzymać całą aplikację; wykorzystanie CPU, RAM, storage i autoskalowania — błędna konfiguracja prowadzi do degradacji wydajności lub wzrostu kosztów; latencja sieci i storage (IOPS, throughput, latency) — bezpośrednio wpływa na czas odpowiedzi aplikacji; limity i quota usług — ich osiągnięcie blokuje skalowanie i wdrożenia; monitoring kosztów (budżety, anomalie, niewykorzystane zasoby, transfer danych) — pozwala wykryć niekontrolowany wzrost wydatków. Kluczowe dla RCA: quota usług → brak nowych zasobów; błędne autoskalowanie → przeciążenie lub wzrost kosztów; degradacja storage/sieci → spadek wydajności aplikacji; awaria regionu lub usługi zarządzanej → niedostępność aplikacji.
Chmura publiczna: VM/Instances, Kubernetes, bazy danych, storage, sieć, load balancery, usługi zarządzane, dostępność, wydajność, pojemność, koszty (FinOps), wykorzystanie quota i limity usług.

Chmura Publiczna

6. Macierze dyskowe / Storage

Monitorowanie macierzy dyskowych (storage arrays) w zakresie ich parametrów wydajnościowych, zdrowia, dostępności, konfiguracji i funkcjonowania, pul pamięci (storage pools), wolumenów, grup hostów, dysków fizycznych, kontrolerów, zasilaczy, wentylatorów, baterii systemowych, połączeń i replikacji, a także pojemności i jej predykcji (capacity forecasting)

Macierze dyskowe

7. Sieć SAN / Fibre Channel

Monitoring sieci SAN / Fibre Channel jest krytyczny, bo problemy na tym poziomie bezpośrednio powodują I/O errors i timeouty w aplikacjach: BB_Credit (Buffer-to-Buffer Credit) — gdy spada do zera, I/O zostaje całkowicie wstrzymane; błędy FC (CRC errors, Loss of Sync, Loss of Signal, Link Reset) — przejściowe błędy powodują przerwy w I/O; congestion i powolne drain — jeden wolny host może zablokować cały segment fabric; latencja I/O na portach FC; stan ISL (Inter-Switch Links) — saturacja ISL = wąskie gardło dla całego fabric; dostępność ścieżek MPIO — utrata jednej ścieżki powoduje failover i chwilowy wzrost latencji; zoning — błędy konfiguracji zoning uniemożliwiają dostęp hosta do storage. Kluczowe dla RCA: CRC errors na porcie → przerywane I/O errors; BB_Credit = 0 → całkowity stall I/O → timeout aplikacji; awaria ISL → ruch storage przez jedną ścieżkę → saturacja.

Sieć SAN / Fibre Channel

8. Sieć LAN / Przełączniki i routery

Monitoring sieci LAN obejmuje parametry kluczowe dla latencji i dostępności aplikacji: wykorzystanie interfejsów (% bandwidth) — saturacja łącza to bezpośrednia przyczyna wzrostu latencji, packet loss i retransmisji TCP; błędy interfejsów (CRC, input/output errors, giants, runts) — wskazują na problemy ze sprzętem lub kablami; STP (Spanning Tree) — zmiany topologii powodują chwilowe przerwy w komunikacji (30 s converge = blackout); stany protokołów routingu BGP/OSPF — utrata sąsiedztwa = utrata trasy do aplikacji lub storage; MTU i jumbo frames — niezgodność MTU powoduje fragmentację i dramatyczny wzrost latencji dla NFS/iSCSI/vMotion; stan trunk VLAN i port-channel/LACP — utrata portu z LAG = redukcja przepustowości; QoS — brak priorytetyzacji ruchu storage lub VoIP powoduje degradację; flow (NetFlow/sFlow) — identyfikacja 'zajmujących całe łącze'. Kluczowe dla RCA: 100% utilization interfejsu → retransmisje TCP → spowolnienie aplikacji; STP TCN (topology change) → 30s blackout; MTU mismatch → I/O errors dla NFS/iSCSI.

Sieć LAN / Przełączniki i routery

9. Sieci WAN, tożsamość

Sieci WAN

10. Sieć VPN

Monitoring sieci WAN, VPN i tożsamości obejmuje elementy krytyczne dla dostępu użytkowników i systemów do aplikacji: terminatory VPN — liczba aktywnych sesji, przepustowość tuneli, latencja (VPN dodaje 10–50ms dla użytkowników zdalnych), błędy autentykacji (sygnał problemów z ADFS/RADIUS), certyfikaty SSL (data wygaśnięcia — expired cert = wszyscy użytkownicy tracą dostęp); SD-WAN — jakość poszczególnych łączy (latencja, jitter, packet loss per link), automatyczne przełączanie (failover) między łączami i czas failover; Direct Connect/ExpressRoute — przepustowość, BGP session state (utrata BGP = utrata łącza do chmury), latencja do cloud; ADFS/IdP — czas wystawiania tokenów, error rate autentykacji, dostępność endpointu federation (niedostępny ADFS = niemożność logowania do wszystkich aplikacji federowanych). Kluczowe dla RCA: packet loss > 1% na łączu WAN → retransmisje TCP → spowolnienie aplikacji; ADFS endpoint down → logowanie niemożliwe dla 100% użytkowników; wygaśnięcie certyfikatu VPN → brak dostępu dla pracowników zdalnych.

Sieci VPN

11. Bazy danych i platformy danych

Monitoring baz danych dostarcza kluczowych informacji dla RCA problemów aplikacyjnych: latencja zapytań (średnia, P95, P99 per query/SP) — identyfikacja wolnych zapytań; wait events (lock waits, I/O waits, CPU waits, network waits) — dokładne wskazanie gdzie zapytanie traci czas; blokady i deadlocki — blokowanie sesji zatrzymuje transakcje w aplikacji; buffer/cache hit ratio — niski ratio = dużo I/O do storage (korelacja z latencją storage); connection pool utilization — wyczerpanie puli połączeń = nowe żądania czekają lub dostają błąd; replikacja (lag w ms) — opóźniona replika zwraca nieaktualne dane lub powoduje failover z utratą danych; log shipping / WAL apply lag; rozmiar i wzrost tabel/indeksów, bloat — puchnące indeksy = wolniejsze zapytania; backup i czas wykonania — długi backup blokuje I/O; autovacuum/purge — zaległości powodują bloat i spowolnienie. Kluczowe dla RCA: lock wait → aplikacja 'zamarza'; I/O wait → problem w storage; connection pool wyczerpany → HTTP 503 w aplikacji.

Bazy danych i platformy danych

12. Aplikacje i middleware

Monitoring middleware i aplikacji uzupełnia obraz o warstwy niewidoczne dla infrastruktury: JVM heap i GC (Garbage Collection) — długie GC pauzy (Stop-the-World) powodują timeouty requestów — aplikacja 'zamarza' na sekundy; thread pool utilization — wyczerpanie puli wątków = kolejkowanie żądań → wzrost latencji → timeout; connection pool do bazy danych — wyczerpanie → HTTP 500/503; kolejki żądań (queue depth) — wskaźnik zaległości; response time per endpoint i percentyle (P95, P99); error rate (4xx, 5xx) — nagły wzrost = problem w kodzie lub infrastrukturze; session count i concurrent users; Active Directory / ADFS: czas odpowiedzi LDAP i Kerberos — wolna autentykacja = timeout logowania w aplikacji; replikacja AD między kontrolerami domeny; kolejki EAP/Exchange: długość kolejki = opóźnienia dostarczania poczty. Kluczowe dla RCA: Full GC co 5s → timeouty API; wyczerpanie thread pool → HTTP 503; wolne LDAP → niemożliwość zalogowania.

Aplikacje i middleware

13. Backup, odtwarzanie po awarii (DR) i replikacja

Monitoring infrastruktury i oprogramowania backupu jest krytyczny z perspektywy RCA i ciągłości działania: status i wynik zadań backup (success/warning/failed) — nieudany backup wykryty po fakcie = brak możliwości odtworzenia po awarii; czas trwania okna backupu — zbyt długie okno powoduje nakładanie się zadań i wzrost obciążenia I/O na produkcji; przepustowość backupu (MB/s) — identyfikacja wąskich gardeł na ścieżce backup (sieć, storage, proxy); stopień deduplikacji i kompresji — nagły spadek wskazuje zmianę charakteru danych; pojemność i zajętość repozytoriów — pełne repozytorium = zatrzymanie wszystkich zadań; stan napędów taśmowych i bibliotek (błędy odczytu/zapisu taśmy = niezapisany backup); lag replikacji i RPO — dla systemów DR, opóźnienie replikacji określa maksymalną utratę danych przy awarii; RTO — czas odtworzenia po awarii (monitoring testów DR). Kluczowe dla RCA: cichy błąd backupu → brak RPT przy awarii; pełne repozytorium → wszystkie backupy zatrzymane; lag replikacji > RPO → naruszenie SLA.

Backup, odtwarzanie po awarii (DR) i replikacja

14. DR i replikacja

Monitoring infrastruktury i oprogramowania backupu jest krytyczny z perspektywy RCA i ciągłości działania: status i wynik zadań backup (success/warning/failed) — nieudany backup wykryty po fakcie = brak możliwości odtworzenia po awarii; czas trwania okna backupu — zbyt długie okno powoduje nakładanie się zadań i wzrost obciążenia I/O na produkcję; przepustowość backupu (MB/s) — identyfikacja wąskich gardeł na ścieżce backup (sieć, storage, proxy); stopień deduplikacji i kompresji — nagły spadek wskazuje zmianę charakteru danych; pojemność i zajętość repozytoriów — pełne repozytorium = zatrzymanie wszystkich zadań; stan napędów taśmowych i bibliotek (błędy odczytu/zapisu taśmy = niezapisany backup); lag replikacji i RPO — dla systemów DR, opóźnienie replikacji określa maksymalną utratę danych przy awarii; RTO — czas odtworzenia po awarii (monitoring testów DR).Kluczowe dla RCA: cichy błąd backupu --> brak RPT przy awarii; pełne repozytorium --> wszystkie backupy zatrzymane; lag replikacji --> RPO --> naruszenie SLA. Wgląd w plany odtwarzania, status replikacji vSphere, testy DR, — lag, status, RPO per VM, VPG, lag replikacji (seconds), RPO, historia testów DR, grupy spójności, lag, RPO, RTO, lag, status transferów, opóźnienie, synchronous/async, lag, failover, dzierżawcy, repozytoria cloud, zadania replikacji.

DR i replikacja

15. Konektory z systemami monitorin

Konektory z zewnętrznymi systemami umożliwiając budowanie relacji i korelację alertów i unikanie wielu narzędzi jednocześnie podczas RCA: import alertów do jednego widoku — korelacja czasowa zdarzeń z różnych warstw (alert sieci + alert aplikacji = sieć jest przyczyną); integracja ITSM — automatyczne tworzenie z powiązanym kontekstem metryk (nie tylko 'serwer jest wolny', ale 'CPU Ready 15%, 50ms, Alert '); synchronizacja CMDB — Aria zna topologię zależności aplikacja --> VM --> host --> sieć, co pozwala na automatyczny . Kluczowe dla RCA: bez integracji każda warstwa ma własne alerty bez korelacji; z integracją jeden alert w zawiera pełny kontekst infrastruktury.

Konektory z systemami monitorowania

16. ITSM i zarządzanie incydentami

ITSM i zarządzanie incydentami

17. Monitoring środowiska Data Center (Facility)

Monitoring środowiska fizycznego data center wykrywa problemy zanim staną się awarią: temperatura serwerowni i rzędów serwerów — każdy stopień powyżej progu skraca MTTF dysków i procesorów; temperatura inlet/outlet szafy — identyfikacja hot spotów; wilgotność — zbyt niska (ryzyko ESD), zbyt wysoka (korozja); UPS: stan baterii (capacity, estimated runtime, health), obciążenie (% load), praca na baterii (czas i przyczyna) — pozwala oszacować ryzyko przy zaniku zasilania; PDU: pobór mocy per gniazdo (identyfikacja przeciążonych obwodów), prąd per faza; systemy chłodzenia: temperatura podawanego powietrza, efektywność (PUE), alarmy jednostek CRAC/CRAH, wycieki wody (liquid cooling); generatory: czas ostatniego testu, poziom paliwa, czas uruchomienia. Kluczowe dla RCA: temperatura > progu → CPU throttling na całej szafie; UPS na baterii bez alarmu → nieoczekiwana utrata zasilania; przeciążony obwód PDU → trip bezpiecznika → utrata wielu serwerów.

Monitoring środowiska Data Center (Facility)

18. Współpraca

Rozwój technologii wlymaga dostepu do komponentów infrastruktury, testowania i weryfikacji integracji oraz certyfikacji jej u producenta (Broadcom) . Sami nie poiadamy takiej ilości sprzętu, dlatego potrzebujemy dostepu do niego u naszy partnerów i klientów. Czy zgodzisz sie w ramach współpracy na poniższe działania by promowac i rozwijac ecosystem integracji.

Współpraca.