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

Попробую подвести итоги по теме:
На вопрос
"До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения....
Кто-то с таким сталкивался? "
Я ожидал ответов в стиле
"У меня на сервере при нагрузке 70 (80, 90 и т.д.) тыс/сек ничего подобного не наблюдается (или наблюдается что-то подобное)"
Или что-то близкое по смыслу.
Судя по содержанию данных советов:
Подобную статистику не ведут, т.к. не видят особого смысла.

Зачем мне это нужно:
Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы.
Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются.
Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут.

Регулярно требуется "нестандартная" статистика, например
"средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"
"соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час"
"наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..."
"объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)"
и т.д.
нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси.
Сами файлы логов живут максимум 15-20 минут, этого достаточно для извлечения необходимых данных.
Нестыковки стали вылезать, когда один из 3-х фронтов погасили на пару дней, нагрузка на оставшиеся 2 стала выше 50тыс/сек на каждом из них (при этом их предел гораздо выше, каждый может гарантировано "переварить" 200тыс/сек) и пошли расхождения в отчетах по количеству запросов с фронтов и беков.

При снижении количества запросов все снова хорошо согласуется.

Получены советы:
1) Уточнить методику расчета -- не вижу смысла, сколь-нибудь существенные и системные расхождения появляются только когда нагрузка на реверс-прокси выше 50тыс/сек, т.е. 3 х 40 проблем нет,а 2 х 60 уже проблема? при этом когда "железки" 2 шт, а nginx-ов на них 3шт проблема снова исчезает...
2) Тюнинг сокетов -- в процессе, UDP исключен, замер связки unixSocket+rsyslog на один unixSocket пока показал "потолок" 150тыс/сек производительность, но еще не все идеи реализовал-проверил.
3) Настройки rsyslog-а
$SystemLogRateLimitInterval 0
$SystemLogRateLimitBurst 0

$SystemLogRateLimitBurst -- ставился и "0", и "20000000", на конечный результат не повлияло. как и замена на другой syslog.

Всё точно идёт сразу в syslog/rsyslog напрямую, а не через
systemd-journal ?
Точно, в systemd-journal эти данные не фиксируются и туда вообще не попадают.

Производительности хранилища точно достаточно для 150тыс/сек (один из способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении нескольких часов заливка-ротация-удаление)

Все работает на физическом железе, без VPS-ов и контейнеров.

По результатам отпишусь, но врядли скоро, т.к. такая нагрузка не регулярна, а вариантов для проверки не 1 и не 2 :)

Всем спасибо за внимание.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru