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.
|
11/28/2016 2:48:12 PM
from DB (#834)
Let the exception from JSON decode method to throw and catch it in the caller where more information is available to be logged. This whay it is easier to identify which project is having this issue from logs.
|
|
|
11/23/2016 10:07:00 PM
Option to create Kafka Appender for user job logs (#778)
JobRunner now checks for properties in jobs to check if Kafka logging is
enabled. If it is, then it will attempt to create a Kafka appender. If
that fails, it will report the failure but not crash the application.
User side:
A basic example usage of this would be to drop a properties file (named maybe like kafka.properties) with the following lines into the root directory of your project:
azkaban.job.logging.kafka.enable=true
This property should cause all the jobs in your project to log to Kafka, using a producer provided by the executor server. Note that the executor server can override this property and refuse to provide this producer.
The property azkaban.job.logging.kafka.enable is by default false, so if left alone, the default behavior is to not log to Kafka.
Server admin side:
There are two properties to configure the Kafka producer that would be used as a logger for user jobs and they can be set in azkaban.properties. They are:
azkaban.server.logging.kafka.brokerList
azkaban.server.logging.kafka.topic
If any of these two properties are missing, then the executor server will refuse to attempt to make the producer. This can doubly act as a killswitch if the server admins decide they don't want anyone logging to Kafka, or don't have a Kafka cluster set up.
If during the creation of the Kafka logger, something wrong happens, then we will fail silently (not crash the app), and report the failure in the flow log.
* Refactored Constants.java into separate files and added new constants
Added some configuration strings into the Constants.java file. These
configurations specify properties to manage user job Kafka logging, as
well as job and flow level properties.
* Added server props object to job and flow runners
Changed job and flow runner objects to have a copy of the Azkaban
Executor server properties, so that when running flows we can activate
server wide configurations.
As a result, a bunch of tests had to be altered.
|
11/23/2016 5:24:37 PM
(#827)
* fixSoloServerExecuteAsUser
* Updated file path to be consistent with current plugin configuration
|
11/23/2016 12:18:38 PM
adding necessary logs to help trace and debug issues
* log stack trace to logger
|
