Мы собираемся установить развертывание, где у нас будет много серверов, большинство из которых автоматически добавляются в балансировщик нагрузки, когда трафик увеличивается. Проблема с этой настройкой заключается в том, что если отдельному разработчику необходимо зайти в журнал для устранения каких-либо проблем, ему придется открывать консоль на каждом сервере, что осложняется тем фактом, что разработчик часто не знает, КАК многие серверы мы могли бы имеют функцию в то время.
Если разработчик может найти все журналы на одном сервере – скажем, наш сервер развертывания, то устранение неполадок становится проще.
В связи с этим я подумывал настроить push с каждого компьютера FE на сервер развертывания, используя cron, который будет реплицировать журналы на нашем сервере развертывания. С этим подходом существуют две проблемы:
Чтобы решить эту проблему, я рассматриваю способ подключения error_log или PEAR Log для отправки журналов непосредственно на наш сервер развертывания, который будет регистрировать его в реальном времени в локальных локациях в / var / log / ..
Кто-нибудь знает, как я могу это настроить? Или, может быть, услуга, которая это выполняет?
Наши серверы – это Ubuntu 10.04 LTS, и мы запускаем эти серверы на экземплярах EC2 в AWS. Наша версия PHP – 5.3.
Что вы можете сделать, так это войти в пользовательский канал syslog, который записывает на центральный сервер ведения журнала.
php.ini
error_log = syslog
syslog-ng.conf в php-блоках
destination php { tcp("10.10.10.10" port(5140)); }; log { source(src); filter(f_php); destination(php); };
Это отправит все протоколы php в поле 10.10.10.10 где syslog-ng прослушивает порт 5140 .
В вашем блоке регистрации вы должны открыть порт 5140 в группе безопасности ec2
Вот хороший учебник по настройке сервера syslog
http://praxis.edoceo.com/howto/syslog-ng
EDIT: Это, конечно же, также позволит регистрировать другие важные источники журналов ваших php-боксов на сервере журнала. Думая о журналах трафика, системных журналах и т. Д.
Ответ от @MichelFeldheim был генезиса, но мы улучшили его, чтобы обрабатывать несколько приложений, записывая несколько файлов журнала.
Центральный сервер регистрации
На центральном сервере регистрации установите syslog-ng и настройте его таким образом:
sudo apt-get install syslog-ng
добавьте следующее в /etc/syslog-ng/syslog-ng.conf:
destination d_php { file("$PROGRAM" owner(www-data) group(www-data) perm(0644)); }; filter f_php { program("^\/var\/log\/"); }; log { source(s_all); filter(f_php); destination(d_php); flags(final); }; source s_all { # .... # .... LET THE PREVIOUS CONTENT STAY - add the following line tcp(port(5140) keep_alive(yes)); };
перезапустить службу syslog:
sudo service syslog-ng restart
На серверах FE
На каждом из FE-серверов установите syslog-ng и настройте его таким образом:
sudo apt-get install syslog-ng
добавьте следующее в /etc/syslog-ng/syslog-ng.conf на каждом из FE-серверов:
destination php { tcp("log.example.com" port(5140)); }; log { source(s_all); filter(f_php); destination(php); }; filter f_php { facility(user); };
перезапустить серверы syslog:
sudo service syslog-ng restart
Изменения кода приложения :
Теперь код приложения можно изменить таким образом. Предположим, что каждое приложение имеет код, подобный этой записи, в отдельный файл, и вы хотите, чтобы одна и та же структура отражалась на центральном лог-сервере:
// PREVIOUS CODE: using PEAR Log include '/usr/share/php/Log.php'; $log = Log::singleton('file', '/var/log/nginx/xxx.log', '', array(), PEAR_LOG_INFO); // PREVIOUS CODE: Using error_log ini_set('error_log' , '/var/log/nginx/xxx.log');
Новый код должен выглядеть так:
// NEW CODE: using PEAR Log include '/usr/share/php/Log.php'; $log = Log::singleton('syslog', LOG_USER, '/var/log/nginx/xxx.log', array(), PEAR_LOG_INFO); // NEW CODE: Using error_log ini_set('error_log', 'syslog'); openlog('/var/log/nginx/xxx.log', LOG_NDELAY, LOG_USER);
Если ваши FE-серверы и серверы ведения журнала находятся в одной группе безопасности EC2, нет необходимости открывать порты, так как в пределах групп все порты могут быть доступны свободно, пока служба его прослушивает.
Этот подход позволяет каждому из ваших приложений, модулей решать, хотят ли они централизованного ведения журнала или нет.