Documentation
Table of Contents
8 Co nowego w Zabbix 2.2.3
8.1 Zapytania zbiorcze SNMP
Wydajność monitorowania SNMP znacząco podniesiono dzięki zapytaniom zbiorczym z maksymalnie 128 pozycji. Obciążenie serwera Zabbix i monitorowanych urządzeń SNMP powinno być znacząco zredukowane:
* zwykłe pozycje SNMP korzystają z GetRequest-PDU z większą liczbą powiązań zmiennych;
* reguły niskopoziomowego wykrywania SNMP dla SNMPv2 i SNMPv3 korzystają z GetBulkRequest-PDU z większą wartością pola "max-repetitions";
* pozycje SNMP z dynamicznymi i indeksami korzystają z obydwu udoskonaleń: jednego przy weryfikacji indeksu, drugiego przy budowaniu pamięci cache.Więcej informacji o przetwarzaniu zbiorczym SNMP.
8.2 Udoskonalenia interfejsu użytkownika
8.2.1 Aktualizacje tłumaczeń
- Brazylijski portugalski
- Włoski
- Japoński
- Słowacki
- Turecki
8.3 Udoskonalenia demona
- Znacznie zwiększono wydajność przetwarzania wykresów podczas niskopoziomowego wykrywania. Testowanie 2048 wykresów wykazało 600-krotne zmniejszenie ilości zapytań SQL dla pierwszego wykrywania. Kolejne uruchomienia bez zmian wykazały 2500 razy mniejszą ilość zapytań SQL, a jeżeli wymagana była zmiana w nazwie wykresu, ilość zapytań SQL była 1500 razy mniejsza. Ogólny rozmiar wyrażeń SQL zmniejszył się 3.7 razy dla pierwszego wykrywania, 3000 razy mniejszy dla kolejnych uruchomień bez zmian i 1500 razy mniejszy, kiedy zmiany w nazwie wykresu były wymagane.
- Wykresy utworzone przez niskopoziomowe reguły wykrywania nie będą już usuwane i nadal będą działać nawet wtedy, gdy pozycje nie będą już wykrywane (aż do usunięcia tych pozycji).
- Dodano przetwarzanie wsadowe usług IT. Rozwiązało to możliwe zakleszczenia i zwiększyło wydajność przetwarzania większych drzew usług It. Testowanie 800 usług IT w drzewie o 4 poziomach wykazało 300% wzrost wydajności.
- Znacznie udoskonalono monitorowanie pliku logów (pozycje
log[]ilogrt[]):- wydajniejszy odczyt pliku logu i dopasowywanie rekordów z wyrażeniami regularnymi.
- wydajniejszy wybór plików logu podczas sprawdzania pozycji
logrt[]. - dla rekordów pliku logu dłuższych niż 256 kB, tylko początkowe 256 kB jest dopasowywane do wyrażeń regularnych, reszta rekordów jest ignorowana. Jednakże, jeżeli agent Zabbix zostanie zatrzymany, gdy przetwarza długi rekord, jego stan wewnętrzny zostaje stracony, długi rekord po ponownym uruchomieniu agenta będzie analizowany ponownie i może być przetwarzany inaczej niż poprzednio.
- dla pozycji
log[]: jeżeli jest jakiś problem z plikiem logu (np. nie istnieje lub nie można go odczytać) pozycjalog[]staje się NIEWSPIERANA. Przed zmianą (w 2.2.2) nie przechodziła w stan NIEWSPIERANE z powodu błędu w agencie. - dla pozycji
logrt[]:
* Na platformach UNIX pozycja ''logrt[]'' staje się NIEWSPIERANA jeżeli katalog, w którym powinien być plik logu, nie istnieje.
* Niestety, na Microsoft Windows, jeżeli katalogu nie ma pozycja nie stanie się NIEWSPIERANA (na przykład, przy literówce w kluczu pozycji). Aktualnie jest to ograniczenie agenta.
* Brak obecności plików logu dla pozycji ''logrt[]'' nie czyni ich NIEWSPIERANYMI.
* Błędy odczytu plików logu w pozycjach ''logrt[]'' są logowane jako ostrzeżenia w pliku logu agenta Zabbix ale nie czynią pozycji NIEWSPIERANYMI.
* Plik logu agenta Zabbix może pomóc przy określeniu, dlaczego pozycje ''log[]'' lub ''logrt[]'' stały się NIEWSPIERANE. Zabbix może monitorować plik logu agenta z wyjątkiem poziomu DebugLevel=4.
* Należy zauważyć, że nawet po zwiększeniu wydajności sprawdzania pozycji ''log[]'' i ''logrt[]'' nie zmieniły się ograniczenia co do maksymalnej liczby analizowanych rekordów plików logu i liczby rekordów zgodnych wysyłanych do serwera w jednym sprawdzeniu. Na przykład, jeżeli pozycja ''log[]'' lub ''logrt[]'' ma //Interwał aktualizacji// ustawiony na 1 sekundę, domyślnie agent nie przeanalizuje więcej niż 400 rekordów pliku logu i wyśle do serwera Zabbix nie więcej niż 100 rekordów zgodnych w jednym sprawdzeniu. Zwiększając parametr **MaxLinesPerSecond** w pliku konfiguracyjnym agenta lub ustawiając parametr **maxlines** w kluczu pozycji można zmienić limit maksymalnie do 4000 analizowanych rekordów pliku logu i do 1000 zgodnych rekordów wysyłanych do serwera Zabbix w jednym sprawdzeniu. Jeżeli //Interwał aktualizacji// jest ustawiony na 2 sekundy, limity dla jednego sprawdzenia zostaną zwiększone dwukrotnie względem tego, co dla 1 sekundowego //Interwału aktualizacji//.
* Skrypty uruchomieniowy i zatrzymujący brany Java nie ukrywają już komunikatów błędów podczas wykonywania. Dodatkowo wykrywają stare pliku PID i powinny działać z /bin/sh.
* Naprawiono raportowanie większej niż w rzeczywistości wolnej przestrzeni cache'a wartości.
* Udoskonalono komunikaty o błędach dla pozycji VMware. Teraz zamiast ogólnego błędu "Simple check is not supported" pojawi się konkretny komunikat błędu.
* Zwiększono maksymalny rozmiar transmitowanych danych z 64MB na 128MB, by utrzymać kompatybilność z poprzednimi wersjami Zabbix. W przypadku, gdy jeden proces z limitem transmisji danych równym 128MB wysyłał dane do innego z limitem 64MB, proces odbierający odrzucał dane z powodu przekroczenia limitu rozmiaru.
* Zwiększono maksymalny rozmiar cache'a konfiguracji z 2GB do 8GB.
* Przy zbiorczych insertach w bazach danych Oracle używane są teraz przypisania zmiennych, powodując zwiększenie wydajności.8.4 Inne udoskonalenia
- Podręcznik man demona agenta Zabbix opisuje teraz znaczenie typu wartości dla -p lub -t.