OpenSSL не дает возможности узнать что-либо про использование kTLS.
На уровне ядра можно посмотреть статистику:
cat /proc/net/tls_stat
TlsCurrTxSw 2
TlsCurrRxSw 0
TlsCurrTxDevice 0
TlsCurrRxDevice 0
TlsTxSw 5975
TlsRxSw 492
TlsTxDevice 0
TlsRxDevice 0
TlsDecryptError 0
TlsRxDeviceResync 0
TlsDecryptRetry 0
TlsRxNoPadViolation 0
Вот только она общесистемная и не привязана к какому-либо слушающему сокету или процессу.
Понятно.
Ещё возник вопрос 
Можно ли ещё расширить статистику по соединениям - добавить возможность просматривать по протоколам HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3. А так же используемый трафик этими протоколами.
В целом было бы можно, но надо понимать, что любой дополнительный счетчик, тем более такой глобальный - не бесплатен. Сейчас по возможности Angie задействует только те глобальные счетчики, которые уже были в nginx, а все остальное настраивается индивидуально.
Поэтому за добавлением дополнительных счетчиков должна быть достаточная ценность. Не очень понимаю, какая ценность в статистике по версии HTTP протокола в реальном времени, кроме простого любопытства. А для достоверного подсчета трафика на уровне протоколов желательно вообще смотреть на пакетный уровень, т.к. 5 байт переданные одним пакетом или пятью - тоже будет иметь значение.
В планах есть добавить возможность конфигурирования произвольных счетчиков, которые будут работать на основе переменных и там тогда пользователь сможет настроить любую произвольную статистику, в том числе считать протоколы на уровне запросов хотя бы.
1 Like
Благодарю, вариант с конфигурированием произвольных счетчиков выглядим оптимальным
Благодарю разработчиков Angie за консоль для мониторинга web-сервера. С её помощью можно не только просматривать текущую нагрузку, но и проводить отладку конфигурации web-сервера.
Например, можно наглядно посмотреть нагрузку на каждый блок location и как часто используется.
В процессе настройки консоли удалось подобрать оптимальный вариант конфигурации блоков location для Mastodon и найти критическую ошибку в исходной конфигурации Peertube. Также обратил внимание на другие мелкие недочёты в своей конфигурации web-сервера.
1 Like
Захотел в блок location добавить кэширование статических файлов с валидацией:
location /console/ {
alias /nix/store/izgjcccpx7irvs4b4qblys4rh98y2d9y-angie-console-light-1.1.1/share/angie-console-light/html/;
add_header Cache-Control 'public, max-age=604800, must-revalidate';
}
После обновления файлов console-light до последней версии в браузере основные файлы не обновились.
Я думал, что параметр must-revalidate должен указывать браузеру перепроверять каждый раз файлы при запросе…
Я это я неправильно разобрался в методике кэширования статических файлов?
Добрый день.
Из https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control:
The
must-revalidateresponse directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse.
В вашем случае, ресурс считается fresh в течение недели (604800 секунд).
1 Like
Понятно.
Я то вообще предполагал, что параметр must-revalidate позволяет всегда поддерживать файлы в актуальном состоянии, проверять на обновления.
Похоже надо глубже изучать и разбираться с кэшированием.
Ещё узнал о параметре stale-while-revalidate=<seconds>, протестировал, но он у меня похоже не сработал. Пробовал заменить на такой вариант:
add_header Cache-Control 'max-age=600, stale-while-revalidate=30';
Пробовал обновить страницу браузера через несколько минут, но запросы на проверку статических файлов не приходят.
В последнем примере вы явно сообщили браузеру, что файлы могут считаться актуальными 10 минут. И, после окончания этого времени, еще 30 секунд можно использовать их как stale, при этом пытаясь обновить в фоне.
Я не вполне понимаю, какую задачу вы хотите решить и для чего вы пытаетесь использовать Cache-Control. Также, следует учитывать, что это заголовок двойного назначения - как для браузеров, так и для промежуточных кеширующих прокси-серверов. Часть директив адресована преимущественно для последних и не факт, что имеет однозначную трактовку для браузеров.
Просто хотел закэшировать статические файлы
Тогда стоит просто убрать add_header
Браузер один раз скачает файл и сам больше этого делать не будет, пока вы не скажете ему это явно. А когда вы все же перезагрузите страницу - сделает условный запрос (HTTP conditional requests - HTTP | MDN), и получит легковесный 304 Not Modified ответ, либо новую версию файла со статусом 200 OK.
1 Like
А если, к примеру, очень много мелких файлов находится на сайте, тогда браузер будет отсылать запрос на проверку. Я то думал, что параметр must-revalidate даёт браузер закэшировать файлы, и периодически проверять их на обновление, но так, чтобы каждый раз не отправлять запросы на проверку :)))
Тут два момента:
- в составе Angie Console просто нет большого количества файлов
- загрузка имеющихся производится однократно, если только вы не нажимаете все время
Reload Page
Кажется, что вся эта овчинка точно не стоит выделки
1 Like
Есть ли возможность встроить кнопки для сброса статистики для зон и локаций?
Во время диагностики для этого приходится полностью перезапускать web-сервер.
В самом API сейчас нет возможности сбрасывать отдельные метрики. И не очень бы хотелось её реализовывать, т.к. многие метрики взаимозависимы на разных уровнях и сброс отдельной их части может приводить к неконсистентности.
Во время процедуры сброса могут быть активные соединения с запросами, которые были уже посчитаны в одних счетчиках, а в других посчитаются при закрытии. Если сбросить тот же processing в этот момент, то он уйдет в минус. Да и было бы странно видеть число ответов больше, чем число запросов.
В общем не такая тривиальная задача, как может показаться.
1 Like
Директиву auto_redirect сделали: Модуль http_core — документация Angie 1.5.0
1 Like