В процессе работы и технического обслуживания сервера часто необходимо контролировать различные ресурсы сервера, такие как: мониторинг загрузки процессора, мониторинг использования дисков, мониторинг номеров процесса и т. Д., Чтобы быстро тревожить, когда в системе происходит ненормальность и уведомить системный администратор. В этой статье представлены несколько распространенных требований к мониторингу и написания сценариев оболочки в Linux Systems.
Справочник статьи:
1.Nilux использует Shell, чтобы проверить, существует ли процесс
2. Linux использует оболочку для обнаружения процесса использования ЦП
3. Linux использует Shell для обнаружения использования памяти процесса
4. Linux использует Shell для обнаружения использования обработки процесса
5.nlinux использует Shell, чтобы увидеть, прослушивает ли TCP или UDP -порт
6.nlinux использует Shell для просмотра количества процессов работы
7. Linux использует Shell для обнаружения системы процессора системы
8. Linux использует Shell для обнаружения дискового пространства системного диска
9. Резюме
Проверьте, существует ли процесс
При мониторинге процесса нам обычно нужно получить идентификатор процесса. Идентификатор процесса является уникальным идентификатором процесса, но иногда несколько процессов с одинаковым именем процесса могут быть запущены при разных пользователях на сервере. Функция GetPID ниже приводит функцию получения идентификатора процесса указанного имени процесса при указанном пользователе (в настоящее время только с учетом начала процесса с этим именем процесса в соответствии с этим пользователем). Он имеет два параметра: имя пользователя и имя процесса. Сначала он использует PS, чтобы найти информацию о процессе, и отфильтровать требуемый процесс через GREP, и, наконец, находит значение идентификатора процесса через SED и AWK (эта функция может быть изменена в соответствии с фактическими условиями, такими как фильтрация другой информации и т. Д.).
Перечисление 1. Мониторинг процесса
Кода -копия выглядит следующим образом:
функция getPid #user #name
{
PSUSER = 1 доллар
Psname = $ 2
pid = `ps -u $ psuser | grep $ psname | grep -v grep | grep -v vi | grep -v dbx/n
| grep -v tail | grep -v Start | grep -v Stop | sed -n 1p | awk '{print $ 1}' `` `
Echo $ pid
}
Образец демонстрации:
1) Исходная программа (например, найдите идентификатор процесса пользователя как root, а имя процесса - cftestapp)
Кода -копия выглядит следующим образом:
Pid = `getpid root cftestapp`
Echo $ pid
2) Результаты вывод
Кода -копия выглядит следующим образом:
11426
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Из приведенного выше вывода мы видим, что 11426 является идентификатором процесса программы CFTESTAPP при пользователе root.
4) Введение команды
1. PS: Просмотреть мгновенную информацию процесса в системе. Параметры: -u <Код идентификации пользователя> перечисляет состояние программы, принадлежащей пользователю, а также может быть указан с использованием имени пользователя. -p <Код идентификации процесса> Укажите код идентификации процесса и перечислите состояние процесса. -o Укажите выходной формат 2. grep: используется для поиска текущей строки в файле, который соответствует строке. Параметры: -v обратный выбор, то есть строка, которая не показывает содержимое «строки поиска». 3. SED: неинтерактивный текстовый редактор, который редактирует файлы или экспортируемые файлы из стандартного ввода, и может обрабатывать только одну строку контента одновременно. Параметры: -n Стройте следующую входную строку и используйте следующую команду для обработки новой строки вместо первой команды. P Флаг печатает соответствующие строки 4. AWK: язык программирования для обработки текста и данных в рамках Linux/Unix. Данные могут быть из стандартного ввода, одного или нескольких файлов или вывода других команд. Он поддерживает расширенные функции, такие как пользовательские функции и динамические регулярные выражения, и представляет собой мощный инструмент программирования под Linux/Unix. Он используется в командной строке, но больше как сценарий. Способ обработки текста и данных AWK: он сканирует файл шаг за шагом, от первой строки до последней строки, поиск рядов сопоставления определенных шаблонов и делать то, что вы хотите на этих строках. Если не указано никакое действие обработки, соответствующие строки отображаются на стандартный выход (экран). Если режим не указан, обрабатываются все строки, указанные в операции. Параметры: -f FS или Field -Sparator FS: указывает разделитель входного файла, FS -это строка или регулярное выражение, например -f:.
Иногда возможно, что процесс не начался. Следующая функция - проверить, существует ли идентификатор процесса. Если этот процесс не запускает выход:
Кода -копия выглядит следующим образом:
Процесс не существует.
# Проверьте, существует ли процесс
if ["-$ pid" == "-"]
Затем
{
Эхо «Процесс не существует».
}
фигура
Обнаружение использования процессора процесса
При обслуживании прикладных услуг мы часто сталкиваемся с бизнес -блокировкой из -за чрезмерного процессора, что приводит к прерыванию бизнеса. Если процессор слишком высок, это может быть связано с чрезмерной деловой нагрузкой или аномальными циклами, такими как мертвые циклы. ЦП бизнес -процесса своевременно контролируется с помощью сценариев, и персонал по обслуживанию может быть своевременно уведомлен, когда использование ЦП является ненормальным, так что обслуживающий персонал может быть быстро проанализирован, позиционировать и избежать перерывов бизнеса. Следующая функция может получить использование процессора процесса указанного идентификатора процесса. Он имеет параметр в качестве идентификатора процесса. Сначала он использует PS, чтобы найти информацию о процессе, отфильтровать %ROWS CPU через GREP -V и, наконец, находит целочисленную часть процента использования ЦП через AWK (если в системе есть несколько процессоров, использование ЦП может превышать 100 %).
Листинг 2. Мониторинг процессора бизнес-процесса в реальном времени
Кода -копия выглядит следующим образом:
функция getCpu
{
Cpuvalue = `ps -p $ 1 -o pcpu | grep -v CPU | awk '{print $ 1}' | awk - f. '{print $ 1}' ``
Echo $ cpuvalue
}
Следующая функция заключается в получении использования ЦП в этом процессе с помощью вышеуказанной функции getCPU, а затем использовать условное утверждение, чтобы определить, превышает ли использование ЦП. Если он превышает 80% (его можно скорректировать в соответствии с фактической ситуацией), будет выведен сигнализация, в противном случае будет выведена нормальная информация.
Листинг 3. Определите, превышает ли использование ЦП
Кода -копия выглядит следующим образом:
Функция CheckCPU
{
PID = 1 $
CPU = `getCpu $ pid`
Если [$ cpu -gt 80]
Затем
{
Эхо «Использование процессора превышает 80%»
}
еще
{
Эхо «Использование процессора нормально»
}
фигура
}
Образец демонстрации:
1) Исходная программа (при условии, что идентификатор процесса CFTESTAPP был запрошен выше 11426)
Кода -копия выглядит следующим образом:
CHECKCPU 11426
2) Результаты вывод
Кода -копия выглядит следующим образом:
Использование процессора составляет 75
Использование процессора нормально
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Как видно из вышеуказанного вывода: текущее использование ЦП программы CFTESTAPP составляет 75%, что является нормальным, и не существует предела тревоги более 80%.
Обнаружение использования памяти процесса
При поддержании услуг приложений часто встречается, что процесс сбивается из-за чрезмерного использования памяти, что приводит к прерыванию бизнеса (например, максимальное пространство памяти, которое 32-разрядная программа может адресовать, составляет 4G, если она превышает память, память потерпит неудачу, а физическая память также ограничена). Чрезмерное использование памяти может быть связано с утечкой памяти, накоплением сообщений и т. Д. Использование памяти бизнес -процесса может быть своевременно контролироваться с помощью сценариев, и тревоги могут быть своевременно отправляться, когда использование памяти является аномальным (например, через SMS), чтобы облегчить обслуживающий персонал, чтобы своевременно обрабатывать его. Следующая функция может получить использование памяти процесса указанного идентификатора процесса. Он имеет параметр в качестве идентификатора процесса, который сначала использует PS, чтобы найти информацию о процессе, отфильтровать линии VSZ через grep -v, а затем принимает использование памяти в мегабайтах, делясь 1000.
Листинг 4. Мониторинг использования памяти бизнес -процесса
Кода -копия выглядит следующим образом:
функция getMem
{
Memusage = `ps -o vsz -p $ 1 | grep -v vsz`
((Memusage /= 1000))
Echo $ memusage
}
Следующая функция заключается в получении использования памяти этого процесса с помощью вышеуказанной функции GetMem, а затем использовать условное утверждение, чтобы определить, превышает ли использование памяти предел. Если он превышает 1,6 г (он может быть скорректирован в соответствии с фактической ситуацией), будет выведен сигнализация, в противном случае будет выведена нормальная информация.
Список 5. Определите, превышает ли использование памяти предел
Кода -копия выглядит следующим образом:
mem = `getMem $ pid`
Если [$ mem -gt 1600]
Затем
{
Эхо «Использование памяти больше 1,6 г»
}
еще
{
Эхо «Использование памяти нормально»
}
фигура
Образец демонстрации:
1) Исходная программа (при условии, что идентификатор процесса CFTESTAPP был запрошен выше 11426)
Кода -копия выглядит следующим образом:
mem = `getMem 11426`
Эхо "Использование памяти - это $ mem m"
Если [$ mem -gt 1600]
Затем
{
Эхо "использование памяти больше 1,6 г"
}
еще
{
Эхо "использование памяти нормально"
}
фигура
2) Результаты вывод
Кода -копия выглядит следующим образом:
Использование памяти составляет 248 м
Использование памяти нормально
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Из приведенного выше вывода мы видим, что текущее использование памяти программы CFTESTAPP составляет 248 м, что является нормальным, и не существует предела тревоги, превышающего 1,6 г.
Обнаружение использования обработки процесса
При обслуживании прикладных услуг часто встречаются перерывы в бизнесе из -за чрезмерного использования ручки. Каждая платформа использует ручки процесса с ограниченным использованием. Например, на платформе Linux мы можем использовать команду Ulimit N (Open Files (-n) 1024) или просмотреть содержимое /etc/security/limits.conf для получения ограничений обработки процесса. Если ручка используется слишком высокой, утечка ручки может быть связана с чрезмерной нагрузкой, утечкой ручки и т. Д. Использование бизнес -процесса своевременно контролируется сценариями, а тревоги могут быть своевременно отправляться в случае отклонений (например, через SMS), чтобы облегчить обслуживающий персонал, чтобы своевременно обрабатывать его. Следующая функция может получить использование обработки процесса указанного идентификатора процесса. Он имеет параметр в качестве идентификатора процесса. Сначала он использует LS для вывода информации о обработке процесса, а затем считает количество выводов через WC -L.
Кода -копия выглядит следующим образом:
функция getDes
{
Des = `ls/proc/$ 1/fd | wc -l`
Echo $ des
}
Следующая функция состоит в том, чтобы получить использование ручки этого процесса с помощью приведенной выше функции getDes, а затем использовать условное утверждение, чтобы определить, превышает ли использование ручки предел. Если он превышает 900 (он может быть скорректирован в соответствии с фактической ситуацией), будет выведена сигнализация, в противном случае будет выведена нормальная информация.
Кода -копия выглядит следующим образом:
des = `getdes $ pid`
Если [$ des -gt 900]
Затем
{
Эхо «Количество DES больше 900»
}
еще
{
Эхо «Количество DES нормально»
}
фигура
Образец демонстрации:
1) Исходная программа (при условии, что идентификатор процесса CFTESTAPP найдена выше, 11426)
Кода -копия выглядит следующим образом:
des = `getdes 11426`
Эхо "Количество des - это $ des"
Если [$ des -gt 900]
Затем
{
Эхо "Количество DES больше 900"
}
еще
{
Эхо "количество DES нормальное"
}
фигура
2) Результаты вывод
Кода -копия выглядит следующим образом:
Количество DES составляет 528
Количество DES нормально
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Из приведенного выше вывода мы видим, что текущая ручка программы CFTESTAPP составляет 528, что является нормальным, и не существует предела тревоги более 900.
4) Введение команды
WC: Статистика Количество байтов, слов и строк в указанном файле и отображает статистические результаты для вывода. Параметры: -l Считайте количество рядов. -c подсчитайте количество байтов. -В COUN COUN СЛОВА СЛОВА.
Проверьте, слушает ли порт TCP или UDP
Обнаружение порта часто встречается при обнаружении системных ресурсов, особенно при сетевой связи, обнаружение состояния порта часто очень важно. Иногда процессы, процессор, память и т. Д. Могут быть в нормальном состоянии, но порт находится в ненормальном состоянии, и бизнес не работает нормально. Следующая функция может определить, слушает ли указанный порт. У него есть параметр, который является портом, который должен быть обнаружен. Сначала он использует NetStat для вывода информации о оккупации порта, а затем фильтрует выходной номер портов TCP через Grep, AWK, WC. Второй оператор заключается в выводе количества мониторов портов UDP. Если и порты TCP и UDP равен 0, верните 0, в противном случае возврат 1.
Листинг 6. Обнаружение порта
Кода -копия выглядит следующим образом:
функция прослушивание
{
TcplisteningNum = `netStat -an | Греп ": $ 1" | /n
awk '$ 1 == "tcp" && $ nf == "Слушать" {print $ 0}' | wc -l`
UdplisteningNum = `netstat -an | grep": $ 1 " /n
| awk '$ 1 == "udp" && $ nf == "0.0.0.0:*" {print $ 0}' | wc -l`
((Слушание num = tcplisteningnum + udplisteningnum)))
Если [$ alingnum == 0]
Затем
{
эхо "0"
}
еще
{
эхо "1"
}
фигура
}
Образец демонстрации:
1) Исходная программа (например, запрос, слушает статус порта 8080)
Кода -копия выглядит следующим образом:
islisten = `прослушивание 8080`
Если [$ islisten -eq 1]
Затем
{
Эхо "порт слушает"
}
еще
{
Эхо "порт не слушает"
}
фигура
2) Результаты вывод
Кода -копия выглядит следующим образом:
Порт слушает
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Из приведенного выше вывода видно, что порт 8080 этого сервера Linux находится в состоянии прослушивания.
4) Введение команды
NetStat: используется для отображения статистических данных, связанных с протоколами IP, TCP, UDP и ICMP, и обычно используется для проверки состояния сетевого соединения каждого порта машины. Параметры: -a отображает гнезда во всех соединениях. -n используйте IP -адрес напрямую, а не через сервер доменных имен.
Следующая функция также должна определить, находится ли TCP или порт UDP в нормальном состоянии.
Кода -копия выглядит следующим образом:
TCP: NetStat -an | egrep $ 1 | awk '$ 6 == "Слушай" && $ 1 == "tcp" {print $ 0}'
udp: netstat -an | egrep $ 1 | awk '$ 1 == "udp" && $ 5 == "0,0.0.0:*" {print $ 0}'
Командование введения
Egrep: Найдите указанную строку в файле. Эффект выполнения Egrep похож на grep -e. Используемый синтаксис и параметры могут быть направлены на инструкцию GREP. Разница от GREP - это метод интерпретации строк. EGREP интерпретируется с использованием расширенного синтаксиса регулярного выражения, в то время как GREP использует базовый синтаксис регулярного выражения. Расширенные регулярные выражения имеют более полные спецификации экспрессии, чем основные регулярные выражения.
Проверьте количество запущенных процессов
Иногда нам может потребоваться получить количество запуска процесса на сервере. Следующая функция заключается в обнаружении количества запущенных процессов, таких как имя процесса - CFTESTAPP.
Кода -копия выглядит следующим образом:
Runnum = `ps -EF | grep -v Vi | Греп -V Хвост | grep "[ /] cftestapp" | grep -v grep | wc -l
Обнаружение системы процессора системы
При поддержании сервера иногда возникает прерывание бизнеса из -за чрезмерной нагрузки CPU (использование) системы. Может быть возможно запустить несколько процессов на сервере. Нормально просмотреть процессор одного процесса, но нагрузка на ЦП всей системы может быть ненормальной. Системная нагрузка процессора контролируется своевременно с помощью сценариев, и тревоги могут быть своевременно отправляться в случае аномалий, что облегчает техническому персоналу своевременно справляться с ним и предотвращать несчастные случаи. Следующая функция может обнаружить использование ЦП системы. Используйте VMStat, чтобы взять значение простоя в системе CPU 5 раз, возьмите среднее значение, а затем получите фактическое значение текущего ЦП текущего процессора, получив разницу с 100.
Кода -копия выглядит следующим образом:
Функция gesyScpu
{
Cpuidle = `vmstat 1 5 | sed -n '3, $ p' /n
| awk '{x = x + $ 15} end {print x/5}' | awk -f. '{print $ 1}'
Cpunum = `echo" 100- $ cpuidle "| до н.э.
Echo $ Cpunum
}
Образец демонстрации:
1) Исходная программа
Кода -копия выглядит следующим образом:
CPU = `gesyScpu`
Echo "Система процессор - это процессор $ cpu"
Если [$ cpu -gt 90]
Затем
{
Echo "Использование процессора системы превышает 90%"
}
еще
{
Echo "Использование системного процессора нормы"
}
фигура
2) Результаты вывод
Кода -копия выглядит следующим образом:
Системный процессор составляет 87
Использование процессора системы является нормальным
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Из приведенного выше вывода мы видим, что текущая скорость использования ЦП в системе сервера Linux составляет 87%, что является нормальным, и не существует предела тревоги более 90%.
4) Введение команды
VMSTAT: аббревиатура виртуальной статистики Meomory, которая может контролировать виртуальную память, процессы и действия операционной системы.
Параметры: -n означает, что когда вывод информация заголовка отображается только один раз во время периодического циклического вывода.
Обнаружение системного диска пространства
Обнаружение системы дискового пространства является важной частью обнаружения системных ресурсов. Во время технического обслуживания системы нам часто нужно проверять использование серверного дискового пространства. Поскольку некоторым предприятиям необходимо написать листы вызовов, журналы или временные файлы в любое время, если пространство диска исчерпано, это также может вызвать прерывание бизнеса. Следующая функция может обнаружить использование дискового пространства каталога в текущем системном диске. Параметр ввода - это имя каталога, которое необходимо обнаружить, используйте DF для вывода информации об использовании системного пространства, а затем получить процент использования пространства дискового пространства с помощью GREP и AWK -фильтрации.
Кода -копия выглядит следующим образом:
Функция getDiskSpc
{
Если [$# -ne 1]
Затем
возврат 1
фигура
Папка = "$ 1 $"
Diskspace = `df -k | Grep $ foter | awk '{print $ 5}' | awk -f% '{print $ 1}'
Echo $ Diskspace
}
Образец демонстрации:
1) Исходная программа (каталог обнаружения IS /Boot)
Кода -копия выглядит следующим образом:
Folder = "/boot"
Diskspace = `getDiskSpc $ foter`
Echo "System $ Disk Disk Space - это $ Diskspace%"
Если [$ Diskspace -gt 90]
Затем
{
Echo "Использование системного диска (папка $) превышает 90%"
}
еще
{
Echo "Использование системного диска (папка $) нормально"
}
фигура
2) Результаты вывод
Кода -копия выглядит следующим образом:
Пространство системы /загрузочного диска составляет 14%
Использование системного диска (/загрузка) нормально
[dyu@xilinuxbldsrv shell] $
3) Анализ результатов
Как видно из вышеуказанного вывода: в настоящее время дисковое пространство каталога /загрузки в этой системе сервера Linux использовалось на 14%, что является нормальным, и не существует предела тревоги, превышающего 90% использования.
4) Введение команды
DF: Проверьте использование пространства дискового пространства файловой системы. Эта команда может быть использована для получения информации, например, сколько места занял жесткий диск и сколько места осталось. Параметры: -K отображается в K Bytes.
Суммировать
В рамках платформы Linux мониторинг сценариев Shell является очень простым, удобным и эффективным методом для мониторинга серверов и процессов, который очень полезен для персонала разработки и технического обслуживания системы. Он может не только отслеживать вышеуказанную информацию и отправлять аварийные сигналы, но также отслеживать журналы процессов и другую информацию. Я надеюсь, что эта статья будет полезна всем.