I do not agree to yours "Logs are not for debugging". In heavy loaded multithreaded applications it could be the only way to debug. The DEBUG level IS definitively for debugging purpose. In production, I agree, the level should be INFO or higher. Heri
> -----Original Message----- > From: Julius Davies [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2008 8:18 PM > To: Log4J Users List > Subject: [SPAM (DNS Blacklist)] - what to log - Sending mail > server found on relays.ordb.org > > Richard J. Barbalace wrote the following in the "best > practises" thread: > > ----------------------------------- > [...] Do NOT log valuable information. > > By valuable, I mean information that has value to the > organization or the users, as opposed to the developers. For > instance, in medical applications, you should not log > personal health information (PHI). This is hopefully > obvious, but I would never want to see this in a log: > 2004-09-28/18:37:35.138/PDT - Submitted POSITIVE result for > HERPES test for patient SMITH. > > That could violate the HIPAA law, create a severe privacy > breach if someone unauthorized reviewed your log, and might > include information that the developer is not even legally > permitted to see. > > As another example, in a banking system, you should not log > personal account details, social security numbers, etc. to a > file whose only purpose is for debugging. Thankfully, in > most cases, the exact personal details are not necessary for > debugging an application. > ----------------------------------- > > Logs are not for debugging. That's the least important side > of logging. (Unfortunately in the java world, debugging is > where most of the logs are focused!) I think of logs as an > intense write-always, read-rarely database. So I log 5TB of > data over a year because my client might need to look at 1KB > when something serious happens. > > As for what to log, look at the real life situation: > > - The doctor can see the patient's chart (same for doctor's staff). > - The lab technician can see the lab's correspondence with > the doctor (same for lab's staff). > - Additional people probably have access to the information > through the lab's software systems, and the doctor's software systems. > > > I don't see why the log shouldn't be able to store similar > information. Of course access to the log should be > controlled. When I worked at a credit union, the production > logs were tightly controlled. Only a few select people had > access to specific logs, and developers, almost always, never > had access. > > Probably logs should have the same security, privacy, and > access controls around them that one would apply to the > database (and its hard-drive). In the end it's just > information on a hard-drive. If we go down the path you're > suggesting, one should also not store this information in a database! > > On the other hand, I strongly believe in not logging valuable > information when there is no need to log it. Logging a > customer's bank balance is never useful. But logging the > fact they made a bill payment for $5,000 can be useful if > they call up later after something goes wrong. In other > words, log important state changes, but don't log the state. > If a patient's state changed from "healthy" to "herpes," I > would log that. (What if the computer made a mistake? > The log will help!) > > You also can't log information if you promise your customers > you will never retain it (or even see it), like a password. > > > Logs are not for developers. Like the rest of the > application, they are written by developers, and used by > everyone else. In the case of logs the users are usually: > sysadmins, customer support, security auditors, lawyers, and > occasionally the police! > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > 250-893-4579 (Mobile) > http://juliusdavies.ca/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
