Zabbix cpu load в чем измеряется

2 Обнаружение CPU и ядер CPU

Аналогично обнаружению файловых систем, имеется возможность также обнаружения CPU и ядер CPU.

Ключ элемента данных

Ключом элемента данных, который используется в правиле обнаружения является

 system.cpu.discovery

Этот ключ поддерживается начиная с Zabbix агента 2.4.

Поддерживаемые макросы

Этот ключ обнаружения возвращает два макроса — и , идентифицирующие порядковый номер CPU и состояние соответственно. Отметим, нельзя сделать четкого различия между действительными, физическими процессорами, ядрами и hyperthread. на Linux, UNIX и BSD системах возвращают состояние процессора, которое может быть как «online», так и «offline». На Windows системах, этот же макрос может представлять собой третье значение — «unknown» — которое указывает на то, что процессор был обнаружен, но информация по нему еще не собрана.

Обнаружение CPU основано на процессе коллектора агента, чтобы поддерживать соответствие с данными, которые поставляются коллектором и сохранить ресурсы на получение данных. Такое поведение дает эффект, что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен.

Примеры прототипов элементов данных, которые вы мозможно захотите создать на основе обнаружения CPU включают, например:

Мониторинг использования CPU в Zabbix

Приведу пример мониторинга использования каждого ядра процессора используя Zabbix.

Допустим на высоконагруженном NAT сервере основная нагрузка от softirq, присутствует один процессор с 8 ядрами, а также на сервере установлен Zabbix агент.
И чтобы увидеть равномерно ли распределены прерывания сетевого адаптера по ядрам процессора, создадим элементы данных на Zabbix сервере, в которых укажем:
Тип: Zabbix агент
Тип информации: Числовой (с плавающей точкой)
Единица измерения: %
А также ключ:

system.cpu.util[0,softirq,avg5]

Где 0 — номер процессора, softirq — тип нагрузки, avg5 — средняя нагрузка за 5 минут. Аналогично создадим элементы данных для других ядер процессора с ключами, а также добавим их на один график:

system.cpu.util[1,softirq,avg5] system.cpu.util[2,softirq,avg5] system.cpu.util[3,softirq,avg5] .

Вместо softirq можно указать idle, nice, user (по умолчанию для Linux), system (по умолчанию для Windows), iowait, interrupt, softirq, steal, guest, guest_nice.
А вместо avg5 можно указать: avg1 (среднее за одну минуту, по умолчанию) или avg15 (среднее за 15 минут).

Чтобы не указывать ядра процессоров вручную, можно создать правило обнаружения:

system.cpu.discovery

И указать в нем элемент данных, например:

system.cpu.util[,softirq,avg5]

Также можно создать триггер, чтобы узнать когда значение будет больше 90:

Ниже приведу примеры элементов данных, которые отображают различную информацию о CPU, кстати эти элементы данных по умолчанию присутствуют в шаблоне «Template OS Linux».

Processor load (1 min average per core):

system.cpu.load[percpu,avg1]

Processor load (5 min average per core):

system.cpu.load[percpu,avg5]

Processor load (15 min average per core):

system.cpu.load[percpu,avg15]

Interrupts per second:

system.cpu.intr

Context switches per second:

system.cpu.switches

system.cpu.util[,idle]

CPU interrupt time:

system.cpu.util[,interrupt]

CPU iowait time:

system.cpu.util[,iowait]

system.cpu.util[,nice]

CPU softirq time:

system.cpu.util[,softirq]

system.cpu.util[,steal]

CPU system time:

system.cpu.util[,system]

system.cpu.util[,user]

Смотрите другие мои статьи в категории Zabbix.

• Нажмите, чтобы открыть на Facebook (Открывается в новом окне)
• Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
• Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
• Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
• Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
• Ещё

• Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
• Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
• Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
• Нажмите для печати (Открывается в новом окне)

Нагрузка на сервер: определение причин

Постараемся ответить на вопрос: что делать в случае проблем на сервере, какие инструменты использовать и на что обращать внимание для диагностирования проблем производительности в операционной системе Linux .

Команда top

Главным инструментом в этом деле станет команда top. Результат её выполнения выглядит так:

Программа top выдает динамическое представление о работающей системе в реальном времени. Верхнюю часть вывода занимает краткая обобщённая информация, нижнюю часть — список запущенных процессов.

Рассмотрим основные показатели, которые могут нас заинтересовать.

Средняя нагрузка на систему (load average)

Load Average — среднее значение загруженности системы за период времени (в дальнейшем LA). Три значения показывают усреднённую нагрузку за последние 1, 5 и 15 минут. LA является одним из самых спорных показателей. Можно найти множество противоречивых статей, какое значение считать нормальным. Обычно принимается, что значение 0 это простой ядра, а значение 1 это полная нагрузка ядра. Оценить показатель средней нагрузки можно только зная количество ядер в системе. Узнать сколько ядер доступно можно командой:

dmidecode -t processor | grep "Core Enabled:" Core Enabled: 6 Core Enabled: 6

Видим, что на данной системе находится 12 физических ядер (6+6). Соответственно, нормальный показатель LA должен быть менее 12. Однако, на процессорах Intel используется технология Hyper-Threading, которая делит одно физическое ядро на два логических.

dmidecode -t processor | grep "Thread Count:" Thread Count: 12 Thread Count: 12

Соответственно, в данном случае в системе может быть одновременно 24 виртуальных процессора (потока).

Технология Turbo Boost позволяет процессору «разгоняться» и работать на частоте выше заявленной (т.е. выше 100%, выше единицы). Какой показатель LA считать нормальным в данном случае является предметом споров.

Были попытки вычислить нормальное значение LA эмпирическим путем. Но мы считаем это бессмысленным занятием. Дело в том, что в LA попадают также процессы, стоящие в очереди чтения/записи и не имеющие отношение к процессору, а также процессы с приоритетом, измененным с помощью команды nice . В случае если команда запущенна с низким приоритетом, она будет находится в очереди, но не будет оказывать влияния на реальную производительность.

Высокий LA может сигнализировать о каких-либо проблемах. С другой стороны, высокое значение не обязательно говорит о наличие проблем. Полагаться в диагностике только на LA нельзя, его значения нужно учитывать только совместно с другими значениями. Поэтому переходим к следующей интересующей нас строке: Cpu .

Параметр Cpu

Строка Cpu показывает сразу несколько параметров нагрузки:

us (user)	Использование процессора пользовательским процессами
sy (system)	Использование процессора системным процессами
ni (nice)	Использование процессора процессами с измененным приоритетом с помощью команды nice
id (idle)	Простой процессора. Можно сказать, что это свободные ресурсы
wa (IO-wait)	Говорит о простое, связанным с вводом/выводом
hi (hardware interrupts)	Показывает сколько процессорного времени было потрачено на обслуживание аппаратного прерывания
si (software interrupts)	Показывает сколько процессорного времени было потрачено на обслуживание софтверного прерывания
st (stolen by the hypervisor)	Показывает сколько процессорного времени было «украдено» гипервизором

Не будем углубляться в анализ значений hi и si в этой статье, поскольку проблемы с прерываниями встречаются очень редко. Скажем только, что наиболее вероятная причина высоких значений данных параметров — проблема с кодом, ядром или DDoS-атака.

Рассмотрим подробнее остальные параметры Сpu .

Нагрузка на процессор (параметры sy, us, ni)

Высокие значения sy , us и ni самые понятные и простые для диагностики, поскольку показывают нагрузку на CPU, создаваемую запущенными программами. Смотрим в выводе команды top процессы по столбцу %CPU и оптимизируем их при необходимости. Либо просто добавляем мощность CPU на сервер.

Однако надо учитывать, что однопоточные процессы будут выполнятся только на одном ядре. В этом случае даже при невысоком общем us могут наблюдаться проблемы.

Также нужно добавить, что высокое значение ni не всегда будет отрицательно влиять на работоспособность сервера. Возможно, приоритет процессов был понижен специально, чтобы они выполнялись только в том случае, когда процессор будет свободен. Данные процессы не оказывают влияния на работу системы. Например, это могут быть процессы создания бекапов.

Пример диагностики проблем при высоком us и sy

На сервере top показывает следующие значения:

CPU: 21.0% user, 0.0% nice, 74.6% system, 0.0% interrupt, 4.4% idle PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 95383 mysql 37 4 0 227M 74388K sbwait 1 0:00 49.80% mysqld 96904 qhost 1 97 0 171M 31884K CPU1 1 0:04 7.08% httpd 97360 frekbok 1 97 0 185M 42464K RUN 0 0:02 7.08% httpd 97442 frekbok 1 97 0 178M 37196K RUN 2 0:01 5.18% httpd 97423 frekbok 1 -4 0 178M 37160K RUN 1 0:01 4.79% httpd 97439 frekbok 1 97 0 178M 37052K RUN 2 0:01 4.79% httpd 97411 frekbok 1 -4 0 178M 37148K RUN 3 0:01 4.69% httpd 97418 frekbok 1 97 0 178M 37168K RUN 0 0:01 4.59% httpd 97444 frekbok 1 -4 0 178M 37192K RUN 1 0:01 4.59% httpd 97416 frekbok 1 -4 0 178M 37052K RUN 2 0:01 4.49% httpd 97421 frekbok 1 -4 0 178M 37060K CPU0 0 0:01 4.39% httpd 97424 frekbok 1 97 0 178M 37304K RUN 2 0:01 4.30% httpd

При этом LA больше 100.

Явно видно, что проблемы в нехватке CPU для работы mysql , и в большом количестве http -соединений пользователя frekbok .

Заходим к пользователю frekbok и смотрим лог apache . Там видим такие POST -запросы, и множество им подобных:

76.164.234.170 - - [18/Sep/2015:06:10:41 +0400] "POST /component/k2/ HTTP/1.0" 200 59 "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 76.164.234.170 - - [18/Sep/2015:06:10:41 +0400] "POST /component/k2/ HTTP/1.0" 200 59 "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" 76.164.234.170 - - [18/Sep/2015:06:10:43 +0400] "POST /component/k2/ HTTP/1.0" 200 59 "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"

По результату анализа логов можно сделать вывод, что проблема в китайских ботах, которые постят рекламу в комментарии на сайте. Ставим капчу на комментирование или отключаем комментарии, чистим БД. Проблема решена.

Определение оверселлинга (параметр st)

Параметр st интересен для виртуальных машин. Можно сказать, что он отображает оверселлинг CPU на родительской ноде. Он будет отличаться от 0 в случае, если VDS требуется процессор, но гипервизор не может выделить CPU, так как он используется в данный момент другими VDS. В случае, если данный параметр принимает большие значения на вашей VDS (ориентировочно более 5-10% совместно с высоким LA) и это мешает вашей работе, то остается только написать в техподдержку с просьбой перенести VDS на другую ноду.

Нагрузка ввода-вывода (параметр wa)

Самый интересный показатель это wa . На современных серверах мощности процессора и памяти обычно хватает, а большинство проблем связаны с операциями ввода/вывода.

Высокие значения wa , а также высокий LA, обычно говорят о простое процессов в состоянии D-state , связанном с дисковой подсистемой или с сетевыми проблемами. Однако, нельзя забывать, что этот параметр относится ко всем операциям ввода/вывода. Например, на выделенном сервере это значение может вырасти при работе с USB-накопителем, ожидании ответа от сокета или быть вызвано другими причинами.

Упрощенная модель состояний в Linux

• D-state — состояние непрерывного сна (процессы, которые ожидают освобождения потока ввода-вывода)
• R-state — процесс активен в настоящее время (выполняется в данный момент)
• S-state — состоянии ожидания (sleeping), т.е. он ожидает какого-то события или сигнала
• Т-state — процесс приостановлен сигналом STOP или выполнением трассировки
• Z-state — «зомби», процесс, завершивший свое выполнение, но присутствующий в системе, чтобы дать родительскому процессу считать свой код завершения

Посмотреть состояние процессов в системе можно с помощью команды ps с опциями: ps aux

По практическому опыту, заметные проблемы начинаются при wa больше 10-30%. Нужно понимать, что большое значение этого параметра не всегда свидетельствует о проблемах. Но желательно установить причину такого поведения и по возможности исправить ситуацию.

Пример нахождения причин высокого wa и load average

Смотрим командой ps aux | grep D процессы в состоянии D.

102 628884 0.0 0.0 97308 2432 ? D 13:08 0:00 /usr/sbin/exim4 -bd -q30m 102 628885 0.0 0.0 97308 2432 ? D 13:08 0:00 /usr/sbin/exim4 -bd -q30m 102 628886 0.0 0.0 97308 2432 ? D 13:08 0:00 /usr/sbin/exim4 -bd -q30m 102 628887 0.0 0.0 97308 2424 ? D 13:08 0:00 /usr/sbin/exim4 -bd -q30m 102 628888 0.0 0.0 97308 2424 ? D 13:08 0:00 /usr/sbin/exim4 -bd -q30m 102 628890 0.0 0.0 97308 2424 ? D 13:08 0:00 /usr/sbin/

Видим, что в состоянии ожидания висит множество процессов exim4 . Скорее всего сервер был взломан и с него массово рассылают спам. Останавливаем exim и находим источник рассылки.

В случае, если у вас несколько VDS на ноде и необходимо найти источник нагрузки, нужно найти ту, с которой рассылается спам. Для этого можно использовать команду tcpdump -n | grep «smtp» , с помощью неё мы проанализируем почтовый трафик на порту 25, и обнаружим IP-адрес с которого выполняется рассылка спама.

Нужно знать, что высокий wa внутри VDS, не всегда означает проблемы внутри контейнера. Проблемы также возможны на «родительской» ноде. Например, на ней не хватает I/O диска для всех VDS. Поэтому ваши процессы попадают в состояние ожидания. В таком случае нужно создать тикет в тех поддержку.

Нагрузка ввода-вывода: копаем глубже (atop)

Удобный инструмент для определения причин нагрузки — это atop c опциями: atop -l -c -d1

Однако, дальнейшее описание в первую очередь будет относится к VDS на виртуализации KVM и выделенным серверам. На виртуализации OpenVZ мы не сможем воспользоваться полными возможности данной утилиты, и скорее всего вам придется обратиться в тех. поддержку.

Рассмотрим его вывод:

В строке DSK мы видим использование диска в данный момент. В строке busy в процентах указывается примерно сколько «ресурсов» диска потребляется в данный момент. Если там будет значение около 100% значит на диске, скорее всего, наблюдаются проблемы с операциями ввода/вывода. В случае использования VDS, данной строки может не быть и пугаться не стоит.

В нижней части видим список процессов, которые в данный момент выполняют дисковые операции. Вверху списка будут процессы, потребляющие больше всего ресурсов.

Как мы видим, процесс с идентификатором pid 539189 в данный момент ведет активную запись на диск. Узнать в какие файлы пишет данные этот процесс можно с помощью команды lsof.

Вызов команды lsof -p539189 (подставляем pid-идентификатор нужного процесса) показал такой результат:

mysqld 539189 110 4u REG 182,374993 0 12516 (deleted)/tmp/ib30lihW lsof: no pwd entry for UID 110 mysqld 539189 110 5u REG 182,374993 0 12520 (deleted)/tmp/ibSrHvsH lsof: no pwd entry for UID 110 mysqld 539189 110 6u REG 182,374993 0 12522 (deleted)/tmp/ibLkoJDs lsof: no pwd entry for UID 110 mysqld 539189 110 7u REG 182,374993 0 12524 (deleted)/tmp/ibNk007Y

Видно, что данный процесс mysql пишет временные файлы на жесткий диск и этим создает нагрузку. Поэтому желательно провести его оптимизацию.

Более подробно проанализировать нагрузку на дисковую систему можно также с помощью специализированной утилиты iotop.

Заключение

В данной статье мы рассказали о малой части средств для мониторинга нагрузки на серверах. И даже в них мы охватили минимум возможностей. Для более полного знакомства с возможностями описанных утилит, читайте документацию (ссылки в статье на названиях команд). Но даже описанных в статье возможностей хватает для диагностики большинства возникающих проблем.

Zabbix load/cpu roll-your-own formula

I know that newer versions of Zabbix (2.0 onward) has a simple way of determining average load per cpu via the introduction of the «percpu» parameter. Unfortunately, I’m using 1.8. With 2.0 I would be able to create an item with this key: system.cpu.load[percpu,avg15] How do I roll-my-own calculated item using 1.8? I have tried the following formulas (Many are desperate and improbable, I know): system.cpu.load[,avg15].last/system.cpu.num.last Template_Linux:system.cpu.load[,avg15]/Template_Linux:system.cpu.num / / / / «Template_Linux:system.cpu.load[,avg15]».last()/»Template_Linux:system.cpu.num».last() «Template_Linux:system.cpu.load[,avg15].last()»/»Template_Linux:system.cpu.num.last()» Thanks!

asked Jan 30, 2015 at 22:33
yack spillsaps yack spillsaps
59 1 1 silver badge 7 7 bronze badges

Considering that Zabbix 1.8 is no longer supported, what prevents you from using a newer version? Note also that if you are using passive checks, you can use a Zabbix 2.x agent with Zabbix 1.8 server. Strictly speaking, using a newer agent with older server is not officially supported, but practically the passive check protocol of newer agents is compatible with Zabbix 1.8 server.