-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose jobVersion, jobJarUrl as part of RuntimeTask interface #689
expose jobVersion, jobJarUrl as part of RuntimeTask interface #689
Conversation
@@ -33,4 +33,9 @@ void initialize( | |||
UserCodeClassLoader userCodeClassLoader); | |||
|
|||
String getWorkerId(); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer we do not add specific metrics/metadata into these entry-interfaces. can you elaborate on why it's on the runtimeTask for metrics instead of using regular metrics collector tagging? I feel like there are existing metrics path to do this without adding into this interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Andyz26 thanks for the review!
can you elaborate on why it's on the runtimeTask for metrics instead of using regular metrics collector tagging?
The job metadata is only available as part of the job submission, not the actual running job itself. From my understanding, we need to hook into the task/job submission to get information like version. Right now, we have written our own AgentMain class, and we can hook into the TaskExecutor onTaskStarting
to add custom job labels, like the scaffolding that exists here:
mantis/mantis-server/mantis-server-agent/src/main/java/io/mantisrx/server/agent/AgentV2Main.java
Line 59 in c1c7f34
public void onTaskStarting(RuntimeTask task) {} |
Given the context above, do you have a recommendation for a better place to make this change? Happy to move things around, it's possible I've missed a better metrics path when going through the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo since agent to inner task is not always 1 to 1 it would be more consistent to construct such metrics within the worker runtime where you have access to things like MetricsRegistry (I don't know how your current metrics integration is done into with this one).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it, thanks for the feedback! are you opposed to adding jobVersion
to the ExecuteStageRequest
? I think we'll need it to capture the jobVersion
on the worker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above.
39b131f
to
eb10be1
Compare
@@ -239,4 +239,5 @@ protected Observable<Status> getStatus() { | |||
public String getWorkerId() { | |||
return executeStageRequest.getWorkerId().getId(); | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove blank line
Context
Expose
jobVersion
,jobJarUrl
as part of RuntimeTask interface.This allows us to add version and sha labels to our job metrics. We'd like these metric labels so we can monitor our automated job deploys.
Checklist
./gradlew build
compiles code correctly./gradlew test
passes all tests