|
|
|
|
|
# Поиск и устранение неисправностей
|
|
|
|
|
|
|
|
|
|
|
|
из книги: https://sre.google/sre-book/table-of-contents/
|
|
|
|
|
|
|
|
|
|
|
|
Устранение неполадок — важнейший навык для любого, кто управляет распределенными вычислительными системами, особенно SREs, но его часто рассматривают как врожденный навык, которым обладают одни люди, а другие нет. Одна из причин такого предположения заключается в том, что для тех, кто часто занимается устранением неполадок, это укоренившийся процесс; объяснить, как устранять неполадки, сложно, так же как объяснить, как ездить на велосипеде. Тем не менее, мы считаем, что устранения неполадок можно обучиться и научить.
|
|
|
|
|
|
Новички часто сбиваются с пути при устранении неполадок, потому что задача в идеале зависит от двух факторов: понимания того, как устранять неполадки в целом (т.е. без каких-либо конкретных системных знаний), и основательного знания отлаживаемой системы. В то время как вы можете исследовать проблему, используя только общий процесс и вывод из первых принципов, мы обычно находим этот подход менее эффективным и менее эффективным, чем понимание того, как все должно работать. Знание системы обычно ограничивает эффективность SRE, нового для системы; мало что может заменить изучение того, как спроектирована и построена система.
|
|
|
|
|
|
Давайте рассмотрим общую модель процесса устранения неполадок. Читатели, имеющие опыт в устранении неполадок, могут не согласиться с нашими определениями и процессом; если ваш метод эффективен для вас, нет причин не придерживаться его.
|
|
|
|
|
|
|
|
|
|
|
|
## Теория
|
|
|
|
|
|
|
|
|
|
|
|
Формально мы можем рассматривать процесс устранения неполадок как применение гипотетико-дедуктивного метода: учитывая набор наблюдений за системой и теоретическую основу для понимания поведения системы, мы итеративно выдвигаем гипотезы о потенциальных причинах сбоя и пытаемся проверить эти гипотезы.
|
|
|
|
|
|
В идеализированной модели, мы бы начали с отчета о проблеме, сообщающего нам, что с системой что-то не так. Затем мы можем просмотреть данные телеметрии и журналы системы, чтобы понять ее текущее состояние. Эта информация в сочетании с нашими знаниями о том, как устроена система, как она должна работать, и о режимах ее сбоев, позволяет нам выявить некоторые возможные причины.
|
|
|
|
|
|
Затем мы можем проверить наши гипотезы одним из двух способов. Мы можем сравнить наблюдаемое состояние системы с нашими теориями, чтобы найти подтверждающие или опровергающие доказательства. Или, в некоторых случаях, мы можем активно «лечить» систему, то есть изменять систему контролируемым образом, и наблюдать за результатами. Этот второй подход уточняет наше понимание состояния системы и возможных причин сообщаемых проблем. Используя любую из этих стратегий, мы неоднократно тестируем до тех пор, пока не будет определена основная причина, после чего мы можем предпринять корректирующие действия, чтобы предотвратить повторение, и написать postmortem. Конечно, для устранения непосредственной причины (причин) не всегда нужно ждать первопричины или postmortem заключения.
|
|
|
|
|
|
|
|
|
|
|
|
## Практика
|
|
|
|
|
|
|
|
|
|
|
|
Практический совет - в случае проблемы ищите руководства по устранению неполадок (имя технологии troubleshooting guide в google) для вашего программного обеспечения.
|
|
|
|
|
|
|
|
|
|
|
|
### Облегчение устранения неполадок
|
|
|
|
|
|
|
|
|
|
|
|
Существует множество способов упростить и ускорить устранение неполадок. Пожалуй, самые основные из них:
|
|
|
|
|
|
- расширение наблюдаемости — как с помощью метрик белого ящика, так и структурированных журналов — в каждом компоненте с нуля,
|
|
|
|
|
|
- проектирование систем с хорошо понятными и наблюдаемыми интерфейсами между компонентами.
|
|
|
|
|
|
|
|
|
|
|
|
Обеспечение единообразной доступности информации во всей системе — например, использование уникального идентификатора запроса во всем диапазоне RPC, сгенерированных различными компонентами, — снижает необходимость выяснять, какая запись журнала в вышестоящем компоненте соответствует записи журнала в нижестоящем компоненте, ускоряя время диагностики и восстановления.
|
|
|
|
|
|
|
|
|
|
|
|
Проблемы с правильным представлением реального состояния при изменении кода или изменении среды часто приводят к необходимости устранения неполадок. Упрощение, контроля и регистрации таких изменений может снизить потребность в устранении неполадок и упростить их, когда они происходят.
|
|
|
|
|
|
|
|
|
|
|
|
Настройте четыре основных метрики в системе мониторинга:
|
|
|
|
|
|
- задержка (время, необходимое для обслуживания запроса),
|
|
|
|
|
|
- трафик/скорость (запросов в секунду, транзакций в секунду, скорость ввода-вывода),
|
|
|
|
|
|
- частота ошибок (ошибки HTTP, промахи кеша, ошибки, связанные с сервисом),
|
|
|
|
|
|
- насыщенность (насколько «полный» ваш сервис, время отклика 99-го процентиля в небольшом окне).
|
|
|
|
|
|
|
|
|
|
|
|
## Примеры
|
|
|
|
|
|
### Отладка nginx
|
|
|
|
|
|
|
|
|
|
|
|
Это некоторые основные шаги по устранению некоторых наиболее распространенных ошибок с Nginx.
|
|
|
|
|
|
|
|
|
|
|
|
#### Поиск синтаксических ошибок или предупреждений в конфигурации
|
|
|
|
|
|
|
|
|
|
|
|
С помощью простой команды вы можете проверить состояние файла конфигурации Nginx: $ sudo systemctl config nginx В выводе будет показано, правильный ли файл конфигурации, или, если это не так, он покажет файл и строку, в которой возникла проблема.
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo systemctl config nginx
|
|
|
|
|
|
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
|
|
|
|
|
|
nginx: configuration file /etc/nginx/nginx.conf test is successful
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Зайдите в файл /etc/nginx/nginx.conf и переместите директиву worker_connections внутрь блока http
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo systemctl config nginx
|
|
|
|
|
|
"worker_connections" directive is not allowed here in /etc/nginx/nginx.conf:12
|
|
|
|
|
|
nginx: configuration file /etc/nginx/nginx.conf test failed
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Если в вашей системе nginx не сконфигурирован как сервис systemd, вы можете использовать параметр -t, который также проверяет файл конфигурации на правильность синтаксиса, а затем пытается открыть файлы, указанные в конфигурации.
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo nginx -t
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Убедитесь, что Nginx работает
|
|
|
|
|
|
|
|
|
|
|
|
Проверить статус службы Nginx, вы можете использовать следующую команду:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo systemctl status nginx
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Вы также можете использовать общие команды для проверки статуса службы:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo /etc/init.d/nginx status
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Или найти nginx среди процессов:
|
|
|
|
|
|
```
|
|
|
|
|
|
ps uax | grep nginx
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Убедитесь, что порты открыты и служба их слушает
|
|
|
|
|
|
|
|
|
|
|
|
Убедитесь, что у вас открыты необходимые порты, и чтобы убедиться, что служба Nginx прослушивает их, вы можете использовать команду lsof, в идеале с портами по умолчанию 80 и 443.
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo lsof -i :80 -s TCP:LISTEN
|
|
|
|
|
|
nginx 1305 nginx 6u IPv4 1613873 0t0 TCP *:http (LISTEN)
|
|
|
|
|
|
nginx 1305 nginx 7u IPv6 1613874 0t0 TCP *:http (LISTEN)
|
|
|
|
|
|
nginx 1306 nginx 6u IPv4 1613873 0t0 TCP *:http (LISTEN)
|
|
|
|
|
|
nginx 1306 nginx 7u IPv6 1613874 0t0 TCP *:http (LISTEN)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Проверить, обрабатывает ли Nginx запросы
|
|
|
|
|
|
|
|
|
|
|
|
Если Nginx действительно прослушивает соответствующие порты, следующим шагом будет проверка обработки запросов, что можно сделать с помощью инструмента curl с использованием IP-адреса, URL-адреса или локального хоста, если ваша установка прослушивает локальный хост:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ curl -i http://127.0.0.1/nginx_status
|
|
|
|
|
|
HTTP/1.1 200 OK
|
|
|
|
|
|
Server: nginx/1.11.1
|
|
|
|
|
|
Date: Wed, 08 Aug 2021 11:36:43 GMT
|
|
|
|
|
|
Content-Type: text/plain
|
|
|
|
|
|
Content-Length: 97
|
|
|
|
|
|
Connection: keep-alive
|
|
|
|
|
|
|
|
|
|
|
|
Active connections: 1
|
|
|
|
|
|
server accepts handled requests
|
|
|
|
|
|
3 3 3
|
|
|
|
|
|
Reading: 0 Writing: 1 Waiting: 0
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### Проверьте журналы
|
|
|
|
|
|
|
|
|
|
|
|
Проверьте последние журналы службы Nginx. $ sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log
|
|
|
|
|
|
|
|
|
|
|
|
#### Проверить разрешения
|
|
|
|
|
|
|
|
|
|
|
|
Убедитесь, что Nginx имеет соответствующие разрешения для доступа к нужным файлам.
|
|
|
|
|
|
```
|
|
|
|
|
|
$ namei -om /usr/share/nginx/html/index.html
|
|
|
|
|
|
f: /usr/share/nginx/html/index.html
|
|
|
|
|
|
drwxr-xr-x root root /
|
|
|
|
|
|
drwxr-xr-x root root usr
|
|
|
|
|
|
drwxr-xr-x root root share
|
|
|
|
|
|
drwxr-xr-x root root nginx
|
|
|
|
|
|
drwxr-xr-x root root html
|
|
|
|
|
|
-rw-r--r-- root root index.html
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### Перезагрузите сервис
|
|
|
|
|
|
|
|
|
|
|
|
Если вы внесли изменения в файл конфигурации, которые не были применены, вы можете перезагрузить службу, запустив новые процессы Nginx и осторожно завершив работу старых рабочих процессов, чтобы избежать быстрого и агрессивного завершения работы.
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo systemctl reload nginx
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Для грубого перезапуска без ожидания завершения процессов используйте:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ sudo systemctl restart nginx
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### Включите режим отладки
|
|
|
|
|
|
|
|
|
|
|
|
В конфигурационном файле (обычно /etc/nginx/nginx.conf) измените уровень логирования директивой error_log:
|
|
|
|
|
|
```
|
|
|
|
|
|
server {
|
|
|
|
|
|
# stuff
|
|
|
|
|
|
error_log /var/logs/nginx/error.log debug;
|
|
|
|
|
|
# stuff
|
|
|
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Вы можете включить правило перезаписи журнала, чтобы увидеть результаты обработки в журнале ошибок:
|
|
|
|
|
|
```
|
|
|
|
|
|
server {
|
|
|
|
|
|
# stuff
|
|
|
|
|
|
error_log /var/logs/nginx/error.log notice;
|
|
|
|
|
|
rewrite_log on;
|
|
|
|
|
|
# stuff
|
|
|
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
#### Проверьте разрешение имён DNS
|
|
|
|
|
|
|
|
|
|
|
|
Правила в /etc/hosts имеют приоритет над разрешениями DNS. Вы можете проверить записи DNS с помощью:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ host -t Веб-сайт.com
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Вы также можете проверить полное разрешение DNS:
|
|
|
|
|
|
```
|
|
|
|
|
|
$ dig +trace веб-сайт.com
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Литература
|
|
|
|
|
|
|
|
|
|
|
|
- https://sre.google/sre-book/monitoring-distributed-systems/
|
|
|
|
|
|
- https://sre.google/sre-book/effective-troubleshooting/
|
|
|
|
|
|
- https://docs.rackspace.com/support/how-to/basic-nginx-troubleshooting/
|
