Итак, у вас есть этот аккуратно настроенный unix-сервер, он супербыстрый, отлично работает, месяцами все отлично, и внезапно начинают появляться всевозможные странные ошибки для множества различных служб, и ни одна из них сама по себе не имеет большого смысла. , тем более вместе.
Какие дешевые вещи вы должны проверить, как только вы подключите свой сеанс ssh к машине?
Меня особенно интересуют истории о травмах, в которых выделяются неочевидные команды и редкие ситуации, но я предполагаю, что очевидное варьируется от человека к человеку, поэтому мы можем просто перечислить их все в произвольном порядке.
Первый заказ: реагирует ли он?
Если вы не можете войти в систему, возникнут большие проблемы. Обычно это бывает двух видов: отказ оборудования и отказ программного обеспечения. Оба потенциально катастрофичны. Чтобы предотвратить ошибки DFA, сначала проверьте общее состояние оборудования - обычно достаточно простого беглого взгляда.
Второй порядок: в хорошем ли состоянии и в порядке ли лежащие в основе системы структуры?
Проверьте «Золотую триаду» систем:
За последние несколько десятилетий триада расширилась до «четырехугольника», который включает коммуникации (сети):
Третий порядок: какова серьезность проблемы?
Какие программы или службы затронуты? В порядке убывания серьезности, является ли он системным (общесистемным), кластерным (группа программ) или изолированным (конкретная программа)? Кластеры программ обычно отключаются из-за того, что конкретная базовая служба вышла из строя или перестала отвечать. Иногда с этим связаны системные проблемы (подумайте о конфликтах DNS или IP), но обычно ключом является знание того, где искать.
Четвертый порядок: предоставляют ли диагностические инструменты полезные данные, относящиеся к проблеме? Теперь, когда у вас есть информация о работоспособности системы (второй порядок) и о том, какие части ее испытывают проблемы (третий порядок), это должно упростить определение того, где находится проблема.
Сообщения об ошибках или файлы журналов должны быть общей точкой в этом путешествии.
Проблемы с процессором:
Проблемы с дисковым пространством / вводом-выводом:
Проблемы с памятью:
Проблемы с подключением:
Наиболее частая жалоба (что я слышу):
Электронная почта доставляется недостаточно быстро (более минуты от отправки до получения получателем) или электронная почта отклоняет мою попытку отправить. Обычно это сводится к срабатыванию ограничителя скорости в Postfix во время спам-шторма, который влияет на способность принимать внутреннюю доставку.
Пример из жизни:
Тем не менее, это не всегда так. Один раз проблема сохранялась независимо от перезапуска службы; так что через 3 минуты пришло время начать осматриваться. ЦП был загружен, но менее 100%, но при этом нагрузка взлетела до 15 на коробку всего с 2 ядрами и грозила стать выше. Команда top выявила, что почтовая система была перегружена, как и почтовый сканер, но дочерних процессов amavis не было видно. Это была подсказка - команда очереди почты (mailq) показала более 150 недоставленных сообщений, более 80% из них были спамом, за последние 20 минут. Быстрая корректировка для снижения ограничителя скорости (что снизила скорость приема спам-шторма) при одновременном увеличении количества процессов дочернего сканера электронной почты (чтобы помочь обработать невыполненный журнал), с последующим перезапуском службы, решила проблему, и система смогла для выполнения поставок в короткие сроки.
Причина проблемы заключалась в том, что родительский процесс amavis перестал работать, и все дочерние процессы в конечном итоге завершились своим ходом (они завершаются самостоятельно после стольких сканирований для предотвращения утечек памяти). Итак, в postfix были SMTP-процессы, которые пытались связаться ... из воздуха ... чтобы выполнить необходимое сканирование на спам / вирусы. В дистрибутиве, который я использовал, были устаревшие пакеты, которые никогда не обновлялись; поскольку установка должна была быть заменена примерно через год, я вручную "переопределил" установку до последней версии, которая включала несколько исправлений ошибок. С тех пор у меня не было такой проблемы.
обычно "кто" следует "последний"
куча проблем на машинах, которыми я управлял в течение долгого времени, была из-за очень расплывчатого определения «нетронутый» - часто кто-то что-то делал :)
Хорошо, начну.
Один раз меня укусил, я часами пробовал тысячи разных вещей, отключая службы тут и там, перезагружая и т. Д. В чем была проблема? Полностью не хватает места на диске.
Итак, вот первое, что я набираю при отладке сервера, который неожиданно оказался проблемным:
df -h
Я никогда этого не забываю. Это просто сэкономило мне много потраченных впустую усилий. Думал поделиться.
верх (или htop)
Если вы можете, я всегда стараюсь выключить все сетевые адаптеры, кроме управляющей.
Первое, что я проверяю, это «верхний» (есть ли какие-нибудь странные процессы; те, которые занимают память или время процессора).
Если там ничего не появится, я проверю «кто», чтобы узнать, есть ли еще кто-нибудь на моей машине по какой-либо причине.
Возможно, файловая система размонтирована; проверьте с помощью вызова «cat / etc / mtab», а затем «fstab», чтобы убедиться, что все работает сразу при загрузке.
Проверьте время безотказной работы, чтобы убедиться, что количество пользователей на коробке разумное (это должны быть только вы), а затем пролистайте файл var / log / auth.log, чтобы увидеть, что там не так.
Это комплексные решения. В зависимости от ошибок, которые выдает ваш ящик, вам может потребоваться изучить определенные процессы, которые вызывают проблемы.
Запуск чего-то вроде (в) сар на хосте практически обязательно. Нельзя недооценивать полезность возможности получить исторические снимки ЦП, сети, памяти и дискового ввода-вывода (среди прочего).
Много раз мне удавалось диагностировать неисправность, проверяя, что хост делал за последние 24 часа, и смотрел, когда что-то пошло не так.
Проверка dmesg на наличие ошибок - обычно я начинаю с dmesg | tail, потому что есть вероятность, что что-то все еще идет не так, и сервер все еще пытается сделать то, что вызывает ошибку.
top df -h и ВСЕГДА проверяйте / var / log, чтобы убедиться, что раздел не заполнен. Это несколько раз вызывало у меня полное таяние.
df -ha
чтобы проверить, заполнены ли жесткие диски и кто-то не получил предупреждений
htop или топ
чтобы проверить память и использование процессора не слишком высоко.
В качестве альтернативы, если коробка не отвечает, я захожу в клиент vm-ware и проверяю процессор / оперативную память оттуда.
В Linux я обычно проверяю dmesg и / var / log / messages или / var / log / syslog. dmesg укажет, если это внезапная аппаратная ошибка; довольно много других проблем будет отображаться в системных журналах.
Полагаю, первое, что я делаю, это проверка дискового пространства (как уже упоминали другие). Если простые проверки не выявят "распространенную" проблему, я займусь дальнейшим исследованием.
Одна вещь, которую я люблю делать, - это делать снимок системы. Позже я могу найти их, чтобы найти все, что привлекло мое внимание.
lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &
Оттуда это устранение неполадок 101, но я считаю, что это немного быстрее, чтобы найти сохраненные журналы, и если условие очищается, пока я вошел в систему, мне есть что продолжить или поискать изменения.