Comments 21
А для кого написана эта статья?
Для «системного администратора», которому откровением будет факт что логи находятся в папке "/var/log/"?
Для «системного администратора», которому откровением будет факт что логи находятся в папке "/var/log/"?
UFO just landed and posted this here
По своему опыту могу сказать, что логи могут быть засунуты куда угодно. Но это, скорее, косяки предыдущих горе-настройщиков. Ну и вообще, местоположение логов в *nix-системах — секрет полишинеля, однако же регулярно встречаю на форумах и разных тематических чатах ступор при просьбе показать кусок лога. Даже если эта статья попадется на глаза всего лишь одному юному падавану, это уже облегчит жизнь. Ну и не забывайте, что во многих организациях еще существуют свои серверные, поэтому проверка физического уровня — пока что не пустой звук
Хорошая статья и главное правильные мысли. Неплохо бы ещё написать про документирование настроек и описывать там же решение типовых проблем. И тогда виртуализация будет праздником, а не ещё одной головной болью.
Вы меня извините, но какие то настолько банальные советы, что даже и не знаю.
1. Сейчас много серверов удаленных (имею ввиду хостинги в других странах) и осмотреть их просто нет возможности. Что делать тогда?
2. Что будете делать, когда у вас апач будет сегфолтиться? Причем раз в день/неделю независимо от нагрузки, в произвольный момент времени. Или ядро будет выпадать в корку.
3. Зачастую поиск проблем с железом может доставить кучу проблем. Особенно проверка памяти. Сталкивался много раз на Хецнере. И да, ЕСС вам особо не поможет. В некоторых случаях просто приходилось менять сервер.
4. Для 3го/4го шагов должны использоваться системы мониторинга, которые избавляют от множества неприятностей.
1. Сейчас много серверов удаленных (имею ввиду хостинги в других странах) и осмотреть их просто нет возможности. Что делать тогда?
2. Что будете делать, когда у вас апач будет сегфолтиться? Причем раз в день/неделю независимо от нагрузки, в произвольный момент времени. Или ядро будет выпадать в корку.
3. Зачастую поиск проблем с железом может доставить кучу проблем. Особенно проверка памяти. Сталкивался много раз на Хецнере. И да, ЕСС вам особо не поможет. В некоторых случаях просто приходилось менять сервер.
4. Для 3го/4го шагов должны использоваться системы мониторинга, которые избавляют от множества неприятностей.
А почему в аппаратных неисправностях остановились только выдернутых кабелях и проблемах с ОЗУ? Такие проблемы редкие, а от проблемы з жорскими дисками, блоками питания, батареями кеш контролера довольно часто встречаются.
Не соглашусь со многими выше отписавшимися ораторами. Статья вполне годная. Хотя бы как справочник для не слишком опытных Linux админов. А это уже очень хорошо. На данном ресурсе, да и в целом в интернете, в последние как минимум лет 7 преобладает тенденция замусоривания информационного пространства ничего не несущим г***ном спамом. Найти что-то реально полезное и нужное все сложнее. А тем кто тут погрузился в критику, старый бородатый совет: 'критикуешь — предлагай'.
И что за манера примерять текст статьи только на себя и свои знания (есть только я, мир вращается вокруг меня и только для меня?). Не ужели реально считаете, что все вокруг настолько грамотные (прямо с рождения), что данная статья не имеет права на существование?
Эти шаги вам врядли помогут в реальных задачах, имхо. Банальные случаи — забился диск или явно посыпался (куча сообщений в dmesg), или после 5 минут прогона memtest у вас появились ошибки — я не беру в счет.
Предложите свои шаги для тех реальных задач, с которыми вы сталкивались. Поделитесь опытом с массами. Желательно в виде удобочитаемой статьи с примерами команд и результатами их вывода. После этого я признаю за вами право критиковать автора данного "бесполезного" перевода.
Все вроде бы просто. Или все таки нет?
Спасибо автору за статью. После прочтения у меня появилось несколько вопросов, однако хочу заметить, что я не системный администратор, просто пользуюсь Linux уже некоторое время. Конкретно меня интересует есть ли разница между
и просто
А также, что делает следующая команда:
приведенная в статье. На мой взгляд она берет вывод dmesg и пуляет его tail, который его игнорирует, так как ему специфицирован файл, из которого читать. В чем я не прав?
sudo df
и просто
df
А также, что делает следующая команда:
dmesg | tail -f /var/log/syslog
приведенная в статье. На мой взгляд она берет вывод dmesg и пуляет его tail, который его игнорирует, так как ему специфицирован файл, из которого читать. В чем я не прав?
Да, банально. Да, многие знают. Но все равно часто делают не так.
Я, например, иду по другой цепочке шагов.
- Проверка доступности сервера/сервиса
- Проверка нужного сервиса (подтверждение проблемы)
- В зависимости от 1 и 2 смотрю логи, топы, диски, провода, звоню в поддержку и тп
Не учите детей плохому.
netstat давно deprecated и его могут выкинуть в любой момент.
Ознакомьтесь, хотя бы, с https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/, что бы минимально понимать о чем пишите.
netstat давно deprecated и его могут выкинуть в любой момент.
Ознакомьтесь, хотя бы, с https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/, что бы минимально понимать о чем пишите.
Cosmopolitan наступает на пятки: сначала было 10 способов найти отличного мужа. Потом стало 20 лучших утилит DevOps. Теперь подход к траблшутингу стал len(чеклистом).
Что нас ждет? 7 способов передать аргумент по референсу?
Любая подобная статья — не мануал к траблшутингу, а границы компетентности автора статьи. Чем более он компетентен, тем больше пунктов и более они глубокие. То есть, например, сначала люди верят в утилиту free. Потому они узнают, что свободная память в Linux занимается пейдж кэшем и свободного пространства в идеале в памяти быть не должно (не совсем так, но вы поняли). Тогда они узнают файл /proc/meminfo.Потом им становится и этого не достаточно и они начинают смотреть кто где какую резидентную память откушал, а кто общую. Сколько ушло из L1/2/3 в RAM и почему, slabtop и так далее. И все глубже и глубже. < — ха ха, я остановился на границах своей компетентности. Я не знаю, что дальше. Видите?
На каком-то уровне наступает степень компетентности «я знаю 1000 возможных причин, почему могла сломаться эта конкретная делать. Но попробовать все 1000 я не могу. Поэтому я начинаю менять подход к траблшутингу — я проверяю от конца цепочки каждый ее элемент, пока не наткнусь на нерабочий. Я не проверяю все подряд, только потому, что я знаю о его существовании».
Я не хочу выглядеть занудой, который критикует, вместо того, чтобы вложитсья. Я просто не вижу, зачем вкладываться в развитие непонимания смысла траблшутинга (именно это обозначено в загаловке к статье «Пять шагов к спасению Linux-сервера, который рухнул»). Лучше я вложусь в объяснение, что траблшутинг делается по другому.
Что нас ждет? 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 валится в офис.на отдельное хранилище.
В итоге мы видим потенциальную проблему еще до того, как она стала реальной и принимаем меры. Либо меняем арендованный сервер, либо на выходные в ночь просим поддержку ДЦ поменять диски либо что-то где-то тюним под изменившийся характер нагрузки. Так что траблшутинг мы слава Ктулху оставили в прошлом уже много лет назад.
Аптайма всем побольше и седых волос поменьше.
1. Nagios установлен на Raspbery Pi, а на любом рабочем месте закреплена вкладка с «Service status». Так-же прикручено информирование через SMS (тут-же на хабре статей по теме куча)
2. Периодически меряем скорость выполнения некоторых задач и сравниваем с эталоном. Задачи периодические, так что мы просто «за одно» знаем не начал ли тормозить наш сервер там, где не должен.
3. Периодически смотрим в error.log'и Nginx и Apache. Если размер >0, ищем что и где поломалось и устраняем. Как правило проблемы на стороне криво написанных PHP. Их тоже чиним. Хотим, чтоб размер error.log'ов был =0
4. Бэкапы, быкапы бэкапов и бэкапы бэкапов бэкапов.
4.1. Средствами самих CMS'ок + отдельным скриптом в отдельный каталог (чтоб быстрый доступ был к свежим бэкам) и все это по rsync валится в офис.на отдельное хранилище.
В итоге мы видим потенциальную проблему еще до того, как она стала реальной и принимаем меры. Либо меняем арендованный сервер, либо на выходные в ночь просим поддержку ДЦ поменять диски либо что-то где-то тюним под изменившийся характер нагрузки. Так что траблшутинг мы слава Ктулху оставили в прошлом уже много лет назад.
Аптайма всем побольше и седых волос поменьше.
Sign up to leave a comment.
Пять шагов к спасению Linux-сервера, который рухнул