caxapa.ru :: Т.е. лог вы уже ведёте, исходный массив данных уже есть?

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

Т.е. лог вы уже ведёте, исходный массив данных уже есть?

Три кита на которых зиждется реклама: враньё, преувеличение, замалчивание. Новости СМИ - это политическая реклама.

Ответить

- Не понял вопроса. - 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)

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