
|
If you were logged in you would be able to see more operations.
|
|
|
|
Rio needs provide a better way to deal with the logs that services produce, by providing a way to easily aggregate the various log files so they can be viewed and analyzed. The requirements here surround both running systems as well as deployments that may only be temporary (such as distributed test case execution). For the latter, including the log files from the distributed collection of services that made up the test case as part of the produced report can be fairly important, especially if the test case fails. For the former, being able to consolidate the logs for a running system is also important. Having all the log files taken as a snapshot of the system allows for more effective analysis. Unless of course you consider ssh to each machine and running tail is what you call fun :)
Other options for log harvesting would be to develop a 'network logger', that would basically take log records and write then to a centralized logging service as logging occurs. Although this could be buffered, IMO this adds way to much network traffic and overhead. Consider a distributed system composed of 50+ services, all pushing log records to a logging service.
Options for distributed log viewing can also be done by attaching to a specific service's JVM and streaming log records. This may meet the requirement to view a running system's logs, but for the requirement to be able to view things like test case logs we fall short. Also, I have the concern of overhead. For a system that logs alot, the network overhead may be an issue here as well.
|
|
Description
|
Rio needs provide a better way to deal with the logs that services produce, by providing a way to easily aggregate the various log files so they can be viewed and analyzed. The requirements here surround both running systems as well as deployments that may only be temporary (such as distributed test case execution). For the latter, including the log files from the distributed collection of services that made up the test case as part of the produced report can be fairly important, especially if the test case fails. For the former, being able to consolidate the logs for a running system is also important. Having all the log files taken as a snapshot of the system allows for more effective analysis. Unless of course you consider ssh to each machine and running tail is what you call fun :)
Other options for log harvesting would be to develop a 'network logger', that would basically take log records and write then to a centralized logging service as logging occurs. Although this could be buffered, IMO this adds way to much network traffic and overhead. Consider a distributed system composed of 50+ services, all pushing log records to a logging service.
Options for distributed log viewing can also be done by attaching to a specific service's JVM and streaming log records. This may meet the requirement to view a running system's logs, but for the requirement to be able to view things like test case logs we fall short. Also, I have the concern of overhead. For a system that logs alot, the network overhead may be an issue here as well. |
Show » |
|
The file copy happens only when requested, allowing a client (automated or user driven) to collect all service log files on demand.