жизнеспособность библиотеки журналов c ++ для асинхронного захвата данных с высокой пропускной способностью?

Question

Я работаю с системой реального времени, написанной на C ++. Мы планируем использовать буст или пантео для регистрации. Система имеет некоторые стандартные требования к ведению журналов, которые, я уверен, могут быть выполнены любой платформой, но, кроме того, мы хотим иметь возможность регистрировать все входные данные, полученные этой системой. Этот вход будет перехвачен несколькими потоками, включая некоторые потоки, которые имеют ограничения в реальном времени и не могут допустить значительных задержек из-за неэффективного ведения журнала. Это должно привести к высокой пропускной способности регистрируемых данных.

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

Я полагаю, что обе платформы ведения журналов могут сделать это, но мне неясно, если взглянуть на их API. Может ли кто-нибудь, кто использовал любой из этих инструментов ведения журналов, дать мне некоторую обратную связь о том, насколько они эффективны в этом контексте, насколько легко было бы реализовать то, что я описал, или их предпочтение между двумя структурами ведения журналов? Действительно любая информация была бы полезной.

Спасибо

Answer 1

Я сделал запись в больших многопоточных ситуациях. Мой опыт был:

• Ведение журнала доступно только для разработчиков. Никто другой не будет читать или понимать файлы журнала.

• Разъедините генерацию сообщений журнала и порядок их регистрации.

• Если вы хотите сделать генерацию сообщений журнала более эффективной, сначала используйте быстрый контекст, проверьте, регистрирует ли что-либо этот контекст, а если нет, не генерируют. В противном случае сгенерируйте сообщение. (Наиболее распространенное использование этого метода - «уровень», который может быть «отладкой», «информация» и т. Д., И если ничего не регистрируется на этом уровне, мы не создаем сообщение).

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

• Также зарегистрируйте идентификатор потока, который генерирует сообщение.

• Для ведения журнала используйте отдельный поток, чем те, которые генерируют сообщение. (библиотека логирования boost делает это так)

• Остерегайтесь сходить с ума по макросам, хотя легкие макросы, добавляемые в такие вещи, как FILE и LINE , автоматически в порядке.

Answer 2

Я использую библиотеку журналирования Boost, написанную Джоном Торжо, и эта предлагает сделать всю запись в файлы журналов из выделенного потока, поэтому у вас нет задержек ввода-вывода в потоке, выполняющем ведение журнала.Недостаток заключается в том, что при сбое системы некоторые операторы журнала могут не регистрироваться, так как она использует внутреннюю очередь.

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

Если это не вариант, вам придется выполнять ввод / вывод из потока, нуждающегося в регистрации, что на самом деле не идеально для системы реального времени.

Если вы 'Вы работаете в Windows, вы знаете, что это не ОС RT, верно?

Answer 3

Вы можете рассмотреть http://www.logog.org. Похоже, вы сталкиваетесь со многими из тех проблем, с которыми я сталкивался, когда писал. Первоначально я написал его для регистрации многопоточного аудио DSP-движка, что, конечно, является сущностью рендеринга, критичного ко времени.

См. Также https://stackoverflow.com/questions/696321/best-logging-framework-for-native-c