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

Днес ще покажем практиката за анализиране на 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 DBMS. 3 – ниво на събитието. Следват свойствата на събитието DBMSSQLи всяко събитие има свой собствен набор от свойства. Пълният списък от свойства за всички събития може да бъде намерен в ръководството на администратора. Тук ще разгледаме по-отблизо имотите само за текущото събитие. Процес– Описва процеса, за който е написан този журнал. Всички събития имат това свойство. В моя случай се записва дневникът на процеса на rphost. P: име на процес– име на информационната база 1C. Събитието е създадено в база данни, наречена Deadlock. T: clientID- идентификатор на връзка с клиента чрез TCP. T: име на приложение– идентификатор на клиентска програма. Тези. кой точно е причинил събитието, в моя случай това е фонова работа. T:connectID– номер за връзка с информационната база. Сесиен идентификатор– номер на сесия, присвоен на текущата нишка. Ако текущата нишка няма присвоена сесия, тогава свойството не се добавя. Usr– името на потребителя на информационната база, под който се изпълнява този поток. Ако потребителят не е дефиниран, стойността DefUser се замества. прев– показва дали транзакцията е отворена в началото на събитието или не. 1 – отворено, 0 – не. dbpid– номер на връзка на 1C сървъра със сървъра на базата данни. SQL– текст на SQL оператора. Най-често това съдържа текста на SQL заявката с параметри. Редове– броя на редовете, върнати от заявката. Засегнати редове– броят редове, които заявката е променила в базата данни. Контекст– кой ред код на езика 1C генерира това събитие. Може би най-интересното събитие за нас.

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

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

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

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

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

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

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, като се използва например запетая като разделител

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

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

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

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

За да активирате технологичния дневник, трябва:
Създайте файла logcfg.xml в папката C:\Program Files (x86)\1cv82\8.2.15.301\bin\conf (път - директория 1C Enterprise) на сървъра 1C Enterprise.
След това трябва да запишете пътищата до създадените папки във файла logcfg.xml (където Указан път 1 е пътят към регистрационните файлове, а Указан път 2 е пътят към дъмповете):

Ето пример за настройки от моя сървър:























След като изпълните тези стъпки, приложението 1cv8 автоматично ще започне да записва системна информация за всички грешки, възникнали в системата в тези директории.
След като анализът приключи, регистрационният файл на процеса може да бъде деактивиран чрез изтриване или преименуване на файла logcfg.xml.
Предполага се, че на компютрите, където този журнал ще бъде активиран, файловете могат да заемат доста голямо количество дисково пространство (относително казано, разбира се). Затова препоръчвам да посочите пътища към дискове с голямо количество свободно пространство.
1) За да създадете успешно регистрационни файлове, трябва да създадете директории за регистрационни файлове (например „D:\1Clog“) и дъмпове (например „D:\1Cdumps“), по-добре е да ги създадете не на системното устройство.
2) Следните права трябва да бъдат конфигурирани за тези TG директории:
— пълни права върху каталога на технологичното списание;
— права за четене на собственика на директорията на технологичния журнал.
Забележка. Ако TZ все още не е записан, дайте на всички права върху тази папка (временно, за да се уверите, че правата са правилни).
3) В директорията на технологичния журнал не трябва да има никакви странични файлове. Директория, която съдържа чужди файлове, няма да позволи създаването на журнал(и).
4) Изхвърлянията на местоположението за съхранение и регистрационните файлове не трябва да се съхраняват заедно, защото след определения интервал (1 час по подразбиране) съдържанието ще бъде напълно изтрито и вие ще загубите изхвърлянията
По-добре е да конфигурирате TJ (използвайки филтри - тагове logcfg.xml) само за изследваните събития, не събирайте останалите, в противен случай ще изпитате „липса на дисково пространство“ и ще забавите производителността на сървъра.
1) По-лесно е да конфигурирате филтри, използвайки обработка с ITS настройки на Technological Journal.epf, но в същото време не забравяйте, че новите функции на най-новите версии може да не са включени в връщането (всяка нова версия добавя нови функции, те са не се отразява в обработката). В този случай коригирайте файла logcfg.xml ръчно.
2) За да спрете събирането на регистрационни файлове, просто преименувайте файла, няма нужда да рестартирате сървъра, настройките се преизчисляват всяка минута „в движение“;
3) конфигурирайте logcfg.xml за филтриране на събития за конкретна информационна сигурност, използвайте „p:processName=“

С тези настройки събирам информация за:

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

    събития, които са започнали, но не са приключили, когато е настъпила извънредна ситуация.

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

    контролни действия на администратора на сървърен клъстер 1C:Enterprise 8.2

    събития, свързани с увеличаване на обема на паметта, заета от сървърни процеси (ragent, rmngr, rphost).

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


Не толкова отдавна открих нещо ново за себе си, оказа се, че има технологично списание (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: Предприятие- списание за технологии.

Не всички специалисти знаят за него и само малцина знаят как да го използват правилно. Нека се опитаме да поправим ситуацията :)

Описание и включване на технологичния дневник

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

  • Описание и предназначение на инструмента Списание за технологии
  • Как да го включите Списание за технологии V 1C:Предприятие 8
  • Принципът на генериране и запазване на дневници и дъмпове

Описание на TJ

TJпредназначени да изследват грешки, да анализират и диагностицират различни проблеми в работата на платформата 1C: Предприятие.

С помощта на TZ можете да разберете кои заявки се изпълняват бавно и откъде се извикват, при изпълнение на кой код работните процеси на сървъра се сриват, къде изтича памет и много, много повече.

Всички инструменти за анализ на ефективността на платформата използват TJ за получаване на информация. Ако желаете и задълбочено проучите проблема с помощта на TJ, можете да напишете свой собствен инструмент за анализ на ефективността.

TJ може да се събира както за 1C сървърни процеси, така и за клиентски приложения. Съответно наборът от събития, които могат да бъдат записани в TD, ще бъде различен.

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

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

трупи– това са файлове с разширение .дневник, където информацията се съхранява в текстов вид.

Свалкие файл с разширение .mdmp, който съдържа съдържанието на RAM паметта на процеса по време на срива.
Изхвърлянето може да бъде изключително необходимо за разследване на проблеми със стабилността на платформата. Не можем сами да анализираме сметищата, защото... Ние не разполагаме с изходния код на платформата, но можем да ги изпратим на техническа поддръжка или партньорски форум и да получим решение на нашия проблем.

Включване на TJ

По подразбиране регистърът на процеса е активиран и работи, но събира много ограничено количество данни.

Минималното количество данни означава 2 неща:

1) Формиране на сметища с минимален размер в случай на аварийно изключване на 1C клъстерни процеси ( регент, rmngrили rphost).

По подразбиране дъмпът се създава в директорията:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\dumps

Ако използвате Windows Vista и по-нова версия, ще се използва директорията:

%LOCALAPPDATA%\1C\1Cv82\dumps

За 8.3 вместо директория 1Cv82използвани 1Cv8.

2) За 8.3 минималната TZ включва формирането на дневници с едно събитие СИСТЕМАс ниво Грешка.

Дневниците се записват в директорията:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv8\logs

За Windows Vista и по-стари се използва директорията:

%LOCALAPPDATA%\1C\1Cv8\регистрационни файлове

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

Най-често информацията от TJ по подразбиране не е достатъчна и е необходимо да се конфигурира ръчно.

За да настроите фино TJ, трябва да създадете файл logcfg.xmlс определена структура на определено място.

Този файл трябва да бъде поставен в директорията:

C:\Program Files\1Cv82\conf (за 8.3 директория 1Cv8)

В този случай настройките TJще важи за всички версии 1C, които са инсталирани на този компютър и за всички потребители. Тази опция се използва най-често и е тази, която препоръчваме да използвате.

При настройка МКЦ, облачни услуги за наблюдение на производителността и други инструменти, където трябва да посочите пътя до logcfg, също така е по-добре да използвате тази конкретна директория, в противен случай при актуализиране на платформата или промяна на потребителското име, под което се изпълнява сървърната услуга 1C, описаните инструменти ще спрат да работят и ще трябва да промените настройките.

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

Нагласям TJсамо за една версия на платформата, ние поставяме logcfg.xmlв каталога:

C:\Program Files\1Cv82\8.2.19.106\bin\conf

Където 8.2.19.106 – това е номерът на версията, от която се нуждаете.

Изключително рядко, но все пак може да се наложи да конфигурирате TJ отделно за всеки потребител, под който се изпълнява сървърната услуга 1C.

След това поставяме logcfgв каталога:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\Conf

За Windows Vista и по-стари:

%LOCALAPPDATA%\1C\1Cv82\Conf

Това може да е необходимо, ако имате например 1 сървърна услуга 1Cсе използва като работещ, а вторият се използва за отстраняване на грешки. Ако е необходимо, можете да стартирате услуги под различни потребители и да събирате TJсамо за една от тях, за да не натоварвате втория сървър и да не събирате ненужни данни в логовете, или направете свои собствени настройки за всяка от услугите TJ.

Настройките от logcfg не се четат мигновено, а на всеки 60 секунди и всеки от процесите на клъстера чете файла с настройки независимо от другите процеси. Например регистрационните файлове на процеса rmngr могат да се появят първи и само след 45 секунди регистрационните файлове на rphost.

Да изключа TJпросто изтрийте или преименувайте файла logcfg.xml.

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

В следващите статии ще разгледаме нюансите на настройката TJи практика на използване.

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