WordPress — это удивительная разработка. Неудивительно, что более четверти всех сайтов на базе CMS используют его . В действительности же сайты WordPress рушатся, как и любой другой сайт. Плохие плагины или темы, вызывающие «экран смерти WordPress» или обновления WordPress на юг, встречаются слишком часто.
Когда что-то идет не так, одной из первых вещей, которую вы захотите посмотреть, являются файлы журнала. Не потому, что вам это нравится — файлы журнала нелегко расшифровать, а потому, что они содержат ценную информацию, которая может пролить свет на то, что именно произошло.
Однако в современных условиях эта задача является сложной задачей. В то время как администраторам WordPress, возможно, никогда не понадобится слышать слово «log», веб-разработчикам и командам DevOps, работающим на сайте, часто приходится проходить строки за строками файлов журнала, чтобы понять, что пошло не так.
«Итак, что нового?» — спросите вы. В конце концов, существует множество плагинов WordPress, таких как WP Log Viewer, которые позволяют легко просматривать эти журналы из панели администратора WordPress.
Хотя это и правда, анализа логов WordPress и PHP просто недостаточно. Есть также веб-сервер и журналы базы данных, чтобы просеять. Для успешного запроса огромных объемов сообщений журнала, поступающих из разных источников, и выявления корреляций, требуется более надежное решение.
Войдите в стек ELK . ELK — самая популярная и быстро развивающаяся платформа для анализа журналов с открытым исходным кодом, позволяющая создать централизованную систему ведения журналов, которая может извлекать журналы из любого количества источников, которое вы определяете, а затем анализировать и визуализировать эти данные.
Чтобы показать пример использования ELK, в этой статье будут рассмотрены этапы создания конвейера журналов из вашего приложения WordPress в стек Logz.io ELK . Вы можете, если хотите, использовать любой экземпляр стека для выполнения точно таких же процедур.
Включение ведения журнала для приложений WordPress
Первый шаг — настроить WordPress для записи логов. Для этого мы собираемся ввести некоторые определения в наш файл wp-config .
Сначала мы изменим значение WP_DEBUG на true :
define( 'WP_DEBUG', true );
Теперь вы начнете видеть ошибки PHP, уведомления и предупреждения, а также сообщения отладки WordPress на страницах вашего приложения.
Далее мы включим функцию регистрации в WordPress:
define( 'WP_DEBUG_LOG', true );
Это сохранит все сообщения об ошибках в файле debug.log расположенном в каталоге /wp-content/ вашего приложения.
Если вы не хотите, чтобы сообщения об ошибках отображались на страницах вашего приложения, используйте WP_DEBUG_DISPLAY — это еще одна константа, которая позволяет вам контролировать показ сообщений WP_DEBUG внутри HTML вашего сайта. Чтобы изменить поведение по умолчанию, отображающее ошибки на экране, измените значение на false чтобы скрыть все сообщения:
define( 'WP_DEBUG_DISPLAY', false );
Еще одна полезная опция — это определение SAVEQUERIES, которое сохраняет запросы к базе данных в массив. Затем вы можете использовать этот массив, чтобы помочь проанализировать проблемы:
define( 'SAVEQUERIES', true );
Каждый запрос будет сохранен вместе с информацией о том, сколько времени потребовался для выполнения запроса, и функцией, которая его вызывала.
Сохраните вашу конфигурацию.
Вы все готово! Чтобы проверить создание файла debug.log , смоделируйте ошибку (вы можете использовать функцию error_log() ), а затем найдите и откройте файл. Если файла нет, вы еще не вызвали ошибку.
Конечно, использование WP_DEBUG не рекомендуется в производственной среде, поэтому будьте осторожны с тем, как вы его используете и какие определения вы используете (например, определение SAVEQUERIES может значительно замедлить ваш сайт).
Доставка бревен в ELK
Теперь, когда мы включили ведение журналов для нашего приложения WordPress, следующим шагом является сбор нового файла журнала и его отправка вместе с журналами Apache в стек ELK для анализа. Для этого мы будем использовать Filebeat, средство доставки журналов от Elastic, которое следит за файлами журналов и отправляет отслеживаемые данные в Logstash или Elasticsearch.
Установка Filebeat
Я использую Ubuntu 14.04 и собираюсь установить Filebeat из репозитория (если вы используете другую ОС, здесь приведены дополнительные инструкции по установке ).
Сначала я собираюсь скачать и установить открытый ключ подписи:
curl https://packages.elasticsearch.org/GPG-KEY-elasticsearch | sudo apt-key add -
Далее я собираюсь сохранить определение репозитория в /etc/apt/sources.list.d/beats.list :
echo "deb https://packages.elastic.co/beats/apt stable main" | sudo tee -a /etc/apt/sources.list.d/beats.list
Наконец, я собираюсь запустить apt-get update и установить Filebeat:
sudo apt-get update && sudo apt-get install filebeat
Logz.io использует TLS в качестве дополнительного уровня безопасности, поэтому следующим шагом перед настройкой конвейера данных является загрузка сертификата и его перемещение в правильное местоположение:
wget http://raw.githubusercontent.com/cloudflare/cfssl_trust/master/intermediate_ca/COMODORSADomainValidationSecureServerCA.crt sudo mkdir -p /etc/pki/tls/certs sudo cp COMODORSADomainValidationSecureServerCA.crt /etc/pki/tls/certs/
Настройка Filebeat
Нашим следующим шагом будет открытие файла конфигурации Filebeat в /etc/filebeat/filebeat.yml и настройка Filebeat для отслеживания определенных файлов журнала и вывода их в экземпляр Logzash Logz.io.
В разделе Prospectors мы определим файлы, к которым мы хотим привязать Filebeat: в этом случае наши файлы журнала Apache ( /var/log/apache2/*.log ), а также файл отладки WordPress ( /var/www/html/wordpress/wp-content/debug.log ). Если вы используете Nginx, измените соответственно.
Для каждого исследователя мы определим тип журнала (Apache, WP) — это помогает различать различные сообщения журнала, когда они начинают накапливаться в нашей системе ELK, и позволяет нам легче анализировать их.
Мы также добавим некоторые дополнительные поля, специфичные для Logz.io (кодек и токен пользователя) для каждого исследователя.
Конфигурация выглядит следующим образом:
################### Filebeat Configuration Example ######################### ############################# Filebeat ##################################### filebeat: # List of prospectors to fetch data. prospectors: # This is a text lines files harvesting definition - paths: - /var/www/html/wordpress/wp-content/debug.log fields: logzio_codec: plain token: tWMKrePSAcfaBSTPKLZeEXGCeiVMpuHb fields_under_root: true ignore_older: 24h document_type: WP - paths: - /var/log/apache2/*.log fields: logzio_codec: plain token: tWMKrePSAcfaBSTPKLZeEXGCeiVMpuHb fields_under_root: true ignore_older: 24h document_type: apache registry_file: /var/lib/filebeat/registry
Далее в разделе «Вывод» файла конфигурации мы определим хост Logzash Logz.io ( listener.logz.io:5015 ) в качестве места назначения вывода для наших журналов и расположение сертификата TLS, используемого для аутентификации.
############################# Output ######################################## # Configure what outputs to use when sending the data collected by the beat. output: logstash: # The Logstash hosts hosts: ["listener.logz.io:5015"] tls: # List of root certificates for HTTPS server verifications Certificate_authorities: ['/etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt']
Теперь, если вы используете ELK-стек с открытым исходным кодом, вы можете отправить его напрямую в Elasticsearch или использовать Logstash. Конфигурация для любого из этих выходов в этом случае проста:
Output: logstash: hosts: ["localhost:5044"] elasticsearch: hosts: ["localhost:9200"]
Сохраните свою конфигурацию Filebeat.
Настройка Logstash
Logstash, компонент в стеке, отвечающий за анализ журналов перед их пересылкой в Elasticsearch, может быть настроен на манипулирование данными, чтобы сделать журналы более удобочитаемыми и легко анализируемыми.
В нашем случае мы будем использовать плагин grok для разбора наших логов WordPress. Теперь, если мы используем Logz.io, о гроккингах позаботятся о нас. Но если вы используете ELK с открытым исходным кодом, просто примените следующую конфигурацию непосредственно к вашему файлу конфигурации /etc/logstash/conf.d/xxxx.conf ( /etc/logstash/conf.d/xxxx.conf ):
if [type] == "WP" { grok { match => [ "message", "\[%{MONTHDAY:day}-%{MONTH:month}-%{YEAR:year} %{TIME:time} %{WORD:zone}\] PHP %{DATA:level}\: %{GREEDYDATA:error}" ] } mutate { add_field => [ "timestamp", "%{year}-%{month}-%{day} %{time}" ] remove_field => [ "zone", "month", "day", "time" ,"year"] } date { match => [ "timestamp" , "yyyy-MMM-dd HH:mm:ss" ] remove_field => [ "timestamp" ] } }
Проверка конвейера
Пришло время убедиться, что конвейер журналов в ELK работает как положено.
Во-первых, убедитесь, что Filebeat работает:
cd /etc/init.d ./filebeat status
И если нет, введите:
sudo ./filebeat start
Затем откройте Kibana (интегрирован в пользовательский интерфейс Logz.io). Журналы Apache и ошибки WordPress начнут появляться в главной области экрана.
Анализировать логи
ELK предназначен для больших данных. Таким образом, платформа позволяет просеивать большие объемы поступающих сообщений, запрашивая компонент хранилища стека — Elasticsearch.
Чтобы разобраться в данных, выберите одно из сообщений в основной области дисплея — это даст вам представление о том, какая информация доступна. Помните другой тип, который мы определили для поисковиков Filebeat? Чтобы сделать этот список сообщений более понятным, выберите поля type , response , level и error из списка отображенных полей слева.
Теперь предположим, что вы хотите отфильтровать результаты, чтобы видеть только сообщения, поступающие из файла debug.log WordPress. Есть несколько способов сделать это, самый простой из которых — ввести следующий запрос на уровне поля в поле запроса Kibana в верхней части страницы:
type:WP
Снова откройте одно из сообщений и просмотрите информацию, которая была отправлена в систему. Вот пример ошибки базы данных, записанной PHP в файл debug.log и перенаправленной в стек ELK:
[01-Jun-2016 14:03:11 UTC] PHP Warning: mysqli_real_connect(): (28000/1045): Access denied for user 'ro'@'localhost' (using password: YES) in /var/www/html/wordpress/wp-includes/wp-db.php on line 1490
Сохранить поиск. Мы будем использовать его для создания визуализации на следующем шаге.
Визуализация журналов
Наш следующий шаг — попытаться создать графическое изображение данных, создав новую визуализацию Kibana. В качестве примера, мы собираемся создать круговую диаграмму, дающую нам разбивку различных зарегистрированных ошибок PHP и WordPress.
Выберите вкладку «Визуализация» в Kibana и выберите из списка доступных визуализаций тип визуализации «Круговая диаграмма».
Далее выберите создание визуализации на основе нашего сохраненного поиска выше и настройте ее следующим образом:
Мы используем простое объединение терминов, используя поле level чтобы показать счетчик для 5 основных типов ошибок. Нажмите зеленую кнопку Play, чтобы увидеть предварительный просмотр визуализации:
Это простой пример того, как ваши данные журнала WordPress могут быть визуализированы в Kibana. То же самое относится к вашим журналам Apache и любому другому источнику данных, который вы конфигурируете для интеграции с ELK, и, когда у вас есть серия визуализаций для мониторинга вашего приложения WordPress, вы можете добавить их, чтобы создать панель мониторинга, дающую вам общий обзор вашей среды. ,
Написание пользовательских журналов
Другой вариант — записать свои собственные журналы в файл журнала.
Разработка на основе журналов (LDD) — это методология разработки, включенная в культуру DevOps, которая основана на том, что разработчики пишут и отслеживают журналы как неотъемлемую часть своего процесса разработки.
Используя функцию error_log() , вы можете записать пользовательские сообщения в файл журнала WordPress для последующего использования в ELK. Примерами использования этой функции могут быть наблюдения за чтением определенной строки кода или даже при посещении определенной страницы.
Финальная нота
Возможность централизовать ведение журнала всех компонентов и сервисов, на которые опирается ваше приложение, является ключом к отслеживанию вашей среды, особенно если ваше приложение работает в облачной инфраструктуре, в которой несколько служб работают за скрытой завесой.
Хотя WordPress поддерживает различные подключаемые модули ведения журналов, ни один из них не позволяет сопоставлять журналы с дополнительными источниками данных, такими как веб-сервер, база данных или балансировщик нагрузки. Централизованное ведение журнала с помощью ELK позволяет вам делать это вместе с возможностью анализа данных и создания панелей мониторинга, которые помогут вам визуализировать их.