caxapa.ru :: 1) Я не один, есть команда 2) У каждого в команде своя специализация. Информационная охота - это мое :) 3) Иметь книги и читать их ВСЕ "от корки до корки" - разные понятия, никак не связанные друг с другом 4) Идеальных книг не бывает, полное

Evgeny_CD^{Архитектор} (24.02.2012 13:47, просмотров: 1071) ответил =AlexD= на У меня такое ощущение, что у Вас, Евгений, основной принцип - "не вые#$, так хоть согреюсь"(с) - я не представляю, что-бы кто-нибудь освоил весь тот пласт книг, которые Вы коллекционируете.

1) Я не один, есть команда 2) У каждого в команде своя специализация. Информационная охота - это мое :) 3) Иметь книги и читать их ВСЕ "от корки до корки" - разные понятия, никак не связанные друг с другом 4) Идеальных книг не бывает, полное предствление о теме можно получить только из нескольких. Теперь по полному логу. Все идеи я тут высказывал, и я, и многие другие их реализовали. Если лог автономный, то тут надо смотреть на задачи и ресурсы. Хорошо помогает "битовый лог" - когда каждый бит обзначает наступление события. К некоторым событиям прикручиваем счетчики. В 128 байтах можно мониторить факт наступления 1024 событий - не мало, знаете ли :) Если есть связь c ПЦ то все просто. Есть FPGA. В ней тикает таймер. Пишем из программы по адресу int. В FPGA логится время, адрес и данные. Пакуется само в пакет и через FTDI чип гонится на писюк. При некоторой хитрости все в 8 байт слазит. 30 Мбайт\сек FTDI "отсоса" - почти 4м событий в сек. Главное, потом разобрать такой поток :) Его надо сразу в SQL базу, и анализатор всего этого (совместно с кодом, где и стоят эти "метки") - это уже большое know-how. Вся система как на ладони. Отладка просто суперская. Code Coverage в реальном времени и реальном устройстве.

Ответить

- Не понимаю любителей СУБД, засунуть бинарный лог в строки БД, а потом тратить на порядки большие ресурсы на их анализ. - lentjaj2(24.02.2012 13:58, )
  - ??? Если структура БД отвечает задаче, и всовывать не BLOB, а сразу в нужном формате по полям, и БД держать в памяти - Вы предпочитаете ручками в логах терминала ковыряться? - Evgeny_CD(24.02.2012 14:02)
    - Зачем BLOB, достаточно бинарного файла, места не много занимает и автоматизированный анализ будет требовать меньше ресурсов. Хотя судя по Вашей задаче "поиск жуков" требуется другое, думаю можно обойтись без БД, конвертировать нужный lentjaj2(103 знак., 24.02.2012 14:45, )
- Т.е. лог вы уже ведёте, исходный массив данных уже есть? - =AlexD=(24.02.2012 13:56)
  - Не понял вопроса. - Evgeny_CD(24.02.2012 14:03)
    - 4м событий вы получаете, складываете в файл, накапливаете - всё это уже есть и работает? - =AlexD=(24.02.2012 14:07)
      - Если в файл складыается 1к событий в сек (система медленная, сейчас говнокодерские ошибки выловили, можно мониторить только важное), и вместо FPGA стоит "микроконтроллер для логгинга" - что изменится для Вас? Что именно я делаю в рамках своих Evgeny_CD(29 знак., 24.02.2012 14:10)
        
        Я просто пытаюсь понять, что полезного даёт вам гиг подобных логов? Есть польза, или процесс не выходит за рамки ручного изучения логов, когда система ведёт себя не по спецификации? - =AlexD=(24.02.2012 14:26)
        
        Простой пример. Едет машина "по дорогам и по взгорьям" с GPRS девайсом. Связь то есть, то нет. Юзер звонит голосом, ему звонят. Есть 3 замечательных сущности: Evgeny_CD(368 знак., 24.02.2012 14:33)
        
        SQL это слишком круто. Практически в похожей ситуации можно записывать тупо текстовые файлы. Или "полутекстовые", когда вместо текстов записываются ссылки на адрес строки в ПЗУ (потом этот поток легко декодируется если есть бинарник записавшей fk0(220 знак., 24.02.2012 14:52)
        
        Потому, что SQL стандартен и удобен, при базе в памяти очень быстр. Для целей разработки экономия ресурсов не так важна. Для экономии памяти помогает предварительный парсинг - неважные записи игнорируем. Но это ухудшает полноту картины. - Evgeny_CD(24.02.2012 14:57)
        
        Тем не менее вы ушли от ответа ;-). Понятно, что в 4Г логе нужно найти пропадание связи в некотором промежутке времени и прошерстить внутренние переходы состояний программы. Но сможете ли вы найти баг, если юзверь не жаловался? :-) - =AlexD=(24.02.2012 14:41)
        
        В общем, иногда можно. Если поведение системы при нормальной работе должно соответствовать некому шаблону (последовательность действий, соответствующих им диагностических сообщений), при ненормальной работе шаблон не подходит. Вопрос как fk0(41 знак., 24.02.2012 14:54)
        
        Мои экземпляры объектов класса "юзер" выдавали в stdout только "Вы мудаки! Ничего не работает!" :) В общем, если никаой реакции нет - можно и не рисечить. Но иногда, в важных проектах, ма привентивно пускали тестовую машину, и потом анализировали Evgeny_CD(52 знак., 24.02.2012 14:54)
        
        Ну в общем понятно, мегалоггинг с некоторыми инструментами выковыривания данных. Я то думал, что вы нашли способ более-менее строгого определения корректности работы системы, и точите инструментарий под полную автоматизацию. - =AlexD=(24.02.2012 15:06)
        
        Я бы сказал так, это правильная цель, но я понимаю как ее достичь только для узких задач. Т.е. вот сейчас делается простое устройство с высокой надежностью, там будет отдельный программно-аппаратный модуль контроля правильности работы. Но там Evgeny_CD(82 знак., 24.02.2012 15:33)
        
        Нет, о таком я пока аккуратно так мечтаю внутри себя :) - Evgeny_CD(24.02.2012 15:09)

Средства и методы разработки