GPS-логгер (GPS рекордер, пассивный трекер или GPS DATA-логгер) — особый класс GPS-радиоприёмников, который может работать в режиме обычного GPS-приёмника (принимая информацию от спутниковой группировки NAVSTAR и передавая её на другое устройство по Bluetooth или USB) или — в режиме рекордера/логгера записывая информацию о пройденном пути (треке) в свою встроенную память. Впоследствии накопленную информацию из приёмника можно выгрузить в компьютер для её анализа.
GPS-логгер обычно используется для спутникового мониторинга людей, домашних животных и других ценных объектов. От обычного GPS-приёмника GPS-логгер отличается отсутствием экрана, а от GPS-трекера его отличает отсутствие GSM модуля, обеспечивающего онлайн-передачу данных на серверный центр мониторинга.
Регистратор данных (также даталоггер или дата-логгер) — электронное устройство, которое записывает во внутреннюю память, на внешнее хранилище или передаёт в облачный сервис данные. Данные сохраняются с течением времени или по отношению к местоположению. Данные могут поступать от встроенного в прибор сенсора или датчика или от внешних приборов и датчиков. Всё больше и больше, но не полностью, регистраторы данных создаются на базе цифровых процессоров (или компьютеров). Они, как правило, небольшие, на батарейках, портативные, и снабжены микропроцессором, внутренней памятью для хранения данных и различными встроенными датчиками. Некоторые регистраторы данных обладают специальным интерфейсом для подключения к персональному компьютеру, а также используют программное обеспечение, чтобы активировать регистратор данных, просматривать и анализировать собранные данные. В то же время некоторые устройства могут иметь локальный интерфейс (клавиатура, дисплей) и могут быть использованы в качестве автономного устройства.
Регистратор данных сохраняющий технические данные и показания сенсоров
Регистраторы данных варьируются от изделий общего назначения для измерительных применений до очень специфических приборов для измерения в одной среде, или только одного параметра. Возможность программирования является общей особенностью для изделий общего назначения; в то время как многие другие даталоггеры остаются как статическими машинами с ограниченным количеством или полным отсутствием сменных параметров. Электронные регистраторы данных заменили Диаграммные самописцы во многих областях.
Одним из основных преимуществ использования дата-логгеров является возможность автоматически собирать данные на 24-часовой основе. После активации, регистраторы данных обычно продолжают сбор данных, оставленные без присмотра, для измерения и записи информации в течение периода мониторинга. Это позволяет обеспечить всестороннее, точное представление об условиях окружающей среды или наблюдаемых параметрах технологического процесса, таких как температура воздуха, относительная влажность или расход, давление, вибрация, ударная нагрузка и пр.
Стоимость регистраторов данных сокращается на протяжении многих лет, поскольку технологии улучшаются и сокращают расходы. Простые одноканальные регистраторы данных стоят всего $25. Более сложные регистраторы могут стоить сотни или тысячи долларов.
Небольшой регистратор данных со встроенными датчиками измерения температуры, давления, влажности, света и ускорения в 3-х осях
На сегодняшний день, многим отраслям необходимо обеспечивать надлежащее качество своей продукции. С этим как нельзя лучше справляется логгер – специальное устройство, с помощью которого определяют показатели температуры и влажности. Его применение особенно актуально в промышленности, сельском хозяйстве, различных жилых и производственных зданиях, позволяя обеспечивать надлежащий контроль хранения продуктов или других товаров. В статье много полезной информации о принципах работы данного прибора, его пользе в бизнесе и других сферах жизнедеятельности человека.
Когда речь идет о товарах широкого потребления, без работы этого электронного прибора не обходится ни один производственный процесс. Логгеры температуры актуальны там, где необходимо регулярно поддерживать ее в оптимальном режиме, а именно:
Как видите, функции регистраторов температуры весьма обширны, выступая в качестве незаменимого атрибута в современном технологическом мире.
Логгеры воздуха тоже немаловажны для обеспечения нормальных условий труда работников. Благодаря ему уровень влажности в складских или бытовых помещениях, на рабочем месте в офисах или банках всегда в норме. Обеспечение надлежащих микроклиматеческих условий – важный критерий, повышающий производительность труда.
Логгеры данных отвечают за качество воздуха, ведь чем больше в нем углекислого газа, тем он насыщеннее. Широко применяются как в жилых, так и офисных помещениях. Поддержание свежести продуктов также находится в прямой зависимости от использования этого инновационного чуда техники.
В заключение, хотелось бы упомянуть о том, что измеритель регистратор логгер может использовать для сохранения данных накопитель MicroSD, хотя и сам рассчитан на большие объемы памяти (до 15 тысяч измерений). При необходимости обработки данных, смело подключайте его к ПК, ноутбуку либо другому гаджету, посредством USB интерфейса. Современные модели оснащены даже беспроводной сетью Wi-Fi, что значительно упрощает процесс работы. Способен выдерживать как низкие, так и высокие температуры. Легок и удобен в управлении, умещаясь в руке или кармане.
Время на прочтение
Часто вижу, что помимо обработки исключений, люди мучаются кое с чем еще, а именно с логированием.
Большинство людей не знают, что писать в логи, поэтому решают логировать все, что угодно, думая, что все подряд – это в любом случае лучше, чем ничего, и, в конечном итоге, просто создают шум. А шум – это информация, которая никак не помогает вашей команде понять, в чем дело и как решить проблему.
Более того, я не думаю, что эти люди могут уверенно пользоваться уровнями логирования, поэтому используют по умолчанию logger.info везде (если не пишут print).
Наконец, люди, похоже, не знают, как сконфигурировать логирование в Python, понятия не имеют, что такое обработчики, фильтры, методы форматирования (форматтеры) и т.д.
Цель этой статьи – разъяснить, что такое логирование и как вы должны его реализовывать. Я постараюсь привести содержательные примеры и обеспечить вас гибкими эмпирическими приемами, которые следует использовать при логировании в любом приложении, которое вы когда-либо будете создавать.
- Введение
- Хорошее логирование имеет значение
- Когда нужно логировать?
- Что логировать?
- Хороший пример логов
- Предоставление контекста с помощью Python
- Правильно настройте логгер
- Что такое логгеры?
- Форматируйте логи
- Фильтруйте логи
- Обрабатывайте логи и то, как все связано
- Шаблон конфигурации логирования
- Конфигурация логирования
- Ведение журнала данных и сбора данных
Введение
Примеры облегчают визуальное восприятие, поэтому мы будем рассматривать следующую систему:
Я не буду сосредотачиваться на проблемах поддержки таких интеграций, просто пронаблюдаем за тем, как это работает.
Хорошее логирование имеет значение
Для начала давайте проанализируем характеристики логов.
Логи должны быть:
«Наглядными» мы их называем потому, что они предоставляют вам какую-то информацию, «контекстными», потому что они дают вам общее представление о том, как обстоят дела на данный момент времени. И наконец, «реактивными» они являются потому, что они позволяют вам предпринимать действия только после того, как что-то произошло (даже если ваши логи отправляются/получаются в режиме реального времени, на самом деле вы не можете изменить то, что произошло только что).
Если вы не будете учитывать природу логов, то будете производить только шум, что снизит вашу производительность.
Дальше я приведу несколько примеров, основанных на системе, которую мы определили выше:
Если вы зададите описание, к примеру «operation connect failed», но не добавите контекст, трудно будет понять, какая из интеграций не отработала, кто пострадал, на каком этапе подключения произошел сбой, поэтому и среагировать вы не можете. В конечном итоге вы будете копаться в тонне логов без малейшего представления о том, где может быть проблема.
О, а еще не стоит недооценивать способность разработчика испортить описание. Сделать это легко, просто отправив поверхностные сообщения без какого-либо контекста, например «An error happened» или «An unexpected exception was raised». Если я прочту такое, то даже не пойму, на что повлияла ошибка, потому что не буду знать, ЧТО конкретно произошло. Так что да, можно сломать даже основной смысл логов.
Логи – это конфиденциальная информация из вашего программного обеспечения, нужная чтобы вы оставались в курсе происходящего и могли реагировать на ситуации. Любые логи, которые не дают вам такой информации – это шум.
Когда нужно логировать?
Чтобы логи оставались реактивными, вам нужно логировать «события». Сделайте их такими же понятными и удобными для чтения, как эта статья. Возможно, вы не прочитали каждую строку, которую я написал выше, но вы все равно можете продолжить дальше, пропустить ненужные разделы и сосредоточиться на том, что привлекло ваше внимание. Логи должны быть такими же.
Есть эмпирическое правило построение логов:
Логи должны рассказывать вам историю, у каждой истории есть начало, середина и конец.
Будьте осторожны с релевантностью, добавлять логи проще, чем удалять их, ведь все, что нерелевантно – шум.
Что логировать?
Чтобы логи были наглядными и контекстными, нужно предоставлять правильный набор информации, и я не могу сказать, какая информация будет являться таковой, не зная вашего случая. Давайте вместо этого воспользуемся нашим примером.
Рассмотрим интеграцию с AWS в качестве примера. Было бы круто иметь следующие сообщения:
Хороший пример логов
Допустим, что извлечь экземпляры из региона af-south-1 не удалось из-за какой-то внезапной ошибки в этом регионе.
В обоих случаях, я могу отследить, когда произошло какое-то событие (в логах есть отметки о времени), что именно произошло и кто от этого пострадал.
Я решил не указывать пользователя при начале и успешном завершении операции, потому что это не имеет значения (ведь это шум), поскольку:
Добавление таких данных делает логи шумными, потому что на них невозможно реагировать, делать-то с этим ничего не надо! Но я все еще должен быть в состоянии собрать детальную информацию из атрибутов (кто, когда, почему и т.д.). Если вы хотите что-то измерить, вам следует воспользоваться метриками, а не логами.
Ключевой момент следующий: вы можете отреагировать сразу и для этого вам не требуется более глубокого изучения ситуации. Вы знаете все, что вам нужно, и можете немедленно принять меры для уменьшения ущерба. Разработчикам, возможно, потребуется углубиться в трассировку стека, чтобы собрать больше контекста (в случае с ошибкой), но общая картина уже становится ясна.
Любое сообщение об ошибке, в котором отсутствует эта минимальная информация, становится шумом, поскольку у вас появляется беспокойство, но вы все еще не можете действовать. Сначала нужно углубиться в ситуацию, чтобы понять, насколько проблема серьезна.
Если вы все еще не поняли, как писать полезные сообщения, я поделюсь с вами очень простым лайфхаком:
Всегда спрашивайте себя: Что я хочу уяснить для себя, после получения такого лога?
Предоставление контекста с помощью Python
В Python атрибуты логов можно добавить с помощью дополнительного поля, например:
Контекст не отменяет необходимости в содержательных сообщениях! Поэтому я бы так не делал:
Сообщения должны быть четкими и не оставлять места вопросам о том, что же вообще происходит. Контекст должен обогащать ваш опыт, предоставив информацию о более глубоких деталях, и давать вам понимание, по какой причине что-то произошло.
Нечто большее, чем logger.info и logger.error
Не так-то просто понять, что происходит, когда тысячи клиентов выдают логи «Connecting to Slack». Поскольку вы выдаете логи, а вашим приложением пользуются несколько клиентов, нужно иметь возможность фильтровать информацию по релевантности.
В логах бывает много уровней (т.е. уровней релевантности). В Python у вас есть DEBUG, INFO, WARNING, ERROR, CRITICAL. Я рекомендую использовать их все.
Чтобы упростить ситуацию, вот вам новое эмпирическое правило (будьте гибкими):
Для описанной системы/потоков, я бы использовал уровни логов, как определено:
Что делать с logger.critical и logger.warning?
Для примера хочу осветить случаи, когда я бы рассмотрел возможность использования WARNING и CRITICAL.
Для этих случаев мы рассмотрим:
Непопулярное мнение: использование DEBUG-уровня на продакшене
Да, я считаю, что логи DEBUG нужно использовать на продакшене.
Другой вариант – включить дебаг после того, как странная ошибка потребует более детального разбирательства.
Простите, но для меня такой вариант недопустим.
В реальном мире клиентам нужна быстрая реакция, командам нужно выполнять свою работу и постоянно поддерживать системы в рабочем состоянии. У меня нет времени и пропускной способности для нового деплоя или включения флага и ожидания повторения проблемы. Я должен реагировать на неожиданные проблемы в считанные секунды, а не минуты.
Правильно настройте логгер
Еще я замечаю, что люди испытывают трудности при настройке логгера (или вообще его не настраивают). Конечно, документация в Python не очень дружелюбная, но это не оправдание, чтобы вообще ее не трогать.
Есть несколько способов настроить логгер. Вы можете использовать logging.config.dictConfig, logging.config.fileConfig или вообще сделать все вручную, вызывая такие команды как setLevel, AddHandler, addFilter.
По моему опыту:
Поэтому в качестве примера мы будем придерживаться dictConfig. Еще можно запустить basicConfig, но не думаю, что он вам понадобится, если вы все настроили правильно.
Я поделюсь несколькими советами и определениями, которые вам надо знать, а затем мы создадим окончательную конфигурацию на реальных примерах из проектов, над которыми я работаю.
Вот кусочек того, о чем мы будем говорить дальше:
Что такое логгеры?
Логгеры – это объекты, которые вы создаете с помощью logging.getLogger, они позволяют выдавать сообщения. Каждый отдельный логгер может быть привязан к конфигурации со своим собственным набором форматтеров, фильтров, обработчиков и т.д.
Самое интересное, что логгеры образуют иерархию и все наследуются от root-логгера. Дальнейшее наследование определяется «.» (точками), например mymodule.this.that будет наследником mymodule.this.
Из-за этого в документации Python есть рекомендация по использованию logger.getLogger(name), поскольку name, вернет лишь пространство имен текущего пакета.
В любом случае, придерживайтесь:
Внимание: Вы можете обратиться к корневому логгеру по имени root, пустой строке “” или вообще ни по чему. Да, это сбивает с толку, поэтому используйте root для многословности и ясности.
Форматируйте логи
Форматтеры вызываются для вывода конечного сообщения и отвечают за него преобразование в конечную строку.
Когда я работал в Zak (бывшем Mimic), и даже сегодня в Lumos мы форматировали логи как JSON. Он является хорошим стандартом для систем, работающих на продакшене, поскольку содержит множество атрибутов. Проще визуализировать JSON, чем обычную длинную строку, и для этого вам не нужно создавать свой собственный форматтер (ознакомьтесь с python-json-logger).
Для локальной разработки я рекомендую использовать форматирование по умолчанию для простоты.
Ваше решение будет зависеть от вида проекта. Для Tryceratops я решил использовать обычный форматтер, поскольку он проще и работает локально, там нет нужды в JSON.
Фильтруйте логи
Фильтры можно использовать либо для фильтрации логов (внезапно), либо для добавления дополнительного контекста в запись лога. Рассматривайте фильтры, как хуки, вызываемые до обработки итогового лога.
Их можно определить следующим образом:
Адаптировано из https://docs.python.org/3/howto/logging-cookbook.html#using-filters-to-impart-contextual-information
Или их можно добавить прямо в логгер или обработчик для упрощения фильтрации по уровням (скоро будут примеры).
Обрабатывайте логи и то, как все связано
Обработчики представляют из себя комбинации форматтеров, выходных данных (потоков) и фильтров.
С ними вы можете создавать следующие комбинации:
Наконец логгеры указывают обработчикам.
Теперь, когда вы понимаете, что делают все эти объекты, давайте писать собственные! Как всегда, я постараюсь показать вам примеры из реальной жизни. Я буду использовать конфигурацию Tryceratops. Вы можете открыть ссылку и посмотреть самостоятельно окончательную конфигурацию.
Шаблон конфигурации логирования
Начнем с такого каркаса, создадим константу LOGGING_CONFIG:
Корневой логгер можно определить тремя разными способами, что сбивает с толку:
Выбирайте любой! Мне нравится оставлять его снаружи, поскольку так он выглядит очевиднее и подробнее говорит о том, чего я хочу, ведь корневой логгер влияет на все другие определенные логгеры.
Конфигурация логирования
Я дополню пример из Tryceratops примером с JSON из Lumos.
Обратите внимание, что имена, которые мы задаем (default, simple и JSON), – произвольные, но актуальные. Вскоре мы к ним обратимся.
Обратите внимание, что если вы используете logging.fileConfig, иметь хорошую константу, такую как ERROR_LOG_FILENAME, невозможно. Эту же информацию можно прочитать из переменных среды, если хотите.
Также обратите внимание, что классы/параметры, которые я использую для обработчиков, создавал не я. Они из библиотеки logging, и там есть не только они!
Конфигурация логирования: логгеры и root
Давайте разберемся, что происходит:
Имя логгера tryceratops – это очень важная часть, и оно должно соответствовать логгерам, которые я создам позже. Для нашего примера, когда я пишу: logger.getLogger(name) внутри модуля, я получаю такие имена как tryceratops.main, tryceratops.runners или tryceratops.files.discovery, и все они соответствуют созданному нами правилу.
Я определил новый набор обработчиков для tryceratops, но все другие логгеры (в том числе из сторонних библиотек) будут использовать те, которые находятся в корне.
Кроме того, обратите внимание, что я могу переписать правила по умолчанию. Через настройки или позже динамически. Например, каждый раз, когда triceratops получает подобный флаг от CLI, он обновляет конфигурацию logging чтобы включить дебаг.
Логирование – это важно, но наличие хорошо структурированных исключений и блоков try/except также важно, поэтому вы можете также прочитать, как профессионально обрабатывать и структурировать исключения в Python.
Материал подготовлен в рамках курса «Python Developer. Basic».
Использование регистратора данных для погодной станции P2I LIPI
Применение регистрации данных включает:
GPS-треки. Туристические маршруты на карте
Несколько протоколов были стандартизированы в том числе смарт-протокол, интерфейс SDI-12, что позволяет некоторым приборам подключаться к различным регистраторам данных. Использование этого стандарта не получило широкого признания за пределами экологической промышленности. SDI-12 также поддерживает многоканальные устройства. Некоторые компании-производители сейчас поддерживает протокол Modbus. Этот протокол традиционно используется в области промышленного контроля, и есть много промышленных инструментов, которые поддерживают этот стандарт связи. Ещё один многоточечной протокол, который сейчас начинает все более широко использоваться на основе шины CAN (стандарт ISO 11898). Некоторые регистраторы данных используют гибкий алгоритмы со скриптами, чтобы адаптироваться к различным нестандартным протоколам.
Ведение журнала данных и сбора данных
Термины регистрация данных и сбор данных часто используются как синонимы. Однако, в историческом контексте они совершенно разные. Регистратор данных-это система сбора данных, но система сбора данных не обязательно является регистратором.
Стандартизации протоколов и форматов данных была проблемой, но на данный момент в отрасли форматы XML, JSON и YAML, все чаще используются для обмена данными. Развитие Semantic Web и Internet of Things, вероятнее всего ускорится — в этом нынешняя тенденция.
Спорт, туризм, геотегинг фотографий, спутниковый мониторинг, геокэшинг, рыболовство, слежение за подвижными объектами, городское ориентирование, геодезия, картография и др.