По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Понимать состояние ваших серверов с точки зрения их загрузки и производительности - крайне важная задача. В этой статье мы опишем несколько самых популярных методов для проверки и мониторинга загрузки ЦПУ на Linux хосте.
Методы проверки
Проверяем загрузку процессора с помощью команды top
Отличным способом проверки загрузки является команда top. Вывод этой команды выглядит достаточно сложным, зато если вы в нем разберетесь, то точно сможете понять какие процессы занимают большую часть ваших вычислительных мощностей.
Команда состоит всего из трех букв: top
У вас откроется окно в терминале, которое будет отображать запущенные сервисы в реальном времени, долю системных ресурсов, которую эти сервисы потребляют, общую сводку по загрузке CPU и т.д
Будем идти по порядку: первая строчка отображает системное время, аптайм, количество активных пользовательских сессий и среднюю загруженность системы. Средняя загруженность для нас особенно важна, т.к дает понимание о среднем проценте утилизации ресурсов за некоторые промежутки времени.
Три числа показывают среднюю загрузку: за 1, 5 и 15 минут соответственно. Считайте, что эти числа - это процентная загрузка, т.е 0.2 означает 20%, а 1.00 - стопроцентную загрузку. Это звучит и выглядит достаточно логично, но иногда там могут проскакивать странные значения - вроде 2.50. Это происходит из-за того, что этот показатель не прямое значение загрузки процессора, а нечто вроде общего количества "работы", которое ваша система пытается выполнить. К примеру, значение 2.50 означает, что текущая загрузка равна 250% и ваша система на 150% перегружена.
Вторая строчка достаточна понятна и просто показывает количество задач, запущенных в системе и их текущий статус.
Третья строчка позволит вам отследить загрузку ЦПУ с подробной статистикой. Но здесь нужно сделать некоторые комментарии:
us: процент времени, когда ЦПУ был загружен и которое было затрачено на user space (созданные/запущенные пользователем процессы)
sy: процент времени, когда ЦПУ был загружен и которое было затрачено на на kernel (системные процессы)
ni: процент времени, когда ЦПУ был загружен и которое было затрачено на приоритезированные пользовательские процессы (системные процессы)
id: процент времени, когда ЦПУ не был загружен
wa: процент времени, когда ЦПУ ожидал отклика от устройств ввода - вывода (к примеру, ожидание завершения записи информации на диск)
hi: процент времени, когда ЦПУ получал аппаратные прерывания (например, от сетевого адаптера)
si: процент времени, когда ЦПУ получал программные прерывания (например, от какого-то приложения адаптера)
st: сколько процентов было "украдено" виртуальной машиной - в случае, если гипервизору понадобилось увеличить собственные ресурсы
Следующие две строчки показывают сколько занято/свободно оперативно памяти и файла подкачки, и не так релевантны относительно задачи проверки нагрузки на процессор. Под информацией о памяти вы увидите список процессов и процент ЦПУ, который они тратят.
Также вы можете нажимать на кнопку t, чтобы прокручивать между различными вариантами вывода информации и использовать кнопку q для выхода из top
Немного более модный способ: htop
Существует более удобная утилита под названием htop, которая предоставляет достаточно удобный интерфейс с красивым форматированием. Установка утилиты экстремально проста:Для Ubuntu и Debian:
sudo apt-get install htop
Для CentOS и Red Hat:
yum install htop
Для Fedora:
dnf install htop
После установки просто введите команду ниже:
htop
Как видно на скриншоте, htop гораздо лучше подходит для простой проверки степени загрузки процессора. Выход также осуществляется кнопкой q
Прочие способы проверки степени загрузки ЦПУ
Есть еще несколько полезных утилит, и одна из них (а точнее целый набор) называется sysstat.Установка для Ubuntu и Debian:
sudo apt-get install sysstat
Установка для CentOS и Red Hat:
yum install sysstat
Как только вы установите systat, вы сможете выполнить команду mpstat - опять же, практически тот же вывод, что и у top, но в гораздо лаконичнее.
Следующая утилита в этом пакете это sar. Она наиболее полезна, если вы ее вводите вместе с каким-нибудь числом, например 6. Это определяет временной интервал, через который команда sar будет выводить информацию о загрузке ЦПУ.
К примеру, проверяем загрузку ЦПУ каждые 6 секунд:
sar 6
Если же вы хотите остановить вывод после нескольких итераций, например 10, добавьте еще одно число:
sar 6 10
Так вы также увидите средние значения за 10 выводов.
Как настроить оповещения о слишком высокой нагрузке на процессор
Одним из самых правильных способов является написание простого bash скрипта, который будет отправлять вам алерты о слишком высокой степени утилизации системных ресурсов.
#!/bin/bash
CPU=$(sar 1 5 | grep "Average" | sed 's/^.* //')
CPU=$( printf "%.0f" $CPU )
if [ "$CPU" -lt 20 ]
then
echo "CPU usage is high!" | sendmail admin@example.com
fi
Скрипт будет использовать обработчик sed и среднюю загрузку от команды sar. Как только нагрузка на сервер будет превышать 85%, администратор будет получать письмо на электронную почту. Соответственно, значения в скрипте можно изменить под ваши требования - к примеру поменять тайминги, выводить алерт в консоль, отправлять оповещения в лог и т.д.
Естественно, для выполнения этого скрипта нужно будет запустить его по крону:
crontab -e
Для ежеминутного запуска введите:
* * * * * /path/to/cpu-alert.sh
Заключение
Соответственно, лучшим способом будет комбинировать эти способы - например использовать htop при отладке и экспериментах, а для постоянного контроля держать запущенным скрипт.
В предыдущей статье, мы рассказывали, как установить Asterisk 14.3.0 из источников, в сегодняшней статье, хотелось бы поговорить про базовые возможности управления Asterisk из командной строки после установки.
По умолчанию, после запуска Asterisk будет работать как процесс в фоновом режиме и для того, чтобы подключиться и начать управлять работающим процессом, необходимо включить удаленную консоль следующей командой:
[root@localhost ~]# asterisk -r
Asterisk 14.3.0, Copyright (C) 1999 - 2016, Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 14.3.0 currently running on localhost (pid = 1887)
localhost*CLI>
Опция -R также поможет подключить удаленную консоль, однако она будет автоматически пробовать переподключиться к Asterisk, если по каким-то причинам, соединение было разорвано.
Чтобы отключиться от удаленной консоли Asterisk, нужно нажать сочетание клавиш Ctrl+C
Существует несколько способов остановки работающего процесса Asterisk:
core stop now - данная команда мгновенно останавливает процесс, обрывая все проходящие на сервере соединения и звонки
core stop gracefully - данная команда не позволяет новым соединениям устанавливаться на Asterisk, но позволяет текущим соединениям продолжаться. Когда все соединения заканчиваются, то Asterisk останавливается
core stop when convenient - данная команда также дожидается пока на сервере не останется текущих звонков, а затем останавливает Asterisk. Однако, новые звонки, поступающие на сервер - разрешены
Команды для перезапуска процесса Asterisk работают аналогично командам, останавливающим процесс, которые описаны выше, но вместо того чтобы останавливать Asterisk, они его перезапускают в соответствии с синтаксисом команды:
core restart now
core restart gracefully
core restart when convenient
Существует также команда, которая отменяет введенную ранее команду остановки или перезапуска, если пользователь вдруг передумал:
core abort shutdown
Также можно подключиться к Asterisk как root, командой:
[root@localhost ~]# asterisk -c
Asterisk 14.3.0, Copyright (C) 1999 - 2016, Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for detail s.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
[ Initializing Custom Configuration Options ]
*CLI> Asterisk Ready.
Мы категорически не рекомендуем запускать Asterisk с правами root’а, поскольку это опасно и может негативно повлиять на систему, на которой работает Asterisk.
Управление степенью логирования событий в Asterisk
Вы можете управлять тем, насколько подробно будут логироваться события Asterisk, для этого используется специальная опция -v. Каждая –v повышает уровень VERBOSE сообщений.
Например, следующая команда повышает уровень логирования на 2:
# asterisk –r –v -v
Возможен и такой вариант ввода, разницы между ними нет
# asterisk -rvv
Другие опции
Можно также запускать Asterisk от имени другого пользователя:
# asterisk –U asteriskuser
Для работы от имени другого пользователя, советуем убедиться, что у него есть разрешения на доступ к следующим директориям. Используйте команды:
# sudo chown -R asteriskuser:asteriskuser /usr/lib/asterisk
# sudo chown -R asteriskuser:asteriskuser /var/lib/asterisk
# sudo chown -R asteriskuser:asteriskuser /var/spool/asterisk
# sudo chown -R asteriskuser:asteriskuser /var/log/asterisk
# sudo chown -R asteriskuser:asteriskuser /var/run/asterisk
# sudo chown asteriskuser:asteriskuser /usr/sbin/asterisk
Команды в консоль сервера IP - АТС Asterisk можно и давать с помощью графической оболочки FreePBX. Для этого, перейдите в раздел Admin → Asterisk CLI
Существует большое множество других опций и режимов, доступных при запуске Asterisk, для того чтобы посмотреть и ознакомиться с ними, используйте команду:
# asterisk –h
Чтобы управлять сервисом Asterisk из командной строки Вашей операционной системы используйте следующие команды:
Для запуска сервиса:
# service asterisk start
Starting asterisk (via systemctl): [ OK ]
Для остановки сервиса:
# service asterisk stop
Stopping asterisk (via systemctl): [ OK ]
Для перезапуска сервиса:
# service asterisk restart
Stopping asterisk (via systemctl): [ OK ]
Starting asterisk (via systemctl): [ OK ]
Для проверки статуса:
# service asterisk status
? asterisk.service - LSB: Asterisk PBX
Loaded: loaded (/etc/rc.d/init.d/asterisk; bad; vendor preset: disabled)
Active: active (running) since Wed 2017-03-01 15:59:26 MSK; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 11611 ExecStop=/etc/rc.d/init.d/asterisk stop (code=exited, status=0/SUCCESS)
Process: 11672 ExecStart=/etc/rc.d/init.d/asterisk start (code=exited, status=0/SUCCESS)
Main PID: 11697 (asterisk)
CGroup: /system.slice/asterisk.service
+-11695 /bin/sh /usr/sbin/safe_asterisk
L-11697 /usr/sbin/asterisk -f -vvvg -c
Mar 01 15:59:26 localhost.localdomain systemd[1]: Starting LSB: Asterisk PBX...
Mar 01 15:59:26 localhost.localdomain asterisk[11672]: Starting asterisk:
Mar 01 15:59:26 localhost.localdomain systemd[1]: PID file /var/run/asterisk/...
Mar 01 15:59:26 localhost.localdomain systemd[1]: asterisk.service: Supervisi...
Mar 01 15:59:26 localhost.localdomain systemd[1]: Started LSB: Asterisk PBX.
Hint: Some lines were ellipsized, use -l to show in full.
Подход DevSecOps с частым систематическим сканированием приложений на наличие уязвимостей значительно увеличивает процент программного обеспечения с исправленными уязвимостями и сокращает время, необходимое для выпуска исправлений, что особенно важно в контексте критических ошибок. Согласно Veracode State of Software Security Vol. 10, по сравнению с 2018 годом процент уязвимых приложений увеличился в 2019 году с 52 до 56%. С другой стороны, в случае приложений, сканируемых один раз в месяц или реже, среднее время обновления составляло 68 дней, в то время как приложения, сканируемые не реже одного раза в день, имели в среднем 19 дней для обновления.
Эти результаты, а также выводы исследования Enterprise Strategy Group подтверждают, насколько сегодня важно последовательно и как можно раньше расширять процесс разработки приложений до стадии тестирования безопасности. В прошлом эта задача входила в обязанности отдела безопасности и выполнялась после завершения программирования. Сегодня сами разработчики также должны продемонстрировать соответствующие компетенции.
Новые модели и способы доставки программного обеспечения - общедоступное облако, контейнеры и микросервисы - положили конец большим выпускам приложений и редким обновлениям. Вместо них у нас есть молниеносные циклы публикации, а приложения разделены на более мелкие, независимо работающие модули. В результате программное обеспечение просто создается слишком быстро, и новые версии приложения, так называемые выпуски могут идти "в производство" в оптовых количествах даже на один день, чтобы проверка безопасности по методологии WaterFall была эффективной. Ситуация дополнительно осложняется тем фактом, что конечный продукт, то есть приложение с определенной функциональностью, содержит как код, созданный внутри компании, так и элементы, заимствованные из открытых бесплатных репозиториев или через менеджеры пакетов).
Следовательно, функционирование разработки, операций и безопасности как отдельных организационных структур не существует и не может существовать. Разработчикам следует понимать, что поддержка и защита программного обеспечения также зависят от них.