Ошибка загрузки справочника товаров подробности в лог файле
Диагностика загрузки Windows: процесс загрузки драйверов для системы в текстовом формате.
Привет всем, продолжаем знакомиться с Windows более внимательно, и сейчас мы рассмотрим возможность изучить порядок загрузки драйверов поэтапно. Система позволяет это сделать, предлагая пользователю создавать одновременно с загрузкой лог-файл, в который она внесёт список загружаемых и выгружаемых драйверов. По умолчанию он именуется, дополняется (не обновляется) и хранится в виде C:\Windows\ntbtlog.txt. Относительно опытные пользователи наверняка знакомы с такой функцией, которая в нормально работающей системе доступна прямо из графического интерфейса. Она видна в одной из вкладок утилиты Конфигурации системы msconfig. Быстрый способ на неё выйти это набрать в строке Выполнить или через поиск (клавиша WIN) команду вызова
и выставить галку у чек-бокса Журнал загрузки:
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
- поиск ошибок и сбоев в работе системы;
- выявление вредоносной активности;
- сбор статистики посещения веб-ресурса.
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Windows работает.
Запускаем консоль от имени администратора с последующей командой
и завершаем ввод клавишей Ёптр, дождавшись вывода информации из загрузчика. Ориентируемся на сектор Загрузка Windows в части идентификатор. Описание означает, что это и есть текущая Windows. Короче, если система на компьютере одна — вообще не парьтесь. Смотрите вниз: последней строчкой загрузчик скажет, ведётся ли журнал. В части bootlog по умолчанию всегда No (ведение журнала отключено).
Активируем его тут же:
Проверяем сделанное повторной командой (если консоль вы не покидали, просто щёлкните пару раз по стрелочке вверх — это поиск и выбор ранее набранных команд)
Пока не забыли: обратная команда примет вид
Сервер сеансов
Как читать логи. Пример
Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:
Директивы имеют следующее значение:
Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».
Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:
- Analog. Один из самых популярных анализаторов, что во многом объясняется высокой скоростью обработки данных и экономным расходованием системных ресурсов. Хорошо справляется с объемными записями, совместим с любыми ОС.
- Weblog Expert. Программа доступна в трех вариациях: Lite (бесплатная версия), Professional и Standard (платные релизы). Версии отличаются функциональными возможностями, но каждая позволяет анализировать лог-файлы и создает отчеты в PDF и HTML.
- SpyLOG Flexolyzer. Простой аналитический инструмент, позволяющий получать отчеты с высокой степенью детализации. Интегрируется c системой статистики SpyLOG, позволяет решать задачи любой сложности.
Протоколы сервера сеансов
Сервер сеансов может вести два протокола: протокол обращений к серверу сеансов и протокол регистрации пользователей. Имена протоколов задаются вместе с путями до них.
Задается в параметрах файла «SBSessionSrvSettings.xml», который находится в папке с сервером сеансов.
протокол регистрации пользователей - когда и какие пользователи входили в систему, и когда выходили из нее, а также указывается количество свободных лицензий в каждый момент времени.
В этой статье мы постараемся рассмотреть основные ошибки, возникающие при обмене данными через коннектор 1С, способы их расследования и варианты решения.
Иногда возникает ситуация, что коннектор настроен, определены справочники, участвующие в обмене и ключевые реквизиты, настроены фильтры, а обмен не идет. Что делать в такой ситуации? С чего начать? Первым делом нужно проверить параметры подключения к интегрированной системе:
Убедитесь, что вы правильно указали параметры подключения: имя сервера, имя базы данных, логин, пароль и имя плана обмена. Параметр InitiateDataExchangeIn1C должен быть установлен в значение «Да», для того чтобы автоматически запустился процесс обмена данными в системе 1С после формирования файлов с данными по плану, заданному в параметре ExchangePlan.
Если параметры подключения указаны правильно, а обмен не идет, то стоит проверить настройки плана обмена в конфигураторе 1С:
Убедитесь, что объекты 1С, с которым вы настроили обмен, присутствует в списке выбранных объектов плана обмена. Также убедитесь, чтобы не стояло галочки «Распределенная информационная база». Излишне полный план обмена увеличивает количество выгружаемых данных, что очень сильно влияет на скорость обмена данными. Поэтому нужно стараться максимально облегчить план обмена только необходимыми объектами. Например, на приведенном выше скриншоте в плане обмена оставлены только необходимые для интеграции объекты 1С (4 справочника и 1 план видов характеристик).
Иногда после настройки коннектора 1С и попытке провести первый обмен, в логах обмена появляется ошибка вида:
Причина появления данной ошибки в том, что мы пытаемся загрузить в 1С неправильно сформированный XML-файл с данными обмена. Первым делом необходимо проверить настройки обмена на вкладке «Дополнительные настройки»:
Если все настройки сделаны правильно, а ошибка все равно появляется, то попробуем определить ошибочную запись в XML-файле обмена. В нашем случае это файл Message_002_001.xml. Наименование файлов обмена формируется по принципу Message_КодУзлаСистемыИсточника_КодУзлаСистемыПриемника:
У меня, в отличие от приведенного выше скриншота, коды узлов были наоборот (001 - Узел 1С, 002 – Узел DIRECTUM), чтобы вы не путались в дальнейшем. Таким образом, видим, что у нас в качестве источника выступает DIRECTUM, а в качестве приемника 1С. Откроем этот файл обмена в Visual Studio и отформатируем его:
В результате наш отформатированный XML-файл обмена будет выглядеть так:
Сохраним его и попробуем загрузить в 1С с помощью сценария:
В переменной IntegratedSystemCode нужно указать код интегрированной системы, а в переменной FullFileName путь до сформированного XML-файла с данными для обмена. Сценарий можно доработать, добавив запрос переменной IntegratedSystemCode через InputDialog, FullFileName получать из табличной части по коду системы и добавить обработку исключений, т.к. мы ждем, что появится ошибка. Я по своей натуре существо очень ленивое, поэтому оставил его в таком виде. В результате работы сценария мы получим ошибку:
Теперь мы видим строку и столбец «[4369,2]» с ошибочными данными в XML-файле обмена Message_002_001.xml. Снова открываем этот файл в Visual Studio и переходим к указанной в ошибке строке:
Тут сразу видно, что с этой записью что-то не то, но чтобы убедиться в этом окончательно, выгрузим данные из 1С с помощью внешней обработки ВыгрузкаЗагрузкаДанныхXML.epf, которую можно найти на диске ИТС или в интернете. Для этого запускаем 1С Предприятие и через пункт меню Файл\Открыть открываем обработку ВыгрузкаЗагрузкаДанныхXML.epf. Указываем имя файла для выгрузки, отмечаем какой объект 1С необходимо выгрузить и нажимаем кнопку «Выгрузить данные».
На скриншоте не указан период выгрузки, т.к. у меня база 1С была почти пустая. Если у вас в интегрируемых объектах 1С скопилось много данных (например, за несколько лет), то период выгрузки стоит обязательно указать, иначе такой выгрузкой можно очень сильно подвесить систему. Как правило, чтобы оценить правильность формирования XML-файла с данными, достаточно выгрузить 2-3 записи.
После того, как данные будут выгружены, открываем сформированный XML-файл с выгруженными данными и начинаем сравнивать, чем наша неправильно сформированная запись отличается от выгруженных из 1С. В моем случае правильно сформированная запись для выгрузки должна выглядеть так:
Сравнив её с ошибочной записью, видим, что почему-то не заполнены некоторые реквизиты значениями по умолчанию:
Для реквизита типа справочник, вместо пустого значения должны были быть нули «00000000-0000-0000-0000-000000000000», для реквизита типа число должен стоять «0», а не пустая строка, для логического реквизита вместо пустой строки должно быть «true» или «false».
Далее можно действовать исходя из поставленной перед вами задачи:
- Удалить ошибочную запись из XML-файла обмена, провести загрузку данных с помощью сценария указанного выше и скорректировать «Время последней выгрузки» в настройках интегрированной системы на текущее (чтобы эта запись в обмен больше не попадала).
- Дополнить ошибочную запись XML-файла обмена недостающими данными, провести загрузку данных с помощью сценария указанного выше и скорректировать «Время последней выгрузки» в настройках интегрированной системы на текущее (чтобы эта запись в обмен больше не попадала).
- Попытаться найти причину, почему XML-файл сформировался неправильно, и устранить её.
Чтобы найти причину, почему XML-файл формируется неправильно, потребуется добавить отладочную информацию в функции коннектора и в XSL-шаблон преобразования. Об этом поговорим более подробно в следующем материале.
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
Записи в системные журналы выполняет установленный софт.
Служба WorkFlow
*.sbworkflowsrv.log - при возникновении ошибок в работе службы Workflow (например, «Система на сервере XXX и базе YYY не обслуживается службой», ошибки при старте/остановке службы).
Также служба SBWorkflowSrv пишет информацию в журнал событий Windows. Посмотреть журнал можно с помощью оснастки Windows «Просмотр событий»: категория - Приложение, источник - SBWorkflowProcessingServer.
Логи сервера с ошибками error.log
Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.
Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.
Столкнулись с критической ошибкой обновления в таком составе :
1С розница , 2.3.2.28, платформа 8.3.15.1700
Структура трехуровневая - Центр - РИБ по магазину - РИБ по рабочему месту.
Обновляемся на 2.3.2.33 . Центр проходит нормально , РИБ по магазину проходит нормально. РИБ по рабочему месту выпадает при обновлении в ошибку -
Ошибка повторяется на всех базах в узлах ПО рабочему месту.
Смена платформы ничего не дает.
Если узел предварительно отвязать сделать не РИБ - обновление проходит. Но это не вариант
Проблему нашел. "Спасибо" 1С..
Проблема в добавленной процедуре в общем модуле - ИнтеграцияЕГАИСРТ
Суть проблемы, что в РИБе по рабочему месту документы Перемещение не ездят. А тут по тексту мы видим явный ляпс с получением Объекта по ссылке (объект не найден).
Лечение - сделано расширение, поставлена затычка в этом месте.
есть ли возможность в узле по магазину установить константу "Требуется обновление . " если да, попробуйте установить её в ИСТИНА и провести обмен. В нескольких подобных случаях мне это помогало
Проблему нашел. "Спасибо" 1С..
Проблема в добавленной процедуре в общем модуле - ИнтеграцияЕГАИСРТ
Суть проблемы, что в РИБе по рабочему месту документы Перемещение не ездят. А тут по тексту мы видим явный ляпс с получением Объекта по ссылке (объект не найден).
Лечение - сделано расширение, поставлена затычка в этом месте.
Написал 1с - ответили что у них все ок. печаль
Кстати эта же проблема есть и в старых конфах. Но всплывает только при обменах по рабочему месту, если у вас есть перемещения алкоголя
Кому лень - прикрепляю расширение ))
(6)Подкинул расширение и обмен всё равно не проходит и беда в том что обновление уже по точкам прошло((. Вы только подкинули расширение или ещё какие то манипуляции делали?
Вы откатывали обновление и по новой обновляли конфигурацию на главном узле с расширением? У меня на точке уже обновление в конфигуратор загрузилось, даже не знаю что можно придумать.
(6)
достаточно докинуть расширение . только вы явно либо его не поставили, либо поставили - но не сняли в конфигураторе галочку по умолчанию - Безопасные действия. Снимите галочку. Иначе оно взаимодействовать не может с данными.
Ну или же у вас что то другое . ошибку сюда киньте..
Но сперва проверьте галочку Безопасное в конфигураторе
Галочку безопасное действие снял, обмен повторно выполнил из главного узла
Теперь другая ошибка:
Предопределенный элемент не уникален
: Драйвер.Записать();
: Справочники.ДрайверыОборудования.ЗаполнитьПредопределенныйЭлемент(Перечисления.ОбработчикиДрайверовПодключаемогоОборудования.Обработчик1ССканерыШтрихкодаNative, "AddIn.InputDevice", "Драйвер1СУстройстваВводаNative", Ложь, "9.0.8.7");
: МенеджерОборудованияВызовСервераПереопределяемый.ОбновитьПоставляемыеДрайвера();
:ОбновлениеИнформационнойБазыБПО.ОбновитьПоставляемыеДрайвера(Параметры[0])
: Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
: ОбщегоНазначения.ВыполнитьМетодКонфигурации(Обработчик.Процедура, ПараметрыОбработчика);
: ВыполнитьОбработчикОбновления(Обработчик, ПараметрыОбработчика, ДополнительныеПараметры);
: ИтерацияОбновления.ВыполненныеОбработчики = ВыполнитьИтерациюОбновления(ИтерацияОбновления, Параметры);
: Результат = ВыполнитьОбновлениеИнформационнойБазы(ПараметрыОбновления);
:ОбновлениеИнформационнойБазыСлужебный.ВыполнитьОбновлениеИнформационнойБазыВФоне(Параметры[0],Параметры[1])
: Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
: ОбщегоНазначения.ВыполнитьМетодКонфигурации(ИмяПроцедуры, ПараметрыПроцедуры);
: ВыполнитьПроцедуру(ВсеПараметры.ИмяПроцедуры, ВсеПараметры.ПараметрыПроцедуры);
Публикую этот пост для тех, кто не видел статью базы знаний, написанную мной в 2009 году. Бонусом к статье является скрипт GetDirectumLogs.vbs, который копирует лог-файлы DIRECTUM (подробности в последнем разделе статьи).
Диагностика загрузки Windows: анализ документа.
Наиболее частое применение фиксирования загрузки в логах — сравнение журналов для нормального и Безопасного режимов загрузки. Или, реже и как уже указывалось, в случае, если система не загружается или загружается с ошибками в работе с подозрением на какой-то из драйверов. Содержимое файла можно использовать и в тех случаях, если система стала очень уж долго загружаться. Очень давно я лично проводил собственные изыскания по поводу, какие настройки можно легко отключить именно при помощи документа %WinDir%\Ntbtlog.txt. Структура файла, помимо краткой информации по системе и даты создания, содержит список загружаемых драйверов по типу:
Loaded \SystemRoot\System32\DRIVERS\драйвер — т.е. драйвер загрузился
Not loaded \SystemRoot\System32\DRIVERS\драйвер — драйвер не загрузился
Как вы поняли, именно запись Did Not Load свидетельствует о том, что запуск этого драйвера Windows пропустила. Что, впрочем, далеко не всегда означает, что этот драйвер проблемный. По той простой причине, что многим драйверам загружаться одновременно с системой не обязательно. А вот при поиске побитого драйвера могут помочь простые правила.
- Если Windows в Безопасном режиме (в отличие от обычного) загрузилась без проблем. Сравнивайте два журнала, созданные в обычном и Безопасном режимах: проблема лежит в списке тех драйверов, которые в обычном режиме получили статус Loaded, а в Безопасном — Did not loaded. Оставаясь в Безопасном режиме вы легко можете удалить любой из незагруженных драйверов, начиная с недавно установленных или обновлённых по одному-два за раз. При этом пробуя загрузиться в обычном режиме, пока Windows не выкажет признаки стабильности.
- Если Windows не загрузилась даже в Безопасном режиме. Читаем лог из консоли командой
Сравниваем логи для обоих режимов (даже если ни в одном система уже не загружается). Бывает так, что лога для какого-то режима уже нет. В таком случае вам придётся воспользоваться журналом с другого компьютера со схожей конфигурацией Windows (хотя бы в части версии и сборки). И вот почему. Драйвер, мешающий загрузке вашей Windows даже в Безопасном режиме, не отображается в журнале вообще. Но именно он появится в журнале с пометкой Loaded Driver, когда система в Безопасном режиме работает нормально. Такая процедура часто прокатывает и для служб, загружающихся только в нормальном режиме. Они — службы — начинают подгружаться только после успешной загрузки нужных драйверов. Именно в этот момент вы начинаете видеть окна приветствия Windows. Кстати, и запуск служб также можно контролировать. А сейчас вам остаётся удалить побитый (или предположительно побитый) драйвер из консоли и загрузиться в нормальном режиме.
Диагностика загрузки Windows из консоли cmd.
Следующий способ позволит создать журнал загрузки из консоли, что даёт возможность делать это (в том числе) и для Windows, которая уже или не загружается или даёт при загрузке очевидный сбой. Смысл способа в коррекции содержания директив загрузчика, который может находится где угодно. Т.е. возможно и на «побитом» носителе. После чего, изучив в указанном месте указанный файл, ошибка может проявиться в логе отчётливо. Рассмотрим пару вариантов, когда диагностика загрузки Windows активируется в функционирующей системе и когда включить ведение лога через msconfig уже нельзя.
Windows не работает или «опрокидывается».
Смысл тот же, просто стоит учесть, откуда запускаемая в консоли команда bcdedit будет инициирована. Не важно, на каком этапе загрузка системы стопорится (даже в случае BSOD), регистрацию лога можно начать в любом случае. Вариантов тут два: из ремонтной консоли (через восстановление системы) или с внешнего диска (флешки или через дисковод). Если нет загрузочной флешки, путь к созданию и прочтению лога будет таким. Пару раз прерываем загрузку системы кнопкой Reset с корпуса компьютера, вызывая процесс автоматического восстановления:
жмём на кнопку Перезагрузить
нажимаем F2
После перезапуска в корне диска С сформируется файл по адресу C:\Windows\ntbtlog.txt. В любом случае, можно задействовать (в обоих вариантах) и консоль команд. Команда из консоли cmd может принять такой вид:
Просто вместо идентификатор подсуньте тот, что соответствует незагружаемой Windows. Если загружаетесь из среды восстановления, с флешки или с оптического дисковода, для такой Windows это будет default. При этом при первоначальном запросе командой bcdedit информация о ведении журнала не выводится :
Ознакомиться с содержимым документа можно будет прямо из консоли командой
Вот видео для ознакомления с маленькой хитростью, позволяющей «вытаскивать» информацию с незагружаемой Windows и, в том числе, читать текстовые документы прямо из консоли:
Где посмотреть логи
Расположение определяется хостинг-провайдером или настройками установленного софта. На виртуальном хостинге доступ к лог-файлам предоставляется из панели управления хостингом. Если администратор не открыл его для владельца сайта, получить информацию не получится. Но большинство провайдеров разрешают свободно пользоваться журналами и проводить анализ логов сервера. Независимо от разновидности сервера лог-файлы хранятся в текстовом документе. По умолчанию он называется access.log, но настройки позволяют переименовать файл. Это актуально для Nginx, Apache, прокси-разновидностей squid, других типов. Для просмотра их надо скачать и открыть в текстовом редакторе. В качестве альтернативы можно использовать Grep и схожие утилиты. Они позволяют открыть и отфильтровать логи прямо на сервере.
Введение
Для многих компонент системы DIRECTUM ведутся лог-файлы, в которых фиксируются ошибки, исключения и некоторые действия. Имена и расположение лог-файлов зависят от компоненты. В статье приведен перечень лог-файлов для следующих компонент:
- Клиентская часть DIRECTUM
- Служба WorkFlow
- Сервер сеансов
- Служба файловых хранилищ
- Службы ввода и преобразования (DCTS)
- Утилита SASystemActivator
- Утилита SAKeyRegistration
- Утилита STConverter
- Репликация
- Сервер веб-доступа к DIRECTUM
- Расширения DIRECTUM для SharePoint
- Набор средств интеграции DIRECTUM
- Программы установки DIRECTUM
Клиентская часть DIRECTUM
Путь сохраняется в параметре «LogPath» файла «LogSettings.xml», который находится в папке «%ALLUSERSPROFILE%\Application Data\NPO Computer\IS-Builder». Если параметр «LogPath» пуст или файла настроек нет или не удается записать лог-файл в заданную папку, лог-файл записывается в папку профиля пользователя «%APPDATA%\NPO Computer\IS-Builder». Если папки профиля пользователя не доступна (не существует), то лог-файл записывается в каталог «%SystemDrive%\Documents and Settings\Default User\Application Data\NPO Computer\IS-Builder» (для Windows XP, 2000, 2003) или «%SystemDrive%\Users\Default\AppData\Roaming\NPO Computer\IS-Builder» (для Windows Vista).
Клиентская часть DIRECTUM ведет лог-файл профайлинга, предназначенный для мониторинга производительности системы. Подробно о механизме профайлинга написано в разделе «Профайлинг производительности системы» руководства администратора.
Также свои лог-файлы могут вести прикладные сценарии DIRECTUM. Более подробная информация об этом находится в описании сценариев.
Насколько метода точна?
Диагностика загрузки Windows с помощью ntbtlog — не панацея . В Windows «в базовой комплектации» никогда для нас с вами «точного» не было и не будет. Одной из альтернатив могло бы стать применение Windows Assessment Toolkit с каким-нибудь Windows Performance Analyzer внутри. Вы же вполне можете столкнуться с ситуацией, когда список «успешно и не очень» подгруженных драйверов от сеанса к сеансу пусть немного, но будет отличаться. Не редки случаи, когда успешно загруженный в логе драйвер в следующей же строчке того же лога отваливается. Не уверены, должен загружаться драйвер или нет? Копайте вручную: узнавайте, принадлежит ли он системе или другому ПО, каков должен быть в размерах, есть шанс скачать его из официальных источников или вытащить с установочного образа. Но помним, что если он туда полез, не загрузился тот не просто так. Но в тех случаях, когда логи содержат отказы по слишком уж большому количеству драйверов, следует предпринять действия уже по проверки целостности диска и корректной работы RAM. Так что не бойтесь предыдущие логи удалять (или переименовывать) для получения более свежих данных о процессе загрузки Windows. Так или иначе, параллельные варианты диагностики у вас есть:
Далее. Есть смысл присмотреться к драйверам, которые пытаются безуспешно подключиться множественное количество раз — это прямой путь к разгадке, почему Windows загружается очень долго на фоне предпринятых действий по оптимизации (очистке, дефрагментации, коррекции содержимого Автозагрузки и т.п.). Быть может, это какой-нибудь dxgkrnl.sys дискретной видеокарты, которому мешает встроенный видеоадаптер Microsoft Basic Display и есть смысл тот отключить в Диспетчере устройств? Вполне вероятно, что причиной долгой загрузки служит злополучный системный NDPROXY.SYS, «тормозящий» добрую половину компьютеров планеты, находящихся под управлением Windows. Им так любят крутить DNS-управлялки… Вобщем, ремонтные утилиты Windows и антивирус при анализе обнаруженных вам в помощь.
Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Читайте также: