Постоянный парсинг лог-файла

@pixel · Регистрация: 19.05.2009

Author24 — интернет-сервис помощи студентам

Приветствую.
На хостинге автоматом создается лог в текстовом файле с данными по запросу страниц и т.п. Хотелось бы все эти данные видеть в БД а не в текстовике, для оперативной сортировки и выборки, соответственно нужно парсить, но есть вопрос. При заполнении файла сверх определенного объема, файл упаковывается в архив, соответственно при парсинге нужно не только раскидывать данные, но еще и удалять строки, которые уже пропарсились. Как это реализовать, что бы не получить ошибку при одновременной попытке доступа к файлу от скрипта и от ядра системы?

Vovan-VE · 13.05.2013, 17:21

Можно запоминать позицию в файле, до которой дочитали в последний раз, чтобы в следующий продолжать с этой позиции. ftell() и fseek(). Если Ваш лог по размеру не превышает 2ГБ, можно даже не бояться переполнения PHP'шного int32.

@pixel · 13.05.2013, 17:25 **[ТС]**

лог упаковывается не привысив 100 кБ. Запоминать позицию нет смысла, т.к. нужно читать строку, разбивать на значения, отправлять их в БД и удалять строку. Но вдруг данная операция попадет на то же время когда система захочет внести в файл новые данные?

Vovan-VE · 13.05.2013, 17:32

Сообщение от pixel

когда система захочет внести в файл новые данные?

По идее, она его заблокирует только от записи, но не от чтения, так что прочитать должно быть можно.

Сообщение от pixel

отправлять их в БД и удалять строку

Удалять строку из файла? Вы его только читаете. Вместо "удалять строку" Вы смотрите запоминаете текущую позицию, до куда дочитали (ftell()). При следующей попытке Вы сразу перемещаетесь (fseek()) на то же место (при условии, что это всё еще тот же файл, дописанный в конце новыми данными) и читаете дальше.

@pixel · 13.05.2013, 17:38 **[ТС]**

Сообщение от Vovan-VE

при условии, что это всё еще тот же файл, дописанный в конце новыми данными) и читаете дальше.

так я про что и говорю. файл пишется до 100 кБ, потом упаковывается под другим именем. Соответственно, нужно регулярно считывать данные из файла и чистить его, что бы не было переполнения.

@AndreyDyakonov · 13.05.2013, 17:39

А что вам мешает вести лог в просто в бд? тем более с вашими размерами логов..

@pixel · 13.05.2013, 17:47 **[ТС]**

логи создаются системой у хостера. я в панеле управление поставил галки ведения логов, вот и получаю их. соответственно и размер указан у хостера (я не настраивал). а на мой вопрос, по поводу получения этих данных в БД, они сказали что это не возможно.

@AndreyDyakonov · 13.05.2013, 17:57

Но, как можно понять из вашего вопроса, вы имеете доступ из своих скриптов к файловой системе где хранятся логи? если так, то можно cron-ом читать эти файлы и заносить данные из них в базу.. уникальность строки проверять по времени записи(в логе это же должно быть). А хостер, что хочет, то пусть и делает дальше с этими логами.. Ну как вариант..

@pixel · 13.05.2013, 18:01 **[ТС]**

естественно доступ к своему каталогу на файловом уровне у меня есть. естественно, скрипт парсинга запускаться будет кроном. меня волнует вопрос одновременного доступа к одному файлу и от скрипта и от системы. Мне нельзя не чистить файл, т.к. парсинг все равно сработает позднее чем система обновит лог, поэтому получится так: лог на грани переполнения, заносится строка, файл закрывается, упаковывается, создается новый файл, записывается следующая строка, файл закрывается. а потом скрипт недосчитывается как минимум одной строки данных. Что бы этого избежать, нужно чистить лог. тогда и файл не переполнится и все нужные данные будут перенесены в БД.

@AndreyDyakonov · 13.05.2013, 18:13

Сообщение от pixel

т.к. парсинг все равно сработает позднее чем система обновит лог, поэтому получится так: лог на грани переполнения, заносится строка, файл закрывается, упаковывается, создается новый файл, записывается следующая строка, файл закрывается. а потом скрипт недосчитывается как минимум одной строки данных

Скорее всего так и будет...
Вариант один: читаете последний упакованный файл плюс то, что неупаковано. Конечно если ваш хостер пакует адекватным архиватором.
Другой вариант: делать свою схему логгирования.. Имхо это намного проще..
Извините если зря потратил ваше время

@pixel · 13.05.2013, 18:40 **[ТС]**

Сообщение от AndreyDyakonov

Скорее всего так и будет...
Вариант один: читаете последний упакованный файл плюс то, что неупаковано. Конечно если ваш хостер пакует адекватным архиватором.
Другой вариант: делать свою схему логгирования.. Имхо это намного проще..
Извините если зря потратил ваше время

на выходе *.gz. я уже тоже подумал об архивах, но это не очень удобно. Касательно ж "своей схемы логгирования" - это как? в лог-файл попадают данные посещения страниц сайта типа так:
somesite.ru 66.249.78.165 - - [13/May/2013:17:33:01 +0400] "GET / HTTP/1.0" 200 15200 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
somesite.ru 178.151.216.53 - - [13/May/2013:17:36:30 +0400] "GET / HTTP/1.0" 200 15200 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
каким образом я могу реализовать сбор данных всех подключений ко всем страницам сайта?

@hara · 13.05.2013, 19:23

Насколько критично время обновления данных из логов?

Если не критично (допустим вам просто нужно строить отчёты за час, день, сутки)
можно брать уже упакованный файл, распаковывать, парсить и разом записывать в базу.
Затем раз в минуту проверять не обновился ли файл(по дате). Как только обновился, - повторять процедуру.

Т.к. скорее всего имя файла всегда одинаково. Раз там архивация то скорее всего ротация логов. С дописыванием в конец файла цифры. Т.е. имя файла всегда одно.

Например: mysite-error.log
ротируется скорее всего в mysite-error.log.1.gz - т.е. всегда одно и тоже имя.

В общем ответ основан на предположениях. Но если всё совпадает вполне рабочий вариант.

@AndreyDyakonov · 13.05.2013, 19:36

Сообщение от pixel

каким образом я могу реализовать сбор данных всех подключений ко всем страницам сайта?

сейчас стало почти стандартом(Де факто правда), что все запросы пользователей переадресуются на index.php. Там и можно начинать все ловить. Если у вас не так... сложнее конечно.. нужен скрипт простенький по добавлению записи в бд и инклюдить его на каждую страницу...

Добавлено через 3 минуты
а время записи в лог парсить регуляркой... если всетаки хочется ковырять архивы.

Не по теме:

проще договориться с хостером или поменять его. сейчас беспроблемные бесплатные хостеры имеются в достаточном количестве... зачем цеплятся за хостера

@pixel · 13.05.2013, 19:54 **[ТС]**

Сообщение от AndreyDyakonov

сейчас стало почти стандартом(Де факто правда), что все запросы пользователей переадресуются на index.php. Там и можно начинать все ловить. Если у вас не так... сложнее конечно.. нужен скрипт простенький по добавлению записи в бд и инклюдить его на каждую страницу...

Дело в том, что сайт на WordPress, соответственно, нужно инклюдить в кучу файлов - не удобно. Да и какой именно "простенький скрипт"?

Сообщение от AndreyDyakonov

Не по теме:

проще договориться с хостером или поменять его. сейчас беспроблемные бесплатные хостеры имеются в достаточном количестве... зачем цеплятся за хостера

Ну во-первых, у меня платный хостинг, а во вторых, на этом хостинге несколько проектов, переносить их все - смысл?

@AndreyDyakonov · 13.05.2013, 20:04

Сообщение от pixel

Дело в том, что сайт на WordPress

приплыли.. как в любой сms там должна быть переадрессация на index.php или не наю как там называется входной файл. В начале выполнения программы проверяйте и логгируйте все что вам нужно..
Либо подпирать костылями с распаковкой архивов...

@pixel · 13.05.2013, 21:45 **[ТС]**

хотелось бы понять сам принцип, не опираясь на cms, т.к. планирую от нее отказываться и делать на чистом php т.к. задолбали клоуны, которые пытаются взламывать пароль к cms.

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 18:40 [ТС]	11
	Сообщение от AndreyDyakonov Скорее всего так и будет... Вариант один: читаете последний упакованный файл плюс то, что неупаковано. Конечно если ваш хостер пакует адекватным архиватором. Другой вариант: делать свою схему логгирования.. Имхо это намного проще.. Извините если зря потратил ваше время на выходе *.gz. я уже тоже подумал об архивах, но это не очень удобно. Касательно ж "своей схемы логгирования" - это как? в лог-файл попадают данные посещения страниц сайта типа так: somesite.ru 66.249.78.165 - - [13/May/2013:17:33:01 +0400] "GET / HTTP/1.0" 200 15200 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" somesite.ru 178.151.216.53 - - [13/May/2013:17:36:30 +0400] "GET / HTTP/1.0" 200 15200 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" каким образом я могу реализовать сбор данных всех подключений ко всем страницам сайта? 0

@hara 0 / 0 / 3 Регистрация: 12.05.2013 Сообщений: 15
	13.05.2013, 19:23	12
	Насколько критично время обновления данных из логов? Если не критично (допустим вам просто нужно строить отчёты за час, день, сутки) можно брать уже упакованный файл, распаковывать, парсить и разом записывать в базу. Затем раз в минуту проверять не обновился ли файл(по дате). Как только обновился, - повторять процедуру. Т.к. скорее всего имя файла всегда одинаково. Раз там архивация то скорее всего ротация логов. С дописыванием в конец файла цифры. Т.е. имя файла всегда одно. Например: mysite-error.log ротируется скорее всего в mysite-error.log.1.gz - т.е. всегда одно и тоже имя. В общем ответ основан на предположениях. Но если всё совпадает вполне рабочий вариант. 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 19:54 [ТС]	14
	Сообщение от AndreyDyakonov сейчас стало почти стандартом(Де факто правда), что все запросы пользователей переадресуются на index.php. Там и можно начинать все ловить. Если у вас не так... сложнее конечно.. нужен скрипт простенький по добавлению записи в бд и инклюдить его на каждую страницу... Дело в том, что сайт на WordPress, соответственно, нужно инклюдить в кучу файлов - не удобно. Да и какой именно "простенький скрипт"? Сообщение от AndreyDyakonov Не по теме: проще договориться с хостером или поменять его. сейчас беспроблемные бесплатные хостеры имеются в достаточном количестве... зачем цеплятся за хостера Ну во-первых, у меня платный хостинг, а во вторых, на этом хостинге несколько проектов, переносить их все - смысл? 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
		1
	Постоянный парсинг лог-файла 13.05.2013, 17:15. Показов 4414. Ответов 15 Метки нет (Все метки) Приветствую. На хостинге автоматом создается лог в текстовом файле с данными по запросу страниц и т.п. Хотелось бы все эти данные видеть в БД а не в текстовике, для оперативной сортировки и выборки, соответственно нужно парсить, но есть вопрос. При заполнении файла сверх определенного объема, файл упаковывается в архив, соответственно при парсинге нужно не только раскидывать данные, но еще и удалять строки, которые уже пропарсились. Как это реализовать, что бы не получить ошибку при одновременной попытке доступа к файлу от скрипта и от ядра системы? 0

Vovan-VE 13208 / 6596 / 1041 Регистрация: 10.01.2008 Сообщений: 15,069
	13.05.2013, 17:21	2
	Можно запоминать позицию в файле, до которой дочитали в последний раз, чтобы в следующий продолжать с этой позиции. ftell() и fseek(). Если Ваш лог по размеру не превышает 2ГБ, можно даже не бояться переполнения PHP'шного int32. 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 17:25 [ТС]	3
	лог упаковывается не привысив 100 кБ. Запоминать позицию нет смысла, т.к. нужно читать строку, разбивать на значения, отправлять их в БД и удалять строку. Но вдруг данная операция попадет на то же время когда система захочет внести в файл новые данные? 0

Vovan-VE 13208 / 6596 / 1041 Регистрация: 10.01.2008 Сообщений: 15,069
	13.05.2013, 17:32	4
	Сообщение от pixel когда система захочет внести в файл новые данные? По идее, она его заблокирует только от записи, но не от чтения, так что прочитать должно быть можно. Сообщение от pixel отправлять их в БД и удалять строку Удалять строку из файла? Вы его только читаете. Вместо "удалять строку" Вы смотрите запоминаете текущую позицию, до куда дочитали (ftell()). При следующей попытке Вы сразу перемещаетесь (fseek()) на то же место (при условии, что это всё еще тот же файл, дописанный в конце новыми данными) и читаете дальше. 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 17:38 [ТС]	5
	Сообщение от Vovan-VE при условии, что это всё еще тот же файл, дописанный в конце новыми данными) и читаете дальше. так я про что и говорю. файл пишется до 100 кБ, потом упаковывается под другим именем. Соответственно, нужно регулярно считывать данные из файла и чистить его, что бы не было переполнения. 0

@AndreyDyakonov 122 / 120 / 7 Регистрация: 21.04.2013 Сообщений: 615
	13.05.2013, 17:39	6
	А что вам мешает вести лог в просто в бд? тем более с вашими размерами логов.. 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 17:47 [ТС]	7
	логи создаются системой у хостера. я в панеле управление поставил галки ведения логов, вот и получаю их. соответственно и размер указан у хостера (я не настраивал). а на мой вопрос, по поводу получения этих данных в БД, они сказали что это не возможно. 0

@AndreyDyakonov 122 / 120 / 7 Регистрация: 21.04.2013 Сообщений: 615
	13.05.2013, 17:57	8
	Но, как можно понять из вашего вопроса, вы имеете доступ из своих скриптов к файловой системе где хранятся логи? если так, то можно cron-ом читать эти файлы и заносить данные из них в базу.. уникальность строки проверять по времени записи(в логе это же должно быть). А хостер, что хочет, то пусть и делает дальше с этими логами.. Ну как вариант.. 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 18:01 [ТС]	9
	естественно доступ к своему каталогу на файловом уровне у меня есть. естественно, скрипт парсинга запускаться будет кроном. меня волнует вопрос одновременного доступа к одному файлу и от скрипта и от системы. Мне нельзя не чистить файл, т.к. парсинг все равно сработает позднее чем система обновит лог, поэтому получится так: лог на грани переполнения, заносится строка, файл закрывается, упаковывается, создается новый файл, записывается следующая строка, файл закрывается. а потом скрипт недосчитывается как минимум одной строки данных. Что бы этого избежать, нужно чистить лог. тогда и файл не переполнится и все нужные данные будут перенесены в БД. 0

@AndreyDyakonov 122 / 120 / 7 Регистрация: 21.04.2013 Сообщений: 615
	13.05.2013, 18:13	10
	Сообщение от pixel т.к. парсинг все равно сработает позднее чем система обновит лог, поэтому получится так: лог на грани переполнения, заносится строка, файл закрывается, упаковывается, создается новый файл, записывается следующая строка, файл закрывается. а потом скрипт недосчитывается как минимум одной строки данных Скорее всего так и будет... Вариант один: читаете последний упакованный файл плюс то, что неупаковано. Конечно если ваш хостер пакует адекватным архиватором. Другой вариант: делать свою схему логгирования.. Имхо это намного проще.. Извините если зря потратил ваше время 0

	13.05.2013, 21:45

Опции темы

@AndreyDyakonov 122 / 120 / 7 Регистрация: 21.04.2013 Сообщений: 615
	13.05.2013, 19:36	13
	Сообщение от pixel каким образом я могу реализовать сбор данных всех подключений ко всем страницам сайта? сейчас стало почти стандартом(Де факто правда), что все запросы пользователей переадресуются на index.php. Там и можно начинать все ловить. Если у вас не так... сложнее конечно.. нужен скрипт простенький по добавлению записи в бд и инклюдить его на каждую страницу... Добавлено через 3 минуты а время записи в лог парсить регуляркой... если всетаки хочется ковырять архивы. Не по теме: проще договориться с хостером или поменять его. сейчас беспроблемные бесплатные хостеры имеются в достаточном количестве... зачем цеплятся за хостера 0

@AndreyDyakonov 122 / 120 / 7 Регистрация: 21.04.2013 Сообщений: 615
	13.05.2013, 20:04	15
	Сообщение от pixel Дело в том, что сайт на WordPress приплыли.. как в любой сms там должна быть переадрессация на index.php или не наю как там называется входной файл. В начале выполнения программы проверяйте и логгируйте все что вам нужно.. Либо подпирать костылями с распаковкой архивов... 0

@pixel 26 / 19 / 5 Регистрация: 19.05.2009 Сообщений: 2,266
	13.05.2013, 21:45 [ТС]	16
	хотелось бы понять сам принцип, не опираясь на cms, т.к. планирую от нее отказываться и делать на чистом php т.к. задолбали клоуны, которые пытаются взламывать пароль к cms. 0