company_banner

«Инструментарий системного администратора» или «Как мы работаем»

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

    Итак, что в принципе, должен делать (уметь делать) системный администратор:
    Устанавливать/обновлять/удалять ПО
    Настройку ПО
    Планировать работы
    Документировать
    Мониторить состояние ИТ-систем
    Диагностировать и поддерживать ИТ-системы
    Резервное копирование/архивацию ПО и данных

    Для всего этого есть немало различного ПО, постараемся описать все самое необходимое.

    Окружение (среда)

    С чего начинается работа системного администратора — с выбора удобного окружения. Это не просторный светлый офис и удобный стул, хотя это немаловажно, а выбор операционной системы. Мои коллеги работают на Mac OS X, Windows и Ubuntu. После многих проб и экспериментов с дистрибутивами и разными оболочками рабочего стола (Debian, Kubuntu, Fedora Gnome/Cinnamon) я остановился на Ubuntu 12.04 (Unity).
    Я просто освоился и привык к Unity, сейчас она мне кажется логичной и достаточно удобной оболочкой РС. Основное требование для админа это стабильность и простота. Не хочу ни с кем спорить, но именно так себя зарекомендовал Ubuntu.

    Подробно описывать средства для планирования документирования я, пожалуй, не буду. Отмечу, что для документирования мне хватает блокнота (Gedit) и Libre Office ну и Google Docs для совместного использования доков. Все самые полезные заметки и документы мы храним в wiki. Для учета рабочего времени и контроля выполнения задач мы используем Redmine.
    Конечно же, необходимы средства для коммуникации с коллегами и клиентами. Обычно это e-mail и Skype ну и телефон.
    Для планирования я использую Google Calendar, любое другое средство будет одинаково хорошим, если Вы будете на самом деле им пользоваться, например ежедневник.

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

    Утилиты командной строки

    Чаще всего приходится работать с текстом (конфиги, логи, руководства и т.п.), поэтому начнем с текстовых редакторов и прочих средств для манипуляций с текстом и строками:
    vi/vim — этот редактор незаменимый инструмент любого администратора, поскольку его можно найти практически на любом сервере (на любом юниксе) и если вы до сих пор первым делом когда он открывается тут же выходите из него по ctrl+z, то я настоятельно рекомендую вам хотя бы прочитать в man vim как правильно нужно это делать.
    nano — самый простенький редактор, поставляется по-умолчанию в Debian/Ubuntu.
    mcedit — для любителей mc и синих экранов, не самых плохой вариант, достаточно прост и удобен.
    cat — concatinate — изначально инструмент для объединения файлов, но чаще используется для вывода содержимого файла, а также для вставки строк в файл.
    tail — по-умолчанию выводит последние 10 строк файла, можно использовать для слежения за логом (с ключом -f)
    wc — считает строки слова и количество байт в файле
    head — как и tail выводит 10 строк файла, но как наверное понятно из названия, с начала файла.
    grep — самый незаменимый инструмент для фильтрации текстового вывода или просто для поиска нужной строки в файлах.
    sed — stream editor — очень полезен для автоматизации рутинных задач, замена строк в файлах (правка конфигов), удаление строк, вывод содержимого по маске и т.д.
    awk/gawk — очень мощная утилита (на самом деле AWK — целый язык программирования), которая помогает парсить файлы и манипулировать выводом строк и еще много чего.
    Информацию о всех перечисленный утилитах можно почерпнуть в man. Кстати, о man:
    man — доступ к справочным страницам — это то, без чего наверное не обходится ни один рабочий день юникс-администратора. Если вы начинающий специалист, то обязательно начните с ввода man man в командной строке.
    Список можно продолжать, долго продолжать, утилит на самом деле очень много. Но пока остановимся на этом и посмотрим, что можно сделать полезного с помощью awk, wc, cat и grep, почитав немного man.

    Немного практики

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

    Есть лог-файл apache (access.log) в следующем формате:
    1.2.3.4 - - [12/May/2014:03:08:55 +0400] "GET /shop/goods-list HTTP/1.1" 200 1691 "http://example.ru/shop/goods-list" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

    Напишем простой скрипт для подсчета процента успешно обработанных запросов.
    #!/bin/bash
    
    SUM=`wc -l access.log` # Подсчитаем количество строк в файле
    OK=`cat access.log | awk '{print $9}' | grep 200 | wc -l` # Подсчитаем сколько строк с кодом "200"
    
    awk -v SUM="$SUM" -v OK="$OK" '
    BEGIN {
     printf "Passed: %3.2f%%\n", OK / SUM * 100
     exit
    }'
    
    Получим примерно такой вывод: Passed: 93.62%

    И еще несколько полезных примеров:

    Подсчитаем объем переданных данных за час, предшествующий текущему
    cat access.log  | grep `date +%H:%M -d "-1 hour"` | awk '{ total += $10 } END { print total/1024/1024 FS"MB" }'
    

    Вычислим общий объем переданных данных
    awk '{ total += $10 } END { print total/1024/1024 FS"MB" }'  access.log
    

    Вычислим среднее время обработки запроса
    #!/bin/bash
    
    COUNT=`wc -l access.log`
    SUM=`cat access.log | awk '{ total += $16 } END { print total }' `
    
    awk -v COUNT="$COUNT" -v SUM="$SUM" '
    BEGIN {
     printf "Average req-time %3.2fs\n", SUM / COUNT
     exit
    }'
    


    Диагностика загрузки системы

    Чтобы понять насколько загружен сервер есть несколько утилит, прежде всего можно оценить загрузку по показателю load average, на Хабре уже писали что это показатель средней загруженности системы выражающийся в числе блокирующих процессов ожидающих получения ресурсов, за 1 минуту, 5 минут и 15 минут соответственно.
    Первое, что поможет оценить текущую загруженность сервера и увидеть какие же процессы в данный больше нагружают сервер — top или htop:
    top — отображение процессов linux — кроме этого отображает uptime, load average, число выполняющихся задач и тредов.
    Показатели процессора (в процентном соотношении):
    us — время потраченное на выполнение пользовательских без изменения приоритета обработки (un-nice),
    sy — время потраченное на выполнение системных (kernel) процессов,
    ni — время потраченное на выполнение пользовательских c изменением приоритета обработки (nice),
    wa — время ожидания ввода/вывода (дисковой подсистемы),
    hi — время на обработку аппаратных прерываний,
    si — время на обработку софтварных прерываний,
    st — время «украденное» гипервизором для обработки задач на другой виртуальной машине — актуально для виртуальных машин (VPS/VDS) и полезно для оценки честности хостера, если этот показатель велик, то ваш провайдер нагло оверселлит.
    Также top покажет вам сколько в целом потребляется памяти и для чего (процессы, кеши, буфферы), а также покажет сколько потребляет каждый процесс:
    VIRT — отображает сколько в целом памяти использует процесс включая код, данные, общие библиотеки, а также страницы памяти сброшенные в своп и страницы памяти которые были зарезервированы но не использованы,
    RES — размер резидентной памяти — текущее количество оперативной памяти (без свопа) используемой процессом,
    SHR — размер разделяемой памяти — текущее количество оперативной памяти доступной для процесса, как правило, не вся эта память резидентная. Это число просто отображает, сколько памяти может быть разделено с другими процессами.
    Кроме отображения показателей использования ресурсов системы top также используется для манипуляций над процессами, можно послать сигнал завершения процессу либо изменить его приоритет (nice).
    htop — более цветастая версия top — обладает всеми теми же возможностями, что и top, но имеет более дружественный интерфейс (позволяет прокручивать список процессов как вертикально так и горизонтально), а также умеет вызывать lsof, strace и ltrace для выбранного процесса (о них позже расскажем подробней).
    Чтобы оценить нагрузку на дисковую подсистему ввода/вывода можно воспользоваться утилитой iotop:
    iotop — top-подобная утилита для мониторинга нагрузки на диск, выводит таблицу процессов с текущими показателями использования дискового ввода/вывода, такими как:
    — PRIO — приоритет процесса,
    — DISK READ — чтение с диска Байт/сек,
    — DISK WRITE — запись на диск Байт/сек,
    — SWAPIN — время (в процентном соотношении) потраченное процессом на свопинг,
    — IO — время (в процентном соотношении) потраченное процессом на ожидание ввода/вывода.
    Дополнительно выводится информация о суммарном битрейте чтения/записи дисковой подсистемы.
    vmstat — выводит суммарную информацию о процессах, памяти, вводе/выводе, активности процессора и дисков. В отличии от iotop не требует привилегий суперпользователя.

    Диагностика сбоев программ, troubleshooting
    Бывают ситуации когда программа или демон работают не так как вы ожидаете, либо по непонятным причинам сбоят. Когда все логи просмотрены (или когда нет логов), все конфиги проверены и документация перечитана (если есть конечно), на помощь придут утилиты трассировки системных вызовов stace, ltrace, а также lsof покажет список открытых файлов:
    strace — утилита позволяет перехватывать системные вызовы и сигналы запускаемого процесса либо уже запущенного процесса по его PID.
    Вывод можно фильтровать, например выводить только вызовы open() или select(). Если вызов возвращает не отрицательное значение, то все хорошо, если выдается например:
    open("/foo/bar", O_RDONLY) = -1 ENOENT (No such file or directory), то из этого можно понять что приложение пытается открыть несуществующий файл. Также иногда случается, что некорректно выставлены права на файл. Еще например не запускается виртуальная машина, потому, что гипервизор не может выделить ей нужное количество оперативной памяти. Strace в таких ситуациях здорово помогает.
    Если вам просто интересно посмотреть, как работает тот или иной сервис, какие он использует системный вызовы, то stace — ваш друг. Например хотите узнать чем принципиально отличается Apache от Nginx, просто возьмите и посмотрите.
    ltrace — утилита для трассировки библиотечных вызовов — очень похожа на strace, но перехватывает только вызовы к динамическим библиотекам.
    ldd — если натравить ее на программку покажет какие программа использует библиотеки. Полезно если нужно перенести программу в chroot.
    lsof — выводит список открытых файлов с указанием, по умолчанию выводит все подряд. Может выводить список для конкретного процесса по PID (достаточно удобный вывод в htop), для пользователя по UID, или например какие процессы используют тот или иной файл.
    Может оказаться полезной в некоторых случаях. Имеется очень подробный man с описанием и примерами.

    Что еще осталось рассказать

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

    To be continued...

    UPD: Более правильный вариант для подсчета процента успешно обработанных запросов от sledopit
    awk '{sum+=1; if ($9==200) ok+=1} END {printf "Passed: %3.2f%%\n", ok / sum  * 100}'  access.log
    

    И еще более простой вариант со встроенной переменной NR вместо SUM от RumataEstora
    awk '$9 == 200 { s++ } END { print s / NR * 100; }' access.log
    
    Southbridge
    Обеспечиваем стабильную работу highload-проектов

    Похожие публикации

    Комментарии 37

      0
      cat access.log | awk '{print $9}' | grep 200 | wc -l
      

      А теперь представьте, что на сервере таймзона не +0400, а +0200
      • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Хм, ну да. Тем не менее, способ разбора видится несколько ненадежным. Нужно больше регекспов.
            +1
            Предложите тогда, пожалуйста, более «надежный» способ. Всем будет интересно. :)
              +1
              Навскидку не готов. Но зато я придумал, до чего ещё докопаться: успешный запрос это не только код 200. Ещё как минимум есть 300-ые редиректы, а в спеке и 200-ых кодов хватает.
                +2
                awk '{if($9==200)sum+=1}END{print sum}' access.log
                  +4
                  Более того, там вообще весь скрипт можно на один awk заменить, чтобы лог дважды не читать. Особенно это будет полезно, если он большой:
                  awk '{sum+=1;if($9==200)ok+=1}END{printf "Passed: %3.2f%%\n", ok / sum  * 100}' access.log
                    0
                    Спасибо, добавлю к статье если вы не против.
                      0
                      Да, конечно.
                      Сам скрипт, кстати, не совсем рабочий. В COUNT=`wc -l access.log` будет «количество_строк access.log» а не просто количество строк, из-за этого последний awk навернётся, т.к. в -v передастся оно криво, кавычек то у вас там нет (:
                        0
                        Для такого случая (требуется только результат) можно использовать перенаправление:
                        wc -l < FILENAME
                        


                        Переменная sum — лишняя. Для определения количества строк есть встроенная переменная NR (см. habrahabr.ru/company/centosadmin/blog/222469/#comment_7581431).
                          0
                          Спасибо, ваш вариант я тоже добавил. :)
                          0
                          Верно подмечено, очепяточка. Спасибо, исправлю.
                    0
                    Как-то году эдак в 1997, работал я в одной телефонной компании, которая эксплуатировала АТС, вываливающие свои логи в com порт, все это перемежалось какими-то асинхронными сообщениями, влезающими в середину нормальных записей и все портящих, короче еще тот недокументированный винегрет. Так вот, для пост-обработки всей этой неземной красоты, я начал пилить sed скрипт (к сожалению, за давностью лет он не сохранился). Где-то через пол года он вырос до ~1000! строк адского-ада и работал 10 минут (логи были большие), что напрягало. Выручили GNU flex и GNU bison, постобработка стала происходить за 10 секунд и, кончено, стало гораздо проще вносить изменения в код в случае появления новых типов сообщений.
                      0
                      А perl не пробовали? Имхо, для разбора CDR удобнее всего
                        0
                        Ну, это был вообще не CDR, а какой-то поток сознания этой самой GPTёвской SystemX с кучей unsolicited output. Ну, а так как, в то время я был хардкорным С программистом, выросшим из DJGPP, то perl я оставил как-то за бортом… :)
                0
                Причем в данном примере таймзона вообще?
                  +1
                  Из лога — [12/May/2014:03:08:55 +0400]. Если будет +2 часа к UTC, то будет +0200.
                  0
                  deleted, awk быстрее…
                  +3
                  Это же все стандартные инструменты их вообще любой админ Linux использует, иначе как вообще на linux рабоать без их знания. Я думал напишите про что-нить вроде zabbix, chef, а лучше что-то новенькое, чего я не слышал)
                    +2
                    Да, все верно, первая часть про стандартные инструменты. :) Это полезно для начинающих админов. Удивлять опытных юниксоидов не было задачи.
                    Про что-то новенькое напишем в следующих статьях.
                      +4
                      Если бы подобный пост был тогда, когда я линуксом только начал сталкиваться, то это сэкономило бы кучу времени. А так — толстенный талмуд по RHEL оказался наиболее информативной книжкой на тот момент (хотя и дистрибутив был другой). Так что не думаю, что лишним будет в копилке.
                        +1
                        Хороший пост. Пригодится для начинающих админов и особенно для начинающих программистов.
                        +4
                        Напишем простой скрипт для подсчета процента успешно обработанных запросов

                        Можно еще проще
                        awk '$9 == 200 { s++ } END { print s / NR * 100; }' access.log
                        
                          0
                          Полюбил awk за его минимализм и при этом огромный функционал, когда пришлось писать сложные скрипты на embeded-устройствах с ash(shell такой) и практически без утилит вроде head, tail etc.
                          +1
                          Про core utils, наверное, все знают, что про них писать?

                          Было бы интересно почитать про всякие штуки автоматизации/конфигурирования/развёртывания типа Salt, Docker, только не на уровне «Hello World», а с реальными примерами использования и настройки.
                            0
                            на самом деле, про core utils можно рассказывать вечно, очень уж там много всего прикольного и малоизвестного.
                            +1
                            Спасибо за структурную выкладку основных инструментов.

                            Хотелось бы в следующих статьях почерпнуть следующие аспекты:
                            — ваш личный best practice в мониторинге (оповещениях)
                            — реальные графики работы высоконагруженных серверов
                            — какой инструментарий для бекапа используется вами для разных типов данных (большой объем, большое количество, малый объем, малое количество, бекапы баз). Хотелось бы узнать ваш практический опыт в этом, какие инструменты используете в обоих направлениях (создание+восстановление бекапа)
                            — как проводится тестирование сервера до введения его в боевой режим
                              0
                              Спасибо за идеи. Постараемся все отразить в будущих статьях.
                              –1
                              Один я чуть не взорвался от дизайнерских решений на сайте этой компании? :)
                                0
                                Есть ошибочка в формировании даты =)
                                date +%H:%m -d "-1 hour"
                                Так вы месяц выводите, а не минуты. Скорее тогда уж так:
                                date +%H:%M -d "-1 hour"
                                  0
                                  Верно, не заметил. Наверное потому, что минуты тут и не нужны.
                                  0
                                  А не подскажете чего-нибудь прочитать поподробнее про strace, а то как-то пока не довелось использовать? Ну кроме мана, естественно. Желательно на примерах.
                                  +1
                                  Невижу ssh в утилитах командной строки.
                                  Она может быть не первая команда с коротой начинается изучение линукса, но точно первая с которой начинается рабочий день.
                                    0
                                    Тоже верно. Надо было бы, еще упомянуть терминалы (Guake, Terminator и т.п.)…
                                    0
                                    Напишем простой скрипт для подсчета процента успешно обработанных запросов.
                                    Более правильный вариант для подсчета процента успешно обработанных запросов

                                    И самый правильный вариант — использовать mod_status, а не городить огород из анализа access логов. А так же использовать custom лог со всей необходимой информацией.

                                    P.S.
                                    cat access.log | awk ...
                                    < access.log awk…

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

                                    Самое читаемое