Log analysis. Technology magazine

(or part using a filter), for example:
— executable code 1C:Enterprise 8;
— Transact-SQL code for the DBMS;
— interactive actions of users,

- error messages,

Note. If the TJ is still not written, then give everyone rights to this folder (temporarily, to make sure that the rights are correct).

3) There should be no extraneous files in the technological log directory. A directory containing extraneous files will not allow the creation of a log(s).

4) Storage location dumps and logs should not be stored together, because after the specified interval (1 hour by default) the contents will be completely erased and you will lose the dumps

Settings

It is better to configure the TJ (using filters - tags logcfg.xml) only for the events being studied, do not collect the rest, otherwise you will experience “lack of disk space” and slow down the server’s performance.

1) It is easier to configure filters using processing with ITS Settings of the Technological Journal.epf, but at the same time remember that new features of the latest releases may not be included in the return (each new version adds new features, they are not reflected in the processing). In this case, adjust the logcfg.xml file manually.

2) To stop collecting logs, just rename the file; there is no need to restart the server, the settings are recalculated every minute “on the fly”

3) configure logcfg.xml to filter events for a specific information security, use “p:processName=”

4) http://users.v8.1c.ru/Adm1936.aspx - examples of settings

Details

It is clear that collecting logs is not enough; they still need to be processed to solve a specific problem.

1) Difficulties in reading TJ:

— Requires a good understanding of the system architecture

— Request texts are registered in the internal language of 1C:Enterprise and in the DBMS language

2) Technological log files are stored in subdirectories. The name of each subdirectory of the technological log of one process will look like:<ИмяПроцесса>_<ИдентификаторПроцесса>, for example: rphost_4076. The log file name is specified by the pattern YYMMDDHCH.log. For example, in the log 07051819.log the file name is formed from 2007 May 18, 19 hours)

3) The log for analysis can be uploaded to Excel using a comma as a delimiter, for example

If you want to use the log to analyze error messages, use the free service.

if you haven't found the answer to your question, let's expand the material

— executable code 1C:Enterprise 8;
— Transact-SQL code for the DBMS;
— interactive actions of users;
— error messages;
- memory leaks.

In case of abnormal termination, the log allows you to make a memory dump and a copy of the screen for transmission to developers.

To enable the technological log you must:
Create the file logcfg.xml in the folder C:\Program Files (x86)\1cv82\8.2.15.301\bin\conf (path - 1C Enterprise directory) on the 1C Enterprise server.
After this, you need to write the paths to the created folders in the logcfg.xml file (where Specified path 1 is the path to the logs, and Specified path 2 is the path to dumps):

Here is an example of settings from my server:























After completing these steps, the 1cv8 application will automatically begin saving system information about all errors that occurred in the system in these directories.
After analysis has been completed, the process log can be disabled by deleting or renaming the logcfg.xml file.
It is assumed that on computers where this log will be enabled, the files can take up a fairly large amount of disk space (relatively speaking, of course). Therefore, I recommend specifying paths to disks with a large amount of free space.
1) To successfully create logs, you need to create directories for logs (for example “D:\1Clog”) and dumps (for example “D:\1Cdumps”), it is better to create them not on the system drive.
2) The following rights must be configured for these TG directories:
— full rights to the technological magazine catalogue;
— read rights to the owner of the technological journal directory.
Note. If the TJ is still not written, then give everyone rights to this folder (temporarily, to make sure that the rights are correct).
3) There should be no extraneous files in the technological log directory. A directory containing extraneous files will not allow the creation of a log(s).
4) Storage location dumps and logs should not be stored together, because after the specified interval (1 hour by default) the contents will be completely erased and you will lose the dumps
It is better to configure the TJ (using filters - tags logcfg.xml) only for the events being studied, do not collect the rest, otherwise you will experience “lack of disk space” and slow down the server’s performance.
1) It is easier to configure filters using processing with ITS Settings of the Technological Journal.epf, but at the same time remember that new features of the latest releases may not be included in the return (each new version adds new features, they are not reflected in the processing). In this case, adjust the logcfg.xml file manually.
2) To stop collecting logs, just rename the file; there is no need to restart the server, the settings are recalculated every minute “on the fly”
3) configure logcfg.xml to filter events for a specific information security, use “p:processName=”

With these settings I collect information about:

exceptional situations of applications of the 1C: Enterprise 8.2 system, which are not processed normally and can cause an emergency termination of the server process or the client process connected to it.

    events that began but did not end when an emergency occurred.

    events related to the entire process and affecting the further performance of the process. For example: start, end, crash, etc.

    control actions of the administrator of a 1C:Enterprise 8.2 server cluster

    events related to an increase in the amount of memory occupied by server processes (ragent, rmngr, rphost).

    memory leak events that can be caused by errors in the configuration code.

The technological log is a special mechanism of the 1C 8.2 and 8.3 platform, which allows you to log all events occurring in the system, including system errors. Let's look at the instructions for setting up a technological log in 1C: Enterprise.

Instructions for setting up a technological log

  1. Create a special folder for the technological log on the local drives of the 1C application servers. For example, C:\LOG . And for dumps, for example, C:\dumps.
  2. Configure the log to collect error messages (see file) in a subdirectory of this directory. We will name the subdirectory by date: C:\LOG\2014-04-22, etc.
  3. The logcfg.xml file itself must be placed in the conf directory of the server installation folder (!) 1C: Enterprise (for example, C:\Program Files\1cv82\8.2.17.153\bin\conf).
  4. After this, after about a minute, make sure that the folder C:\LOG\2014-01-01 has been created in the directory, and there are also subfolders in it with the names rphost_XXXX, ragent_XXXX, rphost_XXXX, and in them there are files.
  5. If they are created, then everything is fine, if they are not created, then something is wrong.
  6. If something is wrong: the most common errors are: uppercase/small letters in directory names (case must match), in the configuration file a slash was written at the end of the directory name (not needed), and sometimes you also need to configure user rights for the C:\ folders LOG, C:\dumps, C:\Program Files\1cv82\8.2.17.153\bin\conf, if they are too “twisted”.

The inside of the logcfg.xml file should look something like this:









Get 267 video lessons on 1C for free:

Attributes for configuring the log

ALL All events Absolutely all events of the technology magazine
ADMIN Administrative action Administrator User Actions
CALL Incoming call Incoming remote call (remote call on the call receiver side)
CONN Connection to the server Establishing or breaking a TCP connection between processes of the 1C 8.3 system
CLSTR Cluster activity Performing operations that change the operation of a server cluster
EDS External data source All events from external data sources
DB2 IBM DB2 Execution of SQL statements in IBM DB2
DBMSSQL Microsoft SQL Server Execution of SQL statements in Microsoft SQL Server DBMS
DBPOSTGRS PostgreSQL Execution of SQL statements in PostgreSQL DBMS
DBORACLE Oracle Database Execution of SQL statements in Oracle Database
DBV8DBEng SQL, File DBMS Execution of SQL statements in a file DBMS
EXCP Exception An exceptional situation in an application of the 1C: Enterprise system, which is not processed normally and can cause an abnormal termination of the server process or the client process connected to it
EXCPCNTX Exception context An event that began but did not end when an emergency occurred
HASP Calling HASP Accessing the hardware security key ()
LEAKS Memory leak An event associated with a memory leak, which can be caused by errors in the 1C 8.2 configuration code
MEM Server memory leak Event related to an increase in the amount of memory occupied by server processes (ragent, rmngr, ).
PROC Process An event related to the entire process and affecting the further performance of the process. For example: start, end, crash, etc.
QERR The request failed Event related to the detection of query compilation errors or restrictions at the level of records and fields of the database
SCALL Outgoing call Outgoing remote call (outgoing call on the call source side).
SCOM Server context The event of creation or deletion of a server context, usually associated with an infobase.
SDBL Database Query Executing queries to the 1C: Enterprise 8.3 database model
SESN Session Actions related to the work session. For example: start of session, end of session, etc.
SRVC Cluster services Events related to starting, stopping, and alerting server cluster services
TLOCK Lock Managing transaction locks in Managed mode
TDEADLOCK Deadlock detected in Managed mode
TTIMEOUT Time-out Maximum transaction lock timeout exceeded
VRSCACHE http cache Server call cache operation
VRSREQUEST Request to the server Request to the server for some resource
VRSRESPONSE Server response Server response
SYSTEM System events System events of platform mechanisms intended for analysis by 1C employees

Colleagues, we continue the series of articles dedicated to the technology magazine.

Today we will show the practice of analyzing TJ logs.

Other articles from the Technology Magazine series:

Analysis of technological logs

What will you learn from this article?

  • Let's take a closer look at the logs in 1C: Enterprise 8
  • Let's study the log format in detail Technology magazine
  • Let's look at an example of a log with recorded data

Let's see what happens if we create a file logcfg.xml with the above structure and place it in the directory "C:\Program Files\1Cv82\conf"

Let's wait 60 seconds and open the directory "C:\1C_Info\Logs", because this is exactly what we indicated in line 3 of the file logcfg.

If the directory 1C_Info is not on the disk, then the 1C server will try to create it, but there is a risk that the user under whom the 1C service is running will not have rights. Therefore, it is recommended to create directories for logs manually and check whether the 1C server has rights to write to this directory.

As a result, we see 3 subdirectories in the directory.

Each cluster process has created a directory containing logs only for this process, and since I only have 3 processes, so there are also 3 directories.

The directory is created using a template ProcessName_PIDProcess. PID needed to distinguish between processes with the same name.

The log file is named according to the pattern YYMMDDHCH.log.

If the log is older than the number of hours specified in the parameter history file logcfg, then it is automatically deleted by the platform.

Let's take a closer look at the technology log format.

An event is written to the log only after it has completed, because it is necessary to record the duration of the event.

The log line has the format:

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

mm– minute number in the current hour.

ss– number of the second in the current minute.

ttttt– the number of a ten-thousandth of the current second, for 8.3 the number of a millionth is displayed here.

d– duration of the event in ten thousandths of a second, for 8.3 in millionths.

<ИмяСобытия> – name of the event.

<Уровень> – event level on the stack of the current thread.

<Свойства> - event properties separated by commas, property values ​​separated by sign «=» .

Let's look at it with an example.

There is a log with the following content:

00:16 - these are the minutes and seconds of the end of the event. The date and hour of the event can be taken from the name of the log file. The event ended on April 6, 2015 at 11:00 minutes and 16 seconds. 8640 – for 8.2 this is ten thousandths of a second. And for 8.3 - millionths of a second of the moment the event ends. 1 is the duration of the event. In 8.2 the duration is indicated in ten thousandths of a second, in 8.3 in millionths of a second. If you need to set a filter for duration, you can use the property name “Duration”. DBMSSQL is the name of the event. In this case, execution of MS SQL Server DBMS instructions. 3 – event level. Next are the event properties DBMSSQL, and each event has its own set of properties. A complete list of properties for all events can be found in the administrator's guide. Here we will take a closer look at the properties for the current event only. Process– Describes the process for which this log is written. All events have this property. In my case, the rphost process log is written. P:processName– name of the 1C infobase. The event was created in a database called Deadlock. T:clientID- identifier of the connection with the client via TCP. T:applicationName– client program identifier. Those. who exactly caused the event, in my case it is a background job. T:connectID– connection number to the infobase. SessionID– session number assigned to the current thread. If the current thread does not have a session assigned, then the property is not added. Usr– the name of the infobase user under which this flow is executed. If the user is not defined, the DefUser value is substituted. Trans– shows whether the transaction is open at the start of the event or not. 1 – open, 0 – not. dbpid– connection number of the 1C server with the database server. SQL– text of the SQL statement. Most often this contains the text of the SQL query with parameters. Rows– the number of rows that the query returned. RowsAffected– the number of rows that the query changed in the database. Context– what line of code in 1C language generated this event. Probably the most interesting event for us.

Burmistrov Andrey

In the following articles we will look at “Events”, as well as their filtering in TJ.

In the meantime, attach the received material to your test information base :)


Not so long ago I discovered something new for myself, it turns out there is a technology magazine (TJ). What kind of animal this is and why it is needed I will try to answer in this article.

How to speak 1C itself Technology magazine 1C:Enterprise 8 systems can be used to analyze technological problems of the system and analyze emergency terminations. It registers information from all 1C:Enterprise 8 applications running on a given computer.From this definition the usefulness of this tool is immediately obvious, from it we can learn for example:

  • When executing what code does the server's work processes crash?
  • which queries are slow and where they are called from?
  • See if there were deadlocks or timeouts
  • and much more.
What is TJ? A represents TJa collection of text files stored in a specified directory.
These files can be divided into 2 groups
  • dump files
  • log files
Logs– these are files with the log extension, where information is stored in text form.
Dumps– this is a file with the mdmp extension, which contains the contents of the process’s RAM at the time of the crash.


Go ahead. In what directory are the TJ files stored?
Default The TJ is created in the directory:
%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\
If Windows Vista and higher are used, the directory will be used: %LOCALAPPDATA%\1C\1Cv82\
For 8.3, instead of the 1Cv82 catalog, 1Cv8 is used.
But this directory can be changed. More on this below.
How to turn on TJ?
By default, the process log is enabled and configured to save minimal dumps. Using a special file, we can configure the TJ. Namely, we can change the TJ directories, indicate which events should be registered in the TJ, etc.
I'm talking about the TJ settings filelogcfg.xml .

This file should be located in the conf directory in the folder with 1c installed, for example
"D:\Program Files\1Cv8\conf"
Let's look at an example of a settings file for a complete TZ.
config xmlns="http://v8.1c.ru/v8/tech-log"> This configuration file defines the output to the process log of all events along with all properties. The log will be saved for a week (24 hours). However, the amount of information output will be very large.
It is more advisable to configure the TJ only for events that interest us, for example, we want to see if there were errors or long operations in the system (>10 seconds)

The most common TJ events: EXCP– exceptional situations of 1C:Enterprise system applications that are not processed normally and can cause an emergency termination of the server process or the client process connected to it. EXCPCNTX– events that began, but did not end at the time of the occurrence of an emergency situation. DBMSSQL– execution of SQL statements from the Microsoft SQL Server DBMS. Each DBMS uses its own event (BPOSTGRS, DBORACLE, DB2, DBV8DBENG – file version) ADMIN– actions of the cluster administrator in the cluster console. PROC– events related to the entire process and affecting the further performance of the process. For example: start, end, crash, etc. CALL– incoming remote call (remote call on the call receiver side). For example, if you call a function on the server from the client, then the CALL event will be recorded in the TJ on the server. SCALL– outgoing remote call (outgoing call on the call source side). For example, if you call a function on the server from the client, the SCALL event will be recorded in the TJ on the client. SESN– actions related to the work session. For example: start of session, end of session. TDEADLOCK– a deadlock was detected in the controlled interlocking mode. TTIMEOUT– timeout error on managed locks. TLOCK– setting a transactional lock in a controlled locking mode.
Using the TJ settings, you can filter out almost any events that interest us.
Let’s say we want to see in the TC only errors and information about queries to the AccRg105 table that lasted more than 3 seconds. Then logcfg should look like this.
Logical OR works between the two, i.e. When any of the events occurs, it will be recorded in the TJ.
Logical AND works inside one, i.e. a given event will only be recorded if all conditions within one are met.
With this setting, the EXCP event will always be recorded, and the DBMSSQL event will only be recorded if the string “AccRg105” is contained anywhere in the request text and the request has been executed for more than 3 seconds. The filter for event duration must be set in ten thousandths of a second, regardless of the platform version. In this example we use several conditions: eq, gt and like.
The following conditions can be used:

  • eq – equal;
  • ne – not equal;
  • gt – more;
  • ge – greater than or equal to;
  • lt – less;
  • le – less than or equal to;
  • like – matches the mask.
I'll add a couple more notes at the end:
The platform reads data from the settings file once a minute, so don’t get excited and check the files right away, you’ll just have peace of mind in a minute)
If you are not going to send dump data to 1C, then there is no need to store it; do not specify the dump location line in the settings file.
If you are going to store the TJ files in a directory other than the default directory, then it is better to first create it yourself.

In the test database, I deliberately created a timeout on the lock,
Using this as an example