etl logs что это
Высвободил более 5 Гигабайт на диске, удалив файлы etl. Что это и можно ли удалять?
Заметил, что накопился существенный объем файлов с расширение etl в папке C:\ProgramData\Microsoft\Diagnosis\ETLLogs. Откуда они берутся и можно ли их безболезненно удалить?
Сама аббревиатура ETL расшифровывается как Extract, Transform и Load, то есть извлечение, преобразование и загрузка. Подобные файлы накапливают в себе разные системные события, журналы обращений к диску, различные события ядра операционной системы и объединяют их в единое хранилище. Windows 10 хранит в них данные телеметрии, что наводит на мысль о их никчёмности для конечного пользователя.
Стоит отметить, что это не какое-то эксклюзивное изобретение Microsoft и такие данные собираются сейчас повсеместно и используются различными сервисами при машинном обучении, исследовании маркетинговых данных и бизнес-аналитики, да много для чего.
Теоретически, Windows записывает туда различные предупреждения, ошибки или другие события, которые должны использоваться для устранения потенциальных проблем. По заверениям Майкрософт, отправляется только минимальный объем данных, необходимый для защиты Windows. Что там происходит на практике, остаётся только догадываться, но объём этих данных я бы не назвал маленьким. Так на терминальном сервере с 20 пользователями за месяц набегает около 1.5 Гигабайт данных!
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Сборки для сбора данных и предварительные сборки
(Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds.)
Параметру «Разрешить телеметрию» (Allow Telemetry) выставляем значение 0 или «Отключена». Насколько я понимаю, полностью отключить телеметрию в Windows всё-таки не получится, но таким образом можно существенно снизить объёмы накопление логов.
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 2
Большое вам спасибо
Жаль, что не предусмотрели Reg-файл для Windows Home
Файлы журнала Центра обновления Windows
В следующей таблице описываются файлы журнала, созданные Windows Update.
Создание WindowsUpdate.log
Чтобы объединить и преобразовать Windows файлы трассировки (etl files) в один читаемый файл WindowsUpdate.log, см. в публикации Get-WindowsUpdateLog.
При запуске комлета Get-WindowsUpdateLog создается копия файла WindowsUpdate.log в виде статичного файла журнала. Он не обновляется как старый WindowsUpdate.log, если вы не запустите Get-WindowsUpdateLog снова.
Windows обновления компоненты журнала
В Windows Update есть разные имена компонентов. Ниже приводится ряд наиболее распространенных компонентов, которые отображаются в файле WindowsUpdate.log:
Многие сообщения журнала компонентов неоценимы, если вы ищете проблемы в этой области. Однако они могут быть бесполезными, если не фильтровать, чтобы исключить нерелевантные компоненты, чтобы можно было сосредоточиться на важных компонентах.
Windows структура журнала обновления
Структура журнала Windows обновления разделена на четыре основных удостоверения:
Структура WindowsUpdate.log обсуждается в следующих разделах.
Штампы времени
Отметка времени указывает время ведения журнала.
ID процесса и нить ID
ID-данные процесса и потоковые ИД являются случайными, и они могут отличаться от журнала к журналу и даже от сеанса службы до сеанса службы в одном журнале.
Имя компонента
Поиск и определение компонентов, связанных с идентификацией. Различные части Windows обновления имеют разные имена компонентов. Некоторые из них являются следующими:
Идентификаторы обновления
Update ID and revision number
Существуют различные идентификаторы для одного и того же обновления в разных контекстах. Важно знать схемы идентификаторов.
Изменение ID
Локальный ID
Несогласованная терминология
Иногда журналы используют термины несогласованно. Например, в списке InstalledNonLeafUpdateIDs фактически содержатся измененные ИД, а не обновленные.
Распознавание ID-данных по форме и контексту:
Windows установки журнальных файлов с помощью средства SetupDiag
SetupDiag — это диагностический инструмент, который можно использовать для анализа журналов, связанных с установкой Windows обновлений. Подробные сведения см. в инструкции SetupDiag.
Мониторинг ETL-процессов в маленьком хранилище данных
Многие используют специализированные инструменты для создания процедур извлечения, трансформации и загрузки данных в реляционные базы данных. Процесс работы инструментов логируется, ошибки фиксируются.
В случае ошибки в логе содержится информация о том, что инструменту не удалось выполнить задачу и какие модули (часто это java) где остановились. В последних строках можно найти ошибку базы данных, например, нарушение уникального ключа таблицы.
Чтобы ответить на вопрос, какую роль играет информация об ошибках ETL, я классифицировал все проблемы, произошедшие за последние два года в немаленьком хранилище.
Характеристики хранилища, где проводилась классификация:
К логическим ошибкам относятся такие, как нарушение ключей таблицы, не валидные объекты, отсутствие доступа к объектам и т.п.
Планировщик может быть запущен не вовремя, может зависнуть и т.п.
Простые ошибки не требуют много времени на исправление. С большей их частью хороший ETL умеет справляться самостоятельно.
Сложные ошибки вызывают необходимость открывать и проверять процедуры работы с данными, исследовать источники данных. Часто приводят к необходимости тестирования изменений и деплоймента.
Итак, половина всех проблем связана с базой данных. 48% всех ошибок — это простые ошибки.
Третья часть всех проблем связана с изменением логики или модели хранилища, больше половины этих ошибок являются сложными.
И меньше четверти всех проблем связана с планировщиком задач, 18% которых — это простые ошибки.
В целом, 22% всех случившихся ошибок являются сложными, их исправление требует наибольшего внимания и времени. Происходят они примерно раз в неделю. В то время, как простые ошибки случаются почти каждый день.
Очевидно, что мониторинг ETL-процессов будет тогда эффективным, когда в логе максимально точно указано место ошибки и требуется минимальное время на поиск источника проблемы.
Эффективный мониторинг
Что мне хотелось видеть в процессе мониторинга ETL?
Start at — когда начал работу,
Source — источник данных,
Layer — какой уровень хранилища загружается,
ETL Job Name — поцедура загрузки, которая состоит из множества мелких шагов,
Step Number — номер выполняемого шага,
Affected Rows — сколько данных уже обработалось,
Duration sec — как долго выполняется,
Status — всё ли хорошо или нет: OK, ERROR, RUNNING, HANGS
Message — последнее успешное сообщение или описание ошибки.
На основании статуса записей можно отправить эл. письмо другим участникам. Если ошибок нет, то и письмо не обязательно.
Таким образом, в случае ошибки чётко указано место происшествия.
Иногда случается, что сам инструмент мониторинга не работает. В таком случае есть возможность прямо в базе данных вызвать представление (вьюшку), на основании которой построен отчёт.
Таблица мониторинга ETL
Чтобы реализовать мониторинг ETL-процессов достаточно одной таблицы и одного представления.
Для этого можно вернуться в своё маленькое хранилище и создать прототип в базе данных sqlite.
Вывод
Таким образом, сообщения об ошибках в инструментах обработки данных играют мега-важную роль. Но оптимальными для быстрого поиска причины проблемы их сложно назвать. Когда количество процедур приближается к сотне, то мониторинг процессов превращается в сложный проект.
В статье приведён пример возможного решения проблемы в виде прототипа. Весь прототип маленького хранилища доступен в gitlab SQLite PHP ETL Utilities.
Основные функции ETL-систем
ETL – аббревиатура от Extract, Transform, Load. Это системы корпоративного класса, которые применяются, чтобы привести к одним справочникам и загрузить в DWH и EPM данные из нескольких разных учетных систем.
Вероятно, большинству интересующихся хорошо знакомы принципы работы ETL, но как таковой статьи, описывающей концепцию ETL без привязки к конкретному продукту, на я Хабре не нашел. Это и послужило поводом написать отдельный текст.
Хочу оговориться, что описание архитектуры отражает мой личный опыт работы с ETL-инструментами и мое личное понимание «нормального» применения ETL – промежуточным слоем между OLTP системами и OLAP системой или корпоративным хранилищем.
Хотя в принципе существуют ETL, который можно поставить между любыми системами, лучше интеграцию между учетными системами решать связкой MDM и ESB. Если же вам для интеграции двух зависимых учетных систем необходим функционал ETL, то это ошибка проектирования, которую надо исправлять доработкой этих систем.
Зачем нужна ETL система
Проблема, из-за которой в принципе родилась необходимость использовать решения ETL, заключается в потребностях бизнеса в получении достоверной отчетности из того бардака, который творится в данных любой ERP-системы.
Как работает ETL система
Все основные функции ETL системы умещаются в следующий процесс:
В разрезе потока данных это несколько систем-источников (обычно OLTP) и система приемник (обычно OLAP), а так же пять стадий преобразования между ними:
Особенности архитектуры
Реализация процессов 4 и 5 с точки зрения архитектуры тривиальна, все сложности имеют технический характер, а вот реализация процессов 1, 2 и 3 требует дополнительного пояснения.
Процесс загрузки
При проектировании процесса загрузки данных необходимо помнить о том что:
Процесс валидации
Данный процесс отвечает за выявление ошибок и пробелов в данных, переданных в ETL.
Само программирование или настройка формул проверки не вызывает вопросов, главный вопрос – как вычислить возможные виды ошибок в данных, и по каким признакам их идентифицировать?
Возможные виды ошибок в данных зависят от того какого рода шкалы применимы для этих данных. (Ссылка на прекрасный пост, объясняющий, какие существуют виды шкал — http://habrahabr.ru/post/246983/).
Ближе к практике в каждом из передаваемых типов данных в 95% случаев возможны следующие ошибки:
Соответственно проверки на ошибки реализуются либо формулами, либо скриптами в редакторе конкретного ETL-инструмента.
А если вообще по большому счету, то большая часть ваших валидаций будет на соответствие справочников, а это [select * from a where a.field not in (select…) ]
При этом для сохранения аудиторского следа разумно сохранять в системе две отдельные таблицы – rawdata и cleandata с поддержкой связи 1:1 между строками.
Процесс мэппинга
Процесс мэппинга так же реализуется с помощью соответствующих формул и скриптов, есть три хороших правила при его проектировании:
Заключение
В принципе это все архитектурные приемы, которые мне понравились в тех ETL инструментах, которыми я пользовался.
Кроме этого конечно в реальных системах есть еще сервисные процессы — авторизации, разграничения доступа к данным, автоматизированного согласования изменений, и все решения конечно являются компромиссом с требованиями производительности и предельным объемом данных.
Etl logs что это
Вопрос
Накопился большой объем файлов C:\ProgramData\Microsoft\Diagnosis\ETLLogs с расширение etl
Гуглю. но пока в голове не очень укладывается что это.
Что, это, как с ними быть? Чистить? И можно ли отрегулировать политиками?
Ответы
Нашел еще в шедулере задачи Microsoft Compatibility Appraiser «Сбор телеметрических данных программы при участии в программе улучшения качества ПО»
Могли бы уточнить, если указанная задача активна?
Сообщите пожалуйста если следующие службы на сервере активны?
Для того чтобы просмотреть в политике если Телеметрия включена, необходимо выполнить следуюшие шаги(на английском):
Если верить строномиму источнику, то этот файл лог отностится к телеметрии, и если это так, то его можно удалить, но лучше дождаться еще ответов от других участников форума. Также перед тем, как его удалить желательно понять, какая задача способствует наполнению данных в указанный лог событий.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.