12/15/2016 8:36:49 PM
(#852)
URLs, which are referenced by names known as a "topic" are specified in
azkaban.properties
For example if you want an external URL under the topic of
"arbitraryName", you would put the following line into
azkaban.properties:
azkaban.server.external.arbitraryName.url=http://someURL.com
Additionally, an external log viewer can then be specified using the
parameter azkaban.server.external.logviewer.topic=arbitraryName
This line would reference the URL specified earlier in this description
(http://someURL.com) as an external log viewer.
A similar behavior has been added for specifying external analyzers, ie.
azkaban.server.external.analyzer.topic=arbitraryName
Note that this commit is NOT backwards compatible and deprecates the
mechanism created in (#657). That commit specifies external analyzers
with the config
execution.external.link.url=http://someURL.com/?%url
This must now be specified as
azkaban.server.external.arbitraryName.url=http://someURL.com/?${url}
azkaban.server.external.analyzer.topic=arbitraryName
|
12/14/2016 6:49:50 PM
(#854)
When we use the log4j Kafka appender, it seems that the appender
simply does not log the stack trace anywhere. Seeing as the stack trace is a very important piece of information, we create our own PatternLayout class that appends the stack trace to the log message that reported it, so that all the information regarding that error can be found one in place.
|
12/12/2016 11:25:38 PM
are being filled with this message without apparent reason.
Removing this will increase readability of logs.
|
12/12/2016 6:12:12 PM
override change
|
12/9/2016 7:39:33 PM
info (#848)
|
12/5/2016 6:51:29 PM
3.12.0
under utils that will tie out and err to log4j. This
class does this in the main functions of AzkabanWebServer and
AzkabanExecServer, so that all out going messages will be caught by
log4j.
|
12/2/2016 8:48:44 PM
(#828)
* bring dropwizrd Metrics to AZ to get a better monitoring feature
|
12/1/2016 6:40:01 PM
3.11.0
current LI build infrastructure generates version field in a lazy fashion. More specifically, the version value is not immediately available during the root project configuration phase. While this works seamlessly in the open source build, it generates incorrect version number in the jar manifest. Solution was to simply make this configuration lazy using afterEvaluate.
|
11/30/2016 12:28:26 AM
is allowed to perform deletion of projects
This is the prequisite of making project directory as shared among multiple deployments
|
11/28/2016 3:01:16 PM
3.10.0
error output to a log file correctly (#833)
Previously the error output was still sent to the stdout.
|
