Issue #2359 updated readme with bscalio suggestions

Change-Id: I25356e9c6e89473a5442ca1bfdab29b41a996694

Former-commit-id: e2c9407815 [formerly 90a7339f6d] [formerly b08d9d4932 [formerly 2c9c6f8aee77f96911d698bc2031af5e01f03ee0]]
Former-commit-id: b08d9d4932
Former-commit-id: 3f4c9a1d05
This commit is contained in:
Nate Jensen 2014-01-22 17:06:43 -06:00
parent 848f36f88d
commit 2b54a41e8d
2 changed files with 34 additions and 2 deletions

View file

@ -200,8 +200,9 @@
<logger name="com.raytheon">
<level value="INFO"/>
</logger>
<logger name="com.raytheon.edex.plugin.shef">
<logger name="com.raytheon.edex.plugin.shef" additivity="false">
<level value="INFO"/>
<appender-ref ref="ShefLog" />
</logger>
<logger name="com.raytheon.edex.services.ArchiveSrv">
<level value="WARN"/>

View file

@ -36,6 +36,9 @@ the tar.gz file. Next go into the conf directory and modify config.xml to
the default. Once your config settings are right, run the bin/logsrv.sh
script to start the log service.
Setup of Client Processes
------------------
At this point the log service is running but nothing is reporting to it. You
can configure any Java process using logback to report to it, but with the
current version that is just EDEX and CAVE. (Note technically you could
@ -73,7 +76,8 @@ the tar.gz file. Next go into the conf directory and modify config.xml to
in receiver.xml. You can alter the threshold if need be.
Next you must add your new remoteLogSrv appender to a logger. Note that a
logger can have multiple appenders. For EDEX, the recommendation is to add
logger can have multiple appenders, but any logger with additivity="false" will
not go through the root log. For EDEX, the recommendation is to add
it to the root logger. For example:
<root>
@ -111,6 +115,33 @@ everything configured even if the log service or the reporting processes are not
running.
Impacts
-------------
The log service has very little overhead. The appenders, as configured, will be just
another appender so the "normal" logs will continue to function as usual. With the
threshold configuration, only WARN and ERROR messages are sent to the log
service. All of this is done asynchronously so the processing threads that logged
a message will not wait for the message to get sent. Messages sent to the
service are sent over TCP and are buffered. As long as the network path to
the log service is not slower than the rate at which the WARN or ERROR messages
are produced, you should not notice any slowdowns or impacts due to processes
reporting to the log service.
Of course, the less an application produces WARN or ERROR messages, the less
overhead. And the reporting can always be disabled by undoing the modifications
to logback configuration files specified in the setup instructions. Again, if you
disable reporting to the log service, you do not need to restart the Java process.
More information
--------------
For more information about the socket appender, please see
http://logback.qos.ch/manual/appenders.html#SocketAppender
For more information about logback configuration files, please see
http://logback.qos.ch/manual/configuration.html#syntax
Bugs and/or Improvements
--------------
If you encounter a bug with the log service or have an idea of how it can be