Открыть список
Как стать автором
Обновить

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

А для кого написана эта статья?
Для «системного администратора», которому откровением будет факт что логи находятся в папке "/var/log/"?
НЛО прилетело и опубликовало эту надпись здесь
По своему опыту могу сказать, что логи могут быть засунуты куда угодно. Но это, скорее, косяки предыдущих горе-настройщиков. Ну и вообще, местоположение логов в *nix-системах — секрет полишинеля, однако же регулярно встречаю на форумах и разных тематических чатах ступор при просьбе показать кусок лога. Даже если эта статья попадется на глаза всего лишь одному юному падавану, это уже облегчит жизнь. Ну и не забывайте, что во многих организациях еще существуют свои серверные, поэтому проверка физического уровня — пока что не пустой звук

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

Вы меня извините, но какие то настолько банальные советы, что даже и не знаю.

1. Сейчас много серверов удаленных (имею ввиду хостинги в других странах) и осмотреть их просто нет возможности. Что делать тогда?

2. Что будете делать, когда у вас апач будет сегфолтиться? Причем раз в день/неделю независимо от нагрузки, в произвольный момент времени. Или ядро будет выпадать в корку.

3. Зачастую поиск проблем с железом может доставить кучу проблем. Особенно проверка памяти. Сталкивался много раз на Хецнере. И да, ЕСС вам особо не поможет. В некоторых случаях просто приходилось менять сервер.

4. Для 3го/4го шагов должны использоваться системы мониторинга, которые избавляют от множества неприятностей.
1. В датацентре должна быть своя местная зондеркоманда. Писать, звонить, пинать.
2. 146% что-то с железом.

Да, про мониторинг зря не написали в статье. must have.
А почему в аппаратных неисправностях остановились только выдернутых кабелях и проблемах с ОЗУ? Такие проблемы редкие, а от проблемы з жорскими дисками, блоками питания, батареями кеш контролера довольно часто встречаются.

Не соглашусь со многими выше отписавшимися ораторами. Статья вполне годная. Хотя бы как справочник для не слишком опытных Linux админов. А это уже очень хорошо. На данном ресурсе, да и в целом в интернете, в последние как минимум лет 7 преобладает тенденция замусоривания информационного пространства ничего не несущим г***ном спамом. Найти что-то реально полезное и нужное все сложнее. А тем кто тут погрузился в критику, старый бородатый совет: 'критикуешь — предлагай'.
И что за манера примерять текст статьи только на себя и свои знания (есть только я, мир вращается вокруг меня и только для меня?). Не ужели реально считаете, что все вокруг настолько грамотные (прямо с рождения), что данная статья не имеет права на существование?

Эти шаги вам врядли помогут в реальных задачах, имхо. Банальные случаи — забился диск или явно посыпался (куча сообщений в dmesg), или после 5 минут прогона memtest у вас появились ошибки — я не беру в счет.

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


Все вроде бы просто. Или все таки нет?

Спасибо автору за статью. После прочтения у меня появилось несколько вопросов, однако хочу заметить, что я не системный администратор, просто пользуюсь Linux уже некоторое время. Конкретно меня интересует есть ли разница между
sudo df

и просто
df

А также, что делает следующая команда:
dmesg | tail -f /var/log/syslog

приведенная в статье. На мой взгляд она берет вывод dmesg и пуляет его tail, который его игнорирует, так как ему специфицирован файл, из которого читать. В чем я не прав?
Да, по поводу
df

Я имею в виду не банальный ответ, что первый вариант исполняется от root'а, а второй от пользователя. Вопрос в том, что у меня оба дают одинаковый результат. Соответственно вопрос, есть ли между ними реальная разница или это просто привычка все подобные команды исполнять от корня?
Нет, разницы между ними нет. Просто общая безграммотность автора статьи, которая прет из всех щелей.
Побуду немного капитаном: если у пользователя нет прав даже смотреть в примонтированный раздел, то df от него выдаст permission denied.
С такими правами сложно будет поднять рухнувший сервер.

Да, банально. Да, многие знают. Но все равно часто делают не так.
Я, например, иду по другой цепочке шагов.


  1. Проверка доступности сервера/сервиса
  2. Проверка нужного сервиса (подтверждение проблемы)
  3. В зависимости от 1 и 2 смотрю логи, топы, диски, провода, звоню в поддержку и тп
Не учите детей плохому.
netstat давно deprecated и его могут выкинуть в любой момент.
Ознакомьтесь, хотя бы, с https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/, что бы минимально понимать о чем пишите.
Что интересно, статья от 2011 года.
А netstat до сих пор актуален.
Cosmopolitan наступает на пятки: сначала было 10 способов найти отличного мужа. Потом стало 20 лучших утилит DevOps. Теперь подход к траблшутингу стал len(чеклистом).
Что нас ждет? 7 способов передать аргумент по референсу?

Любая подобная статья — не мануал к траблшутингу, а границы компетентности автора статьи. Чем более он компетентен, тем больше пунктов и более они глубокие. То есть, например, сначала люди верят в утилиту free. Потому они узнают, что свободная память в Linux занимается пейдж кэшем и свободного пространства в идеале в памяти быть не должно (не совсем так, но вы поняли). Тогда они узнают файл /proc/meminfo.Потом им становится и этого не достаточно и они начинают смотреть кто где какую резидентную память откушал, а кто общую. Сколько ушло из L1/2/3 в RAM и почему, slabtop и так далее. И все глубже и глубже. < — ха ха, я остановился на границах своей компетентности. Я не знаю, что дальше. Видите?

На каком-то уровне наступает степень компетентности «я знаю 1000 возможных причин, почему могла сломаться эта конкретная делать. Но попробовать все 1000 я не могу. Поэтому я начинаю менять подход к траблшутингу — я проверяю от конца цепочки каждый ее элемент, пока не наткнусь на нерабочий. Я не проверяю все подряд, только потому, что я знаю о его существовании».

Я не хочу выглядеть занудой, который критикует, вместо того, чтобы вложитсья. Я просто не вижу, зачем вкладываться в развитие непонимания смысла траблшутинга (именно это обозначено в загаловке к статье «Пять шагов к спасению Linux-сервера, который рухнул»). Лучше я вложусь в объяснение, что траблшутинг делается по другому.
Мои 5 копеек:
1. Nagios установлен на Raspbery Pi, а на любом рабочем месте закреплена вкладка с «Service status». Так-же прикручено информирование через SMS (тут-же на хабре статей по теме куча)
2. Периодически меряем скорость выполнения некоторых задач и сравниваем с эталоном. Задачи периодические, так что мы просто «за одно» знаем не начал ли тормозить наш сервер там, где не должен.
3. Периодически смотрим в error.log'и Nginx и Apache. Если размер >0, ищем что и где поломалось и устраняем. Как правило проблемы на стороне криво написанных PHP. Их тоже чиним. Хотим, чтоб размер error.log'ов был =0
4. Бэкапы, быкапы бэкапов и бэкапы бэкапов бэкапов.
4.1. Средствами самих CMS'ок + отдельным скриптом в отдельный каталог (чтоб быстрый доступ был к свежим бэкам) и все это по rsync валится в офис.на отдельное хранилище.
В итоге мы видим потенциальную проблему еще до того, как она стала реальной и принимаем меры. Либо меняем арендованный сервер, либо на выходные в ночь просим поддержку ДЦ поменять диски либо что-то где-то тюним под изменившийся характер нагрузки. Так что траблшутинг мы слава Ктулху оставили в прошлом уже много лет назад.
Аптайма всем побольше и седых волос поменьше.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.