Jakie ostrzeżenia i wartości krytyczne należy zastosować dla check_load?

Obecnie używam tych wartości:

# y = c * p / 100
# y: nagios value
# c: number of cores
# p: wanted load procent

# 4 cores
# time        5 minutes    10 minutes     15 minutes
# warning:    90%          70%            50%
# critical:   100%         80%            60%
command[check_load]=/usr/local/nagios/libexec/check_load -w 3.6,2.8,2.0 -c 4.0,3.2,2.4

Ale te wartości są wybierane prawie losowo.

Czy ktoś ma jakieś przetestowane wartości?

Ładowanie systemu Linux jest w rzeczywistości proste. Każda z liczb średniego obciążenia jest sumą średniego obciążenia całego rdzenia. To znaczy.

 1 min load avg = load_core_1 + load_core_2 + ... + load_core_n
 5 min load avg = load_core_1 + load_core_2 + ... + load_core_n
15 min load avg = load_core_1 + load_core_2 + ... + load_core_n

gdzie 0 < avg load < infinity.

Jeśli więc obciążenie wynosi 1 na serwerze 4-rdzeniowym, oznacza to, że albo każdy rdzeń jest używany w 25%, albo jeden rdzeń jest w 100% obciążony. Obciążenie 4 oznacza, że ​​wszystkie 4 rdzenie są obciążone w 100%. Obciążenie> 4 oznacza, że ​​serwer potrzebuje więcej rdzeni.

check_load teraz mam

 -r, --percpu
    Divide the load averages by the number of CPUs (when possible)

co oznacza, że ​​gdy jest używany, możesz myśleć o tym, że twój serwer ma tylko jeden rdzeń, a zatem zapisujesz ułamki procentowe bezpośrednio, nie myśląc o liczbie rdzeni. Dzięki -rostrzeżeniom i krytycznym interwałom staje się 0 <= load avg <= 1. To znaczy. nie musisz modyfikować ostrzeżeń i wartości krytycznych z serwera na serwer.

OP mają 5,10,15 na interwały. To jest złe. Jest 1,5,15.

Chociaż jest to stary post, odpowiadam teraz, ponieważ wiedziałem, że wartości progowe check_load przysparzają początkującym ból głowy;)

Ostrzeżenie ostrzegawcze, jeśli procesor wynosi 70% przez 5 minut, 60% przez 10 minut, 50% przez 15 minut. Alarm krytyczny, jeśli procesor wynosi 90% przez 5 minut, 80% przez 10 minut, 70% przez 15 minut.

*command[check_load]=/usr/local/nagios/libexec/check_load -w 0.7,0.6,0.5 -c 0.9,0.8,0.7*

Wszystkie moje ustalenia dotyczące obciążenia procesora:

Co oznacza „ładunek”: Wikipedia mówi:

Wszystkie systemy uniksowe i podobne do systemu uniksowego generują metrykę trzech „średnich obciążeń” w jądrze. Użytkownicy mogą łatwo zapytać o bieżący wynik z powłoki Unix, uruchamiając polecenie uptime:

$ uptime
14:34:03 up 10:43,  4 users,  load average: 0.06, 0.11, 0.09

Z powyższej średniej obciążenia wyjściowego: 0.06, 0.11, 0.09oznacza (w systemie jednoprocesorowym):

• w ostatniej chwili procesor był niedociążony o 6%
• w ciągu ostatnich 5 minut procesor był niedociążony 11%
• w ciągu ostatnich 15 minut procesor był niedociążony 9%

.

$ uptime
14:34:03 up 10:43,  4 users,  load average: 1.73, 0.50, 7.98

Powyżej średniej obciążenia 1.73 0.50 7.98w systemie jednoprocesorowym jako:

• w ostatniej chwili procesor był przeciążony o 73% (1 procesor z 1,73 uruchomionymi procesami, więc 0,73 procesów musiał czekać na turę)
• w ciągu ostatnich 5 minut procesor był niedociążony 50% (żadne procesy nie musiały czekać na kolej)
• w ciągu ostatnich 15 minut procesor był przeciążony 698% (1 procesor z 7,98 uruchomionymi procesami, więc 6,98 procesów musiało czekać na turę)

Obliczanie wartości progowej Nagios:

W przypadku konfiguracji obciążenia procesora Nagios, która obejmuje ostrzeżenie i krytyczne:

y = c * p / 100

Gdzie: y = nagios value c = number of cores p = wanted load procent

dla systemu 4-rdzeniowego:

time      5 min  10 min    15 min
warning:  90%    70%       50%
critical: 100%   80%       60%

command[check_load]=/usr/local/nagios/libexec/check_load -w 3.6,2.8,2.0 -c 4.0,3.2,2.4

W przypadku systemu z jednym rdzeniem:

y = p / 100

Gdzie: y = nagios value p = wanted load procent

time       5 min  10 min    15 min
warning:   70%    60%       50%
critical:  90%    80%       70%

command[check_load]=/usr/local/nagios/libexec/check_load -w 0.7,0.6,0.5 -c 0.9,0.8,0.7

Świetna biała księga na temat analizy obciążenia procesora autorstwa dr Gunthera http://www.teamquest.com/pdfs/whitepaper/ldavg1.pdf W tym artykule online dr Gunther zagłębia się w jądro systemu UNIX, aby dowiedzieć się, w jaki sposób średnie obciążenia ( „LA Triplets”) są obliczane i jak odpowiednie są jako wskaźniki planowania zdolności.

O ile serwery te nie mają asynchronicznego obciążenia, gdzie głębokość kolejki jest ważnym miernikiem usługi do zarządzania, to naprawdę nie warto monitorować średniej obciążenia. To tylko odwrócenie uwagi od wskaźników, które mają znaczenie, takie jak czas obsługi (czas obsługi i czas obsługi).

Dobre uzupełnienie też Nagios to narzędzie takie jak Munin lub Cacti, które zobrazują różne rodzaje obciążeń, jakich doświadcza serwer. Czy to load_average, użycie procesora, dysk io lub coś innego.

Korzystając z tych informacji, łatwiej jest ustawić dobre wartości progowe w Nagios.

Czy wiesz, na jakie obciążenie wpływa przeciętna wydajność twojego systemu? W moim ostatnim zadaniu mieliśmy serwery, które konsekwentnie utrzymywałyby średnią 35-40 obciążenia, ale nadal reagowały. Jest to pomiar, w którym musisz wykonać trochę pracy detektywistycznej, aby uzyskać dokładne liczby.

Zamiast tego możesz zmierzyć inne parametry w systemie, takie jak średni czas połączenia dla SSH lub http; może to być lepszy wskaźnik obciążenia systemu.

Aby rozszerzyć odpowiedź Invent Sekar: Używając check_load i wartości procentowych, uważam, że będziesz potrzebował argumentu wiersza poleceń „-r” wraz z innymi.

Na przykład:

command[check_load]=/usr/local/nagios/libexec/check_load -r -w 0.7,0.6,0.5 -c 0.9,0.8,0.7