--- title: "Логи баз данных PostgreSQL" description: "Логи облачных баз данных MySQL. Документация и инструкции по использованию и настройке облачных сервисов Timeweb Cloud." --- # Логи баз данных > Полный индекс документации для ИИ-агентов: [llms.txt](https://timeweb.cloud/llms.txt). Мы собираем и выводим в панель управления логи сервисов баз данных, которые они автоматически генерируют в стандартные файлы логов. С помощью логов можно быстро отследить возможные ошибки и оперативно на них отреагировать — самостоятельно или обратившись в нашу поддержку. Просмотреть логи можно на вкладке «Логи». ![8aa75574 Ca0d 4400 9675 2308996ef24c](https://content.timeweb.com/assets/a0da3cee-a1e1-45c2-b44c-af96328130c3.png?width=1551&height=1177) Для PostgreSQL мы выводим основной лог ошибок (PostgreSQL Log), расположенный по пути `/var/log/postgresql/postgresql--main.log`. Он полезен для общего мониторинга состояния кластера, диагностики сбоев, анализа подключений и запросов. Лог содержит следующие типы информации: - `ERROR`, `FATAL`, `PANIC`: Критические ошибки, приводящие к прерыванию сеанса или работы сервера. - `WARNING`: Предупреждения о потенциальных проблемах. - `INFO`: Общая информация о работе сервера (например, запуск, остановка, контрольные точки). - `LOG`: Стандартные информационные сообщения (например, подключения, завершения длительных транзакций, контрольные точки). > [!NOTE] > В целях безопасности из всех логов автоматически удаляются записи, содержащие фразы `WITH LOGIN PASSWORD` или `WITH PASSWORD`, чтобы исключить возможность утечки паролей. ## Сценарии использования Рассмотрим примеры использования логов на практике. Для удобного поиска информации в логе его можно скачать в формате `.txt`. ![568eeae2 8dc0 41eb Beac 85c758f27e17](https://content.timeweb.com/assets/6d55af2c-4c27-45df-96da-2ab72b917652.png?width=1542&height=1155) #### Кейс 1: Внезапный рост потребления vCPU В этом случае нам нужно определить запрос, создающий повышенную нагрузку. Для этого можно проанализировать лог медленных запросов (`log_min_duration_statement`) и быстро выявить операции, которые выполняются дольше других и активно потребляют процессорные ресурсы. Это позволит оперативно оптимизировать проблемный запрос или добавить недостающий индекс. #### Кейс 2: Частые разрывы соединения у приложения Здесь нам нужно определить причину обрыва подключений к БД. Для этого можно проанализировать лог ошибок и проверить, появляются ли в момент разрыва сообщения уровня `FATAL` или `ERROR`. Логи позволяют указать на конкретную причину — например, нехватка памяти, превышение таймаута или лимита подключений. Такой анализ помогает понять, связано ли поведение с сетевыми проблемами, ограничениями ресурсов или ошибками конфигурации.