Вам нужно запустить процесс на 100 Linux-серверах одновременно с вашими действиями

Обновлено: 04.07.2024

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

Я управляю сервером RHEL 2000+ (5,6 и 7)
Все серверы подключены к RHN Satellite
Политика обновления - ежеквартально.

Есть ли у кого-то лучший подход, чем я, пожалуйста, помогите мне.

Ответы

Похоже, у вас довольно хорошо получилось установить исправление. Однако «лучшей» политикой исправления для вас является та, которая соответствует вашим требованиям. Так что же это такое? Какие SLA (соглашения об уровне обслуживания) вы соблюдаете?

Исправление обычно мотивируется безопасностью системы. Помните, что ИТ-безопасность в целом имеет три аспекта:

Конфиденциальность — неправильные люди не должны получить доступ к определенным вещам (по крайней мере, к файлам паролей и другой инфраструктуре аутентификации; возможно, к целым системам и информации в них)
Целостность — обрабатываемая информация не должна быть повреждена в процессе ни из-за ошибок, ни по злому умыслу.
Доступность — системы и информация в них должны быть доступны для использования нужными людьми; именно поэтому они существуют в первую очередь.

Являетесь ли вы интернет-провайдером или веб-хостингом, куда клиенты приносят всевозможные материалы PHP и установки WordPress различного качества и уровня исправлений, а затем выкладывают все это в Интернет? Если это так, и вы устанавливаете обновления только раз в квартал, возможно, в данный момент вы размещаете какое-то вредоносное ПО. В такой среде вам понадобится возможность быстро устанавливать любые соответствующие исправления безопасности, даже если это будет стоить вам некоторого времени безотказной работы.

Или вы представляете собой вычислительную ферму для исследователей, выполняющих моделирование, которое может занять дни или недели? Входящий доступ в Интернет только с аутентификацией по ключу SSH или защищенным VPN? Тогда вы довольно хорошо защищены от внешних угроз и должны мыслить в основном с точки зрения внутренних. Если возможность того, что разные исследователи шпионят друг за другом, не является реальной проблемой, надежность среды и время безотказной работы будут вашими главными проблемами. В этой ситуации ваши решения об установке исправлений могут сильно отличаться.

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

Что делать, если у нас есть сервер, размещенный на AWS, какой ОС является Amazon Linux? Можем ли мы исправить Amazon Linux с помощью спутникового сервера RHN.

Некоторые другие соображения.

**ДОБАВЛЕНО 11 января 2021 г. Рекомендуется отключить EPEL на сателлитном сервере (или другом сервере), если он был временно включен. Сохранение активности EPEL на сателлитном сервере может привести к появлению связанных с EPEL «обновлений» на вашем сателлитном сервере, что вызовет серьезные проблемы. Из-за этого я часами делал «операцию» на предыдущем спутнике и активировал EPEL только для определенных двоичных файлов, таких как, например, iostat или htop EPEL, а затем отключил его. Очистите свою систему от устаревших репозиториев в /etc/yum.repos.d, потому что они могут вызвать у вас большие проблемы. Убедитесь, что ваш каталог /root не переполняется. Я помог одному клиенту решить серьезную проблему, когда его /root/ был заполнен на 100% после обновления ядра. За несколько лет многочисленных обновлений не хватило места, и их /root переполнился, а ядро не дописалось. (по-видимому). **

У нас есть один клиент, который использует Ansible (не Tower) для исправления своей большой сети, но поэтапно. Кроме того, исправление имеет предварительные шаги, такие как поиск нестандартных репозиториев aytpical yum в /etc/yum.repos.d/ и, соответственно, либо перемещение их в известное место в этой системе, либо просто отключение этого нетипичного нестандартного репозитория. . Некоторые репозитории будут «мешать» обычным обновлениям. Теперь, конечно, некоторые скажут, что им требуется [заполните пустое место] репозиторий, и если это так, то его следует регулярно поддерживать (а именно, если это репозиторий, отличный от Red Hat). В некоторых системах, которые на законных основаниях требуют EPEL, репозиторий «отключается» с помощью cron перед установкой исправлений (и каждую ночь в полночь) (изменение «enabled=1» на «enabled=0» в файле репо), так что он не t устанавливать конфликтующие RPM-пакеты (да, это может легко случиться, даже если это случается редко, достаточно выполнить это действие по крайней мере в этой среде) ПРИМЕЧАНИЕ "EPEL" здесь - только один пример многих возможностей. Проблема не обязательно в EPEL, а в любом нетипичном или неожиданном репозитории, который вызовет/вызовет проблемы с обновлением yum.Имейте в виду бродячие или устаревшие репозитории yum, которые страдают от отсутствия поддержки или просто устарели из-за того, что никогда не обновлялись (особенно сторонние), что часто вызывает ужасные конфликты

Есть некоторые серверы, которые работают вместе для одного клиента и должны быть перезагружены в определенном порядке, поскольку они работают вместе, поэтому ansible playbook/script гарантирует, что это произойдет.

Еще один этап исправления, который мы выполняем, — это yum clean all и список репозиториев yum, чтобы при публикации новых исправлений через представление содержимого кэшированная информация не «мешала» новому набору исправлений, хотя это и не является правилом, существует достаточно «исключений», когда это является проблемой, достаточной для того, чтобы сделать это в этой среде. Фактический пробег может отличаться.

Конечно, я думаю, что все поняли это, начните с малого и расширяйте масштаб рациональным/разумным методом. Начните с vmware и делайте моментальные снимки, особенно там, где есть риск. Оцените результаты. Делайте прогрессивные шаги. Некоторые патчи «тестируют» «разработку» и «производство» сегментов своих сетей, и даже в рамках этой «ступенчатой последовательности» предпринимают дополнительные шаги для разумного подхода к исправлению. Мы выполнили исправление серверов Oracle с привлечением администраторов баз данных Oracle, потому что они хотели протестировать что-то до и после. Хорошо, может быть, это сработает для вас или нет. В любом случае полезна предварительная координация или предварительное согласование сроков, поэтому полезно отсутствие «сюрпризов».

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

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

Для целей этой статьи мы предполагаем, что у вас уже есть настроенный SSH для доступа ко всем вашим серверам, и, во-вторых, при одновременном доступе к нескольким серверам уместно настроить SSH на основе ключа без пароля на всех ваших Linux-серверах. серверы. Прежде всего это повышает безопасность сервера, а также упрощает доступ.

1. PSSH – параллельный SSH

Parallel-SSH — это быстрый и простой в использовании набор инструментов Python с открытым исходным кодом, основанный на командной строке, для параллельного выполнения ssh в ряде систем Linux. Он содержит ряд инструментов для различных целей, таких как parallel-ssh, parallel-scp, parallel-rsync, parallel-slurp и parallel-nuke (дополнительную информацию см. на справочной странице конкретного инструмента).

Чтобы установить parallel-ssh, вам необходимо сначала установить PIP в вашей системе Linux.

Затем установите parallel-ssh с помощью pip следующим образом.

Далее введите имена хостов или IP-адреса удаленного сервера Linux с SSH-портом в файл с именем hosts (вы можете назвать его как хотите):

Сохраните файл и закройте его.

Теперь запустите parallel-ssh, укажите файл hosts с помощью параметра -h и команды, которые будут выполняться на всех указанных серверах. Флаг -i означает отображение стандартного вывода и стандартной ошибки по завершении выполнения команды на каждом сервере.

2. Pdsh — утилита для удаленной параллельной работы

Pdsh — это простой инструмент с открытым исходным кодом для удаленной оболочки, предназначенный для одновременного выполнения команд на нескольких серверах Linux. Он использует скользящее окно потоков для выполнения удаленных команд.

Чтобы установить Pdsh на ваши компьютеры с Linux, выполните соответствующую команду ниже.

Чтобы запускать команды на нескольких серверах, добавьте серверы в файл hosts, как описано выше. Затем запустите pdsh, как показано; флаг -w используется для указания файла hosts, а -R используется для указания модуля удаленных команд (доступные модули удаленных команд включают ssh, rsh, exec, по умолчанию используется rsh).

Обратите внимание на ^ перед файлом hosts.

Если вы не укажете удаленную команду для выполнения в командной строке, как показано выше, pdsh запускается в интерактивном режиме, запрашивая у вас команды и запуская их после завершения с возвратом каретки. Для получения дополнительной информации см. справочную страницу pdsh:

3. КластерSSH

ClusterSSH — это инструмент командной строки для одновременного администрирования кластеров из нескольких серверов. Он запускает консоль администрирования и xterm для всех указанных серверов, позволяя запускать одну и ту же команду на всех из них.

Чтобы использовать clusterssh, начните с его установки на локальный компьютер Linux, как показано ниже.

Теперь, когда он установлен, откройте консоль администратора и xterm одновременно на удаленных серверах, как показано ниже. Чтобы запустить команду на всех серверах, щелкните в строке ввода xterm и введите команду; для управления одним хостом используйте его консоль администратора.

Для получения дополнительной информации см. справочную страницу clusterssh:

4. Доступный

Ansible – это популярный инструмент с открытым исходным кодом для автоматизации ИТ-процессов. Он используется для настройки и управления системами, развертывания приложений и многого другого.

Чтобы установить Ansible в системах Linux, выполните соответствующую команду ниже:

После того как вы установили ansible, вы можете добавить имена хостов или IP-адреса вашего сервера в файл /etc/anasible/hosts.

Укажите их в группах, например веб-серверы.

Сохраните файл и закройте его.

Теперь, чтобы проверить время безотказной работы и пользователей, подключенных ко всем серверам, указанным в групповом веб-сервере, в файле конфигурации hosts выше, просто запустите инструмент командной строки ansible следующим образом.

Параметры -a используются для указания аргументов, которые необходимо передать модулю, а флаг -u указывает имя пользователя по умолчанию для подключения к удаленным серверам через SSH.

Обратите внимание, что инструмент Ansible CLI позволяет выполнять не более одной команды.

Вот и все! В этой статье мы объяснили, как выполнять команды на нескольких удаленных серверах Linux одновременно, используя широко используемые инструменты. Если вам известны какие-либо инструменты для той же цели, которые мы не включили в эту статью, сообщите нам об этом через форму комментариев ниже.

Если вам понравилась эта статья, подпишитесь на уведомления по электронной почте о руководствах по Linux. Если у вас есть вопросы или сомнения? обратитесь за помощью в разделе комментариев.

Если вы цените то, что мы делаем здесь, в TecMint, вам следует подумать о следующем:

TecMint – это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете. Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей, доступных всем БЕСПЛАТНО.

Если вам нравится то, что вы читаете, купите нам кофе (или 2) в знак признательности.

Мы благодарны за вашу бесконечную поддержку.

16 ответов 16

Запустить программу1.
Отправьте его в фоновый режим, но продолжайте печатать вывод.
Запустите prog2 и оставьте ее на переднем плане, чтобы вы могли закрыть ее с помощью Ctrl-C .
Когда вы закроете prog2 , вы вернетесь к переднему плану программы prog1, поэтому вы также можете закрыть ее, нажав Ctrl-C .

Только что попробовал это, и у меня это не сработало, как я ожидал. Однако сработала небольшая модификация: prog1 & prog2 ; fg Это было для одновременного запуска нескольких ssh-туннелей. Надеюсь, это кому-нибудь поможет.

@jnadro52 ваше решение приводит к тому, что если программа prog2 не запускается немедленно, вы вернетесь к тому, что prog1 будет отображаться на переднем плане. Если это желательно, то все в порядке.

В оболочке SSH Если вы выполните подобную команду, будет сложно убить prog1. Ctrl-c у меня не работал. Даже уничтожение всего терминала оставило программу prog1 запущенной.

Чтобы запустить несколько программ параллельно:

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

в момент, когда вы хотите, чтобы скрипт их ждал.

Возможно глупый вопрос, но что, если я хочу запустить prog1 | что-то & прог2 | еще один & ? Я почти уверен, что это не сработает.

Если вы хотите иметь возможность легко запускать и уничтожать несколько процессов с помощью ctrl-c , это мой любимый метод: создать несколько фоновых процессов в (…) подоболочке и перехватить SIGINT для выполнения kill 0 , что уничтожит все. создан в группе подоболочек:

У вас могут быть сложные структуры выполнения процессов, и все будет закрыто одним нажатием Ctrl-C (просто убедитесь, что последний процесс запущен на переднем плане, т. е. не добавляйте & после prog1.3 ):

@mpen Правильно, программа kill интерпретирует 0 как «Все процессы в текущей группе процессов получают сигнал». Это описание есть на странице руководства.

Вы можете использовать ожидание:

Он присваивает PID фоновой программы переменным ( $! – это PID последнего запущенного процесса), затем команда ожидания ожидает их. Это хорошо, потому что если вы убиваете скрипт, он убивает и процессы!

@Yash Я думаю, вы можете сохранить идентификаторы процессов в массив, а затем вызвать ожидание для массива. Я думаю, вам нужно использовать $<> для интерполяции в список строк или что-то подобное.

Или, если хотите:

Стоит отметить, что существуют разные версии parallel с разным синтаксисом. Например, в производных от Debian пакет moreutils содержит другую команду, называемую parallel, которая ведет себя совсем по-другому.

@OptimusPrime Это действительно зависит. GNU Parallel вносит некоторые накладные расходы, но, в свою очередь, дает вам гораздо больший контроль над запущенными заданиями и выводом. Если два задания печатаются одновременно, GNU Parallel позаботится о том, чтобы вывод не был смешанным.

Параллельность @OptimusPrime лучше, когда заданий больше, чем ядер, и в этом случае & будет запускать более одного задания на ядро одновременно. (см. принцип «сортировки»)

xargs -P позволяет выполнять команды параллельно.

Несмотря на то, что параметр -P является нестандартным, он поддерживается как GNU (Linux), так и macOS/BSD.

Следующий пример:

запускает максимум 3 команды одновременно,
дополнительные команды запускаются только после завершения ранее запущенного процесса.

Вывод выглядит примерно так:

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

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

BSD/macOS xargs требует, чтобы вы указали количество команд для параллельного выполнения явно, тогда как GNU xargs позволяет вам указать -P 0 для запуска как можно большего количества сколько возможно параллельно.

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

GNU parallel , как упоминалось в ответе Оле (не входит в стандартную комплектацию большинства платформ), удобно сериализует (группирует) вывод для каждого процесса и предлагает многие другие расширенные функции.

Перенаправлять ошибки в отдельные журналы.

Вы должны поставить амперсанд после перенаправления и опустить точку с запятой (амперсанд также будет выполнять функцию разделителя команд): prog1 2> .errorprog1.log & prog2 2> .errorprog2.log &

точка с запятой выполняет обе команды, вы можете протестировать bash, чтобы увидеть, как он работает ;) Пример: pwd & 2> .errorprog1.log; echo "wop" & 2> .errorprog2.log, когда вы переводите программу в фоновый режим и немедленно выполняете следующую команду.

Не работает - ошибки не перенаправляются в файл. Попробуйте: ls notthere1 & 2> .errorprog1.log; ls notthere2 & 2>.errorprog2.log .Ошибки идут в консоль, и оба файла ошибок пусты. Как говорит @Dennis Williamson, & является разделителем, например ; , поэтому (а) он должен идти в конце команды (после любого перенаправления) и (б) вам не нужен ; вообще :-)

Вот функция, которую я использую для параллельного запуска максимально n процессов (n=4 в примере):

Если для параметра max_children задано количество ядер, эта функция будет пытаться избегать простаивающих ядер.

Хороший фрагмент, но я не могу найти объяснение «wait -n» в моем bash, он говорит, что это недопустимая опция. опечатка или я что-то пропустил?

@EmmanuelDevaux: wait -n требует bash 4.3+, и он меняет логику на ожидание завершения любого из указанных/подразумеваемых процессов.

@52coder вы можете настроить функцию для захвата неудачного дочернего элемента, что-то вроде: "$@" && time2=$(date +"%H:%M:%S") && echo "завершение $2 ($time1 - - $время2)." || ошибка=1 &. Затем проверьте наличие ошибки в части «если» и при необходимости прервите функцию

Есть очень полезная программа, которая вызывает nohup.

nohup сам по себе ничего не запускает в фоновом режиме, и использование nohup не является обязательным условием для запуска задач в фоновом режиме. Они часто полезны вместе, но как таковые это не ответ на вопрос.

Недавно у меня была аналогичная ситуация, когда мне нужно было запустить несколько программ одновременно, перенаправить их выходные данные в отдельные файлы журналов и дождаться их завершения, и в итоге я получил что-то вроде этого:

Можете попробовать ppss (заброшен). ppss довольно мощный — вы даже можете создать мини-кластер. xargs -P также может быть полезен, если вам нужно выполнить партию досадно параллельной обработки.

Диспетчер создания процессов

Конечно, технически это процессы, и эту программу действительно следует называть менеджером порождения процессов, но это только из-за того, как работает BASH, когда он разветвляется с использованием амперсанда, он использует fork() или, возможно, clone( ) системный вызов, который клонирует в отдельное пространство памяти, а не что-то вроде pthread_create(), которое разделяет память. Если бы BASH поддерживал последнее, каждая «последовательность выполнения» работала бы точно так же, и ее можно было бы назвать традиционными потоками, получая при этом более эффективный объем памяти. Функционально, однако, это работает так же, хотя и немного сложнее, поскольку ГЛОБАЛЬНЫЕ переменные недоступны в каждом клоне рабочего процесса, поэтому для управления критическими секциями используется файл межпроцессного взаимодействия и элементарный семафор стаи. Разветвление от BASH, конечно, является основным ответом здесь, но я чувствую, что люди знают это, но действительно хотят управлять тем, что порождается, а не просто разветвлять и забывать об этом. Это демонстрирует способ управления до 200 экземплярами разветвленных процессов, каждый из которых обращается к одному ресурсу. Ясно, что это перебор, но мне понравилось писать, поэтому я продолжил. Соответственно увеличьте размер вашего терминала. Надеюсь, вы найдете это полезным.

Если ваше приложение не работает или вам просто нужна дополнительная информация, вам пригодятся эти 20 команд.

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

Являетесь ли вы новым разработчиком или хотите управлять своим собственным приложением, следующие 20 основных команд системного администратора помогут вам лучше понять свои приложения. Они также могут помочь вам описать проблемы системным администраторам, устранив причины, по которым приложение может работать локально, но не на удаленном узле. Эти команды применяются к средам разработки Linux, контейнерам, виртуальным машинам (ВМ) и «голом железу».

1. завиток

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

Опция -I показывает информацию заголовка, а опция -s отключает текст ответа. Проверка конечной точки вашей базы данных с локального рабочего стола:

Так в чем может быть проблема? Проверьте, может ли ваше приложение получить доступ к другим местам помимо базы данных с хоста приложения:

Похоже, все в порядке. Теперь попробуйте получить доступ к базе данных с хоста приложения.Ваше приложение использует имя хоста базы данных, поэтому попробуйте сначала:

Это указывает на то, что ваше приложение не может разрешить базу данных, поскольку URL-адрес базы данных недоступен или хост (контейнер или виртуальная машина) не имеет сервера имен, который он может использовать для разрешения имени хоста.

2. python -m json.tool/jq

После запуска curl выходные данные вызова API могут быть трудночитаемыми. Иногда вы хотите красиво распечатать вывод JSON, чтобы найти конкретную запись. В Python есть встроенная библиотека JSON, которая может помочь в этом. Вы используете python -m json.tool для отступа и организации JSON. Чтобы использовать модуль Python JSON, передайте вывод файла JSON в команду python -m json.tool.

Чтобы использовать библиотеку Python, передайте вывод в Python с параметром -m (модуль).

Для расширенного анализа JSON можно установить jq. jq предоставляет несколько параметров, которые извлекают определенные значения из входных данных JSON. Чтобы красиво распечатать, как в модуле Python выше, просто примените jq к выходным данным.

ls выводит список файлов в каталоге. Сисадмины и разработчики выдают эту команду довольно часто. В пространстве контейнера эта команда может помочь определить каталог и файлы вашего образа контейнера. Помимо поиска ваших файлов, ls может помочь вам проверить ваши разрешения. В приведенном ниже примере вы не можете запустить myapp из-за проблем с разрешениями. Когда вы проверяете разрешения с помощью ls -l, вы понимаете, что разрешения не имеют "x" в -rw-r--r--, которые доступны только для чтения и записи.

4. хвост

Опция -f указывает на опцию "follow", которая выводит строки журнала по мере их записи в файл. В примере есть фоновый скрипт, который обращается к конечной точке каждые несколько секунд, и в журнале регистрируется запрос. Вместо того, чтобы следить за журналом в режиме реального времени, вы также можете использовать tail для просмотра последних 100 строк файла с параметром -n.

5. кот

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

В приведенном выше примере проверяется, есть ли в вашем приложении Python Flask Flask в качестве зависимости.

6. грэп

grep ищет шаблоны файлов. Если вы ищете определенный шаблон в выводе другой команды, grep выделяет соответствующие строки. Используйте эту команду для поиска файлов журналов, определенных процессов и т. д. Если вы хотите увидеть, запускается ли Apache Tomcat, вы можете быть ошеломлены количеством строк. Передавая эти выходные данные команде grep, вы изолируете строки, указывающие на запуск сервера.

Команда ps, входящая в состав пакета procps-ng, который содержит полезные команды для исследования идентификаторов процессов, показывает состояние запущенного процесса. Используйте эту команду, чтобы определить запущенное приложение или подтвердить ожидаемый процесс. Например, если вы хотите проверить работающий веб-сервер Tomcat, вы используете команду ps с ее параметрами для получения идентификатора процесса Tomcat.

Для большей удобочитаемости используйте команду ps и передайте ее в grep.

8. окружение

env позволяет вам устанавливать или печатать переменные среды. Во время устранения неполадок может оказаться полезным проверить, не мешает ли неправильная переменная среды запуску вашего приложения. В приведенном ниже примере эта команда используется для проверки переменных среды, установленных на хосте вашего приложения.

Обратите внимание, что приложение использует Python и имеет переменные среды для подключения к базе данных MongoDB.

9. топ

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

Вашему приложению действительно не хватает памяти? Для подтверждения используйте top, чтобы определить, сколько ЦП и памяти потребляет ваше приложение. При выдаче top вы замечаете, что приложение Python использует большую часть ЦП, при этом его использование памяти растет, и подозреваете, что это ваше приложение. Пока он работает, вы нажимаете клавишу «C», чтобы увидеть полную команду и выполнить обратный инжиниринг, если процесс является вашим приложением. Оказывается, это ваше приложение, интенсивно использующее память (memeater.py). Когда вашему приложению не хватает памяти, система завершает его с ошибкой нехватки памяти (OOM).

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

10. нетстат

11. IP

Если IP-адрес не работает на вашем хосте, его необходимо установить с пакетом iproute2. Адрес подкоманды (или просто ip a для краткости) показывает интерфейсы и IP-адреса хоста вашего приложения. Вы используете IP-адрес для проверки IP-адреса вашего контейнера или хоста. Например, когда ваш контейнер подключен к двум сетям, IP-адрес может показать, какой интерфейс подключается к какой сети. Для простой проверки вы всегда можете использовать команду ip address, чтобы получить IP-адрес хоста. В приведенном ниже примере показано, что контейнер веб-уровня имеет IP-адрес 172.17.0.2 на интерфейсе eth0.

12. лсоф

Имя открытого файла в списке открытых файлов помогает определить источник процесса, в частности Apache.

13. дф

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

Опция -h выводит информацию в удобочитаемом формате. По умолчанию, как и в примере, df предоставляет результаты для всего, что находится в корневом каталоге, но вы также можете ограничить результаты, указав каталог как часть вашей команды (например, df -h /home).

14. дю

Чтобы получить более подробную информацию о том, какие файлы занимают место на диске в каталоге, вы можете использовать команду du. Например, если вы хотите узнать, какой журнал занимает больше всего места в каталоге /var/log, вы можете использовать du с параметром -h (удобочитаемый) и параметром -s для общего размера.

Приведенный выше пример показывает, что самым большим каталогом в /var/log является /var/log/audit. Вы можете использовать du в сочетании с df, чтобы определить, что использует дисковое пространство на хосте вашего приложения.

15. идентификатор

Чтобы проверить пользователя, запускающего приложение, используйте команду id, чтобы вернуть идентификатор пользователя. В приведенном ниже примере Vagrant используется для тестирования приложения и изоляции его среды разработки. После того, как вы войдете в окно Vagrant, если вы попытаетесь установить HTTP-сервер Apache (зависимость), система укажет, что вы не можете выполнить команду от имени пользователя root. Чтобы проверить своего пользователя и группу, введите команду id и обратите внимание, что вы работаете как «бродячий» пользователь в «бродячей» группе.

Чтобы исправить это, вы должны запустить команду от имени суперпользователя, который предоставляет повышенные привилегии.

16. чмод

При первом запуске бинарного файла приложения на хосте может появиться сообщение об ошибке "Отказано в доступе". Как видно из примера для ls, вы можете проверить разрешения двоичного файла вашего приложения.

Это показывает, что у вас нет прав на выполнение (без "x") для запуска двоичного файла. chmod может исправить разрешения, чтобы ваш пользователь мог запускать двоичный файл.

Как показано в примере, это обновляет разрешения с правами на выполнение. Теперь, когда вы пытаетесь выполнить свой двоичный файл, приложение не выдает ошибку отказа в разрешении. Chmod также может быть полезен, когда вы загружаете двоичный файл в контейнер. Это гарантирует, что ваш контейнер имеет правильные разрешения для выполнения вашего двоичного файла.

17. копать / nslookup

Сервер доменных имен (DNS) помогает преобразовать URL в набор серверов приложений. Однако вы можете обнаружить, что URL-адрес не разрешается, что вызывает проблемы с подключением для вашего приложения. Например, скажем, вы пытаетесь получить доступ к своей базе данных по URL-адресу mydatabase с хоста вашего приложения. Вместо этого вы получаете сообщение об ошибке «не удается разрешить». Чтобы устранить неполадки, попробуйте использовать dig (утилита поиска DNS) или nslookup (запрос серверов имен в Интернете), чтобы выяснить, почему приложение не может разрешить базу данных.

Использование nslookup показывает, что mydatabase не может быть разрешена. Попытка решить с помощью dig приводит к тому же результату.

Эти ошибки могут быть вызваны разными причинами. Если вы не можете отладить основную причину, обратитесь к системному администратору для дальнейшего расследования. При локальном тестировании эта проблема может указывать на то, что серверы имен вашего хоста настроены неправильно. Чтобы использовать эти команды, вам потребуется установить пакет BIND Utilities.

18. брандмауэр-cmd

Традиционно брандмауэры в Linux настраивались с помощью команды iptables, и, хотя она сохраняет свое повсеместное распространение, ее фактически заменила nftables. Дружественным интерфейсом для nftables, который по умолчанию поставляется со многими дистрибутивами, является firewall-cmd. Эта команда помогает вам настроить правила, определяющие, какой сетевой трафик, как исходящий, так и входящий, разрешает ваш компьютер. Эти правила можно сгруппировать в зоны, чтобы вы могли быстро и легко переходить от одного набора правил к другому в зависимости от ваших требований.

Синтаксис команды прост. Вы используете команду и некоторое количество опций, каждая из которых названа таким образом, чтобы помочь вам составить почти удобочитаемое предложение. Например, чтобы узнать, в какой зоне вы сейчас находитесь:

В этом примере на вашем компьютере есть два сетевых устройства, одно из которых назначено для корпоративной зоны, а другое — для DMZ-зоны.

Чтобы узнать, что разрешено для каждой зоны, можно использовать параметр --list-all:

Добавить сервисы так же просто:

Взаимодействие с firewall-cmd интуитивно понятно, и он имеет обширный набор предопределенных служб, а также возможность напрямую писать правила nft. Начав использовать firewall-cmd, вы можете загрузить нашу памятку firewall-cmd, которая поможет вам запомнить наиболее важные параметры.

19. статус

Обычно вы обнаружите, что SELinux (модуль безопасности Linux) применяется на хосте приложений, управляемом предприятием. SELinux обеспечивает доступ с минимальными привилегиями к процессам, запущенным на хосте, предотвращая доступ потенциально вредоносных процессов к важным файлам в системе. В некоторых ситуациях приложению требуется доступ к определенному файлу, но оно может вызвать ошибку. Чтобы проверить, блокирует ли SELinux приложение, используйте tail и grep для поиска сообщения об отказе в журнале /var/log/audit. В противном случае вы можете проверить, включен ли на компьютере SELinux, используя sestatus.

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

20. история

Когда вы вводите так много команд для тестирования и отладки, вы можете забыть о самых полезных! В каждой оболочке есть вариант команды history. Он показывает историю команд, которые вы ввели с начала сеанса. Вы можете использовать историю, чтобы регистрировать, какие команды вы использовали для устранения неполадок вашего приложения. Например, когда вы публикуете историю в ходе этой статьи, она показывает различные команды, с которыми вы экспериментировали и изучили.

Что делать, если вы хотите выполнить команду из предыдущей истории, но не хотите вводить ее повторно? Использовать ! перед номером команды для повторного выполнения.

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

Эта статья была впервые опубликована в июле 2017 года и обновлена редактором.

В этой статье я представляю несколько приемов для обработки ошибок. Некоторые из них строго не подпадают под категорию обработки ошибок (реактивный способ обработки непредвиденных обстоятельств), а также некоторые приемы, позволяющие избежать ошибок до того, как они произойдут.< /p>

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

Скажем, у вас есть задание cron в каждой из ваших систем Linux, и у вас есть сценарий для сбора информации об оборудовании из каждой:

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

Вот несколько возможных причин, по которым что-то пошло не так:

Ваш отчет не был выполнен, поскольку сервер не работал
Не удалось создать каталог для сохранения файлов
Инструменты, необходимые для запуска скрипта, отсутствуют
Вы не можете получить отчет, потому что ваш удаленный компьютер дал сбой
Один или несколько отчетов повреждены

В текущей версии скрипта есть проблема — он будет выполняться от начала до конца, с ошибками или нет:

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

Ядерный вариант: отказ жесткий, отказ быстрый

Правильный способ обработки ошибок – проверить, успешно ли завершилась программа, используя коды возврата. Это звучит очевидно, но коды возврата, целое число, хранящееся в bash $? или $! переменные, имеют иногда более широкое значение. Страница руководства bash сообщает вам:

Для целей оболочки команда, завершающаяся с нулевым
статусом выхода, выполнена успешно. Нулевой статус выхода указывает на успех.
Ненулевой статус выхода указывает на сбой. Когда команда
заканчивается фатальным сигналом N, bash использует значение 128+N в качестве
статуса выхода.

Дополнительные ресурсы по Linux

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

Если вы добавите set -o errexit в свой скрипт, с этого момента он прервет выполнение, если существует какая-либо команда с кодом != 0 . Но errexit не используется при выполнении функций внутри условия if, поэтому вместо запоминания этого исключения я предпочитаю явную обработку ошибок.

Посмотрите на вторую версию скрипта. Это немного лучше:

Вот что изменилось:

В строках 11 и 12 я включаю трассировку ошибок и добавляю «ловушку», чтобы сообщить пользователю, что произошла ошибка и впереди турбулентность. Вместо этого вы можете убить свой сценарий здесь, я покажу вам, почему это может быть не лучшим решением.
Строка 20, если каталог не существует, попробуйте создать его в строке 21. Если создать каталог не удалось, выйдите с ошибкой.
В строке 27 после запуска каждого фонового задания я фиксирую PID и связываю его с машиной (соотношение 1:1).
В строках 33–35 я жду завершения задачи scp, получаю код возврата и, если это ошибка, прерываю ее.
В строке 37 я проверяю, может ли файл быть проанализирован, в противном случае я завершаю работу с ошибкой.

Итак, как теперь выглядит обработка ошибок?

Как видите, эта версия лучше обнаруживает ошибки, но она очень неумолима. Кроме того, он не обнаруживает все ошибки, не так ли?

Когда вы застряли и хотите, чтобы у вас был будильник

Код выглядит лучше, за исключением того, что иногда scp мог зависнуть на сервере (при попытке скопировать файл), потому что сервер слишком занят, чтобы отвечать, или просто находится в плохом состоянии.

Еще один пример — попытаться получить доступ к каталогу через NFS, где $HOME смонтирован с сервера NFS:

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

Тайм-аут — это решение. И на помощь приходит тайм-аут GNU:

Здесь вы пытаетесь регулярно убивать (сигнал TERM) процесс красиво через 10,0 секунд после его запуска. Если он все еще работает через 20,0 секунд, отправьте сигнал KILL ( kill -9 ). Если вы сомневаетесь, проверьте, какие сигналы поддерживаются вашей системой (например, kill -l ).

Если это непонятно из моего диалога, посмотрите на сценарий для большей ясности.

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

Какие изменения?:

Между строками 16–22 проверьте наличие всех необходимых инструментов зависимостей. Если он не может выполниться, тогда «Хьюстон, у нас проблема».
Создана функция remote_copy, которая использует тайм-аут, чтобы гарантировать, что scp завершится не позднее 45,0 секунд (строка 33).
Добавлено время ожидания соединения 5 секунд вместо TCP по умолчанию (строка 37).
Добавлена повторная попытка в scp в строке 38: 3 попытки с ожиданием 1 секунда между каждой.

Есть и другие способы повторить попытку при возникновении ошибки.

В ожидании конца света: как и когда повторить попытку

Вы заметили, что для команды scp добавлена повторная попытка. Но это повторение только для неудачных подключений, что, если команда завершится ошибкой в середине копирования?

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

Вот изменения в remote_copy , если кратко (четвертая версия):

Как это выглядит сейчас? В этом прогоне у меня одна система не работает (mac-pro-1-1) и одна система без файла (macmini2).Вы можете видеть, что копия с сервера dmaf5 работает сразу, но для двух других есть повторная попытка в течение случайного времени между 1 и 60 секундами перед выходом:

Если я потерплю неудачу, мне придется делать это снова и снова? Использование контрольной точки

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

Вы можете на один день создать небольшой «кэш состояния», в который будут записываться только успешные операции обработки на каждом компьютере. Если там есть система, не утруждайте себя повторной проверкой на этот день.

Некоторые программы, такие как Ansible, делают что-то подобное и позволяют вам повторить плейбук на ограниченном количестве машин после сбоя ( --limit @/home/user/site.retry ).

В новой версии (пятой версии) скрипта есть код для записи состояния копии (строки 15–33):

Вы заметили ловушку в строке 22? Если сценарий прерывается (убивается), я хочу убедиться, что весь кеш недействителен.

А затем добавьте эту новую вспомогательную логику в функцию remote_copy (строки 52–81):

При первом запуске распечатывается новое новое сообщение для каталога кеша:

Если вы запустите его снова, то скрипт узнает, что dma5f готов к работе, и не нужно повторять попытку копирования:

Представьте, насколько это ускоряется, когда у вас есть больше машин, которые не нужно повторно посещать.

Оставляя крохи позади: что записывать, как записывать и подробный вывод

Если вы похожи на меня, мне нравится немного контекста, с которым можно сопоставить, когда что-то идет не так. Операторы эха в скрипте хороши, но что, если бы вы могли добавить к ним отметку времени.

Если вы используете logger , вы можете сохранить вывод в journalctl для последующего просмотра (даже агрегирования с другими инструментами). Самое приятное то, что вы сразу же демонстрируете мощь journalctl.

Поэтому вместо того, чтобы просто делать echo , вы также можете добавить вызов logger, используя новую функцию bash под названием « сообщение »:

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

Так чем же это полезно? Что ж, вы могли получать сообщения между 13:26 и 13:27, только ошибки ( priority=0 ) и только для нашего скрипта ( collect_data_from_servers.v6.sh ), вывод в формате JSON:

Поскольку это структурированные данные, другие сборщики журналов могут просматривать все ваши компьютеры, объединять журналы сценариев, и тогда у вас есть не только данные, но и информация.

Вы можете ознакомиться со всей шестой версией сценария.

Не торопитесь заменять данные, пока не проверите их.

Если вы заметили с самого начала, я снова и снова копировал поврежденный файл JSON:

Это легко предотвратить. Скопируйте файл во временное место, и если файл поврежден, не пытайтесь заменить предыдущую версию (и оставьте неверную версию для проверки. Строки 99-107 седьмой версии скрипта):

Выберите правильные инструменты для задачи и подготовьте свой код с первой строки

Одним из очень важных аспектов обработки ошибок является правильное кодирование. Если у вас плохая логика в вашем коде, никакая обработка ошибок не сделает его лучше. Чтобы это было кратко и имело отношение к bash, ниже я дам вам несколько советов.

Вы должны ВСЕГДА проверять синтаксис ошибок перед запуском скрипта:

Серьезно. Он должен быть таким же автоматическим, как и любой другой тест.

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

Используйте ShellCheck для проверки скриптов bash

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

Если вам интересно, финальная версия скрипта после прохождения ShellCheck находится здесь. Идеальная чистота.

Вы заметили что-то с фоновыми процессами scp

Карьерный совет

Возможно, вы заметили, что если вы закроете скрипт, он оставит несколько разветвленных процессов. Это нехорошо, и это одна из причин, по которой я предпочитаю использовать такие инструменты, как Ansible или Parallel, для решения задач такого типа на нескольких хостах, позволяя фреймворкам выполнять правильную очистку за меня. Конечно, вы можете добавить дополнительный код для обработки этой ситуации.

Этот bash-скрипт потенциально может создать форк-бомбу. Он не контролирует, сколько процессов должно запускаться одновременно, что является большой проблемой в реальной производственной среде. Кроме того, существует ограничение на количество одновременных сеансов ssh, которые вы можете иметь (не говоря уже о потреблении полосы пропускания). Опять же, я написал этот вымышленный пример на bash, чтобы показать вам, как вы всегда можете улучшить программу, чтобы она лучше обрабатывала ошибки.

<р>1. Вы должны проверить код возврата ваших команд. Это может означать решение повторить попытку до тех пор, пока временное состояние не улучшится, или закоротить весь сценарий.
2. Говоря о переходных условиях, вам не нужно начинать с нуля. Вы можете сохранить статус успешных задач, а затем повторить попытку с этого момента.
3. Баш «ловушка» — ваш друг. Используйте его для очистки и обработки ошибок.
4. При загрузке данных из любого источника исходите из того, что они повреждены. Никогда не перезаписывайте свой хороший набор данных свежими данными, пока не выполните некоторые проверки целостности.
5. Воспользуйтесь преимуществами journalctl и настраиваемых полей. Вы можете выполнять сложный поиск проблем и даже отправлять эти данные в агрегаторы журналов.
6. Вы можете проверить статус фоновых задач (включая подоболочки). Просто не забудьте сохранить PID и подождать.
7. И, наконец: используйте помощник Bash lint, такой как ShellCheck. Вы можете установить его в свой любимый редактор (например, VIM или PyCharm). Вы будете удивлены, сколько ошибок в сценариях Bash остаются незамеченными.

Читайте также: