По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Понимать состояние ваших серверов с точки зрения их загрузки и производительности - крайне важная задача. В этой статье мы опишем несколько самых популярных методов для проверки и мониторинга загрузки ЦПУ на 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 при отладке и экспериментах, а для постоянного контроля держать запущенным скрипт.
img
Если Вы наконец поняли, что повсюду окружены контейнерами и обнаружили, что они решают массу проблем и имеют много преимуществ: Контейнеры вездесущи - ОС, версии библиотек, конфигурации, папки и приложения помещаются в контейнер. Вы гарантируете, что та же самая задача, которая была протестирована в QA, достигнет производственной среды с таким же поведением. Контейнеры упрощены - объем памяти контейнера невелик. Вместо сотен или тысяч мегабайт контейнер будет выделять память только для основного процесса. Контейнеры быстрые - Вы можете запустить контейнер для начала работы так же быстро, как типичный процесс Linux. Вместо минут можно запустить новый контейнер за несколько секунд. Тем не менее, многие пользователи по-прежнему относятся к контейнерам так же, как к типичным виртуальным машинам, и забывают про важную характеристику: они одноразовые. Мантра о контейнерах: “Контейнеры эфемерны”. Эта характеристика заставляет пользователей поменять свое мышление относительно того, как они должны обращаться с контейнерами и управлять ими; и я объясню, чего НЕ следует делать, чтобы продолжать извлекать наилучшие преимущества контейнеров. 10 вещей, которых следует избегать в Docker контейнерах Не хранить данные в контейнерах - контейнер может быть остановлен, удален или заменен. Приложение версии 1.0, работающее в контейнере, может быть легко заменено версией 1.1 без какого-либо неблагоприятного воздействия или потери данных. Поэтому, если нужно сохранить данные, сделайте это на диске. В этом случае следует также позаботиться о том, чтобы два контейнера записывали данные на один и тот же диск, что может привести к повреждению. Убедитесь, что приложения могут записывать данные в хранилище объектов. Не разделять свое приложение на две части - так как некоторые люди видят контейнеры в роли виртуальной машин и поэтому большинство из них склонны думать, что они должны применять свое приложение только в существующих работающих контейнерах. Это может быть справедливо на этапе разработки, на котором Вам необходимо непрерывно разрабатывать и налаживать процесс; но для непрерывной доставки (CD) в QA и производства, Ваше приложение должно быть частью образа. Помните: Контейнеры нельзя изменить. Не создавать большие образы - большой образ будет труднее распространить. Убедитесь в наличии только необходимых файлов и библиотек для запуска приложения/процесса. Не устанавливайте ненужные пакеты и не запускайте обновления (yum update), которые загружают много файлов на новый слой образы. Не использовать однослойный образ - чтобы эффективно пользоваться многоуровневой файловой системой, всегда создавайте собственный базовый слой образы для операционной системы, а также другой слой для определения имени пользователя, слой для установки во время выполнения, слой для конфигурации и, наконец, слой для приложения. Будет проще воссоздать образ, управлять им и использовать его. Не создавать образы из запущенных контейнеров - другими словами, не используйте слово docker commit для создания образа. Этот способ не приносит пользы, и его следует полностью избегать. Всегда используйте полностью воспроизводимый Dockerfile или любой другой S2I (от источника к изображению) подход, и Вы можете отследить изменения в Dockerfile, если сохранить его в хранилище системы управления версиями (git). Не использовать latest (последний) тег – он подобен SNAPSHOT для пользователей Maven. Метки подключаются из-за слоистой файловой природы контейнеров. Вы ведь не хотите иметь сюрпризы при построении образа несколько месяцев, а потом выяснить, что приложение не может быть запущено, так как родительский слой (из-за Dockerfile) был заменен новой версией, которая не является обратно совместимой, или из кэша сборки была получена неправильная "последняя" версия. Тега latest также следует избегать при применении контейнеров в производстве, так как невозможно отследить, какая версия образа выполняется. Не выполнять более одного процесса в одном контейнере - контейнеры идеально подходят для выполнения лишь одного процесса (HTTP, сервер приложений, база данных), но если имеется более одного процесса, могут возникнуть дополнительные проблемы с управлением, извлечением журналов и обновлением их по отдельности. Не хранить учетные данные в виде образов. Используйте переменные среды, ведь для этого не требуется жестко кодировать имя пользователя/пароль в образе. Используйте переменные среды для получения этой информации вне контейнера. Отличный пример этого принципа - образ Постгреса. Не запускать процессы от имени пользователя root - "По умолчанию docker контейнеры выполняются от имени пользователя root. По мере «взросления» docker контейнеров могут стать доступны секретные по умолчанию параметры. На данный момент требуемый root опасен для других и может быть доступен не во всех средах. Ваш образ должен использовать инструкцию USER, чтобы указать пользователя, не являющегося root, для контейнеров, которые будут запускаться". Не полагайтесь на IP-адреса - каждый контейнер имеет свой собственный внутренний IP-адрес, и он может измениться, если вы запустите и остановите контейнер. Если приложению или микросервису требуется связь с другим контейнером, используйте переменные среды для передачи соответствующего имени хоста и порта из одного контейнера в другой.
img
Хочу рассказать, как настроить DHCP Snooping и DAI (Dynamic Arp Inspection). Материал будет полезен начинающим сетевым администраторам. Коротко о технологии DHCP Snooping и DAI Данные функции защищают вашу сеть от подмены DHCP сервера. На коммутаторах вручную настраиваются доверенные порты, которые как правило подключены к маршрутизатору или DHCP серверу. Также доверенными портами назначаются UpLink порты. Другая возможность это Dynamic Arp inspection. Тоже защитная функция, предотвращающая атаку типа Man-in-The-Middle. Это такой вид атаки, когда к вашей сети подключается устройство злоумышленника и, например, объявляет, что IP адрес, принадлежащий авторизованному серверу, принадлежит ему. После этого все данные, которые отправляются на сервер переходят через устройство злоумышленника. Настройка DHCP Snooping и DAI Чтобы включить функцию DHCP Snooping нужно для начала задать доверенные и не доверенные порты. Все порты, к которому подключены конечные пользователи считаются не доверенными. Так как DHCP Snooping и DAI настраиваются в связке я не буду делить это на отдельные части: AccSwitch#conf t AccSwitch(config)# AccSwitch(config)#int ra gi1/0/1-46 AccSwitch(config-if-range)#ip dhcp snooping limit rate 15 AccSwitch(config-if-range)#ip arp inspection limit rate 100 Тут мы задаем количество пакетов, которые должны проходить через не доверенный интерфейс. Обычно такого числа пакетов хватает для получения и обновления IP адреса. Далее настраиваем доверенные интерфейсы: AccSwitch(config)#int ra gi1/0/47-48 AccSwitch(config-if-range)#ip dhcp snooping trust AccSwitch(config-if-range)#ip arp inspection trustПосле этого глобально включаем DHCP Snooping, но НЕ ARP Inspection: AccSwitch(config)#ip dhcp snooping AccSwitch(config)#ip dhcp snooping vlan 200 AccSwitch(config)#no ip dhcp snooping information optionПоследняя команда отключает опцию 82, которая используется коммутатором в DHCP пакетах, идущих от DHCP клиента через коммутатор к DHCP серверу. Опция 82 содержит информацию об устройстве (например, MAC адрес коммутатора) и информацию о номере порта с которого идет запрос для того, чтобы сервер, опираясь на полученную информацию, смог выдать IP адрес DHCP клиенту из нужной подсети. Далее переходим к настройке DAI. Если у вас в сети есть устройства со статическим IP адресом, то нужно как-то сказать коммутатору, чтобы порты, к которым подключены такие устройства не проверялись. Для этого существуют ARP списки доступа. Важно, чтобы название access-list-а было именно DAI. По личному опыту знаю, что в противном случае нужно вводить дополнительные команды. А так все работает без лишних команд. AccSwitch(config)# AccSwitch(config)# arp access-list DAI AccSwitch(config-arp-nacl)# permit ip host 192.168.200.25 mac host 0017.6111.a309 В таком порядке добавляем IP адреса всех устройств со статическим IP. Дополнительно можно настроить Sorce Guard. Этим мы конкретное устройство к порту коммутатора, таким образом другое устройство подключенное к указанному порту не сможет выдать себя за привязанное: AccSwitch(config)#ip source binding 0017.6111.a309 vlan 200 192.168.200.14 interface Gi1/0/5 Также под не доверенными интерфейсами нужно ввести команду ip verify source, которые проверяет источник запросов. Важно! После всех настроек, приведенных выше, ждем сутки-две чтобы DHCP Snooping таблица заполнилась. В противном случае DAI будет блокировать все запросы, и пользователи не смогут работать в сети. Когда таблица заполнена включаем arp inspection: AccSwitch(config)#ip arp inspection vlan 200
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59