азТехнологичният журнал (наричан по-долу TJ) ви позволява да регистрирате всички събития на 1C:Enterprise (или част, като използвате филтър), например:
- изпълним код 1C:Enterprise 8.1;
- Transact-SQL код за СУБД;
- интерактивни действия на потребителите,

Съобщения за грешка

Изтичане на памет.
В случай на необичайно прекратяване, регистрационният файл ви позволява да направите дъмп на паметта и копие на екрана за предаване на разработчиците.

II.Регистърът се конфигурира с помощта на файла logcfg.xml в програмната папка C:\Program Files\1cv81\bin\conf
1) За да създадете успешно регистрационни файлове, трябва да създадете директории за регистрационни файлове (например C:\Program Files\1cv81\bin\logs) и дъмпове (например C:\Program Files\1cv81\bin\dumps)

2) Следните права трябва да бъдат конфигурирани за тези TG директории:

Пълни права върху директорията на технологичното списание;

Разрешения за четене за собственика на директорията на технологичното списание.

Забележка. Ако TJ все още не е записан, дайте на всички права върху тази папка (временно, за да сте сигурни, че правата са правилни).

3) В директорията на технологичния журнал не трябва да има излишни файлове. Директория, съдържаща външни файлове, няма да позволи създаването на журнал(и).

4) Изхвърлянията на местоположението за съхранение и регистрационните файлове не трябва да се съхраняват заедно, защото след определения интервал (1 час по подразбиране) съдържанието ще бъде напълно изтрито и вие ще загубите изхвърлянията

III.По-добре е да конфигурирате TJ (използвайки филтри - тагове logcfg.xml) само за изследваните събития, не събирайте останалите, в противен случай ще изпитате „липса на дисково пространство“ и ще забавите производителността на сървъра.

1) По-лесно е да конфигурирате филтри, като използвате обработка с ITS настройки на Technological Journal.epf, но в същото време не забравяйте, че новите функции на най-новите версии може да не са включени в връщането (всяка нова версия добавя нови функции, те са не се отразява в обработката). В този случай коригирайте файла logcfg.xml ръчно.

2) За да спрете събирането на регистрационни файлове, просто преименувайте файла; няма нужда да рестартирате сървъра, настройките се преизчисляват всяка минута „в движение“

3) конфигурирайте logcfg.xml за филтриране на събития за конкретна информационна сигурност, използвайте "p:processName="

4) http://users.v8.1c.ru/Adm1936.aspx - примери за настройки

IV.Ясно е, че събирането на регистрационни файлове не е достатъчно; те все още трябва да бъдат обработени, за да се реши конкретен проблем.

1) Трудности при четенето на TJ:

Изисква добро разбиране на системната архитектура

Текстовете на заявките се регистрират на вътрешния език на 1C:Enterprise и на езика на СУБД

2) Технологичните регистрационни файлове се съхраняват в поддиректории. Името на всяка поддиректория на технологичния дневник на един процес ще изглежда така:<ИмяПроцесса>_<ИдентификаторПроцесса>, например: rphost_4076. Името на регистрационния файл е указано от шаблона YYMMDDHCH.log. Например в дневника 07051819.log името на файла се формира от 2007 18 май, 19 часа)

3) Дневникът за анализ може да бъде качен в Excel, като се използва например запетая като разделител

4) 1C: MCC използва логове на технологични дневници за своите аналитични дисплеи. Когато използвате MCC, не трябва да се събират други данни; изтрийте logcfg.xml ръчно; MCC ще създаде файл с необходимите настройки.

5) Няма други анализатори на журнали от 1C, има http://partners.v8.1c.ru/forum/getfile.jsp?name=ObrabotkaTehnologiceskogoGurnala.epf
http://partners.v8.1c.ru/forum/thread.jsp?id=576266#576266

V.Възможни грешки и допълнителни информация:

Търсим регистрационни файлове в директорията на сървъра, въпреки че за 64-битов сървър има различна програмна директория

Проследяване на незавършена заявка; Събитието в регистъра на процеса на DBMSSQL се извежда само когато заявката завърши. Ако дадена заявка не може да бъде изпълнена дълго време, нейното изпълнение може да бъде прекъснато, след което събитията, свързани с нея, ще бъдат показани в технологичния дневник.

< config xmlns= "http:>
< log location= "C:\Program Files\1cv81\logs" history= "24" >
< event>
< eq property= "Name" value= "EXCP" />
< /event>
< event>
< eq property= "Name" value= "SDBL" />
< eq property= "Func" value= "BeginTransaction" />
< /event>
< event>
< eq property= "Name" value= "DBMSSQL" />
< ge property= "Duration" value= "30000" />
< /event>
< property name= "All" />
< /log>
< /config>

По-подробна информация за характеристиките на използването на технологичното списание можете да намерите в материалите на семинара на партньорите на 2 - 4 март 2007 г., доклада „Диагностични средства за работата на системата 1C:Enterprise 8.1“.

Курс, в който преподават този въпрос http://www.1c.ru/news/info.jsp?id=9144

На всички въпроси се отговаря в “C:\Program Files\1cv81\AddDoc\RU\V8AddDoc81.htm”, книга “1C:Enterprise 8.1. Конфигуриране и администриране“, Глава 21. Администриране, списание Technology

ако не сте намерили отговора на въпроса си, нека разширим материала


Не толкова отдавна открих нещо ново за себе си, оказа се, че има списание за технологии (TJ). Какъв вид животно е това и защо е необходимо, ще се опитам да отговоря в тази статия.

Как да говорим самата 1C Списание за технологииСистемите 1C:Enterprise 8 могат да се използват за анализ на технологични проблеми на системата и анализ на аварийни прекъсвания. Той регистрира информация от всички приложения на 1C:Enterprise 8, работещи на даден компютър.От това определение полезността на този инструмент е очевидна веднага, от него можем да научим например:

  • При изпълнение на какъв код се срива работните процеси на сървъра?
  • кои заявки са бавни и откъде се извикват?
  • Вижте дали е имало блокиране или изчакване
  • и още много.
Какво е TJ? А представлява TJколекция от текстови файлове, съхранявани в определена директория.
Тези файлове могат да бъдат разделени на 2 групи
  • дъмп файлове
  • Лог файлове
трупи– това са файлове с разширение log, където информацията се съхранява в текстов вид.
Свалки– това е файл с разширение mdmp, който съдържа съдържанието на RAM на процеса в момента на срива.


Продължавай. В коя директория се съхраняват TJ файловете?
По подразбиране TJ се създава в директорията:
%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\
Ако се използва Windows Vista и по-нова версия, ще се използва директорията: %LOCALAPPDATA%\1C\1Cv82\
За 8.3 вместо каталога 1Cv82 се използва 1Cv8.
Но тази директория може да бъде променена. Повече за това по-долу.
Как да включите TJ?
По подразбиране регистърът на процеса е активиран и конфигуриран да запазва минимални дъмпове. С помощта на специален файл можем да конфигурираме TJ. А именно, можем да променим TJ директориите, да посочим кои събития трябва да бъдат регистрирани в TJ и т.н.
Говоря за файла с настройки на TJlogcfg.xml .

Този файл трябва да се намира в директорията conf в папката с инсталиран 1c, например
"D:\Програмни файлове\1Cv8\conf"
Нека да разгледаме пример за файл с настройки за пълен TZ.
config xmlns="http://v8.1c.ru/v8/tech-log"> Този конфигурационен файл дефинира изхода към регистъра на процеса на всички събития заедно с всички свойства. Дневникът ще бъде запазен за една седмица (24 часа). Въпреки това, количеството изведена информация ще бъде много голямо.
По-препоръчително е да конфигурирате TJ само за събития, които ни интересуват, например искаме да видим дали е имало грешки или дълги операции в системата (>10 секунди)

Най-честите TJ събития: EXCP– извънредни ситуации на приложения на системата 1C:Enterprise, които не се обработват нормално и могат да причинят аварийно прекратяване на сървърния процес или свързания с него клиентски процес. EXCPCNTX– събития, които са започнали, но не са приключили в момента на възникване на извънредна ситуация. DBMSSQL– изпълнение на SQL изрази от СУБД на Microsoft SQL Server. Всяка СУБД използва собствено събитие (BPOSTGRS, DBORACLE, DB2, DBV8DBENG – файлова версия) АДМИНИСТ– действия на клъстерния администратор в клъстерната конзола. ПРОЦ– събития, свързани с целия процес и засягащи по-нататъшното изпълнение на процеса. Например: начало, край, срив и др. ОБАДЕТЕ СЕ– входящо дистанционно повикване (дистанционно повикване от страната на приемащото повикване). Например, ако извикате функция на сървъра от клиента, тогава събитието CALL ще бъде записано в TJ на сървъра. СКАЛВАНЕ– изходящо дистанционно повикване (изходящо повикване от страна на източника на повикване). Например, ако извикате функция на сървъра от клиента, събитието SCALL ще бъде записано в TJ на клиента. SESN– действия, свързани с работната сесия. Например: начало на сесия, край на сесия. TDEADLOCK– открита е безизходица в режим на контролирана блокировка. TTIMEOUT– грешка при изчакване при управлявани заключвания. TLOCK– задаване на транзакционно заключване в режим на контролирано заключване.
С помощта на настройките на TJ можете да филтрирате почти всички събития, които ни интересуват.
Да речем, че искаме да видим в TC само грешки и информация за заявки към таблицата AccRg105, които са продължили повече от 3 секунди. Тогава logcfg трябва да изглежда така.
Логическото ИЛИ работи между двете, т.е. Когато се случи някое от събитията, то ще бъде записано в TJ.
Логическото И работи вътре в едно, т.е. дадено събитие ще бъде записано само ако са изпълнени всички условия в едно.
С тази настройка събитието EXCP винаги ще бъде записано, а събитието DBMSSQL ще бъде записано само ако низът „AccRg105“ се съдържа някъде в текста на заявката и заявката е била изпълнена за повече от 3 секунди. Филтърът за продължителност на събитието трябва да бъде зададен на десет хилядни от секундата, независимо от версията на платформата. В този пример използваме няколко условия: eq, gt и подобни.
Могат да се използват следните условия:

  • eq – равен;
  • ne – не е равно;
  • gt – повече;
  • ge – по-голямо или равно на;
  • lt – по-малко;
  • le – по-малко или равно на;
  • like – отговаря на маската.
Ще добавя още няколко бележки в края:
Платформата чете данни от файла с настройки веднъж на минута, така че не се вълнувайте и проверете файловете веднага, просто ще имате спокойствие след минута)
Ако няма да изпращате данни за дъмп на 1C, тогава няма нужда да ги съхранявате; не посочвайте реда за местоположение на дъмпа във файла с настройки.
Ако ще съхранявате TJ файловете в директория, различна от директорията по подразбиране, тогава е по-добре първо да я създадете сами.

В тестовата база данни съзнателно създадох таймаут на ключалката,
Използвайки това като пример

(или част, използваща филтър), например:
— изпълним код 1C:Enterprise 8;
— Transact-SQL код за СУБД;
— интерактивни действия на потребителите,

- съобщения за грешка,

Забележка. Ако TJ все още не е записан, дайте на всички права върху тази папка (временно, за да сте сигурни, че правата са правилни).

3) В директорията на технологичния журнал не трябва да има излишни файлове. Директория, съдържаща външни файлове, няма да позволи създаването на журнал(и).

4) Изхвърлянията на местоположението за съхранение и регистрационните файлове не трябва да се съхраняват заедно, защото след определения интервал (1 час по подразбиране) съдържанието ще бъде напълно изтрито и вие ще загубите изхвърлянията

Настройки

По-добре е да конфигурирате TJ (използвайки филтри - тагове logcfg.xml) само за изследваните събития, не събирайте останалите, в противен случай ще изпитате „липса на дисково пространство“ и ще забавите производителността на сървъра.

1) По-лесно е да конфигурирате филтри, като използвате обработка с ITS настройки на Technological Journal.epf, но в същото време не забравяйте, че новите функции на най-новите версии може да не са включени в връщането (всяка нова версия добавя нови функции, те са не се отразява в обработката). В този случай коригирайте файла logcfg.xml ръчно.

2) За да спрете събирането на регистрационни файлове, просто преименувайте файла; няма нужда да рестартирате сървъра, настройките се преизчисляват всяка минута „в движение“

3) конфигурирайте logcfg.xml за филтриране на събития за конкретна информационна сигурност, използвайте „p:processName=“

4) http://users.v8.1c.ru/Adm1936.aspx - примери за настройки

Подробности

Ясно е, че събирането на регистрационни файлове не е достатъчно; те все още трябва да бъдат обработени, за да се реши конкретен проблем.

1) Трудности при четенето на TJ:

— Изисква добро разбиране на системната архитектура

— Текстовете на заявките се регистрират на вътрешния език на 1C:Enterprise и на езика на СУБД

2) Технологичните регистрационни файлове се съхраняват в поддиректории. Името на всяка поддиректория на технологичния дневник на един процес ще изглежда така:<ИмяПроцесса>_<ИдентификаторПроцесса>, например: rphost_4076. Името на регистрационния файл е указано от шаблона YYMMDDHCH.log. Например в дневника 07051819.log името на файла се формира от 2007 18 май, 19 часа)

3) Дневникът за анализ може да бъде качен в Excel, като се използва например запетая като разделител

Ако искате да използвате дневника за анализ на съобщенията за грешки, използвайте безплатната услуга.

ако не сте намерили отговора на въпроса си, нека разширим материала

Колеги, продължаваме поредицата от статии, посветени на технологичното списание.

Днес ще покажем практиката за анализиране на TJ дневници.

Други статии от поредицата Technology Magazine:

Анализ на технологични дневници

Какво ще научите от тази статия?

  • Нека разгледаме по-отблизо регистрационните файлове 1C: Предприятие 8
  • Нека проучим подробно формата на дневника Списание за технологии
  • Нека разгледаме пример за дневник със записани данни

Да видим какво ще се случи, ако създадем файл logcfg.xmlс горната структура и го поставете в директорията "C:\Program Files\1Cv82\conf"

Нека изчакаме 60 секунди и да отворим директорията "C:\1C_Info\Logs", защото точно това посочихме в ред 3 на файла logcfg.

Ако директорията 1C_Информацияне е на диска, тогава сървърът 1C ще се опита да го създаде, но има риск потребителят, под който работи услугата 1C, да няма права. Ето защо се препоръчва ръчно да се създават директории за регистрационни файлове и да се проверява дали 1C сървърът има права да пише в тази директория.

В резултат на това виждаме 3 поддиректории в директорията.

Всеки клъстерен процес е създал директория, съдържаща регистрационни файлове само за този процес и след това Имам само 3 процеса, така че има и 3 директории.

Директорията се създава с помощта на шаблон Име на процес_PIDПроцес. PIDнеобходими за разграничаване на процеси с едно и също име.

Регистрационният файл е именуван според модела YYMMDDHCH.log.

Ако дневникът е по-стар от броя часове, посочени в параметъра историяфайл logcfg, след което се изтрива автоматично от платформата.

Нека разгледаме по-подробно формата на технологичния журнал.

Събитие се записва в дневника само след като приключи, защото необходимо е да се запише продължителността на събитието.

Редът на дневника има формата:

Мм:сс.ттт-д,<ИмяСобытия>, <Уровень>, <Свойства>

мм– номер на минута в текущия час.

ss– номер на секундата в текущата минута.

ттттт– числото на десет хилядна от текущата секунда, за 8.3 тук се показва числото на една милионна.

д– продължителност на събитието в десет хилядни от секундата, за 8,3 в милионни.

<ИмяСобытия> – име на събитието.

<Уровень> – ниво на събитие в стека на текущата нишка.

<Свойства> - свойства на събития, разделени със запетаи, стойности на свойства, разделени със знак «=» .

Нека го разгледаме с пример.

Има дневник със следното съдържание:

00:16 - това са минутите и секундите от края на събитието. Датата и часът на събитието могат да бъдат взети от името на лог файла. Събитието приключи на 6 април 2015 г. в 11:00 минути и 16 секунди. 8640 – за 8.2 това са десет хилядни от секундата. И за 8,3 - милионни от секундата от момента на края на събитието. 1 е продължителността на събитието. В 8.2 продължителността е посочена в десет хилядни от секундата, в 8.3 в милионни от секундата. Ако трябва да зададете филтър за продължителност, можете да използвате името на свойството „Продължителност“. DBMSSQLе името на събитието. В този случай изпълнение на инструкции за СУБД на MS SQL Server. 3 – ниво на събитието. Следват свойствата на събитието DBMSSQLи всяко събитие има свой собствен набор от свойства Пълен списък от свойства за всички събития може да бъде намерен в ръководството на администратора. Тук ще разгледаме по-отблизо имотите само за текущото събитие. Процес– Описва процеса, за който е написан този журнал. Всички събития имат това свойство. В моя случай се записва дневникът на процеса на rphost. P: име на процес– име на информационната база 1C. Събитието е създадено в база данни, наречена Deadlock. T:клиентски идентификатор- идентификатор на връзката с клиента чрез TCP. T: име на приложение– идентификатор на клиентска програма. Тези. кой точно е причинил събитието, в моя случай това е фонова работа. T:connectID– номер за връзка с информационната база. Сесиен идентификатор– номер на сесия, присвоен на текущата нишка. Ако текущата нишка няма присвоена сесия, тогава свойството не се добавя. Usr– името на потребителя на информационната база, под който се изпълнява този поток. Ако потребителят не е дефиниран, стойността DefUser се замества. прев– показва дали транзакцията е отворена в началото на събитието или не. 1 – отворено, 0 – не. dbpid– номер на връзка на 1C сървъра със сървъра на базата данни. SQL– текст на SQL израза. Най-често това съдържа текста на SQL заявката с параметри. Редове– броя на редовете, върнати от заявката. Засегнати редове– броя на редовете, които заявката е променила в базата данни. Контекст– кой ред код на езика 1C генерира това събитие. Може би най-интересното събитие за нас.

Бурмистров Андрей

В следващите статии ще разгледаме „Събития“, както и тяхното филтриране TJ.

Междувременно прикачете получения материал към вашата тестова информационна база :)

28.12.2016

Настройка на 1C технологичен дневник

Да започнем с това, да кажем, че по подразбиране технологичният дневник е активиран. Работи и записва събития само в два случая:
Ненормално изключване на 1C клъстерни процеси (ragent, rmngr или rphost) Дъмпът се записва в директорията %LOCALAPPDATA%\1C\1Cv82\dumps - за 1C 8.2 %LOCALAPPDATA%\1C\1Cv8\dumps - за 1C 8.3 Ако платформата 8.3 се използва и събитието възниква SYSTEM с ниво на грешка Регистрационните файлове на такива събития се съхраняват за 24 часа, след което платформата ще изтрие лог файловете %LOCALAPPDATA%\1C\1Cv8\logs - за 1C 8.3

Инструкции за създаване на технологичен дневник

Процедура за създаване на технологичен дневник:
  • Създайте специална папка за технологичния дневник (например C:\LOG) и за дъмпове (например C:\dumps)
  • Настройте файла logcfg.xml за събиране на съобщения за грешки (по-долу са примери за конфигурация)
  • Поставете файла logcfg.xml в необходимата директория (пример по-долу)
  • Проверете разрешенията за запис в директории за регистриране и изхвърляне
  • След минута се уверете, че се създават лог файлове (ако не са създадени, тогава настройките не са правилни)
  • Възможна грешка - различен регистър на буквите в имената на директориите (трябва да съвпадат)
  • Възможна грешка - в конфигурационния файл в края на името на директорията наклонената черта "\" не е необходима

Настройка на технологичен дневник (файл logcfg.xml)

Имайте предвид, че най-често използваната директория за местоположението на конфигурационния файл е C:\Program Files\1Cv82\conf - за платформа 8.2 C:\Program Files\1Cv8\conf - за платформа 8.3 В този случай настройките ще бъдат валидни във всички версии на платформата, инсталирани на сървъра. Също така си струва да се каже, че тази конкретна опция е препоръчителна.
На всеки 60 секунди настройките се четат от работните процеси на клъстера. Четенето на настройките от всеки процес става независимо от другите процеси.

Пример за настройка на пълен технологичен дневник

Тези настройки означават, че всички събития с всички свойства ще бъдат извеждани в регистрационния файл на процеса и регистрационният файл ще се съхранява за 168 часа.
Не се препоръчва използването на тази настройка за ежедневна работа, тъй като... количеството информация ще бъде много голямо. Въпреки това, при тестване и намиране на грешки, такава излишна информация ще бъде изключително полезна.

Пример за настройка „всеки ден“.

В повечето случаи следната настройка ще бъде достатъчна: Обемът на данните ще бъде малък. В същото време ще има информация за стартиране и спиране на приложения, установяване и прекъсване на връзки с клъстер от сървъри на 1C:Enterprise, действия на администратора на клъстера и ситуации на грешки в работата на 1C:Enterprise.