Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Gena Makhomed]

On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote:

>>>>> Если вы предлагаете писать напрямую с nginx-а в файл --
>>>>> сделайте у себя ротацию файлов с интервалом 30 сек
>>>>> при 200-250 тыс подключений/сек...
>>>>>
>>>>> Если у вас уже есть такое рабочее решение -
>>>>> поделитесь опытом, буду рад вас выслушать.

> "Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон."

Почему / зачем?

> Дальнейшее перемалывание темы ротации лично для меня интереса не представляет.

Тогда прекращаем.

>>> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно
>>> решать что мне надо :)

Так я и не пытался решать за Вас, как именно будет лучше поступить
в Вашей конкретной ситуации - скорее я рассматривал все множество
задач сбора статистики и обработки информации из логов - и на всем
этом множестве задач старался увидеть наиболее оптимальный способ
решения задачи, если абстрагироваться от затрат времени
и сил на реализацию решения в виде програмного кода.

>> Решайте сами, я просто хотел понять Вашу исходную задачу X,
>> поэтому и задавал уточняющие вопросы.

> Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте теме я уже все решил.

С моей точки зрения более важным является обеспечение более высокой
надежности работы системы, чтобы логи не терялись в процессе записи,
чем экономия свободного места на диске и экономия ресурсов NVMe SSD.

Поэтому с моей точки зрения - я не могу признать решение
через syslog и unix socket более оптимальным, чем вариант
записи логов напрямую в файлы и ротации логов через SIGUSR1.

а ротацию логов можно делать и чаще, чем раз в 30 секунд,
например, раз 15, или раз в 10 или даже раз в 5 секунд,
если хочется уменьшить отставание статистики по времени.

По сути - лог-файл на диске - это можете воспринимать примерно,
как то же самое, что и unix socket, только с буфером не в памяти,
а в виде файла на диске и без существенных ограничений по размеру
такого буфера, что будет лучше сглаживать всплески нагрузки
и может позволить большую асинхронность между процессом
записи информации в лог и процессом чтения информации
из лога. А во всем остальном - никакой существенной
разницы нет, учитывая только что запись логов в файлы
меньше грузит процесор и использует немного больше
свободного места на диске.

Но мне например, лучше чтобы процессор был немного свободнее,
чем проистаивающее и никак не используемое место на диске.

Но самое главное - что запись логов в файлы не приводит к потере
данных, а запись логов в unix socket может приводить к потерям
даных, если читатель будет не успевать забирать данные из unix socket.

Более надежное и более простое решение, и более экономно
расходующее процесор сервера - и будет более оптимальным.

> При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не едет" 2 концептуальных решения:
> 1.Заменить машину.
> 2.Устранить причины "не едет" в имеющейся.
> Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя запчасть.
> Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти.
> Вы предлагаете замену машины.

Не так, я скорее рассматриваю одновременно все множество путей
из точки А в точку Б для различных вариантов А и Б и различных
внешних условий и стараюсь понять, какой именно автомобиль,
с какими именно параметрами будет наиболее оптимальным
решением для такой задачи - перемещения их точки А в точку Б.

Вот как я уже говорил, задача построения VPN - если взять все множество
таких задач, то в части случаев для построения VPN более оптимальным
вариантом будет использование WireGuard, а в части случаев - OpenVPN.
Именно потому, что WireGuard обладает некоторыми свойствами
и качествами, которые отсутствуют в OpenVPN, и наоборот,
потому что OpenVPN обладает некоторыми свойствами и качествами,
которые отсутствуют в WireGuard. И поэтому в части случаев
оказывается более оптимальным и целесообразным построение
VPN с использованием WireGuard, а в некоторых случаях
- более оптимальнныи и целесообразным оказывается
построение VPN с использованием OpenVPN.

>> Получить потери можно в случае использования syslog
>> и unix socket`ов - если читающая сторона не будет
>> успевать читать данные из сокета - у nginx не останется
>> иных варантов, кроме как дропать часть записей.
>>
>> При записи логов в файлы - этот вариант исключен,
>> если на разделе есть достаточное количество свободного места.
>>
> О появились доп. условия -- место на разделе...

Так ведь свободное место на разделе есть, с этим же нет проблем.

Если часто делать ротацию логов - его надо будет совсем не много.

Тем более, что можно включить компрессию логов на лету, если надо.

>> Хотя бы даже одним только этим свойством запись логов в файлы
>> намного лучше записи логов в unix socket`ы.

> А как же место на разделе? Замена одной проблемы другой. Только и всего.

У Вас разве есть проблемы со свободным местом на разделе?
тогда включите компрессию логов на лету - свободного места
потребуется меньше, ресурсов процессора будет использовано
больше. Только и всего. Это не проблема, это лишь tradeoff.

> Т.е. Проблему X -- расхождение при использовании сокета, вы меняете на проблему У -- достаточное количество места
> и производительность системы ввода-вывода, просто с вашей точки зрения это как-бы и не проблема вовсе

Количество свободного места на разделе - это не проблема, потому что
Thin provisioning и все разделы виртуальных машин имеют логический
размер в 50 TiB, - я бы сделал и больше, но Red Hat не рекомендует.

> с моей точки зрения менять одну проблему на другую смысла нет

использование места на диске - это не проблема, это необходимая плата
за то, что запись в логи будет происходить без потерь информации,
и что чтения и обработка информации из логов не обязаны быть
такими синхронными и производительными, как в случае с unix socket`ами.

> Вот вам идея оптимального по большинству критериев решения --
> Когда будете решать сходную задачу напишите свой модуль для nginx
> Чтоб сразу считать все нужное "внутри" без посредников.
> Я такое решение тоже рассматривал, отказался.
> Лично мои трудозатраты по реализации такого подхода превосходят все разумные пределы.
> Что и стало ключевым фактором "против".

Такой модуль уже есть, Angie умеет экспортировать данные
напрямую в Prometheus. Если бы у njs была возможность разделять
данные между worker`ами, то можно был бы пряом через njs это делать.
И скорее всего - это можно уже сейчас запрограммировать на lua,
используя в качестве веб-сервера OpenResty, там есть доступ
к разделяемой памяти. Или - просто парсить логи и все,
это будет и быстрее и проще, чем unix socket`ы, IMHO.

-- 
Best regards,
  Gena