-
Notifications
You must be signed in to change notification settings - Fork 812
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
Add support for XXL-JOB #10421
Add support for XXL-JOB #10421
Conversation
7d3e9cb
to
53119af
Compare
instrumentation/xxl-job/xxl-job-1.9.2/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
instrumentation/xxl-job/xxl-job-1.9.2/javaagent/build.gradle.kts
Outdated
Show resolved
Hide resolved
.../io/opentelemetry/javaagent/instrumentation/xxljob/v1_9_2/GlueJobHandlerInstrumentation.java
Outdated
Show resolved
Hide resolved
...o/opentelemetry/javaagent/instrumentation/xxljob/v1_9_2/SimpleJobHandlerInstrumentation.java
Outdated
Show resolved
Hide resolved
...src/main/java/io/opentelemetry/javaagent/instrumentation/xxljob/v1_9_2/XxlJobSingletons.java
Outdated
Show resolved
Hide resolved
...t/java/io/opentelemetry/javaagent/instrumentation/xxljob/v1_9_2/SimpleCustomizedHandler.java
Outdated
Show resolved
Hide resolved
...agent/src/test/java/io/opentelemetry/javaagent/instrumentation/xxljob/v1_9_2/XxlJobTest.java
Outdated
Show resolved
Hide resolved
...ava/io/opentelemetry/javaagent/instrumentation/xxljob/common/XxlJobCodeAttributesGetter.java
Outdated
Show resolved
Hide resolved
...ntelemetry/javaagent/instrumentation/xxljob/common/XxlJobExperimentalAttributeExtractor.java
Outdated
Show resolved
Hide resolved
2. Found there is a bug in setting span status in 2.3.0+, so added a new module of xxl-job-2.3.0 to solve it.
closing and reopening to trigger checks |
* Rework xxl job instrumentation * simplify
...n/java/io/opentelemetry/javaagent/instrumentation/xxljob/common/XxlJobSpanNameExtractor.java
Outdated
Show resolved
Hide resolved
public String extract(XxlJobProcessRequest request) { | ||
GlueTypeEnum glueType = request.getGlueType(); | ||
if (SCRIPT_JOB_TYPE.contains(glueType.getDesc())) { | ||
return glueType.getDesc() + ".ID-" + request.getJobId(); |
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.
span names like GLUE(Shell).ID-2
don't follow general span naming guidelines outlined in https://github.com/open-telemetry/opentelemetry-specification/blob/v1.26.0/specification/trace/api.md#span the id portion should be removed from the span name.
GLUE(Shell)
feels a bit weird to me, but looking at the xxl-job doc I get the feeling that this is what the xxl-job ui displays. If that is the case then I think it is fine to keep it.
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.
span names like
GLUE(Shell).ID-2
don't follow general span naming guidelines outlined in https://github.com/open-telemetry/opentelemetry-specification/blob/v1.26.0/specification/trace/api.md#span the id portion should be removed from the span name.GLUE(Shell)
feels a bit weird to me, but looking at the xxl-job doc I get the feeling that this is what the xxl-job ui displays. If that is the case then I think it is fine to keep it.
It backs to discussion above. If we remove the id portion from spanName, it will cause no way to distinguish specific GLUE(Shell) job in system. Such as there are three Shell jobs, their jobIds are 1,2,3. Without jobId in spanName, they are same spanName in APM. it's hard for user to troubleshooting.
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.
@trask could you provide guidance on this. Should the job id be added to the span name (I guess it doesn't have a particularly high cardinality so perhaps a bit similar to http.route) or added as an attribute to to the span?
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.
@steverao can you help us understand the Job ID a bit better?
a couple of questions in particular,
- how does a user correspond a Job ID back to their workflow?
- is the Job ID stable, meaning a given workflow will always have the same job ID? or can a given workflow's job ID sometimes change over time?
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.
@steverao can you help us understand the Job ID a bit better?
a couple of questions in particular,
- how does a user correspond a Job ID back to their workflow?
- is the Job ID stable, meaning a given workflow will always have the same job ID? or can a given workflow's job ID sometimes change over time?
Sure, answers to related questions are as follows:
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.
is it possible to use the "Job description" instead of the "Job ID"? that looks more similar to existing span names for other instrumentations
I think the "Job description" is not good choose, because it has no restrictions on the input values, so jobs of the same type may have the same description.
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.
jobs of the same type may have the same description
is this common?
we could still capture job id as a span attribute (just doesn't seem to be the best span name, since span name is ideally more human readable)
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.
is this common?
yes
we could still capture job id as a span attribute (just doesn't seem to be the best span name, since span name is ideally more human readable)
ok, I understand it, but I have an alternative span name GLUE(Shell).{jobId}
, then we can add the relevant jobId to a non ExperimentalAttributeExtractor for script job. It's will be more friendly to users to find jobId in attribute. What do you think of this? @trask @laurit
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.
(sorry I haven't read the code) is the Job ID only included in span name for "GLUE" type jobs? what does the span name look like for other jobs? thanks
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.
(sorry I haven't read the code) is the Job ID only included in span name for "GLUE" type jobs? what does the span name look like for other jobs? thanks
In fact, the Job Id just be used in script job, such as Shell or Python script, they may not have method name. you can refer to #10421 (comment). Other jobs type are designed for java, so I can get their className and methodName, I use className.methodName
as span name. They look like CustomizedGroovyHandler.execute
. You can see more cases in relevant test code:) https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/10421/files#diff-46bda3c71cf5f790cba801eca4373fa35faebeebace4431b64c82695277a96a9
I communicated with @laurit today, considering the community release plan, we first use GLUE(Shell)
as span name and set a jobId in experimental attribute for script job in 2.2.0, I will restart a subsequent PR to discuss a better span name later.
Resolves #8084