Итак, у меня есть веб-сайт, работающий с nginx / php-fpm / ubuntu
Он работает очень хорошо (и быстро) и почти не использует память. Мой клиент вчера запустил рекламную кампанию, и было несколько раз, когда по пять или десять минут сайт не загружался. Я очень сомневаюсь, что это была перегрузка по трафику, поскольку статистика показывает, что посетителей пока не так много.
Во время этих "отключений" я подключался по ssh и запускал htop, чтобы посмотреть статистику ресурсов. Процессоры (все они) были около 0%, а оперативная память была примерно 350 МБ из 1024 МБ, и без свопа.
Я бегло просмотрел журналы доступа и не увидел там многого, хотя заметил парочку ботов. Я сомневаюсь, что это их вина, так как их там не так много (Кстати, как лучше всего «потреблять» простые текстовые файлы журналов?)
Каковы все шаги для отладки этого?
Первым шагом было бы определить, где происходит сбой. Похоже, вы смогли подключиться к серверу во время простоя, поэтому мне кажется маловероятным, что это был общий сбой сервера или проблема локальной сети сервера.
Первое, что я сделал бы, если бы мой веб-браузер не смог открыть страницу, - это установить, отвечает ли порт 80 на попытки подключения. Самый простой способ сделать это - использовать telnet, например (при условии, что вы используете что-то вроде Unix):
$ telnet your.server.name 80
Попробуйте это с серверами, которые, как вы знаете, работают, чтобы увидеть, как выглядит успешное сообщение. Например, для www.google.com я получаю:
$ telnet www.google.com 80
Trying 74.125.95.103...
Connected to www.l.google.com.
Escape character is '^]'.
(Чтобы выйти из telnet в этом состоянии, вам нужно нажать Ctrl-], затем Enter, затем Ctrl-D.)
Сбои, которые вы можете увидеть, включают сбой DNS:
$ telnet fake.dns.entry 80
telnet: could not resolve fake.dns.entry/80: Name or service not known
В этом случае вы должны попытаться подключиться к IP-адресу.
Другая возможность сбоя - отказ в соединении или соединение с превышением времени ожидания:
$ telnet serverfault.com 99
Trying 64.34.119.12...
telnet: Unable to connect to remote host: Connection timed out
Обычно это означает, что сервер или балансировщик нагрузки между вами и сервером не прослушивает правильный порт. Вы также можете увидеть:
$ telnet 192.168.0.237
Trying 192.168.0.237...
telnet: Unable to connect to remote host: No route to host
Это означает, что сервер не существует по адресу, который, как вы думали, существует, или есть проблема с сетевой маршрутизацией между ними.
Вы должны сначала проверить это вне сети, в которой находится сервер, предпочтительно где-нибудь, где отключены несколько интернет-провайдеров. Тогда попробуйте из локальной сети. Затем попробуйте его с локального компьютера, используя «localhost» вместо имени хоста, предполагая, что ваш веб-сервер настроен на прослушивание петлевых соединений.
Как только вы узнаете характер отказов, вы можете начать попытки выяснить, где именно происходит сбой. Инстинкт подсказывает мне, что корень проблемы - это ваш nginx или FastCGI, а не какая-то периодически возникающая сетевая проблема, которая не влияет на SSH-трафик, но на самом деле невозможно устранить неполадки дальше, не решив сначала сетевой вопрос.
Надеюсь, это даст вам некоторые идеи о том, с чего начать в следующий раз. Удачи.
Обновить
Я только что заметил ваш побочный вопрос о том, как лучше всего «потреблять» файлы журналов. Если вы находитесь в процессе устранения проблемы, я рекомендую использовать tail. Откройте на сервере два сеанса ssh и в одном tail -f /var/log/nginx/access_log а в другом tail -f /var/log/nginx/error_log (или каковы бы ни были пути в вашей системе).
Если вам нужно покопаться в плотном файле журнала постфактум, хороший инструмент для начала - less. Просто беги less /var/log/nginx/error_log, а затем нажмите пробел, чтобы перейти на страницу вниз, b на страницу вверх, / начать поиск, после чего n найдет следующий результат поиска и N найдет предыдущий результат и воспользуется q чтобы вернуться в оболочку.
Я бы предположил, что есть лучшие инструменты для определенных типов журналов, но tail и less Обычно при устранении неполадок с моими журналами я получаю около 90% того, что мне нужно.
Вы не предоставили никакой информации о том, как настроен сервер / где он размещен. На это может повлиять множество вещей - например, проблемы с сетевым подключением, проблемы с процессором на виртуальной машине.
Я предполагаю, что вы правильно настроили ведение журнала ошибок и проверили, что во время этих отключений не было изменений в структуре ошибок.
Вероятно, вы мало что можете сделать для анализа того, что произошло в предыдущем событии, но обязательно посмотрите, не было ли изменений во времени ответа.
Забегая вперед, вы можете подумать о настройке iptables для регистрации начала каждого квитирования tcp на порту 80 и записи% D в файлы журнала. Затем посмотрите, есть ли медленные ответы / промежутки между пакетами синхронизации и завершенными ответами.
Если система дает постоянную задержку между файлом cookie синхронизации и ответом, проблема не в программном обеспечении, запущенном на машине.
Запуск внешнего (http) и внутреннего (просто демона, который что-то записывает в файл журнала, а затем засыпает на некоторое время) контрольных пакетов сервера также может быть хорошей идеей. Опять же, если вы видите проблемы во внешнем пульсе, но не во внутреннем, это указывает на проблему с сетью, если вы видите пробелы в обоих, то есть проблема с оборудованием самого сервера.
Подумайте о добавлении агента производительности на стороне клиента, такого как бумеранг, для регистрации времени ответа страницы.
Вы должны использовать IP-адреса, внешние по отношению к вашему местоположению, например прокси или что-то в этом роде. Вы можете попробовать использовать сеть Tor для такого рода тестирования. Прежде всего, необходимо проверить, доступен ли сайт из разных мест в Интернете. Возможно, записи DNS были изменены недавно и еще не распространены.