LogBag: logs groups of messages based on highest priority

Discussions

News: LogBag: logs groups of messages based on highest priority

  1. Cameron Purdy recently posted a link to a new logging framework, called LogBag. This framework collects log entries in a "bag," presumably a collection of log entries, and when the bag is completed, whether it's written out or not is determined by the message with the highest severity in the bag. LogBag hasn't been released yet, but the concept is worth noting. Cameron's post contrasts LogBag to Log4J, but the LogBag authors say that LogBag uses Log4J internally, which is amusing. However, the concept itself is definitely worth consideration, from a number of different aspects:
    • Often, log information isn't useful to programmers because log messages lack context of the transaction to which they apply.
    • Log information tends to be useless to programmers because developers are rarely interested in unexceptional conditions.
    Sarbanes-Oxley, however, requires logging regardless of success or failure, so LogBag might cause some issues there - that said, your Humble Editor is certainly not a lawyer or a Sarbanes-Oxley expert. Could someone shed light on this?

    Threaded Messages (15)

  2. I like the concept[ Go to top ]

    I was already designing something similar in my head due to resource constraints (disk) and multi-user logging in a combined log file, so I may look at LogBag (ooookk... looked, and nothing to see). When an error or warning condition occurs in production, you want to get a decent amount of context prior to the error, and because of this many developers leave debug on (the case I'm dealing with) and generate GBs of log data each day, but that slows down forensic analysis of errors. If you also log audit information to the same file ("user X loaded document Y", "user Z saved document A", etc.) then a requirement for your app would be do do regular logging AND LogBag logging or have LogBag somehow pick out 'info' messages from a bag and log them before tossing it. As a side note, I'd like to know how various webapp/J2EE developers handle logging of all messages associated with a specific user and/or session, without using AOP and logging all messages to a single log file. Any design patterns or articles to recommend? The architecture we have allows for only one log file, and we end up building a simple LogContext POJO that we pass references to for all operations called by servlets/actions so they can prepend that information to log messages and therefore be tied to a specific user and/or session. Kind of a pain, though.
  3. Re: I like the concept[ Go to top ]

    Well, Log4J has the concept of a logging context (see NDC and MDC) for this. That's part of it. What other mechanisms are out there, folks?
  4. Joseph: "Well, Log4J has the concept of a logging context (see NDC and MDC) for this. That's part of it. What other mechanisms are out there, folks?" JXInsight's Tracer is an enterprise solution for "contextual" tracing across distributed systems. We offer a very simple, but powerful, API to our distributed tracing and profiling engine that is used by nearly all of JXInsight's technology trace and profile extensions (Hibernate, Spring, Coherence, JDO, EJB3, EJB, Servlets,.....) Our Tracer API can be used by customers and partners today to integrate custom instrumentation (JBoss AOP, CORBA Interceptors, Spring Interceptors, AspectJ) with our awarding winning management console UI. http://www.jinspired.com/products/jxinsight/api/com/jinspired/jxinsight/trace/Tracer.html I had thought about submitting a JSR derived from this API that would specify an extensible service provider contract enabling the delivery of resource metering, error diagnostics, and performance profiling across all platforms and architectures while decouple instrumentation, event correlation and visualization tooling. Thoughts? In JXInsight 4.2 we made significant enhancements to the timeline snapshot analysis including the ability to turn on the capturing of contextual trace state information related to trace call arguments, results, exceptions, thread, request context and target object. http://www.jinspired.com/products/jxinsight/new-in-4.2.html I wrote an article, "Context in Time", that touched more on this subject. http://www.jinspired.com/products/jxinsight/contextintime.html By the way we have offered an tracing extension for log4j and Java logging since JXInsight 3.2 http://www.jinspired.com/products/jxinsight/new-in-3.2.html Regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  5. Re: I like the concept[ Go to top ]

    Once in a while we all face the issue when the user reports an error on the production systems and the developers find that stack trace doesnot provide enough information! It is not exactly unheard of - that developers would request the user reporting the problem to provide more details and if possible, steps to re-create the problem. So why dont we Log levels set to "Debug" in production and why not just use NDC to group. Many of these implementations write GBs of logs every day - if set to Debug level, and problems may take a week or two ( depending on priority) before the developer even looks at that. This means that we should have atleast 30 days of logs. Maintaining the 100+ GB of log and actually shipping them offsite to the developer - when the need be is serious business - even after zipping and cheap bandwidth, even within the same building. Why not NDC? The preferred architecture today is to use lots of small "blade servers" and cluster them using some kind of load balancer. Also SOA has arrived, and there are very high chances that the business logic will run in a different VM. We cant pass thread context across Soap invocations or to different machines. So we cant Group by NDC. We have contemplated the fact that someone will come and say - all this is possible, look at so and so implementation of this grid computing product. If that happens and once we are convinced that the solution works, We will call of this project and spend the time better possibly having Courage Bigger at a London Pub , than re-inventing the wheel. Have a look at this thread at comp.lang.java.programmer (url shortened by editor) many people face logging problems, but settle for custom solutions or lesser solutions or live with the problem. This is not intented to replace profilers, which need to provide a much deeper analysis. This is only intending to reduce the occurances of requests from developers to the users : Can you please give me steps to reproduce the problem. We need to clarify that we intend to make use of all the good work done by log4J. We will not be looking to re-developer the different log appenders. We will try to figure out areas where people have contributed to Log4J and would try to make this product binary compatible with those contributions if possible. Also system failures are best handled with interleaved logs on individual systems, which give you the best view of what is happening to the entire system and not a user thread. This means that we will need to consider local logging as well. We are yet to give it a thought but looks like we would have to support passing thru the requests to Log4J or something for local logging as well. Thanks for all the useful comments. We are still convinced that we need to go ahead and that there is nothing similar out there. We invite ideas, implementations and comments.
  6. Re: I like the concept[ Go to top ]

    Nice concept. How about having a web based interface to do all the config etc? /a http://apoorv.info
  7. Re: I like the concept[ Go to top ]

    I've been working on a solution that uses a general correlation engine instead of requiring passing around a LogBag GUID. This way I can correlate non-application logs (like apache access logs) as well. I still think you have a very nice and simple solution. /Magnus Johansson
  8. Re: I like the concept[ Go to top ]

    Ohhhhkay. I can see the point here. Per default all my log4j (love the package) contain NDC, thread and time. This usually allows me to group stuff sufficiently; NDC allows me to separate out what happened within one session (as in: application - user combination), thread what happenened within one execution, and time will sort it for me. But I can understand that a bigger grouping could be interesting, especially since grids become more and more common.
  9. Re: I like the concept[ Go to top ]

    Well, Log4J has the concept of a logging context (see NDC and MDC) for this. That's part of it. What other mechanisms are out there, folks?
    I finally got the links to work, and those look interesting so I'll check them out. For my purposes (we have a custom logger -- doesn't everybody? ;-) I'm also going to investigate writing a FIFO queue to buffer messages arriving at the logger then empty the whole queue to the logfile if a trigger condition is reached (error/warning), even if it has debug level messages in the queue and the current level is set to info or something. Uses a little more memory but could be worth it. Only problem might be how to deal with out-of-time-sequence messages from older items in the queue. BTW, has anyone heard of using JMS for centralizd logging?
  10. JMS Logger[ Go to top ]

    There is/was JMS Appender in log4j. I contributed the original JMS appender, however I used a queue; when I last looked the log4j appender used a topic. Clearly using JMS for logging is heavy weight, but with appropriate filtering can be useful for centralised logging. Andrew
  11. Re: I like the concept[ Go to top ]

    If you also log audit information to the same file ("user X loaded document Y", "user Z saved document A", etc.) then a requirement for your app would be do do regular logging AND LogBag logging
    Interleaving logs for system operation and business activity is common, and plain wrong. It is also a common reason for why production systems logs on debug level. Most people just dont plan how they will log, where they will log it, and what they will log when designing the system. Instead it is left to the implementers, often with the assuring thought that "we are using the ultraflexible log4j so its just about configuration". Well, it is, but since most people associate the logger instance with the class *using" it, and many classes can log both system errors, *and* errors in application logic, as well as auditing information, configuration becomes a nightmare. The quick *solution* becomes debug all on and GB:s of log files. Personally, I prefer to log auditing to a database (usually the same as the rest of the business data since for many systems (banking, insurance, etc) audit trail is in fact business data), and the rest of the business log to a separate log file, reserving the server log for events that actually has something to do with the operation of the server.
  12. Re: I like the concept[ Go to top ]

    If you also log audit information to the same file ("user X loaded document Y", "user Z saved document A", etc.) then a requirement for your app would be do do regular logging AND LogBag logging


    Interleaving logs for system operation and business activity is common, and plain wrong. It is also a common reason for why production systems logs on debug level.

    Most people just dont plan how they will log, where they will log it, and what they will log when designing the system.
    Agreed. Designed logging is a deficiency in a lot of applications I see. But odd requirements, such as a single log *file* for all logging, does come up.


    Personally, I prefer to log auditing to a database (usually the same as the rest of the business data since for many systems (banking, insurance, etc) audit trail is in fact business data), and the rest of the business log to a separate log file, reserving the server log for events that actually has something to do with the operation of the server.
    At my location developers are not allowed to log to the server log. Database logging is ok but depending on logging volume and may require it's own machine (harder to get approval for and higher maintenance cost) or it will be a drag on the production database performance. And a lot of times you need a comprehensive timeline of events from both audit and error logs to figure out if an entry in one was caused by or affected by the other, so a merged logfile (even if it's not written merged but done post-write) is useful. Plus, sometimes you have a 'soft' audit, in other words it's not a business requirement but more of an activity log to see how people are interacting with the software. Any way you do logging, it should be well-thought out so that it's useful to the log users.
  13. Log parsing[ Go to top ]

    One quick method is to process the log file to zoom in on relevant log entries. For instance, a quick shell script to separate out entries by thread_id, which usually serves as the context_id for related log messages.
  14. Re: Log parsing[ Go to top ]

    One quick method is to process the log file to zoom in on relevant log entries. For instance, a quick shell script to separate out entries by thread_id, which usually serves as the context_id for related log messages.
    I hadn't really thought about thread_id as a context id. I'll have to try that out and see how it works. Our current cluster is all nodes on one server, but thread_id might not work if multiple servers are used. Plus, WebLogic (our app server) uses thread pools I believe, so you could potentially have multiple users logging with the same thread ids over time? I know there's lots of web server log parser UIs out there -- are there any of them or other similar tools for "generic" log files available? I guess if you have a delimited file you could use a spreadsheet tool if the log weren't too big. But a dedicated UI would be best.
  15. Logging entry in the Javapedia[ Go to top ]

    I added LogBag to the Javapedia: http://wiki.java.net/bin/view/Javapedia/Logging
  16. Other end of that approach[ Go to top ]

    I've gone the "other end" approach which is to log everything intiially but clean out the less important older ones on a schedule.. That way you have decreasing diagnostics ability the further back in time you go. e.g. up to 72 hours you have everything, after that you are missing the mostly useless information messages then eventually you lose the warns and errors as per the cycling of logging info. The platform I'm doing a lot of work with currently has the option to save all the resubmission data in the case of errors, errors and success or top level execution.. The idea being that you have debug/audit/resubmission ability if you are likely to need it, otherwise it doesn't take up DB space. regards, Nathan Lee