Заметил неожиданное различие между системой Ubuntu и Debian, хотя казалось бы в этом контексте его быть не должно. Для замены шлюза по умолчанию в Ubuntu можно сделать так:
Сначала добавили новый, потом удалили старый. Команды нормально отработают. Заменяют шлюз 172.31.112.1 на 172.31.112.5. Та же самая последовательность команд на Debian не сработает:
Там сработает другая и более правильная, которую имеет смысл использовать в обеих системах.
И дело тут не в версии утилиты ip. Специально проверил на Debian 12, где iproute2-6.1.0 и более старой Ubuntu 22, где версия старее - iproute2-5.15.0. Различия судя по всему системные.
А вообще в Ubuntu такое удобно делать через netplan. Меняем шлюз, потом на всякий случай проверяем конфигурацию и применяем её.
Если что-то не так, и связь потеряна, настройки откатятся обратно. Я хоть и не особо люблю Ubuntu за её частые изменения, которые не всегда нужны, но конкретно netplan удобен именно вот в этом
Лично мне формат конфигурационного файла
Не хватает проверки изменений перед их применением. Когда настраиваешь сеть на арендованных дедиках с Proxmox, почти всегда приходится менять этот файл с сетевыми настройками. И ошибка в них зачастую фатальна. Можно потерять доступ к серверу, если, к примеру, арендуешь подсеть внешних IP адресов и делаешь на них бридж, чтобы прокидывать реальные адреса виртуалкам. Поэтому я всегда эти вещи делаю сразу после установки системы и потом стараюсь настройки сети вообще не трогать. Чаще всего это и не нужно, если уже настроил и проверил.
Кстати, netplan можно установить в Debian, если очень хочется. Например, если в инфраструктуре используются обе системы, и Debian, и Ubuntu.
Дальше рисуем конфигурацию для netplan и применяем:
Заметил, что если у вас в системе используется динамический IP адрес от DHCP сервера, то
❓Вам какой формат сетевых настроек больше нравится?
◽️Как в Debian
◽️Как в Ubuntu
◽️Как в RHEL и форках в
Не знаю, как сейчас в RHEL сеть настраивается. Не смотрел свежие версии. В старых всегда network-scripts использовал. А удобнее всего мне формат interfaces. Люблю, когда всё в одном файле, а не по нескольким раскидано.
#linux
# ip route add default via 172.31.112.5# ip route del default via 172.31.112.1Сначала добавили новый, потом удалили старый. Команды нормально отработают. Заменяют шлюз 172.31.112.1 на 172.31.112.5. Та же самая последовательность команд на Debian не сработает:
# ip route add default via 172.31.112.5RTNETLINK answers: File existsТам сработает другая и более правильная, которую имеет смысл использовать в обеих системах.
# ip route replace default via 172.31.112.5И дело тут не в версии утилиты ip. Специально проверил на Debian 12, где iproute2-6.1.0 и более старой Ubuntu 22, где версия старее - iproute2-5.15.0. Различия судя по всему системные.
А вообще в Ubuntu такое удобно делать через netplan. Меняем шлюз, потом на всякий случай проверяем конфигурацию и применяем её.
# netplan tryЕсли что-то не так, и связь потеряна, настройки откатятся обратно. Я хоть и не особо люблю Ubuntu за её частые изменения, которые не всегда нужны, но конкретно netplan удобен именно вот в этом
try. В Debian никаких проверок нет. Если ошибся в конфигурации сети, то узнаешь об этом уже по факту, когда перезагрузишься или перезапустишь сеть через:# systemctl restart networkingЛично мне формат конфигурационного файла
/etc/network/interfaces в Debian максимально удобен и понятен. Не знаю, зачем тут нужен yaml или что-то ещё. Открыл, посмотрел, поправил. Не надо никакие пробелы и отступы ловить. Все интерфейсы в одном месте.Не хватает проверки изменений перед их применением. Когда настраиваешь сеть на арендованных дедиках с Proxmox, почти всегда приходится менять этот файл с сетевыми настройками. И ошибка в них зачастую фатальна. Можно потерять доступ к серверу, если, к примеру, арендуешь подсеть внешних IP адресов и делаешь на них бридж, чтобы прокидывать реальные адреса виртуалкам. Поэтому я всегда эти вещи делаю сразу после установки системы и потом стараюсь настройки сети вообще не трогать. Чаще всего это и не нужно, если уже настроил и проверил.
Кстати, netplan можно установить в Debian, если очень хочется. Например, если в инфраструктуре используются обе системы, и Debian, и Ubuntu.
# apt install netplan.io openvswitch-switch# systemctl enable --now systemd-networkd# apt remove ifupdownДальше рисуем конфигурацию для netplan и применяем:
# netplan generate# netplan tryЗаметил, что если у вас в системе используется динамический IP адрес от DHCP сервера, то
netplan try будет работать некорректно. Он будет получать новый IP адрес, если на DHCP сервере нет привязки этой системы на выдачу одного и того же IP адреса, и в итоге вас будет отключать от системы. Но откатить обратно сетевые настройки уже не получится. Система получит новый IP адрес и он применится. Вам придётся вручную к ней подключаться. Так что в любом случае надо аккуратно к изменениям сетевых настроек подходить.❓Вам какой формат сетевых настроек больше нравится?
◽️Как в Debian
/etc/network/interfaces◽️Как в Ubuntu
/etc/netplan/*.yaml◽️Как в RHEL и форках в
/etc/sysconfig/network-scripts/ifcfg-*Не знаю, как сейчас в RHEL сеть настраивается. Не смотрел свежие версии. В старых всегда network-scripts использовал. А удобнее всего мне формат interfaces. Люблю, когда всё в одном файле, а не по нескольким раскидано.
#linux
👍122👎5
В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
Вы должны увидеть строки с упоминанием файла
Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
vm-109-disk-0.qcow2 и этот файл по какой-то причине был удалён в момент работы VM. То есть машина работает, а файла уже нет. Поверяем, реально ли файл удалён, но всё ещё открыт его дескриптор:# lsof | grep '(deleted)'kvm 402083 root 14u REG 0,39 21478375424 17 /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Вы должны увидеть строки с упоминанием файла
/var/lib/vz/images/109/vm-109-disk-0.qcow2. Значит, он реально ещё не удалён. Его держит процесс с пидом 402083. Проверяем это:# ls -l /proc/402083/fd | grep deletedlrwx------ 1 root root 64 Aug 3 21:16 14 -> /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
# cp /proc/402083/fd/14 /var/lib/vz/images/109/vm-109-disk-0.qcow2Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Server Admin
Бэкап виртуальных машин KVM без остановки VM
Описание различных подходов к бэкапу виртуальных машин в kvm в зависимости от типа дисков. Представлен скрипт для автоматического бэкапа.
5👍154👎4
На прошлой неделе читал статью про ansible-cmdb. Понравился инструмент. Раньше про него не слышал. Он довольно просто устроен, особенно для тех, кто знает и регулярно использует Ansible в инфраструктуре. Собственно, ansible-cmdb работает на базе Ansible.
Поясню, для тех, кто не в курсе и не работает с Ansible. У неё есть список хостов, куда она имеет доступ по SSH. Соответственно, с помощью Ansible можно ходить по хостам, что-то там делать, собирать информацию. Ansible-cmdb использует вывод модуля setup, который заходит на хосты и собирает о них информацию в так называемые ansible_facts. A ansible-cmdb берёт эту информацию и оформляет в наглядную html страницу.
Как я уже сказал, если вы уже используете Ansible, вам ничего пояснять и настраивать не надо. Просто берёте файл с инвентарём, проходите по нему модулем setup и строите отчёт примерно так:
Теперь расскажу, как собрать информацию о хостах для тех, кто вообще не знаком и не настраивал Ansible. Я не буду рассказывать, как с ней работать, а просто по шагам покажу, как вам собрать информацию со своих хостов, даже если вы не хотите изучать и далее использовать Ansible. Хотя, разумеется, современному админу или девопсу крайне желательно уметь с ней работать.
Настраивать всё буду в Debian 12. Рекомендую использовать для этого отдельную виртуалку или контейнер. Ставим необходимые пакеты:
У ansible-cmdb есть собранный deb пакет. Я изначально использовал его. Но так и не смог заставить работать. Я не знаю, что там за версия python нужна, но у меня постоянно были какие-то ошибки в коде. Залез в репозиторий, в Issues, увидел там похожие ошибки и решение в виде установки через pip, а не из пакета.
Поставил в итоге следующим образом. Это не рекомендованный способ, но для демонстрации работы и простоты делаю так. Когда разберётесь и решите, что вам этот инструмент нужен, устанавливайте и запускайте его через venv. А пока ставим:
Теперь нам нужно подготовить конфигурацию ansible. Добавляю минимальную конфигурацию в файл
И создаю так называемый инвентарь
Передаю в переменную конфигурацию Ansible:
Создаю сертификат, по которому буду подключаться к хостам:
Копирую его на хосты в authorized_keys:
Проверяю, видит ли ansible хосты в инвентаре, всё ли верно настроено:
Всё в порядке, собираем факты:
Если всё в порядке, и в директории появились текстовые файлы с информацией о хостах, то строим по ним html страничку:
Копируем overview.html к себе на компьютер и смотрим браузером. Получили наглядный список, где в выпадающем списке подробная информация о хостах.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #ansible
Поясню, для тех, кто не в курсе и не работает с Ansible. У неё есть список хостов, куда она имеет доступ по SSH. Соответственно, с помощью Ansible можно ходить по хостам, что-то там делать, собирать информацию. Ansible-cmdb использует вывод модуля setup, который заходит на хосты и собирает о них информацию в так называемые ansible_facts. A ansible-cmdb берёт эту информацию и оформляет в наглядную html страницу.
Как я уже сказал, если вы уже используете Ansible, вам ничего пояснять и настраивать не надо. Просто берёте файл с инвентарём, проходите по нему модулем setup и строите отчёт примерно так:
# mkdir out# ansible -m setup --tree out/ all# ansible-cmdb out/ > overview.htmlТеперь расскажу, как собрать информацию о хостах для тех, кто вообще не знаком и не настраивал Ansible. Я не буду рассказывать, как с ней работать, а просто по шагам покажу, как вам собрать информацию со своих хостов, даже если вы не хотите изучать и далее использовать Ansible. Хотя, разумеется, современному админу или девопсу крайне желательно уметь с ней работать.
Настраивать всё буду в Debian 12. Рекомендую использовать для этого отдельную виртуалку или контейнер. Ставим необходимые пакеты:
# apt install python3-pip ansibleУ ansible-cmdb есть собранный deb пакет. Я изначально использовал его. Но так и не смог заставить работать. Я не знаю, что там за версия python нужна, но у меня постоянно были какие-то ошибки в коде. Залез в репозиторий, в Issues, увидел там похожие ошибки и решение в виде установки через pip, а не из пакета.
Поставил в итоге следующим образом. Это не рекомендованный способ, но для демонстрации работы и простоты делаю так. Когда разберётесь и решите, что вам этот инструмент нужен, устанавливайте и запускайте его через venv. А пока ставим:
# pip install ansible-cmdb --break-system-packages# ln -s /usr/bin/python3 /usr/bin/pythonТеперь нам нужно подготовить конфигурацию ansible. Добавляю минимальную конфигурацию в файл
~/.ansible/ansible.cfg[defaults]home = ~/.ansible/inventory = ~/.ansible/inventory.yamlremote_user = rootgather_facts = Trueprivate_key_file = ~/.ssh/id_ed25519host_key_checking = FalseИ создаю так называемый инвентарь
~/.ansible/inventory.yaml в терминологии Ansible со списком серверов, для которых будем делать отчёт. all: hosts: Debian12-VPS: ansible_host: 127.0.0.1 ansible_port: 22 Debian12-CT: ansible_host: 10.20.1.24 ansible_port: 22 Ubuntu24-CT: ansible_host: 10.20.1.21 ansible_port: 22Передаю в переменную конфигурацию Ansible:
# export ANSIBLE_CONFIG="$HOME/.ansible/ansible.cfg"Создаю сертификат, по которому буду подключаться к хостам:
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"Копирую его на хосты в authorized_keys:
# ssh-copy-id root@127.0.0.1# ssh-copy-id root@10.20.1.24# ssh-copy-id root@10.20.1.21Проверяю, видит ли ansible хосты в инвентаре, всё ли верно настроено:
# ansible -i inventory.yaml all --list-hosts Debian12-VPS Debian12-CT Ubuntu24-CTВсё в порядке, собираем факты:
# mkdir ~/.ansible/out# ansible -m setup --tree ~/.ansible/out allЕсли всё в порядке, и в директории появились текстовые файлы с информацией о хостах, то строим по ним html страничку:
# ansible-cmdb ~/.ansible/out > overview.htmlКопируем overview.html к себе на компьютер и смотрим браузером. Получили наглядный список, где в выпадающем списке подробная информация о хостах.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #ansible
2👍151👎3
Вспомнил про одну необычную утилиту из мира консоли Linux. Сначала даже не был уверен, что не писал о ней ранее. Оказалось, что реально не писал, только пару упоминаний мельком сделал. Речь пойдёт о faketime. Вспомнил, когда скрипты пересматривал к утренней публикации. Искал что-то для примера в прикреплённой картинке.
Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться
Приложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:
Передали утилите
Я чаще всего утилиту использую, когда с помощью
Покажу наглядный пример, где можно ошибиться и где я лично ошибался не раз. Простая конструкция:
◽️mtime – время последнего изменения файла
◽️+1 - n*24 часа, в данном случае n=1, то есть 24 часа
Это информация из
Создали файл 28 августа в 14:39, а в 29 августа в 14:40 ничего не находит, хотя мы взяли время более 24 часов вперёд.
Уехали на 48 часов и 1 минуту вперёд и нашли файл. У find есть особенность, и в данном случае +1 это не 24 часа, а 48. А чтобы было именно 24 часа, надо использовать +0:
Faketime позволяет проверить работу своих скриптов, заглянув в будущее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться
faketime. Причём сделать это очень просто, потому что утилита с незапамятных времён живёт в базовых репах:# apt install faketimeПриложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:
# faketime '2025-12-31 23:59:59' dateWed Dec 31 23:59:59 MSK 2025Передали утилите
date указанное время, и она его вывела.Я чаще всего утилиту использую, когда с помощью
find удаляю что-то по меткам времени. Удобно запустить через faketime без удаления, просто чтобы проверить, как отработает поиск. Вообще всё, что связано с удалением, предварительно проверяю и только потом ставлю на исполнение. Иногда в скриптах комментирую строки с удалением, чтобы дождаться полного наполнения данными, чтобы потом прийти, вручную всё отладить и только потом включить ключ с удалением. Иначе рано или поздно из-за ошибки или невнимательности можно наделать дел.Покажу наглядный пример, где можно ошибиться и где я лично ошибался не раз. Простая конструкция:
# find . -type f -mtime +1◽️mtime – время последнего изменения файла
◽️+1 - n*24 часа, в данном случае n=1, то есть 24 часа
Это информация из
man find. Ты ожидаешь, что будут найдены все файлы с датой модификации более суток назад. Проверяем:# touch filename.tar# ls -l-rw-r--r-- 1 root root 0 Aug 28 14:39 filename.tar# faketime '2025-08-29 14:40:00' find . -type f -mtime +1Создали файл 28 августа в 14:39, а в 29 августа в 14:40 ничего не находит, хотя мы взяли время более 24 часов вперёд.
# faketime '2025-08-30 14:40:00' find . -type f -mtime +1./filename.tarУехали на 48 часов и 1 минуту вперёд и нашли файл. У find есть особенность, и в данном случае +1 это не 24 часа, а 48. А чтобы было именно 24 часа, надо использовать +0:
# faketime '2025-08-29 14:40:00' find . -type f -mtime +0./filename.tarFaketime позволяет проверить работу своих скриптов, заглянув в будущее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
2👍167👎3
☝️ Всё новое – хорошо забытое старое.
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Telegram
ServerAdmin.ru
Как и обещал, подготовил заметку по профилированию нагрузки в Linux. Первое, что нужно понимать — для диагностики нужна методика. Хаотичное использование различных инструментов только в самом простом случае даст положительный результат.
Наиболее известные…
Наиболее известные…
1👍185👎2
Я делал заметку про небольшой набор полезных для меня алиасов в консоли bash, которые я использую в повседневной работе в WLS2 на базе Ubuntu в своей рабочей Windows 11. Также я отдельно и подробно описывал один из них, который выводит информацию об IP адресах.
Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:
Передаём на вход имя домена и на выходе получаем краткую информацию по нему:
◽️IP адреса на основе А записей
◽️NS записи
◽️MX записи
За основу взял вот этот скрипт. Он относительно простой. Парсится вывод утилиты host, про которую я отдельно писал ранее. Рекомендую взять на вооружение, регулярно пользуюсь.
Единственное, что я изменил - сделал вывод вместо обычного табличного в json. Мне почему-то так удобнее. Привык уже, возможно из-за подсветки. В общем, вывод сделал такой же, как у других алиасов.
Кстати, попросил ИИ помочь перевести изначальный вывод скрипта в json, напридумывали оба очень длинные потянки. Пришлось самому сделать, потратил 5 минут. Конкретно бесплатный ChatGPT и платный Perplexity AI нагенерировали мне простыню баша с sed и awk. Возможно надо было как-то промпт оформлять, чтобы получить то, что хотелось. Я просто взял две маленькие утилиты, про которые я тут раньше тоже уже писал - jc и jq:
А сам алиас, а точнее функция, выглядит вот так:
Эту строку надо добавить в файл
Хорошо, что я учился ещё в доИИшные времени. Честно говоря, даже не представляю, во что это всё в итоге выльется. Развитие ИИ сумасшедшее. Сам сейчас активно осваиваю и экспериментирую.
Ниже на картинке изначальный вывод и мой обработанный. Второй вариант можно использовать в задачах мониторинга, если каким-то образом наблюдаете за выводимы данными.
#linux #terminal
Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:
$ dinfo yandex.ru{ "Checking the domain 'yandex.ru', please wait...": "", "Domain": "yandex.ru", "IP Address": "77.88.44.55 5.255.255.77 77.88.55.88", "Name Server": "Found 2 NS record", "Name Server 1": "ns1.yandex.ru (213.180.193.1)", "Name Server 2": "ns1.yandex.ru (213.180.193.1)", "Name Server 3": "ns2.yandex.ru (93.158.134.1)", "Name Server 4": "ns2.yandex.ru (93.158.134.1)", "Mail Server": "Found 1 MX record", "Mail Server 1": "mx.yandex.ru (77.88.21.249)"}Передаём на вход имя домена и на выходе получаем краткую информацию по нему:
◽️IP адреса на основе А записей
◽️NS записи
◽️MX записи
За основу взял вот этот скрипт. Он относительно простой. Парсится вывод утилиты host, про которую я отдельно писал ранее. Рекомендую взять на вооружение, регулярно пользуюсь.
Единственное, что я изменил - сделал вывод вместо обычного табличного в json. Мне почему-то так удобнее. Привык уже, возможно из-за подсветки. В общем, вывод сделал такой же, как у других алиасов.
Кстати, попросил ИИ помочь перевести изначальный вывод скрипта в json, напридумывали оба очень длинные потянки. Пришлось самому сделать, потратил 5 минут. Конкретно бесплатный ChatGPT и платный Perplexity AI нагенерировали мне простыню баша с sed и awk. Возможно надо было как-то промпт оформлять, чтобы получить то, что хотелось. Я просто взял две маленькие утилиты, про которые я тут раньше тоже уже писал - jc и jq:
$ view-domain-info.sh -d yandex.ru | jc --kv | jq .А сам алиас, а точнее функция, выглядит вот так:
function dinfo {
bash ~/alias_scripts/view-domain-info.sh -d $1 | jc --kv | jq .
}Эту строку надо добавить в файл
~/.bashrc и потом перечитать: source ~/.bashrc.Хорошо, что я учился ещё в доИИшные времени. Честно говоря, даже не представляю, во что это всё в итоге выльется. Развитие ИИ сумасшедшее. Сам сейчас активно осваиваю и экспериментирую.
Ниже на картинке изначальный вывод и мой обработанный. Второй вариант можно использовать в задачах мониторинга, если каким-то образом наблюдаете за выводимы данными.
#linux #terminal
👍56👎1