этом удалить оттуда часть полей? Есть что-то готовое, что может скажем на 20к rps работать без особых проблем...?
Мне тоже интересно кста
А вы точно смогли сделать такой логгер? А что если вы возвращаете файл или 1000 объектов каждый раз? У вас бесконечные диски для логов?
@IlyaKaznacheev @onokonem help дядьки
Что значит "смогли сделать"? Перечитайте вопрос) Диски как раз не бесконечные, поэтому и вопрос. Ну и плюс секурность местами.
Просто не печатать response, на кой хрен он нужен в логах.
Я говорю это так как сам делал логгер, который скрывал сенсетианые данные, толкну от этого респонса просто нет.
А что вам надо, секреты вырезать? Это можно на уровне коллектора сделать, но не факт, что столько потянет
Да, секреты и часть тяжёлых полей. Я не пробовал, но мне кажется проц и гц захлебнутся
Ну мне кажется что в такой постановке они в любом месте захлебнутся. Попробуйте пойти от обратного, и логгировать только нужные поля. Если у вас 20К рпс, вряд ли кто-то будет сидеть и читать все поля в каждом запросе
Вы всё верно говорите. А какой алгоритм получится этого всего? Ну т.е хендлер записал бади во writer,а что дальше...?
Не знаю
Можно попробовать обрабатывать и логировать ответ nginx. Очень любопытно: какая цель логирования всех ответов?
В общем, более-менее тривиально если нет запроса на риалтайм. Встроится каким-нибудь интерцептором или мидлтварью в точку, где TLS уже отработал, проверить размер тела по заголовку и если он попадает в ожидаемые границы, то асинхронно считать его до конца, сжать и сложить в опративку. Далее по таймеру или по наполнению регулярно дампить эти данные - куда не суть важно, значимеем батчинг, чтобы размер батча бодро бежал по проводам. Не забыть реализовать backoff: если буфер уже полный и не успевает дампиться, то, например, просто выбрасывать самые старые сообщения и использовать новые (для чего складывать бы изначально неплохо в какое-то дерево, типа BST с приколами). Синхронизировать через RWLock.
Другой типичный вариант: иметь два буфера (текущий, прежний) и атомарно менять ссылку между ними. Прежний буфер сериализовать и дампить, это если надо оптимизировать под быструю запись без конфликтов с чтением. Тут бэкофф будет сложнее чуть, а само переключение надо сделать через atomix exchange.
эту статью видели? https://dev.to/mizutani/zlog-secure-logger-in-go-to-prevent-output-of-sensitivesecret-values-394d
сложность именно в неопределенном теле респонса?
Кафка не подходит?
Обсуждают сегодня