Великая единая теория лесозаготовок

Question

Является ли это великой единой теорией лесозаготовок? Должны ли мы разработать один? Вопрос (просто чтобы показать, что это не обсуждение :), как я могу улучшить следующее? (обратите внимание, что я живу в основном во встроенном мире, но не встроенные предложения также приветствуются)

Как вы регистрируетесь, когда вы входите, что вы регистрируете, что вы делаете с файлами журналов?

Как вы регистрируетесь - у меня обычно есть макросы, #ifdef TESTING, вроде того. Они записывают в ОЗУ, а процесс с низким приоритетом записывает их во время простоя системы (используя UDP, поскольку я работаю со встроенными системами)

Когда вы входите в систему - так же, как голосование, досрочно и часто. На каждом (не) значимом событии программы я регистрируюсь на разных уровнях. События получены, транзакция выполнена успешно / неудачно, данные обновлены и т. Д.

Что вы регистрируете - Фатальный / Ошибка / Предупреждение / Информация / Отладка / Трассировка описана в Когда использовать разные уровни журнала?

Что вы делаете с файлами журналов - 1) сохраняйте их (в CVS), проходите и терпите неудачу 2) собирайте все и фильтруйте позже, если я не могу повторить проблему. У меня есть инструменты для фильтрации журнала по «уровню» (Fatal / Error / и т. Д.), Процессу, файлу и т. Д. И для построения диаграмм последовательности сообщений, создания дампов данных, построения гистограмм использования памяти - что мне не хватает?

Хм, бинарный или ascii формат файла журнала? Ascii больше, но бинарный требует больше обработки. Я сделал оба, в настоящее время я использую ascii

Вопрос - я что-то упустил, и как я могу улучшить это?

Answer 1

Одной вещью, которая может быть полезной, является наличие объекта "MaybeLogger", который будет принимать записи журнала для операции, которая может или не может быть успешной, а затем либо отбросит эти записи, если операция завершится успешно или завершится неудачно неинтересным способом, либо войти их, если это что-то интересное. Это относительно легко сделать в чем-то вроде .net. Во встроенной системе это можно сделать очень легко, только если количество регистрируемого материала достаточно мало, чтобы поместиться в свободную оперативную память, но, возможно, можно использовать подход на основе сборки мусора для хранения содержимого во флэш-памяти (иметь один поток данных во флэш-памяти для новых записей журнала и еще один для записей, которые подтверждаются как интересные; периодически перемещайте данные, которые, как известно, являются хорошими, из первого потока во второй).

Answer 2

Вы можете «обрабатывать» свой код разными способами, начиная от событий запуска / останова и заканчивая выполнением отдельных машинных инструкций (используя эмулятор процессора). Из всех возможностей, что стоит делать? Не просто делайте это ради полноты; иметь конкретную цель в виду. Бизнес-кейс, если хотите, с выгодой, которую вы ожидаете получить. E.g.:

• Изучение времени / шаблонов выполнения задач ЦП для включения оптимизации (если вам необходимо повысить производительность).
• Анализ других систем для решения проблем системной интеграции (например, какие сообщения отправляет и получает ваш VoIP-бокс, когда он подключается к конкретному узлу?)
• Понимание природы ошибок (для полевой диагностики)
• Помощь в разработке
• Помощь в проверочном тестировании

Я полагаю, что нет единой теории ведения журнала, потому что то, что вы делаете, будет зависеть от многих деталей:

• Количество данных
• Тип данных
  • События
  • Потоковое аудио / видео
• Доступное хранилище
  • Скорость хранения
  • Емкость
• Доступные каналы для извлечения данных
  • Пропускная способность
  • Стоимость
  • Доступность
    • Интернет подключен 24 × 7
    • Требуется посещение сайта
    • Нужно разблокировать ржавые ворота, взобраться по лестнице на крышу, подключить кабель, после заполнения OHS документации
    • Нужно дождаться окончания зимы в Антарктике и таяния ледяных щитов
• Произвольный доступ против линейного доступа (например, если вы сжимаете его, нужно ли с самого начала читать, чтобы распаковать и получить доступ к некоторой случайной точке?)
• Нужно выжить в условиях ошибки
  • Watchdog перезагружается
  • Возможно повреждение данных
    • Из-за сбоя питания
    • Из-за ненадежных носителей
    • Нужно пережить авиакатастрофу

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

Answer 3

я что-то пропустил, и как я могу улучшить это?

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

Хм, бинарный или ascii формат файла журнала? Ascii больше, но бинарный требует больше обработки. Я сделал оба, в настоящее время я использую ascii

ASCII это хорошо. Чаще всего журналы предназначены для использования в целях отладки. Читаемая человеком форма облегчает и ускоряет это. Однако, если ваши журналы используются в основном для записи информации, которая впоследствии используется для анализа и генерации отчетов (например, статистика или задержки и т. Д.), Предпочтителен двоичный формат. Вы можете сделать шаг вперед и использовать собственный формат вместе со службой db, которая выполняет сортировку на основе индекса, где индекс может быть кортежем времени с типом события.

-

Answer 4

Вот мои $ 0,02.

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

Я делаю ASCII только потому, что это по телнету.

Другим аспектом telnet является то, что он довольно прост. Это порт TCP с выбрасываемым текстом. Очень мало обработки, кроме обычных головных болей TCP.

Файлы журнала сбрасываются, как только я их получаю, потому что я не пытался перехватить и сохранить сеанс telnet. Я думаю, что мог бы с WireShark, но мне не нужна история этого сеанса. Мне просто нужно найти проблему и проверить ее исправление.