Codes binding coefficient?

Question

What is the perfect registration code? I'm not used to writing magazines, since most of the applications I developed did not have a lot of protocols.

I recently changed the task, and I noticed that you do not see the application code for calls in log4net. I appreciate that this is useful, but is it true that too many debugging messages are as bad as none at all?

There are registration messages that tell you when each method starts and ends, and what they return. and when almost nothing is done.

Wouldn't it be easier to have some kind of addon that used reflection to add logging instructions at compile time so they don't interfere when you tried to look at the code?

Also, these days, powerful IDEs and remote debugging are what many protocols really fail.

Answer 1

Actually there is a good library to add to the log after you say PostSharp . This allows you to do this through attribute-based programming, among many other very useful things besides logging.

I agree that what you say is too small to register.

Some of them bring some good points, especially the banking scenario and other mission-critical applications. This may be necessary for extreme logging, or at least be able to turn it on and off if necessary, or set different levels.

Answer 2

Since log4net does a great job of not clogging up resources, I usually understand a little about logging, because when you need to go into debug mode, the more information you have, the better. Here is what I usually record:

DEBUG Level

• Any parameters passed to the Method
• Any number of rows from the result sets that I retrieve
• Any datarows that may contain suspicious data when passing to a method
• Any "generated" file paths, connection strings, or other values ​​that may be collected during the "addition" of the environment.

INFO Level

• The beginning and the end of the method
• Beginning and end of any major cycles
• Beginning of any basic case / switch statements

ERROR Level

• Exceptions Handled
• Invalid login attempts (if security issue)
• Bad data that I intercepted to send

FATAL Level

• Unhandled exceptions.

In addition, the presence of a large amount of registration information does not allow me to ask the user what they do when they receive an error message. I can easily put it together.

Answer 3

Complete log files are amazingly useful. Consider a situation where your application is being deployed somewhere like a bank. You cannot get there and debug it manually, and they are not going to send you their data. You can get a complete log, which may indicate where the problem occurred. Having multiple levels of logs is very helpful. Typically, an application starts in such a mode that it only reports fatal errors or serious errors. When you need to debug it, the user can turn on debug or trace output and get much more information.

The kind of logging you see seems excessive, but I can’t say that for sure, without knowing more about the application and where it can be deployed.

Answer 4

Also, these days, powerful IDEs and remote debugging are what many protocols really fail.

Yes, absolutely, although the mistake that many unskilled developers make is to try to fix the errors using the wrong method, usually trying to log when they should be debugged. There is a place for everyone, but there are at least a few areas where logging is almost always necessary:

• To study problems in real-time code, when a suspension with a debugger will lead to a calculation result (provided, logging will have a small effect on synchronization in real-time, like this, but how much it depends on the software)
• For builds sent to beta testers or other colleagues who don’t have access to the debugger
• To flush data to disk that is not easy to view in the debugger. For example, a specific IDE that cannot properly parse STL structures.
• To "feel" the normal flow of your program
• To make the code more readable in addition to the comments, for example:

 // Now open the data file
 fp = fopen ("data.bin", "rb");

The above comment can be just as easily posted in the journal:

 const char * kDataFile = "data.bin";
 log ("Now opening the data file% s", kDataFile);
 fp = fopen (kDataFile, "rb");

However, you are in some way correct. Using the registration mechanism as an illustrative stack trace logger will create very poor quality log files, since it does not provide a sufficiently useful downtime for the developer to study. Thus, the key here is obviously the correct and reasonable use of registration calls, which I think comes down to the discretion of the developer. You should consider that you essentially make log files for ; your users do not care about them and, as a rule, roughly misinterpret their contents, but you can use them to at least determine why your program behaves badly.

In addition, it is rare that a log file will point you to the direct source of a specific error. In my experience, it usually gives some insight into how you can replicate the error, and then either by replicating it or debugging, find the cause of the problem.

Answer 5

This is not required. There is no reason (in production) to know when each method begins and ends. Maybe you need it by certain methods, but the presence of such noise in the log files makes them almost impossible for effective analysis.

You should be logged when important events occur, such as errors, user logins (audit log), transactions started, important data is updated ... so on and so forth. If you have a problem that you cannot identify from the logs, then you can add more to it if necessary ... but only if necessary.

Also, for your information, adding compile-time registration will be an example of what is called Aspect Oriented Programming . Registration would be a "cross cutting problem."

Answer 6

When you have a client script (that is, the one whose computer you are not gaining physical access to), the only things that “register too much” are repainting functions and almost everything that they are called (which should be almost nothing) . Or other functions that are called 100 times per second during operation (running the program is okay, though, to have 100 calls for entering / installing routines registered because, in my experience, where most problems arise).

Otherwise, you will simply kick yourself when you miss some key point in the log, which will finally tell you that the problem is on the user machine.

(Note: here I mean logging, which occurs when the tracing mode is turned on for developer-oriented logs, and not for user-run normal logs.)

Answer 7

I personally think that in the first place there is no hard and fast rule. I have some applications that register LOT, in and out of methods, and status updates through the middle. These applications, although they are planned processes, turn off hands, and the logs are analyzed by another application that saves success / failure.

I found that in all actions, many user applications do not need a lot of logging, because indeed, if problems arise, you will debug them to track the values. In addition, you generally do not need registration costs.

However, it really depends on the project.

Answer 8

How many of these lines are logged by default? I worked on a system very similar to what you described - just loading it will lead to recording more than 20 MB of logs if logging was started, but even debugging we did not turn over all these modules for all modules. By default, it will be logged when entering a code module and major system events. This was great for debugging, because QA could simply attach the journal to the ticket, and even if it wasn’t reproducible, you could see what happens when the problem occurs. If you have serious multithreading, then registration is even better than any IDE or debugger I've worked with.

Answer 9

When you encounter an error during the beta version of your application and cannot reproduce it, you know that you had to do excessive registration. Similarly, if a client reports an error, but you cannot reproduce it, excessive logging can save a day.

Answer 10

I found that registration is much less necessary since I started using TDD. This greatly facilitates the detection of errors. However, I believe that logging can help to understand what is happening in the code. Undoubtedly, debuggers help give you an idea of ​​what is going on at a low level. But it’s easier for me when I can match the output line with the line of code if I want to get a high-level view of what is going on.

However, one thing I must add is this: make sure your log statements include a module in which the log statement works! I can’t calculate how many times I had to go back and find where the log operator actually lies.

Answer 11

I think that "logs to ratio ratio" is a misunderstanding of the problem.

In my work, from time to time I came across a situation where an error in a Java program cannot be reproduced outside the working environment and where the client does NOT want this to happen again.

Then EVERYTHING, you have the opportunity to fix the error, this is the information that you yourself put into the log files. No debugging sessions (which are in any case prohibited in production environments) - without selecting the input data - nothing!

So, logs are your time machine when an error occurred, and since you cannot predict in advance what information you will need to fix an unknown error - otherwise you could fix the error in the first place - you need to write a lot of things. ..

Exactly THAT things depend on the scenario, but basically enough to make sure that you never doubt what happens when :)

Naturally, this means a lot of recordings will happen. Then you will create two logs: one with everything that is stored only for a sufficiently long time to ensure that you do not need it, and the other with non-trivial information that can be stored for much longer.

Disabling registration as excessive is usually done by those who did not have to correct the error, and do not need anything else :)

Answer 12

In my work, I write many Windows services. For me, logging is not a luxury; this is actually my only user interface. When we introduce ourselves into production, we lose access to debugging and even to the databases to which our services write and do not register, we would not know any specific problems.

Having said that, I think the best approach is a concise logging style. Log messages are usually limited to the business logic of the application, such as “received message from xxx account” than “yyy function entered.” We perform log exceptions, thread starts, echo environment settings and timings. In addition, we look at the debugger to identify logical errors in the development and QA phases.

Answer 13

I must admit that when I started programming, I more or less registered all the details, as described by Dilly-O.

Believe me ... It really helped in the early days of the production deployment, where we relied heavily on log files to solve hundreds of problems.

As soon as the system became stable, I slowly began to delete the log entries, as their addition of value began to decrease. (No Log4j at this point in time.)

I think that the relationship of code entries to the log depends on the project and the environment, and it does not have to be constant.

We currently have a lot of flexibility when registering with packages such as Log4j, dynamic log level enablement, etc.

But if programmers do not use it properly, for example, when to use, when NOT to use INFO, DEBUG, ERROR, etc., as well as data in the log messages (I saw a log message like "Hello X", Hello XX, Hello XXX, etc., which only a programmer can understand), the ratio will remain high with less ROI .

Answer 14

I think another factor is the toolbox / platform used and the agreements that come with it. For example, logging is apparently quite common in the J (2) EE world, whereas I don't remember ever writing a log statement in a Ruby on Rails application.