Monitorowanie urządzenia NETASQ

Posted by pawel in SYSTEM
YouTube video playerYouTube video playerYouTube video player

W sytuacji gdy dojdziemy do wniosku że nasze urządzenie „muli”  lub „bardzo muli” musimy ustalić co jest przyczyną tego zjawiska. Dysponujemy kilkoma prostymi narzędziami aby zdiagnozować sytuację. Widżety wyświetlane w Panelu kontrolnym WebGUI są stosunkowo mało przydatne z uwagi na choćby długi czas odświerzania.

300x10-null

Monitorowanie CPU

top

Filmik przestawia działanie polecenia top w czasie około 1,5 minuty. Spróbuję skomentować najważniejsze informacje jakie są prezentowane w wyniku działania tego polecenia.

300x10-null

top_1

Wiersz CPU: prezentuje aktualne obciążenie procesora w rozbiciu na typy procesów składających się na to obciążenie. Na powyższym przykładzie mamy sytuację gdy pełna moc procesora jest wykorzystana (idle=0%), procesy użytkownika stanowią 91% wykorzystania zasobów czasu procesora, reszta czyli 9% czasu procesora to obciążenie pochodzące od jądra systemu. Procesem obciążającym procesor w największym stopniu jest proces pochodzący od aplikacji enpattern, aplikacji której zadaniem jest implementacja baz sygnatur ASQ (monitorowanie zostało uruchomione w trakcie wykonywania aktualizacji baz na urządzeniu, widzimy zresztą na liście uruchomionych procesów proces pochodzący od aplikacji autoupdate). Interesującym parametrem jest load averages. Trzy wartości opisujące ten parametr odpowiadają za 3 okresy pomiaru 1 minuta, 5 minut i 15 minut. Parametr load averages podaje informację o średniej liczbie procesów będacych w kolejce do wykonania przez CPU w danym okresie. Load averages bywa określany współczynnikiem zapracowania systemu lub jak kto woli miarą obciążenia systemu procesami. Jeżeli te wartości są wysokie (>3) to oznacza, że przeciążenie procesora nosi charakter permanentny.

300x10-null

Monitorowanie ruchu

netstat

Liczbę pakietów przesyłanych na wszystkich interfejsach w przeciągu sekundy możemy monitorować z wykorzystaniem polecenia netstat, wykonując to polecenie z opcją -w1. Możemy zawęzić statystykę do konkretnego interfejsu z zastosowaniem przełacznika -I nazwa_interfejsu.

Należy zaznaczyć, że w przypadku gdy nie wyszczególnimy konkretnego interfejsu podawane przez netstat wartości są dwa razy wyższe od rzeczywistych (wynika to z faktu, że urządzenia dysponują interfejsami wirtualnymi przez które również przechodzi cały ruch).

sfctl -T

Monitorowanie wykorzystanego w danym momencie pasma możemy zrealizować z użyciem polecenia sfctl -T. Polecenie daje możliwość monitorowania również innych parametrów. Wciśnięcie klawisza v spowoduje wyświetlenie liczby połączeń. Liczba połączeń jest krytyczną wartością i zbyt duża ich liczba powoduje drastyczny spadek wydajności urządzenia.

Jeżeli chcemy monitorować liczbę połączeń przechodzących przez moduł proxy musimy aktywować statystyki proxy poprzez skonfigurowanie odpowiednich parametrów w pliku /Firewall/ConfigFiles/proxy, musimy ustawić:

Stat=<okres>
StatFile=<plik>  (wartość ustawiona domyślnie: /tmp/tcproxyd.stat)

gdzie:

okres – określa częstotliwość generowania statystyk (wartość wyrażona w sekundach)

plik – pełna ścieżka do pliku i nazwa pliku do którego będą zapisywane statystyki proxy, należy w zdefiniowanej lokalizacji utworzyć plik o zdefiniowanej nazwie i nadać mu prawa 777

polecenie przeładowujące usługę (demona):

nrestart tproxyd

Zdezaktywowanie zbierania statystyk polega na usunięciu parametru okres i ponownym przeładowaniu usługi.

300x10-null

Logi

Jeżeli w wyniku wykonanie polecenia:

sfctl -s stat | grep "log overflow"

licznik over flow wskaże wartość inną niż zero oznacza, że urządzenie nie wysyła komunikatów do niektórych logów. Taka sytuacja może mieć miejsce w sytuacji gdy urządzenie jest ogólnie przeciążone lub też generowanie przez same urządzenie ogromnej liczby komunikatów (należy z dużą rozwagą załączać logowanie na regułach firewalla, w szczególności tych reguł które generują głównie komunikaty blokujące np. reguła block-all (z załączoną opcją logowania) na końcu listy zapory której mimo, ze jest bardzo pomocna na etapie wdrożenia powinna być wyłączona w standardowej pracy produkcyjnej.

Skalę problemu w odniesieniu do liczby generowanych do logów komunikatów można monitorować z użyciem polecenia loginfo.

loginfo

 

27 Mar 2014


Najnowszy firmware SNS: 3.8.1 (Release Note)
Najnowszy firmware SNSv2: 2.13 (Release Note)