logFaces – Enterprise Logging Suite

Discussions

News: logFaces – Enterprise Logging Suite

  1. logFaces – Enterprise Logging Suite (10 messages)

    Built on top of Apache Logging Services, logFaces is addressed to system integrators, testers, field support and developers. Here are the main features at a glance: • Out-of-the-box log server • Centralized log data sink; many sources, one storage, one point of access • Multiple remote users and personalized environment. • Native and simple user interface (based on Eclipse RCP) • No more hassle with log files; make them yourself as you like it and when you need them • Too much log? Slice it, cut it and view the relevant data in real-time • Find problems quickly (you define what the problem is) • Query and drill down • Schedule and receive log data reports by e-mail • Easy integration with existing systems • Currently available for Windows (win32) and Linux (gtk x86) • Light personal viewer-only edition available. For more information go to http://www.moonlit-software.com

    Threaded Messages (10)

  2. Now I have seen it all.
  3. Integration[ Go to top ]

    Can I use it with slf4j, common-logging, and log4j, all in the same webapp? We like to use as many logging layers as we can for...umm...flexibility, yeah, that's it. (In reality, I understand that this is a network logging server and as such has a completely different set of requirements, but I wanted to get the "complain about too many logging choices" comment out of the way.)
  4. sure..[ Go to top ]

    Can I use it with slf4j, common-logging, and log4j, all in the same webapp? We like to use as many logging layers as we can for...umm...flexibility, yeah, that's it.

    (In reality, I understand that this is a network logging server and as such has a completely different set of requirements, but I wanted to get the "complain about too many logging choices" comment out of the way.)
    Yes, you can use slf4j and commons-logging, these are just an adapters (or facades, whatever ppl call them). Down the road what we need to happen is that your log statements go through conventional log4j socket appenders - either TCP or UDP. And yes, it will work with web apps. With logFaces you could actually differentiate one web application log stream from the other.
  5. No open source edition?[ Go to top ]

    There's no free edition at all as far as I can see. The product looks good at first glance, but I want an open source version :)
  6. thinking about it[ Go to top ]

    There's no free edition at all as far as I can see. The product looks good at first glance, but I want an open source version :)
    Actually there was an idea to have a community edition, but then I thought that open source doesn't really need stuff like this. It's not a library or a framework. It's more of an integrated solution to be used in commercial products. However, if I am wrong and open source projects will ask for a free edition, there shouldn't be a problem. I just have to figure out the formalities and how to qualify who gets the free license. Any ideas how it's done ?
  7. Re: thinking about it[ Go to top ]

    I think the world is craving for just this, integrated open source solutions, right now. Real end users as well, not other open source projects. I guess I'm biased though, writing open source code and working selling support for it. I'd check out how other companies are working with community editions, there's lots of them out there. Cheers, Tomas
  8. Re: thinking about it[ Go to top ]

    Actually this is way cool. Try having to support 30 + applications deployed on various servers, when all you have to do is view everything from one location. I don't see why people have to complain of "yet another log framework" when this tool is a log aggregation. You could role out your own using socket apenders or JDBC appenders or you could use this. By the way this product is screaming to be built for Terracotta or GigaSpaces or what you have. Like this you can deploy multiple instances of the log server and they can all share the log data. You would also probably need to write your own apender to do the load balancing between the instances. Et voila! Instant high availability.
  9. Thank you for the feedback![ Go to top ]

    Actually this is way cool. Try having to support 30 + applications deployed on various servers, when all you have to do is view everything from one location.

    I don't see why people have to complain of "yet another log framework" when this tool is a log aggregation. You could role out your own using socket apenders or JDBC appenders or you could use this.

    By the way this product is screaming to be built for Terracotta or GigaSpaces or what you have. Like this you can deploy multiple instances of the log server and they can all share the log data. You would also probably need to write your own apender to do the load balancing between the instances. Et voila! Instant high availability.
    Razma Tazz, thank you for the great feedback! Yes, the main idea was to allow many applications share the same data sink and most importantly - get a quick access to any instance's log in real time or through queries. This version is kind of a debut for a wide audience.. but I like the idea of Terracotta, makes it all nice and scary :)
  10. Tightly coupled?[ Go to top ]

    If the log server goes down, how does it affect all applications using it? Is there a way to have the applications log locally, i.e. to a file, and have a LogFaces thread reading the file and adding the statements in the log file to the central server? Cheers, Ricky
  11. Re: Tightly coupled?[ Go to top ]

    If the log server goes down, how does it affect all applications using it?

    Is there a way to have the applications log locally, i.e. to a file, and have a LogFaces thread reading the file and adding the statements in the log file to the central server?

    Cheers,
    Ricky
    Your application can always log locally with or without you using logFaces server. When server goes down, the socket appender on the application side (log4j actually) will periodically re-try the connection. But, you are right, lost log statements won't get into the server and currently there is no way to fill such gap. What we can do is to have user manually import local log files into the server. Could be a good idea for the next release, thanks for the tip :)