Pull to refresh

Comments 20

На правах бреда:

А что если написать демона на C который будет слушать сокет, и принимать логи, а затем писать их куда надо и в каком надо формате. Всяко мультипоточность на С организовать проще чем на php.
А зачем тогда вообще писать такого демона если есть syslog и подобные? :)
Тогда можно плагин к php написать.
это вариант - если вы имеет ввиду модуль к пхп типа длл или so
но тут у меня возникает вопрос (я не силен в си вообще) - а сможет ли модуль этот писать многопоточно в файл и выстраивать очередь из записей в лог ? (у меня пхп под fast-cgi)
В Си это возможно, т.к. у меня уровень только в написании модуля, а-ля Hello World, то увы не ко мне с советом, т.к. я еще и под винду это делал, а не под никсы.
над этим я тоже думал - тоже приемлемый вариант
А если какждый поток будет создавать свой лог, а отдельный скрипт будет собираться их в кучу по нужному алгоритму и подчищать?
Или например РНР будет создавать для каждого потока лог s893ffff.log и делать exec команды типа tail s893ffff.log > log перекладывая гимор на систему ? :)
Только написал коммент, а идея уже раскрыта)
отпадает - логов слишком много - машина просто одуреет их потом собирать...- специфика проекта
Я не разбирался с работой несколких потоков, но мысль есть. В начале работы приложения генерируем случайное имя файла, в процессе работы пишем в него. После записи нужно отметить, что запсиь лога завершена. Это можно сделать установив атрибут файла, либо записать что-нибудь в конец файла.

По расписанию запускается сборщик логов, ищет файлы, которые имеют метку конца записи (если скрипт пишущий в лог вылетел с ошибкой, и метки конца записи нет, проверять дату модификации). Затем, логи пишутся в один файл, оригинальные логи удаляются.
читать выше почему нет :(
не понял, о каких потоках идет речь в php. apache threaded mpm?

а вообще - error_log(3, $filename, $message)
речь идет о потоках фаст-цги - каждый запущеный интерпритатор - это поток который пишет в файл логов...
я уже склоняюсь к syslog либо error_log либо аналогичному расширению для пхп заточеного под собстыенные нужды
а, если fastcgi то error_log конечно. я думал это какое-то cli по крону, то что ниже - про него =)
а, понял - речь идет о нескольких _процессах_ и нужно писать в один файл и нормально ротироваться.

- запускаем ОДИН процесс
- делаем $hLog = fopen логфайла
- делаем fork() сколько надо раз
- в детках спокойно пишем в $hLog обычным fwrite
- обрабатываем какой-нибудь сингал (например HUP) по которому логфайл переоткрываем, при ротации файл переименовываем (но не перемещаем на другое устройство!) и шлем сигнал. т.к. хэгдл открытого файла увязан на inode а не на имя файла, до переоткрытия по сигналу все будет писаться в старый файл.
не пойдет форк из-за специфика приложения... грубо говоря это пхп скрипт обрабатывающий запросы юзеров - и он должен писать логи в один файл из разных процессов...

когда юзер 100 - еще ничего - flock хватает - а когда их сразу 10к - флок загибает сервер :)
поэтому наверное решение приму переходить на syslog, error_log либо самописного демона
просто у наших програмеров был опыт работы с log4c++ - и там дела обстоят просто супер - и масштабируемость неплохая - поэтому решили взять log4php - однако не протестили на реальной нагрузке - это нам наука - будем исправляться
а где ваш пофикшеный вариант можно взять? я бы очень хотел попробовать.. у меня нагрузки гораздо меньше, мне бы подошло, если не жалко.
в принципе я могу выложить его - там отфиксены всякие баги которые валили тучу ошибок при работе, и он заточен под нас, но я это вырежу.

если кто скажет можно ли на хабре делать вложения ?:) или мыльце дайте - я зашлю
Вариант вот какой — создать FIFO файл и на читающий конец повесить слушателя, который бы постоянно вычитывал оттуда записи в неблокирующем режиме в память (ту же самую FIFO очередь, но внутри памяти и не ограниченную лимитами система на FIFO файл), и в то же время писал бы эти данные в неблокирующем режиме из конца очереди в памяти сразу в файл. Получится что спокойно можно в несколько потоков писать в этот FIFO файл с другого конца применяя блокировки, поскольку вычитка с другого конца будет происходить моментально. Пример реализации (правда немного для других цели и с другой идеологией) можно подсмотреть в моей заметке о хитростяъх с логированием в однопоточных неблокирующих веб-серверахю
Sign up to leave a comment.

Articles