Re: what to log - API questions :)
Maybe you need to look at AspectJ and Aspect Oriented Programming in general to address this cross-cutting concern? regards, Wim 2008/6/13 Christophe Elek [EMAIL PROTECTED]: They are great discussion :) I really enjoy reading them :) I have one on my own. My goal in IBM Rational is to ensure all products have a consistent set of logging so we can correlate the logs of all the products. Some are legacy products, some are new products. Developers and Architect always ask me... 'Chris, really, do I have to create the 4 Logger in each of my class and then figure out which logger to call ? This is crazy... Can't I just have an API like this MyComponent.log(String,Exception) ?' My answer to them is that the component owner must create the API and I see the following API 1) MyComponent.createLogRecord(String messageKey,Object[] parametersMessage,int severity,Throwable exception) 2) MyComponent.error(MyLogRecord) or MyComponent.audit(MyLogRecord) or MyComponent.traceHttp(MyLogRecord) What do you think the minimal set of API should be ? Or should we force our developers to become expert of Log4J ? I know I can explain to them the value of logging, the value of software engineering, quality of code...and so on... but seriously, If we come up with a very simple set of API...wouldn't that make this discussion between the developer and me easier ? Christophe Elek - Senior Software Analyst IBM Rational Serviceability Architect IBM Toronto Lab 8200 Warden Avenue, Markham, Ontario, L6G 1C7 Phone Number: (905) 413-3467 Email: [EMAIL PROTECTED] Don't just fix the mistakes - fix whatever permitted the mistake in the first place. Charles Fishman
RE: what to log
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]
RE: what to log
I don't see why the log shouldn't be able to store similar information. Depending on where you live, logging such information may be an illegal act (breach of Data Protection, data misuse) or breaking of industry regulations (e.g. recording the 3 security digits from the back of a credit card). Log files are not always as controlled in the same way as other systems, nor does it really need to be. The admin who manages the servers and can lift the log files may or may not be the same admin who maintains (say) the bank's databases. Then there is the aspect of international law. It might be legal in the USA to log personally identifiable information, but in Europe you may already be getting into trouble if you did so. And if that log file was sent to someone outside of Europe, then your company would almost certainly be in breach and in very serious trouble indeed. If we go down the path you're suggesting, one should also not store this information in a database! Correct. And some information should NOT be stored in a database. A common example is credit card information, most companies are simply not permitted to hold certain card info after the transaction is successful. Uncyphered passwords is another example. I have seen system which log usernames and passwords into log files. If the FDA saw that happening at a drugs company in the USA, they'd throw a blue fit! But logging the fact they made a bill payment for $5,000 can be useful if they call up later after something goes wrong. That information should still not be in a log file IMHO (privacy), the transaction will certainly be recorded somewhere much more appropriate (having worked in the banking sector, I never once had to use the log file for such information; I just looked at the transaction records directly.) If such information does need logged, that logging now falls under the realm of a business process and will be subject to a completely different set of rules set by the client. Whilst I am sure that you could use Log4J in this case, more than likely you would be using something else as you are likely to be logging into a business system. I work with software which does this. On certain events we need to log who did what and why. This is done into the fully locked down audit system of the content repository, not into an easily modifiable text file. Normal log files are there to aid the support team in diagnosing what is causing the user problems (be it user error, excessive load or a bug). These log file should not be used to record vital business operational, audit or other information. There are other system much more suited to those jobs (as mentioned above). Right, please excuse me whilst I clamber off this soap box... J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what to log - API questions :)
They are great discussion :) I really enjoy reading them :) I have one on my own. My goal in IBM Rational is to ensure all products have a consistent set of logging so we can correlate the logs of all the products. Some are legacy products, some are new products. Developers and Architect always ask me... 'Chris, really, do I have to create the 4 Logger in each of my class and then figure out which logger to call ? This is crazy... Can't I just have an API like this MyComponent.log(String,Exception) ?' My answer to them is that the component owner must create the API and I see the following API 1) MyComponent.createLogRecord(String messageKey,Object[] parametersMessage,int severity,Throwable exception) 2) MyComponent.error(MyLogRecord) or MyComponent.audit(MyLogRecord) or MyComponent.traceHttp(MyLogRecord) What do you think the minimal set of API should be ? Or should we force our developers to become expert of Log4J ? I know I can explain to them the value of logging, the value of software engineering, quality of code...and so on... but seriously, If we come up with a very simple set of API...wouldn't that make this discussion between the developer and me easier ? Christophe Elek - Senior Software Analyst IBM Rational Serviceability Architect IBM Toronto Lab 8200 Warden Avenue, Markham, Ontario, L6G 1C7 Phone Number: (905) 413-3467 Email: [EMAIL PROTECTED] Don't just fix the mistakes - fix whatever permitted the mistake in the first place. Charles Fishman
