Re: access.log
ср, 13 июл. 2022 г. в 14:00, Илья Шипицин : > > > ср, 13 июл. 2022 г. в 13:49, Gena Makhomed : > >> On 12.07.2022 22:59, Илья Шипицин wrote: >> >> > если рассматривать с точки зрения эффективного использования диска, то >> поля >> > $scheme, $host являются практически константами, можно не логировать их >> на >> > каждую строчку лога (а, например, разнести разные host-ы по разным >> логам). >> >> Разнести разные host-ы по разным логам - это на самом деле плохая идея. >> Когда различных хостов десятки и сотни - это становится очень неудобно. >> Кроме того, это отрицательно сказывается на производительности сервера, >> особенно если используется HDD а не SSD. >> > > это полностью в вашей власти, писать в каждую строку host или делать > отдельные логи. насчет производительности в случае HDD - не соглашусь, > если писать с буферизацией (buffer=... и flush=...), то HDD отлично > справляется вплоть до тысяч запросов в сек, выше не проверял. > > >> >> Имея в наличии один access.log с помощью grep >> можно легко получить из него access.log для любого сайта: >> grep -P '\texample.com\t' access.log | less -S >> > > удобство или неудобство действительно рассматривается в зависимости от > используемых инструментов. > что-то подсказывает, что использование grep как ежедневного инструмента - > ну такое. и grep это опять же > требует ssh доступа. навряд ли аналитикам это удобно. > про grep приходится постоянно иметь в виду "ну вот я сейчас запускаю обработку файла на 50 гигабайт, не повлияет ли это на функции сервера" > > > >> >> $scheme занимает всего несколько байт, и лучше уж пусть будет, >> для полноты картины, по сравнению с $http_user_agent - это мелочь. >> >> Для удобства чтения лога и для уменьшения его размера >> - можно из лога убрать информацию про таймзону: >> >> map $time_iso8601 $time { >> "~([0-9-]+)T([0-9:]+)" "$1 $2"; >> volatile; >> } >> >> log_format frontend '$time\t...'; >> >> Тогда время в логе будет выглядеть примерно так: >> >> 2022-07-13 11:34:40 >> >> а не так: >> >> 2022-07-13T11:34:40+03:00 >> >> Переменная $time вместо $time_iso8601 в логе >> дает и меньший объем лога и его лучшую читаемость. >> > > iso8601 удобен тем, что он поддерживается для импорта во что угодно. > соглашусь, что можно его убрать в логе, а потом добавить при импорте, если > надо > > >> >> Недостаток у этого варианта с переменной $time только >> > > ко мне как-то приставали, чтобы сделать map, которая добавляет > миллисекунды )) > > >> один - приходится программировать на конфигах nginx, >> используя map и регулярные выражения, - это несколько >> увеличивает объем конфига, но должно работать достаточно быстро. >> >> -- >> Best regards, >> Gena >> ___ >> nginx-ru mailing list -- nginx-ru@nginx.org >> To unsubscribe send an email to nginx-ru-le...@nginx.org >> > ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: access.log
ср, 13 июл. 2022 г. в 13:49, Gena Makhomed : > On 12.07.2022 22:59, Илья Шипицин wrote: > > > если рассматривать с точки зрения эффективного использования диска, то > поля > > $scheme, $host являются практически константами, можно не логировать их > на > > каждую строчку лога (а, например, разнести разные host-ы по разным > логам). > > Разнести разные host-ы по разным логам - это на самом деле плохая идея. > Когда различных хостов десятки и сотни - это становится очень неудобно. > Кроме того, это отрицательно сказывается на производительности сервера, > особенно если используется HDD а не SSD. > это полностью в вашей власти, писать в каждую строку host или делать отдельные логи. насчет производительности в случае HDD - не соглашусь, если писать с буферизацией (buffer=... и flush=...), то HDD отлично справляется вплоть до тысяч запросов в сек, выше не проверял. > > Имея в наличии один access.log с помощью grep > можно легко получить из него access.log для любого сайта: > grep -P '\texample.com\t' access.log | less -S > удобство или неудобство действительно рассматривается в зависимости от используемых инструментов. что-то подсказывает, что использование grep как ежедневного инструмента - ну такое. и grep это опять же требует ssh доступа. навряд ли аналитикам это удобно. > > $scheme занимает всего несколько байт, и лучше уж пусть будет, > для полноты картины, по сравнению с $http_user_agent - это мелочь. > > Для удобства чтения лога и для уменьшения его размера > - можно из лога убрать информацию про таймзону: > > map $time_iso8601 $time { > "~([0-9-]+)T([0-9:]+)" "$1 $2"; > volatile; > } > > log_format frontend '$time\t...'; > > Тогда время в логе будет выглядеть примерно так: > > 2022-07-13 11:34:40 > > а не так: > > 2022-07-13T11:34:40+03:00 > > Переменная $time вместо $time_iso8601 в логе > дает и меньший объем лога и его лучшую читаемость. > iso8601 удобен тем, что он поддерживается для импорта во что угодно. соглашусь, что можно его убрать в логе, а потом добавить при импорте, если надо > > Недостаток у этого варианта с переменной $time только > ко мне как-то приставали, чтобы сделать map, которая добавляет миллисекунды )) > один - приходится программировать на конфигах nginx, > используя map и регулярные выражения, - это несколько > увеличивает объем конфига, но должно работать достаточно быстро. > > -- > Best regards, > Gena > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
access.log
On 12.07.2022 22:59, Илья Шипицин wrote: если рассматривать с точки зрения эффективного использования диска, то поля $scheme, $host являются практически константами, можно не логировать их на каждую строчку лога (а, например, разнести разные host-ы по разным логам). Разнести разные host-ы по разным логам - это на самом деле плохая идея. Когда различных хостов десятки и сотни - это становится очень неудобно. Кроме того, это отрицательно сказывается на производительности сервера, особенно если используется HDD а не SSD. Имея в наличии один access.log с помощью grep можно легко получить из него access.log для любого сайта: grep -P '\texample.com\t' access.log | less -S $scheme занимает всего несколько байт, и лучше уж пусть будет, для полноты картины, по сравнению с $http_user_agent - это мелочь. Для удобства чтения лога и для уменьшения его размера - можно из лога убрать информацию про таймзону: map $time_iso8601 $time { "~([0-9-]+)T([0-9:]+)" "$1 $2"; volatile; } log_format frontend '$time\t...'; Тогда время в логе будет выглядеть примерно так: 2022-07-13 11:34:40 а не так: 2022-07-13T11:34:40+03:00 Переменная $time вместо $time_iso8601 в логе дает и меньший объем лога и его лучшую читаемость. Недостаток у этого варианта с переменной $time только один - приходится программировать на конфигах nginx, используя map и регулярные выражения, - это несколько увеличивает объем конфига, но должно работать достаточно быстро. -- Best regards, Gena ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org