Error log question

[Gena Makhomed]

On 26.07.2022 0:34, Maxim Dounin wrote:

>>   >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not allocate
>>   >> new session in SSL session shared cache "le_nginx_SSL" while SSL
>>   >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
>>   >
>>   > This error indicate that nginx wasn't able to allocate new session
>>   > in the SSL session cache defined by the "ssl_session_cache"
>>   > directive, and removing an old session didn't help.  This
>>   > basically indicate that the SSL session cache is too small, and it
>>   > would be a good idea to either configure a larger cache or reduce
>>   > ssl_session_timeout.  The logging level is probably a bit too
>>   > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
>>
>> Максим, Вы говорите, что "The message is probably a bit too scary
>> (while the situation itself is mostly harmless)".
>>
>> Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
>>
>> Разве не проще один раз пофиксить эту проблему в исходниках nginx,
>> чем постоянно рассказывать пользователям в списках рассылки о том,
>> что "The logging level is probably a bit too scary"?
>>
>> Если просто поменять [alert] на [warn] - ничего ведь не сломается?
>> Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
> 
> По конкретному тикету есть несколько моментов:
> 
> - Перед тем, как менять уровень логгирования - надо как минимум
>    проверить, что в случае невозможности выделения памяти для сессии
>    действительно ничего не ломается.
> 
> - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
>    смысла изменить логику удаления старых сессий в случае нехватки
>    памяти, чтобы ошибок не возникало.  Или даже переделать логику
>    выделения памяти под сессии, дабы минимизировать вероятность
>    неуспеха.  Или прикрутить логику, аналогичную реализованной для
>    памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).

Если не будет в логах ошибок - каким образом тогда пользователь
сможет понять, что размер кэша для сессий SSL слишком маленький?

Может же быть так, что установлен размер кэша для примерно 4000 сессий,
а активных клиентов будет примерно в десять раз больше - в этом случае
nginx будет постоянно удалять "старые" сессии, ничего при этом в логах
не сообщая пользователю. Наверное это не самый лучший вариант поведения?

Или наоборот, когда выставлен очень большой размер для кэша сессий SSL,
а используется не более 10% - это тоже неоптимальная настройка nginx.

Пользователи nginx-plus наверное смогут установить на свои сервера
nginx-amplify-agent и возможно смогут увидеть в NGINX Amplify,
что кэш для сессий SSL переполнен и его следует увеличить. (?)

Но что в таком случае делать пользователям open source версии nginx?
Насколько я понимаю, в NGINX Amplify для open source версии nginx
метрик для кэша сессий SSL нет.

Особенно, если пользователи nginx используют Rocky Linux 8.6,
при запуске скрипта install.sh выдается такое сообщение про ошибку:
Checking OS compatibility ... rocky is currently unsupported, apologies!
Хотя по своей сути Rocky Linux 8.6 ведь ничем не отличается от RHEL 8.6.
Это же 1:1 бинарно совместимая с RHEL8 сборка EL8 из тех же исходников.

Если вручную прописать в файле /etc/yum.repos.d/nginx-amplify.repo

[nginx-amplify]
name=nginx amplify repo
baseurl=http://packages.amplify.nginx.com/py3/rhel/8/$basearch
gpgcheck=1
enabled=1

В таком случае NGINX Amplify Agent нормально устанавливается
на Rocky Linux 8.6 и даже нормально запускается.

Этот список рассылки, nginx-ru наверное не очень подходит
для обсуждения NGINX Amplify Agent и NGINX Amplify?

Куда лучше всего будет писать bug reports и feature requests
по NGINX Amplify Agent и NGINX Amplify, напрямую емейлом разработчикам?

-- 
Best regards,
  Gena