Программирование - утомительное, но в то же время увлекательное занятие. Одним из увлекательных аспектов является изучение новых способов использования старых средств. Недавно меня наняли, чтобы найти ошибки в большой и сложной LAMP-системе (Linux, Apache, MySQL, и Linux, Apache, MySQL, PHP/Perl) - системе управления содержимым (Content-Management System - CMS). Архитектура CMS представляла собой стандартную LAMP-модель на Enterprise Red Hat Linux с Apache V2.0. Код Web-сайтов состоял из нескольких сотен PHP-модулей, разбросанных по 30 подкаталогам каталога Apache document root. В Apache и MySQL изменения не потребовались, поэтому все мои усилия были сосредоточены на PHP.
Потратив много времени на изучение работы CMS и оценив ее изящество, я понял, что в самой зрелой программной среде эта система использовала лишь небольшое количество доступных PHP-функций (здесь бал правят тени старого правила 80/20 - 80% работы выполняется при помощи 20% доступных функций). В данной статье демонстрируется, как процесс отладки неизвестной сложной системы помогает узнать о малоиспользуемых функциях, а также приводятся примеры применения этих новых знаний в использовании богатых возможностей функции syslog().
Под микроскопом
Язык программирования PHP насчитывает буквально сотни функций, но некоторые (смею ли сказать, большинство?) никогда не используются, пока о них не прочтут в таких статьях, как эта. Другой способ узнать больше о языке состоит в том, чтобы отлаживать программы, которые написали на нем другие люди. Меня всегда впечатлял творческий подход программистов к использованию инструментария.
Отладка, как и программирование, частью наука, частью искусство. Отыскивая неочевидные ошибки в системе, созданной не вами, нужно обладать отличным чутьем, чтобы найти их в коде. Имея дело с сотнями модулей, правильно было бы начать с того места, где в выходной информации обнаруживается ошибка, а затем идти обратным ходом, чтобы локализовать проблему.
Предположим, например, что вычисленное значение, которое было выведено, является неправильным. Вы должны разработать какой-то способ увидеть промежуточные значения, приведшие к возникновению проблемы. Еще одна проблема может проявиться в случае получения неправильных данных в результате важного запроса к базе. Вы должны иметь возможность видеть сгенерированное SQL-утверждение, предоставляемое кодом MySQL-движку, чтобы понять, здесь ли причина проблемы.
Известная методика состоит в том, чтобы вставить код, который просто выводит эти строки и значения. К сожалению, работая с такими инструментами, как PHP или любые Web-приложения, можно замусорить естественную выходную информацию системы (т.е. HTML-код, посылаемый в браузер) отладочной информацией, особенно если исследуемая система является работающим сервером.
Можно было бы создать регистрационный файл и записывать в него отладочную информацию, но почему не использовать уже предоставленные вам инструменты? Помните: не стоит хоронить инструменты. Время, потраченное на изучение уже предоставленных авторами языка библиотек подпрограмм или функций в поисках нужной вам функции, - правильно потраченное время. Фактически, всегда чувствуется, когда что-либо должно очевидно быть частью программного пакета, и так оно, скорее всего, и есть.
Я понял, что нужная мне функциональность должна походить на syslog UNIX. Я подумал, что в PHP могла бы быть функциональности syslog, поэтому быстро просмотрел документацию по PHP и нашел ее! Я не замечал PHP-функцию syslog() много лет, пока меня не пригласили в этот проект. При помощи syslog() я смог определить и устранить большинство ошибок в работающей системе без побочных эффектов, не считая незначительного времени, необходимого для выполнения каждой функции.
Приобретая новые знания и повышая свою квалификацию, вы начинаете видеть различные способы сделать что-либо, и какой-нибудь один из них станет очевидным при решении задачи. Но всегда имейте в виду: то, что очевидно для вас, вовсе не очевидно для остальных. То, что просто для вас, может доставить кучу неприятностей другим.
Применение функции syslog() позволяет взять сложность под контроль и обеспечивает дополнительное преимущество - удобные настройки при помощи конфигурационных файлов, таких как syslog.conf. Например, можно вставить код для форматирования SQL-утверждения, записи его в syslog() и передачи в MySQL для выполнения. Затем небольшая модификация файла syslog.conf пошлет текст в другой системный журнал или, возможно, просто в битоприемник. Недели или месяцы спустя, если опять потребуется увидеть, что случилось, еще одно простое изменение в файле syslog.conf восстановит функциональность.
syslog
В мире UNIX у syslog богатая и яркая история. Разработанный первоначально как часть проекта Sendmail, syslog оказался настолько полезным, что в его функциональность было включено много других инструментов; тем самым было доказано, что иногда наиболее простые идеи являются наиболее мощными.
Коротко говоря, syslog позволяет приложениям записывать помеченные сообщения в общий набор системных журналов, которые могут храниться там, где это наиболее удобно для программистов и сетевых администраторов. Это означает, например, что можно настроить syslog на Web-сервере на запись системных сообщений на другой сервер, который, возможно, находится на несколько уровней глубже (за брандмауэрами), и к нему легче получить доступ. Но для моих целей достаточно поведения по умолчанию файлов, записываемых в каталог /var/log.
Механизм syslog запускает программа начального пуска, а его исходное поведение определяется правилами в файле syslog.conf. Данные правила позволяют точно указать, что может, а что не может быть записано механизмом - это дает возможность при больших нагрузках на сервере получать файлы журналов приемлемых размеров.
Каждое правило состоит из двух полей: селектора (selector) и действия (action). Селектор указывает, какие сообщения будут регистрироваться (например, ядра, пользователя, почты, принтера), а также приоритет. Поле приоритета содержит ключевые слова, такие как debug (отладка), info (информация), notice (уведомление) или warning (предупреждение). Поле действия определяет, что делать с сообщениями, соответствующими содержимому селектора. Правила могут определять файл для записи сообщения, механизм отправки регистрируемого сообщения, отправившего сообщение пользователя (в виде консольных сообщений) и т.д.
Запись информации
Изучите информацию и руководства по syslog, чтобы настроить систему в соответствии со своими требованиями. В моем случае нужно было знать значения различных PHP-переменных в разное время выполнения CMS. Кроме того, я должен был знать, когда были запущены и остановлены различные модули, а также значения различных промежуточных переменных. Прежде чем приступить к специфическим подробностям, давайте осуществим настройку.
Создайте в вашем любимом редакторе файл, приведенный в листинге 1, назовите его test.php и разместите там, где находится ваш Apache document root (на моей системе это /var/www).
<html>
<head>
<title>PHP Test Page</title>
</head>
<body>
<?php
syslog(LOG_NOTICE, "{$_SERVER['REMOTE_ADDR']}:
test.php - PHP Index page accessed.");
echo '<p>PHP Test Page</p>';
?>
</body>
</html>
|
Также у вас должен быть установлен и настроен PHP. Если все настроено надлежащим образом, при обращении к странице http://localhost/test.php вы должны увидеть в браузере следующий текст:
PHP Test Page |
Теперь откройте окно X-терминала и введите следующую команду, чтобы увидеть, что было записано в файл /var/log/messages:
tail /var/log/messages |
Если все прошло хорошо, в конце листинга вы должны увидеть следующую строку:
Jul 23 14:43:42 localhost apache2: 127.0.0.1: test.php - PHP Index page accessed. |
Если вы это сделали - прекрасно. Вы удостоверились, что у вас есть все необходимое для детальной отладки сложной системы и можно продолжать работу.
Я нашел хороший способ использования syslog() для всех вызовов PHP/MySQL, так что всякий раз, взаимодействуя с Web-сайтом, вы сможете видеть в режиме реального времени, какие сгенерированы SQL-запросы для построения возвращаемой вам страницы. Удобный способ сделать это состоит в том, чтобы открыть дополнительное окно X-терминала и использовать команду tail с параметром -f для просмотра "вживую" журнала сообщений:
tail -f /var/log/messages |
Что записывать
Теперь, когда вы убедились, что запись информации работает и можно увидеть результаты ее работы, я дам несколько советов, как сократить процесс изучения незнакомой системы, поскорее начав использовать данные инструменты.
Важно знать, какие модули делают что-то сверх того, что написано в документации. Поэтому я люблю записывать сообщения, отмечающие начало и конец модулей. Таким образом, можно поиграться со страницами Web-сайта, наблюдая за дополнительным окном X-терминала, где выполняется команда tail -f /var/log/messages. Вы увидите, какие модули выполняются, а также в каком порядке каждый раз браузер запрашивает новую страницу.
Я также люблю регистрировать границы между различными программами, вызываемыми в процессе выполнения PHP-кода. Например, когда сделаны MySQL-запросы или вызваны внешние программы, изменяющие форматирование данных (Extensible Stylesheet Language Transformation (XSLT) механизмы, к примеру). Практика систематического размещения таких контрольных точек в коде каждого модуля поможет привыкнуть к названиям и местоположению модулей. В то же самое время, когда код отправляет сообщения, отображаемые в дополнительном X-терминале, вы просматриваете различные страницы, имея, таким образом, важную обратную связь, облегчающую и углубляющую ваше понимание системы.
Заключение
Средство syslog - мощный инструмент для отладки приложений, написанных не вами. Он позволяет наблюдать, какие модули и SQL-утверждения выполняются, а также значения каких переменных изменяются, когда вы ходите по Web-сайту. Это помогает точно определять модули, в которых, вероятно, имеются проблемы.