Re: access.log

2022-07-13 Пенетрантность Илья Шипицин
ср, 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

2022-07-13 Пенетрантность Илья Шипицин
ср, 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