Быстрый лог

Есть, увы, самому мне сильно в логирование упираться не приходилось, но на хабре была довольно большая статья на тему логирования в крестах с рассмотрением разных средств. Правда почти за 2 года она могла устраеть.

Логируй на отдельной машине. Тогда упрёшься в сеть, но это тема для отдельного топика.

Апока могу сказать, что ты придурок. Оптимизируешь логирование и одновременно накачиваешь производительность....

spdlog

Хорошо, но нет сжатия. Упремся в производительность диска

spdlog+вывод в сокет

Хотя, берешь и прикручиваешь к spdlog zlib.

/thread

nanolog

Сокет зло

А очень быстро это как? Килобайт в секунду? Мегабайт? 100МБ?

Учитывая ответы и предыдущее решение(кстати, чем оно эффективней mmap в отдельном потоке?) - скорее за запись среднего размера сообщения (пусть будет 1024 байта) <200нс в 99.99% случаев.

очередь в разделяемой памяти. Отдельный процесс прямо из памяти пишет в сжатый файл на диске.

Чем это эффективней, чем просто запись в отдельном потоке в такой же файл?

По идее, шарная память, сама по себе будет чуть медленнее, чем память одного процесса, а если, ещё и на разных нума нодах будут крутиться процессы, то ещё +штраф.

Например, 80к записай в секунду. Пусть средний размер записи будет 100 байт.

Например дело в том, что это несколько приложений. При этом они не многопоточные, а многопроцессные. А логировать хочется в один лог, и с соблюдением последовательности записей

Ну именно для случая нескольких процессов тебе нужен либо свой мопед, либо лог в сокет(в мультикаст группу в идеале, если локалхост), либо кастомный синк для имеющихся поделок.

Есть p7 (оно умеет в сетевые логи насколько я понял, и всякую телеметрию, умеет в последовательность). Сам руками не трогал ещё, вот думаю её брать или spdlog(не умеет в гарантированную последовательность в асинхронном режиме).

Я бы на твоём месте прикрутил бы кастомный синк к любому из подходящих по функционалу мопедов(кроме boost.log и log4cpp), готового с твоими требованиями найти будет сложновато.

По идее, шарная память, сама по себе будет чуть медленнее, чем память одного процесса

O rly?

Прикольно, умные дядьки пишут, что нет.

Судя по интернетам(например https://www.balabit.com/wiki/syslog-ng-faq-performance) это очень далеко от того, что может syslog-ng

Писать в ram-диск, и при заполнении процентов до 70 роллить?

А буферизовать их можно? Или обязательно каждую писать на диск?

И как сортировать записи, сделанные в одну мили/нано секунду?

Зачем их сортировать? Они просто пишутся в последовательности возникновения.

Буферизовать конечно можно и нужно.

А сложно оно под оффтопик собирается?

Аргументируй.

zlib ты решил пропустить?

spdlog без сжатия так может

А логировать хочется в один лог, и с соблюдением последовательности записей

Я подумал что нужна строгая последовательность и порядок записей важен.

Именно это и нужно. И очередью в shm это достигается

На очередь (точнее на немного более сложную строктуру типа фифо с возможностью итерироваться) можно натравить несколько слушателей. Один пишет на диск, второй выводит на экран с шифрацией итд. Также при наличии очереди можно лекгко откатится по ней назад, для вывода последних n строк лога. С сокетом так не получится, значит надо будет делать локальную очередь. В идеале для меня логилка должна иметь писать, иметь что-то типа тайл -ф с фильтром по уровню и источнику, и совсем хорошо - просмоторщик логов с раскрасками, фильтрами и автообновлением. grep не подходит т.к. будут проблемы с многострочными записями

Посмотри на ELK стек. Сделано как раз для быстро логгировать, быстро искать в налоггированном. Но конкретно в твоём случае может быть несколько перебором.

что мешает тебе эту «логилку» сделать отдельным процессом? Запускать на отдельном сервере (если хочется производительности). Или тебе принципиально важно иметь высокий кауплинг?

Если запись в лог является производным событием от чего-либо более упорядоченного, то нет.

Если два события произойдут в один момент времени (на разных процессорах например) то в момент записи в лог их таки нужно либо сортировать, либо «кто последний, тот и папа».

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

Отдельный сервер не нравится, т.к. решение должно помещаться на одном-двух (для кластера). Как опция - возможно.