Narzędzia do monitorowania czasu kradzieży (st)

Pracujemy na wirtualnym „dedykowanym” serwerze, co teoretycznie powinno oznaczać, że jesteśmy jedynymi facetami na serwerze. W praktyce ... Myślę, że nie jesteśmy.

wprowadź opis zdjęcia tutaj

Zauważ, że chociaż wygląda na to, że zabijamy naszą maszynę, „Czas kradzieży” wynosi 71%

Biorę statystyki dotyczące obciążenia i byłem rozczarowany, że ta statystyka nie pojawiła się na moich wykresach. Czy są jakieś narzędzia, które to monitorują, które mogą pomóc?

Dodatkowe informacje:

Obsługujemy 4 rdzenie, model:

# grep "model name" /proc/cpuinfo | sort -u
model name  : Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

xen top virtualization

— mgjk
źródło

Wirtualny dedykowany? W przypadku XEN musiałyby przypiąć dedykowane rdzenie do specjalnego zastosowania w maszynie wirtualnej. Wygląda na to, że twój dostawca przepełnił procesory nieuczciwym faktem. Co on na to powie?

— Nils,

Ile masz procesorów wirtualnych i jakiego rodzaju procesor jest zgłaszany grep "model name" /proc/cpuinfo|sort -u? Jeśli to naprawdę serwer dedykowany, to na Dom0 jest coś pochłaniającego czas procesora. LUB dali ci więcej vCPU niż są dostępne w Dom0.

— Nils,

O ile nie jest to chwilowa wartość odstająca, wygląda na to, że twoja osa cię okłamuje i faktycznie obsługują inne procesory vm na tej maszynie lub jest coś skonfigurowanego bardzo źle, co powoduje, że dom0 pochłania dużo czasu procesora .

— psusi

SuSE zaleca zarezerwowanie dwóch rdzeni wyłącznie dla Dom0, aby mógł obsługiwać wszystkie operacje we / wy bez przeszkadzania innym maszynom wirtualnym. Moim zdaniem byłoby to konieczne tylko dla systemów ze skradzionym czasem w DomU ORAZ dużym ruchem IO. Chciałem wiedzieć, czy twój dostawca przypisał więcej vCPU niż rdzenie logiczne - na przykład przypisuje 4 vCPU, podczas gdy w Dom0 dostępne są tylko 2 logiczne procesory - to też wyjaśnia „skradzione” (i jest to całkiem niezły pomysł Braindead - ale możliwe w XEN) .

— Nils

Główną przyczyną tego okazało się to, że ISP nieprawidłowo skonfigurował maszynę wirtualną. Gośćowi powiedziano, że ma więcej rdzeni niż w rzeczywistości. Wydawało się, że powoduje to spustoszenie w harmonogramie. ISP nie mógł zapewnić inteligentnego wsparcia technicznego, ale byliśmy w stanie „udowodnić” problem poprzez wyłączenie rdzeni nieparzystych w / proc. Odtąd nigdy nie stanowi problemu.

— mgjk

Odpowiedzi:

Twoje pytanie jest dobrze zdefiniowane, ale nie podajesz zbyt wielu informacji na temat swojego środowiska, sposobu monitorowania lub używanych narzędzi graficznych. Biorąc jednak pod uwagę, że SNMP jest używany prawie do tego celu, zakładam, że go używasz i przynajmniej trochę go znasz.

Chociaż (tak blisko, jak mogę to stwierdzić) czas kradzieży procesora nie jest obecnie dostępny w snmpd, możesz go przedłużyć o UCD-SNMP-MIB::extOutputobiekt i execpolecenia.

Najprostszym sposobem (jaki znalazłem) na zdobycie czasu kradzieży jest iostat. Korzystając z poniższej konstrukcji, możemy uzyskać tylko czas kradzieży:

$ iostat -c | awk 'NR==4 {print $5}'
0.00

Dlatego dołącz do pliku snmpd.conf następujące elementy:

exec cpu_steal_time /usr/bin/iostat -c | /usr/bin/awk 'NR==4 {print $5}'

(Alternatywnie możesz umieścić polecenie w skrypcie opakowania i wywołać opakowanie od wewnątrz snmpd.conf).

Każde execwywołanie snmpd.confjest indeksowane od 1. Więc jeśli masz tylko jedną instrukcję exec, to będziesz chciał sondować UCD-SNMP-MIB::extOutput.1. Jeśli jest to piąta instrukcja exec, to odpytuj UCD-SNMP-MIB::extOutput.5itp.

Numeryczny OID dla UCD-SNMP-MIB::extOutputjest .1.3.6.1.4.1.2021.8.1.101taki, że jeśli masz indeks 1, to będzie .1.3.6.1.4.1.2021.8.1.101.1, a indeks 5 to będzie .1.3.6.1.4.1.2021.8.1.101.5itd.

Następnie tworzysz odpytywanie wykresu o identyfikatorze OMP SNMPD typu, od 0–100. To powinno dać ci ładne wykresy.

— bahamat
źródło

Świetna odpowiedź. Jak często będą gromadzone te statystyki? Tylko podczas ankiety, czy jest jakiś sposób jak w RMON-MIB, który będzie rejestrował wartości bez zewnętrznego sondowania?

— Nils,

Uważam, że pociągnęłoby to to za każdym razem, gdy snmpdjest pytany o ten identyfikator OID.

— bahamat

Jeśli iostat nie jest zainstalowany: top -bn1 | sed -nr '3s /.*,// gp'

— Davide

sar -umoże być pomocny w twoim przypadku. sar jest zwykle częścią pakietu sysstat.

— Nils
źródło

Chciałbym ustawić więcej niż jedną odpowiedź jako odpowiedź zaakceptowaną. Obie odpowiedzi były bardzo przydatne :-) Dziękuję!

— mgjk

Najbardziej pozytywna odpowiedź jest świetna, ale w tej chwili nie działa w pełni: net-snmp traci potok w execwywołaniu, więc powinno to wyglądać następująco

extend-sh cpu_steal_time /usr/bin/iostat -c 1 1 | /usr/bin/awk '!/%user|Linux|^$/ {print $5}'

Wynik będzie widoczny pod nsExtendOutput1Table:

# snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendOutput1Table
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_steal_time" = STRING: 0.60
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."cpu_steal_time" = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendResult."cpu_steal_time" = INTEGER: 0

gdzie nsExtendOutput1Lineoid to .1.3.6.1.4.1.8072.1.3.2.3.1.1:

snmpwalk localhost .1.3.6.1.4.1.8072.1.3.2.3.1.1
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."cpu_steal_time" = STRING: 0.60

— Drookie
źródło