---

Ниже представлено решение на индивидуальное практическое задание по теме «Работа с сервером: чтение логов, диагностика и устранение типовых ошибок».

### Решение индивидуального задания

#### Часть 1. Чтение и базовый анализ логов веб-сервера (Apache)

**Сценарий:** Пользователь жалуется, что не может получить доступ к файлу `report.pdf` на сайте `www.example.com`. В браузере отображается ошибка "403 Forbidden".

**Задание:** Проанализировать фрагмент лога доступа (`access.log`) и определить причину проблемы.

**Фрагмент лога:**
```
192.168.1.50 - - [29/May/2026:11:20:01 +0300] "GET /downloads/report.pdf HTTP/1.1" 403 205 "-" "Mozilla/5.0"
192.168.1.50 - - [29/May/2026:11:20:05 +0300] "GET /index.html HTTP/1.1" 200 4523 "-" "Mozilla/5.0"
```

**Решение:**
1.  **Анализ строки запроса:**
    *   IP-адрес клиента: `192.168.1.50`.
    *   Время запроса: `[29/May/2026:11:20:01 +0300]`.
    *   Метод и ресурс: `"GET /downloads/report.pdf HTTP/1.1"` — клиент пытается получить файл `report.pdf` из каталога `/downloads/`.
    *   Код ответа сервера: `403`. Этот код означает "Forbidden" (Запрещено). Сервер понял запрос, но отказывается его выполнять. Это отличается от кода `404 Not Found`, который бы означал, что файла нет.
    *   Размер ответа: `205` байт. Для ошибки 403 это обычно размер страницы-заглушки, которую сервер отправляет клиенту.

2.  **Вывод:** Проблема заключается в правах доступа. Веб-сервер имеет права на чтение файла и каталога, в котором он находится, но не имеет прав на выполнение (поиска) для одного из родительских каталогов или самого каталога `/downloads/`. Без флага "execute" на каталоге сервер не может "зайти" в него, чтобы прочитать содержимое и отдать файл.

3.  **Устранение ошибки:**
    Необходимо проверить права доступа к каталогу `/downloads/` и всем его родителям. Права должны быть установлены как минимум на `r-x` (755), чтобы пользователь, от имени которого запущен веб-сервер (например, `www-data`), мог просматривать каталог и получать файлы из него.
    ```bash
    # Проверка текущих прав
    ls -ld /var/www/html/downloads/

    # Установка правильных прав (если веб-корень в /var/www/html)
    chmod 755 /var/www/html/downloads/
    ```

---

#### Часть 2. Диагностика системной ошибки (Service Failure)

**Сценарий:** Внутренний мониторинг сообщает, что сервис базы данных перестал отвечать. Служба `postgresql` неактивна.

**Задание:** Провести диагностику, используя системные логи, и предложить план действий.

**Решение:**
1.  **Проверка статуса службы:**
    Сначала необходимо убедиться в статусе сервиса с помощью команды `systemctl`.
    ```bash
    sudo systemctl status postgresql
    ```
    Предположим, команда вывела:
    > `Active: failed (Result: exit-code)`
    Это подтверждает, что служба завершилась с ошибкой при попытке запуска.

2.  **Чтение логов службы:**
    Для диагностики причины сбоя необходимо просмотреть журнал этой службы.
    ```bash
    sudo journalctl -u postgresql.service --since "today"
    ```
    В выводе журнала находим критическую ошибку:
    > `FATAL: could not create shared memory segment: Cannot allocate memory`
    > `DETAIL: Failed system call was shmget(key=..., size=..., 03600).`

3.  **Интерпретация ошибки:**
    Ошибка `Cannot allocate memory` указывает на нехватку оперативной памяти (RAM) на сервере. PostgreSQL не смог зарезервировать необходимый ей сегмент разделяемой памяти (*shared memory*) для своей работы.

4.  **План устранения:**
    *   **Краткосрочное решение (перезапуск):** Если проблема вызвана временным всплеском нагрузки, можно попытаться освободить память, перезапустив службу. Иногда после завершения других процессов система сможет выделить память.
        ```bash
        sudo systemctl restart postgresql
        ```
    *   **Долгосрочное решение (анализ и масштабирование):** Необходимо проанализировать потребление памяти на сервере (`free -h`, `top`).
        *   Если нагрузка легитимная и будет расти, требуется увеличить объем оперативной памяти на сервере.
        *   Можно оптимизировать конфигурацию самой СУБД (параметры `shared_buffers`, `work_mem` в файле `postgresql.conf`), чтобы она потребляла меньше ресурсов.
        *   Выяснить, какой другой процесс потребляет избыточное количество памяти, и принять меры.

---

#### Часть 3. Анализ логов приложения (PHP-FPM)

**Сценарий:** Пользователи периодически видят на сайте "белый экран смерти" (Blank Page) без каких-либо сообщений об ошибках.

**Задание:** Найти причину в логах PHP-FPM и исправить ее.

**Решение:**
1.  **Локализация лог-файлов:**
    Логи PHP-FPM обычно находятся в директории `/var/log/php-fpm/` или `/var/log/`. Определим точный путь, проверив пул в конфиге `/etc/php/*/fpm/pool.d/www.conf`. Ищем директиву `error_log`.

2.  **Анализ лога:**
    Открываем указанный лог-файл (например, `sudo tail -f /var/log/php7.4-fpm.log`) и видим повторяющиеся записи:
    > `[29-May-2026 11:25:10] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it`
    > `[29-May-2026 11:25:10] WARNING: [pool www] seem to be overloaded, launching 5 children...`

3.  **Интерпретация ошибки:**
    Эти сообщения говорят о том, что все рабочие процессы PHP-FPM (`children`) заняты обработкой входящих запросов. Новые запросы встают в очередь, а когда очередь переполняется, они просто отбрасываются. Клиент получает пустой ответ, так как его запрос даже не был обработан.

4.  **Устранение ошибки:**
    *   **Диагностика:** Нужно понять природу нагрузки. Это кратковременный пик (например, запуск тяжелого скрипта администратором) или постоянная высокая посещаемость?
    *   **Оптимизация конфигурации:** Отредактировать настройки пула в файле `/etc/php/*/fpm/pool.d/www.conf`.
        *   Увеличить значение `pm.max_children` (например, до 10 или 15), если у сервера достаточно оперативной памяти для этого.
        *   Изменить политику управления процессами (`pm = ondemand` или `dynamic`) и их лимиты (`pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`), чтобы лучше соответствовать реальной нагрузке.
    *   **Оптимизация кода:** Если высокая нагрузка вызвана неэффективным скриптом, следует профилировать и оптимизировать его.
    После внесения изменений в конфиг необходимо перезапустить службу PHP-FPM:
    ```bash
    sudo systemctl restart php8.1-fpm
    ```