home Audio Video What are log files for? log file. How to fix problems opening LOG files

What are log files for? log file. How to fix problems opening LOG files

If, in response to some event, the program adds entries to a file, usually identifying the event and its source, then such a file is called a log file. Possible event sources:

The result of certain user actions.
Interrupts coming into the program from the equipment.
Events generated by the programs themselves (for example, obtained as a result of calculations).
Events generated by software errors (the so-called "exceptions").
Events from the operating system or another program, as well as events from any other source.

In a word, we are talking about changing states in a running and running program. The simplest option log file - normal text file with line records. All information in the log files is recorded in a specific format, which makes it possible to later understand the causes of events.

Where are log files used?

The list of applications of log files is huge. Files of this type are used wherever it is necessary to trace the history of a particular program process, keep a record of the state of devices and machines, monitor user actions, incl. and for security purposes. And in many other cases. To search and analyze data in log files, as a rule, an independent software, which allows you to quickly and visually study the recorded data on the work software system. Many log files are very large, so you either have to regularly overwrite their outdated content, or create entire collections of log files with names that include, for example, the date. In many cases, databases are preferred over log files.

Useful examples

Let's give a couple of examples on the use of log files. If there are many unexpected exceptions in the program being debugged, then it is quite possible to write them to a log file for subsequent error analysis. As another example, you can point to the logging of data about connected users in multi-user client-server systems. This allows you to track the unauthorized operations they perform.

Logging helps the developer in the process of creating and subsequent maintenance of the application, in finding errors in the code and in resolving incomprehensible situations when our application behaves in a strange way at the time of work, and we need to find the reason for this behavior.

Any developer faces similar situations when some component of the application works in a strange way, gives the wrong result, or stops working altogether. Using logs will help us in situations like this. The time for searching for problem areas in our code will be significantly reduced, and we will be able to solve this or that problem faster.

In general, at the moment, not a single more or less serious application can do without writing logs.

Log (log) is a special log that stores information about the state of the application (program).

Such a log can be understood as entries to a plain text file, and entries to a database, and entries to a remote web service, and even emails to a specific address about certain states of our application.

What entries to make in this log, that is, what specific information to write down, is determined by the developer himself. This may be information that everything is working normally, that is, just daily monitoring of our application, or that some kind of error has occurred that needs to be responded to and eliminated as soon as possible, and so on.

In total, there are six levels of logging, each of which is intended for messages of one type or another, of one or another importance:

Trace - the most detailed information about what is happening with the target code section, step by step. For example: Attempt to open a database connection, successful/unsuccessful. How long did this operation take? How long was the selection from the database, successful\unsuccessful. How many records are retrieved. What was the load on the system, how much memory was used. How many records passed the required filtering. How many records appeared in the resulting selection, where these records went next. Checking the desired values in each entry.

Debug is information for debugging. Logging of large operations, less detailed than in Trace. Here we do not describe the whole process of the operation in such detail, but, nevertheless, we log the main operations. For example: A request to the database has been made. N records are selected from the database. The records have been successfully processed and sent to the client.

Info - these are more general informational messages about the current operation of the application, what happens to the system in the process of using it. For example: Students were uploaded to an Excel file. A new student has registered on the site. The student has added a new report. The student has been moved to another group.

Warn - messages about strange or suspicious behavior of the application. This is not yet a serious error, but you should pay attention to this behavior of the system. For example: A student with an age of 2 years has been added. The student received a negative score. The teacher completed a course with 0 students. There are more students in the group than the maximum possible.

Error - error messages in the application. Such messages are already a big problem that needs to be solved for further correct operation systems. For example: Error saving a new student in the database. Unable to load students in this group. Login error Personal Area student.

Fatal - messages about very serious errors in the system. Most often, this is due to the health of the entire application or its environment on the server. Such messages should be responded to as quickly as possible. For example: The application constantly reloads due to lack of memory or hard disk space. The application has terminated for an unknown reason. There is no access to the database. No network access. Some port is blocked.

That is, before sending a message to the log, we need to attribute it to a particular group.

For example, we have written a new functionality and want to test it, how it works correctly and quickly. To do this, we will use the Trace message type, that is, all our messages in the log will be marked as Trace.

In a similar way, we can describe how our application works as a whole, messages will be labeled Info.

If we throw an exception in dangerous parts of the code, then now we will also add an entry to the log marked Error.

The developer himself decides which group to attribute this or that message to. This issue should be approached with the utmost seriousness. Obviously, errors should not be flagged as Info, errors should not be ignored and simply not logged. Ease of maintenance of the entire system, prompt response to errors and time spent on troubleshooting will depend on a properly configured logging system.

Sometimes developers are too lazy to write logs, they don't want to spend time on it. In the future, it turns out that the time spent on finding and correcting errors is many times more than the time it would take to create a system of logs.

Naturally, much depends on the complexity of the project. If you are creating a simple three-page business card site or a console application for your own needs on your local computer, then writing a complex logging system can take longer than creating the project itself. In this case, only error messages or why the site crashed can be written to the logs. But if you are working on a complex project in a team with other developers, then proper logging is a must.

In order to start logging, we will connect the NLog platform to our project. It's possible .

$(basedir)- the root directory of our application
$(shortdate) - The current date in the format yyyy-MM-dd
$(longdate)- current date in the format yyyy-MM-dd HH:mm:ss.ffff
$(callsite)- log call location (class name, method name)
$(uppercase:$(level)- logging level
$(message)- directly the message that will be written to the log
$(newline)- newline character

Public class StudentsRepository ( private static Logger logger = LogManager.GetCurrentClassLogger(); //... )

Most often, one static logger should be declared within the entire class. Here we are through the class manager log manager announced a new logger that we will work with.

Let's start logging from the Trace level. In the method where we select a student by his ID, let's describe in as much detail as possible how this happens:

Public Student GetStudentById(int id) ( //here the situation of a real selection of a student from the database is simulated... logger.Trace("Requested student id: " + id); logger.Trace("Trying to connect to the data source"); logger .Trace("Connection to data source was successful. Elapsed time(ms): " + new TimeSpan(0, 0, 0, 0, 20).Milliseconds); var student = _studentsList.FirstOrDefault(x => x.Id = = id); logger.Trace("Sampling was successful. Student with id==" + student.Id); return student; )

Notice that we are calling the Trace() method on the logger object. It has a corresponding meaning - logging messages of type Trace. If we turn to the definition of the Logger class, we can find that there are also other methods for all levels of the log, which we will use further.

Now let's add some Debug level messages. As we remember, this is also debugging information, but less detailed. This approach we use in another method, for clarity:

public list GetStudents() ( //this simulates the situation of a real selection of students from the database... logger.Debug("Connected to the database"); logger.Debug("Fetched all students"); return _studentsList; )

We go further. At the Info level, we describe regular operations in our application, that is, we rise one level higher. Let's say we're working on an ASP.NET MVC application and we have an action in a controller that calls the GetStudentById() method described earlier:

Public ActionResult GetStudent(int id) ( logger.Info("Teacher requested student with id == " + id); StudentsRepository repository = new StudentsRepository(); Student student = repository.GetStudentById(id); return View(student); )

Now let's add Warn level messages to the logs. As we remember, at this logging level we describe all potentially dangerous situations, strange and illogical behavior of components. We will log an entry if the student is less than 15 years old:

//... Student student = repository.GetStudentById(id); logger.Trace("The sampling was successful. The selected student with id==" + student.Id); if (student.Age< 15) logger.Warn("Выбран студент моложе 15 лет"); //...

Var student = _studentsList.FirstOrDefault(x => x.Id == id); if (student == null) logger.Error("Error. No student found with id == " + id); logger.Trace("The sampling was successful. The selected student with id==" + student.Id); if (student.Age< 15) logger.Warn("Выбран студент моложе 15 лет");

Now let's determine what we should record at the Fatal level. In our simplest example, we will simply simulate a similar situation:

//... logger.Fatal("The application's maximum usage limit has been reached random access memory 90%"); //...

We reviewed all six levels of logging and described the process of our application in as much detail as possible. Now we can immediately analyze the operation of the site, simply by examining the logs, and not look into the source code.

This is how logging works. In our simplest example, where we are simulating work with students, everything is extremely clear and transparent even without logs. But in complex projects, logging is an integral part of development.

Of course, these are far from the full customization capabilities of the NLog platform. AT configuration file you can configure logging to other places, for example, to a database, to the console, to RAM, send as an email message, send messages over the network, and so on. You can also set up message filtering, a more complex message template. If you are not satisfied with the standard functionality of the logger, then you can write your own extension and connect it.

That's all here, let's summarize a little. We have studied the topic of logging in the application. We looked at how to correctly log certain sections of code, and also got acquainted with one of the most popular logging platforms - this is the NLog Platform, also considered its capabilities and how you can configure the generation of logs on this platform.

In addition to the standard site statistics, which includes the number of unique visitors, open pages and many more useful information, the webmaster needs to know many other things about such a site, and that is what the logs reveal to him. At the same time, novice webmasters quite often do not even know what a log is and what it gives.

What information is needed?

As mentioned above, in addition to the standard parameters, the site owner must know a lot of other data:

Which pages are the most visited.
What search queries are most likely to bring users to your site.
What browsers or operating systems are most in demand among visitors.
What screen resolution do visitors use the most.
And much more.

How to find out?

In the overwhelming majority of cases, a paid or free counter is installed on sites, while the resource that provides it carries out a thorough analysis of the site and keeps statistics of visits, which can be consulted at any time. Especially the use of such counters is in demand if a person hosts his own website on a free hosting. Considering what a log is, it is important to learn how to work with such counters, since, in fact, they include most of the necessary data.

The overwhelming majority of hosting providers that provide paid hosting initially give their customers the opportunity to use the analysis tools that are already installed in the created site. For example, Apache servers use a specialized utility called Webalizer, which is used as an additional server module.

Those who use paid hosting can also process all the data regarding their site completely independently, since a webmaster who knows what a site log is and how to use it has full access to all the information you need.

What's this?

Any site maintains its own log, which the webmaster can look at at any time convenient for him. What is a log? This is a separate text file that contains information regarding all requests to the site, as well as various errors related to these requests.

How is data written to the log?

Initially, the user types in his own browser the address of a particular site and goes to it. After that, the user's browser begins to send to the server on which this site is located, a request to issue the web page of interest to the user. Along with this, the following information is provided to the server:

visitor's IP address.
The exact time the request was made.
The browser the user is using.
The operating system the user is using.
Page of interest.
The address of the page from which the transition to the target was made.

After that, the server issues a request of interest to the visitor, and all information regarding the transaction is recorded in the event log, creating a so-called log file.

A competent analysis of the site logs allows the webmaster to determine exactly how his resource is used and in which direction it is more relevant to develop it.

What information do the logs give?

Looking through the site logs, you can find huge amount useful information that will improve the further promotion of the resource and make it more effective:

Attendance. Of course, such an indicator is also determined by a standard counter that can be present on each page, but in the log this data is provided in more detail, including traffic by day, hour or month. Also, by using logs, you can determine the hours of a surge or lull in traffic, which is extremely important to know when maintaining a site.
Traffic. In this case, both the traffic of each individual page and the total site traffic for certain period time.
Conversion. This parameter allows you to determine how visitors navigate through your resource, that is, they viewed one page and closed or nevertheless began to "travel" through your site, viewing one page after another. The conversion rate allows you to indirectly determine the quality of your site.
abandoned pages. Considering what server logs are, you can often determine that they contain abandoned pages, that is, those that are visited extremely rarely. In such a situation, the webmaster must conduct a thorough analysis of the situation, because it may be that the pages have ceased to interest people or it has become difficult to find them among the many others on your site.
Popular Pages. Web pages that are most visited. You can use them as a template in the process of creating other pages, and if necessary, you can also direct users from these pages to some others that are abandoned or less popular.
Search queries. Among other things, the site logs also contain the effectiveness of those meta tags, keywords and the names of the web pages that you used and for which your site could be found by certain search engines. Accordingly, the logs contain data about which particular search engine found your site for a particular query.

Instruction

In the properties of the "My Computer" menu, select the item responsible for management. On operating systems Seven and Windows Vista This item is listed on the left side of the My Computer menu bar. Also you can run this menu from "Administration" in the control panel. You should see on your screen special console management.

When working with log files, be sure to pay attention to the restrictions account, since all actions should be performed only by the administrator. Guests and other restricted accounts will not be able to use this action.

Find the Event Viewer and Utilities Viewer in the Computer Management menu. Carefully review each of their sections, then decide which ones you want to remove.

In the event viewer, clear the operating system logs Windows systems by selecting it with the left mouse button. Expand the "Action" item, then run it context menu by highlighting right click mice.

In the window displayed on your screen, select the item called "Erase all events" and, if you really want to do this, confirm the operation in the dialog box that appears. Wait until the contents of the log files are removed from your computer.

Use special programs optimizing the computer to clean up log files in a more understandable and faster manner, usually they can also be configured to automatically clean up their contents. Usually, clearing logs is a secondary task of such programs, but they can be useful for speeding up your computer, removing unused services, and terminating unnecessary processes. They also perform disk defragmentation, error correction, RAM cleaning, and so on.

Useful advice

Do not clean the logs yourself if you do not have the skills of a confident PC user.

The task of clearing the transaction log 1C based on Microsoft SQL Server presents certain difficulties due to the automatic growth of the size of its own files, despite the existing ability to automatically reduce the selected file.

Instruction

Make sure that you understand the scheme of the selected cleanup operation, or rather, truncation of the transaction log: the procedure can only be carried out by truncation of the free space at the end of the file and is directly related to the chosen method of creating backup. If you select the Full option, you must complete all persistent transactions and create a backup in the Remove inactive entries from transactional log mode. Selecting the Simple option truncates the entire file, but does not necessarily restore transactions.

Truncation of the transaction log file can be performed using the Query Analyzer tool with the DBCC Shrinkfile (log_file_name, desired_file_size) command, and the cleanup operation can only be performed after creating a complete reserve base by the same team. Use the following syntax to specify copy options: BackUp Log selected_base_name with truncate only.

Create a full backup of the transaction log file to be purged, if you do not need to restore the data using the Backup Database tool, and clear the Remove inactive entries from transactional log check box. Go to the Options tab and change the value of the Recovery Model parameter to Simple. Truncate the selected file with the above command or use the syntax DBCC ShrinkDatabase (selected_database_name, required_residual_file_size_in_%).

Check the box Remove inactive entries from transactional log and back up the source set from Enterprise Manager. Restore the Recovery Model to Full and retry the log restore from Enterprise Manager over the existing copy. Again uncheck the box Remove inactive entries from transactional log and, once again, execute backup selected transaction log.

Just about the complex. Programs. Iron. Internet. Windows