Cpu jumps zabbix что это
Русские Блоги
[Глава 1] Zabbix3.4. Мониторинг использования ЦП Windows. Дисковый ввод-вывод. Мониторинг порога.
1. Windows-сервер должен сначала установить zabbix-агент
обзор
Zabbix агент развернут на цели мониторинга для активного мониторинга локальных ресурсов и приложений (драйверы оборудования, память, статистика процессора и т. Д.).
Zabbix агент собирает информацию о локальной работе и сообщает данные на Zabbix сервер для дальнейшей обработки. Как только возникает исключение (например, полное пространство на жестком диске или сбой процесса обслуживания), Zabbix сервер будет активно предупреждать администратора об исключении на указанной машине.
Агенты Zabbix чрезвычайно эффективны, потому что они могут использовать локальные системные вызовы для завершения сбора статистических данных.
Пассивная и активная проверка
Агенты Zabbix могут выполнять как пассивные, так и активные методы проверки.
Zabbix агент в Windows работает как служба Windows.
Вы можете запустить один или несколько экземпляров Zabbix агента на хосте.
Один экземпляр может использовать файл конфигурации по умолчанию или файл конфигурации, указанный в командной строке.
В случае нескольких экземпляров каждый экземпляр агента должен иметь свой собственный независимый файл конфигурации (один из которых может использовать файл конфигурации по умолчанию).
Следующие параметры команды могут использоваться в Zabbix агенте:
Разархивируйте загруженный выше файл zabbix_agents_3.4.6.win.zip и поместите его на диск c
Затем вам нужно изменить zabbix_agentd.win.conf в файле conf, который является файлом конфигурации
Запустите cmd с правами администратора. На следующем рисунке показано, что успешно установленный означает успешно, затем перейдите в службу и запустите zabbix-agent
2. Контролировать использование Windows-CPU
После создания элемента мониторинга создайте новый триггер, вы можете проверить, полезен ли триггер в конструкторе выражений
Название: процессор используется более 80%
Серьезность: как правило, серьезная
После создания триггера добавьте график для просмотра графика использования процессора
Название: загрузка процессора
Элементы мониторинга: Шаблон Использование ЦП Windows: Загрузка ЦП
После того, как добавление прошло успешно, вы можете просмотреть графическую таблицу CPU, и данные указывают на успешный мониторинг!
3. Мониторинг мониторинга производительности Windows-Disk IO
Мониторинг производительности ввода-вывода под WIN достигается путем вызова параметров в счетчике производительности
В настоящее время он скомпилирован в шаблон и может использоваться напрямую. Шаблон включает в себя графику и элементы мониторинга, показанные на рисунке выше.
Я здесь для мониторинга Windows, поэтому измените шаблон Windows, если вы отслеживаете Linux, вы можете изменить шаблон Linux
По умолчанию обновляется один раз в час, и изменяется до 600 секунд, то есть обновляется каждые 10 минут. Через 10 минут вы можете видеть значения мониторинга сетевой карты и диска!
Я уже модифицировал его здесь. Если нет изменений или нет элемента триггера, вы можете нажать в правом верхнем углу (создать прототип триггера)
Имя: на диске <#FSNAME>свободное место на диске менее 50 ГБ.
Моя сторона была изменена. Если нет изменений или этот элемент мониторинга недоступен, вы можете нажать в правом верхнем углу (создать прототип элемента мониторинга)
Выражение: vfs.fs.size [<# FSNAME>, бесплатно]
Единица измерения: B
Интервал обновления: 1 м или 60 с
5. Мониторинг правил автоматического обнаружения Windows-сетевой карты
Описание проблемы: Это шаблон Windows по умолчанию, который содержит сетевую карту сервера автообнаружения, но он автоматически найдет много других сетевых карт и другую графику.
Решение: Бесполезно удалять соответствующий графический объект напрямую, поскольку правило автоматического обнаружения будет снова автоматически обнаружено, поэтому вам необходимо изменить правило
6. Настройте функцию почтовой тревоги на сервере
Я использую корпоративную электронную почту Tencent
Следует отметить, что в качестве имени пользователя следует указать свою служебную электронную почту, пароль ввести пароль
Сначала я подумал, что это имя электронной почты, поэтому я не мог его отправить, я мог использовать свой почтовый ящик QQ
SMTP электронная почта: [email protected]
Создать триггер для отправки оповещений по электронной почте
Операция:
Операция восстановления:
Заголовок по умолчанию: Восстановить
Подтвердите операцию:
Название по умолчанию: Подтверждено:
Текущее состояние проблемы:
Наконец, настройте среду тревоги, то есть, чтобы активировать условие тревоги, вам нужно отправить электронное письмо, чтобы узнать, какой почтовый ящик
Нажмите на маленький аватар, затем введите основную информацию пользователя, выберите медиа-сигнал тревоги, чтобы установить
Вы можете выбрать уровень серьезности самостоятельно. После того, как настройка включена, функция будильника установлена!
What does «CPU jumps» mean?
I have the following default chart in zabbix, but I have no idea how to interprete these values. Can anyone explain?
1 Answer 1
An OS is a very busy thing, particularly so when you have it doing something (and even when you aren’t). And when we are looking at an active enterprise environment, something is always going on. (From Wikipedia: zabbix «is designed to monitor and track the status of various network services, servers, and other network hardware.»)
Most of this activity is «bursty», meaning processes are typically quiescent with short periods of intense activity. This is certainly true of any type of network-based activity (e.g. processing PHP requests), but also applies to OS maintenance (e.g. file system maintenance, page reclamation, disk I/O requests). I won’t even get into modern power saving technologies.
If you take a situation where you have a lot of such bursty processes, you get a very irregular and spiky CPU usage plot.
PS As “500 – Internal Server Error” says (love that handle!), the high number of context switches are going to make the situation even worse.
PPS The physics nerd in me just has to mention that this is a very common phenomenon in situations where you have a somewhat large number of bursty events (say particle collisions or atomic decay). Once you get into an extremely large number of such events (think Avogadro’s Number), things smooth out.
Cpu jumps zabbix что это
Задача: разобрать как поставить на мониторинг сам сервер на котором развернута система мониторинга Zabbix
http://IP&DNS/ — авторизуюсь под Административной учетной записью:
Login:admin
Password:zabbix
после Configuration – Hosts – Выделяем текущий хост он же сам сервер где сейчас установлено приложение Zabbix и обращаем внимание на колонку Status, сейчас выставлен статус не мониторить ( Not monitored)
Поправляю это дело:
Нажимаем левой кнопкой мыши на Not monitored – на запрос Включить хост — отвечаю OK
После чего статус примет вид — поставлено на мониторинг и уже с учетом дефолтных настроек начнется сбор статистических данных : ( если же страница не приняла вид который ниже, просто следует немного подождать и обновить содержимое страницы нажатием функционнальной клавиши F5)
Configurations — Hosts — статус у хоста поменялся на (Availability — Z)
Проверить, что сбор осуществляется:
Monitoring – Graphs —
Group: выбираю Zabbix servers
Host: Zabbix server
Graph: CPU jumps (к примеру)
и уже сейчас наблюдаю строящийся график по собираемым данным.
, как видно даже после установки и активации хоста можно собирать некоторые данные и самое главное отображаться их в более наглядном выражении, а именно график. Ни что так не увеличивается полезность, как графическое представление собираемых статистических данных. Работает.
Чтобы увеличить количество собираемых метрик, можно для текущего хоста применить шаблон ( Template) который содержит различные указания на мониторинг тех или иных метрик.
К примеру, для текущего хоста Zabbix добавлю шаблон:
Configuration – Host Groups – нахожу Zabbix servers и щелкаю по Хост группе Zabbix servers ( ниже специально выделил)
Теперь, добавляю к Хост группе дополнительные шаблоны
После проверяю, какие виды графиков доступы. И их стало намного больше чем было до этого, посмотреть которые можно следующим образом:
Monitoring – Latest data
Group: выбираю Zabbix servers
Host: выбираю Zabbix server и ниже вижу категории (к примеру: CPU,Filesystems,General,Memory и т.д) развернув которые можно видеть, что включено, а также с последующем представлением, как в виде простой истории, так и в виде графика:
Допустим разверну категорию Memory и сформирую график по Available memory
В последующих заметках я буду знакомить, а также самостоятельно разбираться как настраивать, устранять ошибки в данной системе мониторинга, как Zabbix. Мне лично данная система больше нравиться чем Nagios, кою я использовал много много лет тому назад в одной интересной конторе. Так вот сейчас я потихоньку перехожу на новый уровень и хоч у расписать все шаги настройки сервисов установленных на мониторинг применительно к Zabbix и решению своих потребностей с целью предотвращения проблем в будущем. А пока все, до встречи с уважением автор блога — ekzorchik.
Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:
Поблагодари автора и новые статьи
будут появляться чаще 🙂
Карта МКБ: 4432-7300-2472-8059
Yandex-деньги: 41001520055047
Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.
I have the following default chart in zabbix, but I have no idea how to interprete these values. Can anyone explain?
1 Answer 1
An OS is a very busy thing, particularly so when you have it doing something (and even when you aren’t). And when we are looking at an active enterprise environment, something is always going on. (From Wikipedia: zabbix «is designed to monitor and track the status of various network services, servers, and other network hardware.»)
Most of this activity is «bursty», meaning processes are typically quiescent with short periods of intense activity. This is certainly true of any type of network-based activity (e.g. processing PHP requests), but also applies to OS maintenance (e.g. file system maintenance, page reclamation, disk I/O requests). I won’t even get into modern power saving technologies.
If you take a situation where you have a lot of such bursty processes, you get a very irregular and spiky CPU usage plot.
PS As “500 – Internal Server Error” says (love that handle!), the high number of context switches are going to make the situation even worse.
PPS The physics nerd in me just has to mention that this is a very common phenomenon in situations where you have a somewhat large number of bursty events (say particle collisions or atomic decay). Once you get into an extremely large number of such events (think Avogadro’s Number), things smooth out.
Приведу пример мониторинга использования каждого ядра процессора используя Zabbix.
Допустим на высоконагруженном NAT сервере основная нагрузка от softirq, присутствует один процессор с 8 ядрами, а также на сервере установлен Zabbix агент.
И чтобы увидеть равномерно ли распределены прерывания сетевого адаптера по ядрам процессора, создадим элементы данных на Zabbix сервере, в которых укажем:
Тип: Zabbix агент
Тип информации: Числовой (с плавающей точкой)
Единица измерения: %
А также ключ:
Где 0 — номер процессора, softirq — тип нагрузки, avg5 — средняя нагрузка за 5 минут. Аналогично создадим элементы данных для других ядер процессора с ключами, а также добавим их на один график:
Вместо softirq можно указать idle, nice, user (по умолчанию для Linux), system (по умолчанию для Windows), iowait, interrupt, softirq, steal, guest, guest_nice.
А вместо avg5 можно указать: avg1 (среднее за одну минуту, по умолчанию) или avg15 (среднее за 15 минут).
Чтобы не указывать ядра процессоров вручную, можно создать правило обнаружения:
И указать в нем элемент данных, например:
Также можно создать триггер, чтобы узнать когда значение будет больше 90:
Ниже приведу примеры элементов данных, которые отображают различную информацию о CPU, кстати эти элементы данных по умолчанию присутствуют в шаблоне «Template OS Linux».
Processor load (1 min average per core):
Processor load (5 min average per core):
Processor load (15 min average per core):
Interrupts per second:
Context switches per second:
CPU interrupt time:
Смотрите другие мои статьи в категории Zabbix.
Мониторим ядра CPU в Zabbix и создаем произвольные счетчики в Low-level discovery
Не так давно тут проходила статья про LLD. Мне она показалась скучной т.к. описывает примерно то же, что есть и в документации. Я решил пойти дальше и с помощью LLD мониторить те параметры, которые раньше нельзя было мониторить автоматически, либо это было достаточно сложно. Разберем работу LLD на примере логических процессоров в Windows: 
Изначально интересовал расширенный монтиринг помимо ядрер CPU и нагрузка на физические диски. До того как обнаружение было введено, эти задачи частично решались ручным добавлением. Я добавлял условные диски в файл конфигурации zabbix_agent и вообще по-разному извращался. В результате это было очень неудобно, добавлялось много неприятной ручной работы и вообще неправильно в общем как-то было 🙂
В итоге получается схема, которая автоматически определяет ядра в системе, а также физические диски, установленные в системе и добавляет необходимые элементы сбора данных. Для того, чтобы узнать как это реализовать у себя, добро пожаловать под кат. Я попытаюсь более-менее подробно расписать работу на примере CPU и то как сделать тоже самое, но для физических дисков.
Тип отправляемых данных
Для начала стоит отослать к документации, где расписывается что такое LLD и с чем его едят. Помимо стандартных шаблонов нас будет интересовать 4-ый раздел с описание JSON формата обнаружения. То есть мы будем создавать свой собственный метод обнаружения. По сути все сводится к вызову скрипта, который формирует в нужном формате нужные данные.
Создаем скрипт.
Для скрипта я выбрал powershell. Его я знаю немного лучше других скриптовых языков, да и учитывая, что все будет крутиться во круг WMI, сделать его можно было бы и на VBS.
Итак, скрипт.
Задача скрипта состоит в том, чтобы определить число логических процессоров с помощью WMI и вывести в консоль эти данные в формате JSON. Передавать мы будем переменную с именем , а также ее значения. Формат вывода будет примерно таким, в зависимости от количества логических процессоров:
Скрипт формирования данных
Сам скрипт выглядит так:
Сейчас мы получаем, что при запуске скрипта он узнает сколько ядер и формирует пакет для отправки.
Что же мы делаем дальше? Нужно создать Discovery rule.
Добавялем низкоуровневое обнаружение в настройках zabbix сервера
Для этого заходим в нужный шаблон, который добавлен к интересующим нас хостам, в раздел Discovery и нажимаем кнопку Create discovery rule.
Тут мы видим непонятное значение поля key: PSScript[proc.ps1]. Это UserParameter. Этот пункт создан для удобства, теперь в каждом новом объекте мы можем просто вписывать параметр в виде имени PS скрипта и он будет искать его в заранее оговоренном месте. Сам параметр прописывается в файле конфигурации клиента (обычно называется zabbix_agentd.conf) и выглядит так:
Мы создали новое правило обнаружения с пользовательским сбором данных. Запрос на изменение информации задан как 1 час. Пожалуй, для таких статических данных, как количество процессоров, это слишком часто :), но каждый волен поставить свое значение. Для первоначального сбора данных и отладки лучше это значение уменьшить до совсем небольших значений, чтобы не ждать часами выполнение скрипта.
Настройка прототипов данных
Хорошо. Данные о количестве процессоров мы начали собирать. Но в результате нам нужны не эти данные, а новый item в мониторинге. Именно item может собирать данные, а не наш скрипт, наш скрипт служит только для обнаружения самих элементов для сбора данных.
А для того что бы создать новый элемент сбора данных, полученный на основании LLD, в том же разделе Discovery мы создаем новый прототип. Для этого заходим в item prototypes и нажимаем create item prototype. Я создал вот такой элемент сбора:
Для сбора данных используется стандартный счетчик производительности. В zabbix для сбора этих данных есть ключ perf_counter. Вместо номера логического ядра мы вставляем полученное значение в виде переменной из раздела Discovery.
Теперь все готово. Или почти все…
С этого момента, когда скрипт discovery обнаружит логические процессоры, для этого хоста будут созданы элементы сбора данных созданных точно для этого количества процессоров.
И теперь если мы зайдем в items для хоста, низкоуровневое обнаружение для которого уже отработало, то мы увидим, что появились новые элементы:
Эти элементы нельзя удалить стандартным способом, т.к. они созданы автоматически, они выделены особенным префиксом с названием правила низкоуровневого обнаружения. На скриншоте кажется, что написана какая-то фигня в имени :), на самом деле все просто, я использую трехзначный код в каждом имени для сортировки. То есть 100 это только лишь сортировочный номер. Следующая цифра от 0 до 11 это номер логического процессора. А дальше уже «% загруженности процессора». А то сначала может показаться, что это 0% загруженности процессора и я пытаюсь это значение собрать 🙂
Единственный недостаток всего этого метода в том, что график, такой как в заголовке этого поста, нельзя создать с помощью механизма низкоуровневого обнаружения. То есть мы можем, конечно, создать не только item, но и graph объект для каждого логического процессора, но создать один суммарный график автоматически со всеми обнаруженными логическими процессорами не получится. По крайней мере я не видел как это можно было бы сделать, на форуме zabbix мне также не смогли подсказать. Это, конечно, не особенно серьезный недостаток, но если у вас 200 хостов, это может стать проблемой :). Ведь график для каждого хоста нужно будет создавать вручную.
Мониторим производительность каждого физического диска в системе
В вышеприведённом способе лучше разобраться и тогда это открывает достаточно широкие возможности для мониторинга объектов в системе, количество которых либо отличается от хоста к хосту либо их количество во все изменяется во время работы.
Например, часто случается, что нужно определить, не происходил ли недостаток в ресурсах физического диска, установленного в сервере. Чаще всего эти данные сложно уловить в реалтайме и хочется иметь их собранными постфактум. Для этого я ввел аналогичное обнаружение и для физических дисков для сбора обширной статистики по ним. И, в отличии от процессоров, элементов сбора данных я создал их с избытком.
Тут, конечно, надо быть внимательным и если mysql у вас стоит на каком-нибудь стареньком забитом компе, то подобное количество достаточно быстро унесет вашу базу данных в небеса. Т.к. в приведенном примере для каждого хоста создается для каждого физического диска 20 новых элементов, которые будут создавать одного новое значение в минуту. В масштабе пары десятков серверов с кучами разных дисков это выливается в более-менее весомое количество данных. Но тут каждый волен выбирать свой путь самурая 🙂
Скрипт для LLD физических дисков выглядит так:
Добавляем новое правило обнаружения по аналогии с CPU. Точно также мы создаем нужные элементы в discovery.
Вообще, конечно, этот механизм дает довольно большие возможности по определению различных элементов для мониторинга. Таким же способом можно, например, добавить мониторинг сетевых интерфейсов, процессов в системе, служб и любых других элементов, имя которых и количество заранее неизвестно.
Надеюсь эта статья кому-нибудь поможет разобраться с LLD. С удовольствием отвечу на возникшие вопросы.