• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question for the experts!

 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Topic: Distributed applications using a central log
Setup: Multiple app-servers, may or may not be on the same machine. Multiple applications, may be unique per app-server, or may be duplicated on each one.
Reason: Centralize log(s) to make adminstration (monitoring) easier. Can also do so in real-time without having to merge multiple log sources.
Question: For each situation, what would be the best method to connect to and use a central log file, or set of log files (for example, one per application, or one per arbitrary application group).
My Thoughts: Use either RMI or HTTP posts to send all log messages to one of the app-servers, to one web application (.war) that does only logging (to database, file, whatever) that synchronizes writes. The biggest issue is performance, next being log integrity, and finally logging service "discovery" (JNDI? Hardcoded URL? ??). At this time I'm not using EJBs, but could do so in the future. I just need to get something up quickly without climbing the EJB curve.
Thanks for your answers and comments!
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My Thoughts.
Your situation is one of kind that is not REALLY possible to think practical.But if you have one, best bet is NOT to have a centralised logging mechanism as apposed to logs in their respective servers(since apps being diff).
While logging is an perf issue by itself, across the wire(network) will be an over-kill.In such a scenario,the maintenance will not actually be a easy-thing and in fact it will be a nightmare to dissect info that pertains to a particular app in a specifice app-server.
Thanks
Raj
 
Gerry Giese
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Raj,
Thanks for the comments. I may have left the question open a little too much. Right now, I'd dealing with a single app server that runs multiple containers (4 at the moment). Each applications deployed to the server will be copied to each of the containters. Error messages are currently showing up in 4 separate log files as determined by the application server. In the future we may have another server locally (probably less than 10 feet away), but also possibly have one in another city altogether.
I'm needing something to start off with for this single machine/multiple containers. None of the remote calls should go across the network, but once they begin to, it will be a VERY high-speed link. The other city will probably have to manage it's own logs locally using configuration, but the local "cluster" ("farm"?) will sure be a pain to monitor if we have 8+ log files to check and no easy way to see a consolidated time-sequential view of what's going on in real-time. I wish we could use a database, but for various reasons we can't at this time, so we're using files.
One thing we were also hoping to do is have a single time-sequential log file per deployed application, despite the fact that 4 copies of the app are running at any one time. We would probably want to try and keep a master log (everything lumped together), too, for a server admin, then let each developer who owns his app view his own log file. We could use filters, but with some of the logs estimated growth statistics, that would be a performance drain (trade off of log entry performance vs. log-viewing performance that might affect running apps).
We're still learning how to deal with this "enterprise" solution, so thanks for bearing with me - I appreciate your comments!
 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is a good idea to have a centralized log file. Just make sure you log the right things. i.e. no abuse. Actually I suggest having 3 log files (stdout, stderr and the centralized one for critical errors) As far as the implementation goes, hard to tell which one is best. the one I've used was programmed as a client/server solution using a protocol over TCP/IP. you can have a pool of logger clients in each appserver each with it's own connection to the logger server. RMI can be good too (easier to maintain) but might lead to poor performance.
Also try to see if something already exists in the free software world.
 
Gerry Giese
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also had another question regarding logging. Since the applicaiton log files will be a shared resource in the java code (logging class stored in ServletContext), what is the best way to protect it? I know it should probably be made thread-safe, but what's the best way to do it? Synchronize on the file, the method doing the writing, the class, where?
At the moment I'm planning on having a factory class that will allow multiple logger types to be registered with it, but maintaining only one copy of each logger type (singleton?). I know the factory needs to be a singleton, but does each logger type need to be singleton as well? The only time you can get a refernece to a logger type is by asking the factory for one, and it makes sure that only one logger is registered for each type (by logger class name).
To those who talk about poor performance using RMI, do you have any good alternate suggestions? Or are there ways to speed it up like compressing the messages before sending, or would the compression CPU overhead outweigh the network transmission cost?
Last, any suggestions for file-writing optimization for performance? Anyone have any good thread-safe file-writing code that screams? It's all simple text output.
Thanks all you experts out there!
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've never actually tried to use it remotely, so I can't tell you if it is fit for this purpose or not, but Log4J is an all-singing all-dancing logging framework that supports, among other things, logging to a remote logging server. It might be worth a look.
- Peter
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you can find a product that fits the bill use a product, unfortunately I do not know of one.
If yoy have to or want to develop something have you thought of using messaging (JMS) to handle the communication between apps and logging. If you do not require synchronous confirmation that the log is written then it would improve performance as basically each app would fire the log message off to the log server and not need to wait.
Phil
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Upcoming JDK 1.4 also provides a comprehensive logging API with differnt handlers, like MemoryHandler, ConsolerHandler, FileHandler and SocketHandler. For remote logging server, a SocketHandler should fit in best.
reply
    Bookmark Topic Watch Topic
  • New Topic