Camunda Pyzeebe Instrumentation #1385
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1385 +/- ##
==========================================
- Coverage 81.57% 81.01% -0.56%
==========================================
Files 205 206 +1
Lines 23217 23346 +129
Branches 3670 3697 +27
==========================================
- Hits 18939 18914 -25
- Misses 3055 3168 +113
- Partials 1223 1264 +41 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
newrelic/hooks/external_pyzeebe.py
Outdated
| async def wrapper(wrapped, instance, args, kwargs): | ||
| txn = current_transaction() | ||
| if txn: | ||
| add_fn = add_custom_span_attribute |
There was a problem hiding this comment.
To add the new pyzeebe attributes, you may want to check out the add_agent_attribute function for this rather than adding these as custom attributes. Here are some examples of its use in other places within the agent: http://github.com/newrelic/newrelic-python-agent/blob/main/newrelic/hooks/messagebroker_kombu.py#L204 https://github.com/newrelic/newrelic-python-agent/blob/main/newrelic/hooks/messagebroker_kafkapython.py#L145. You will also want to add all of these new pyzeebe attributes into this set: https://github.com/newrelic/newrelic-python-agent/blob/main/newrelic/core/attribute.py#L43
There was a problem hiding this comment.
@umaannamalai - I tried using add_agent_attribute and it yields undesired behavior when adding those attributes in the existing txn if block. It will add them to the parent span instead of each of the individual FunctionTrace spans (i.e - run_process, deploy_resource, etc). What is your recommendation to achieve stamping those attributes on each individual span? Below is an example screenshot where those client methods are called inside a main() function that is annotated with @newrelic.agent.background_task()
There was a problem hiding this comment.
@umaannamalai - following up here
| return result | ||
| else: | ||
| # add_fn = add_custom_attribute | ||
| created_txn = BackgroundTask(application=application_instance(), name=method_name, group="ZeebeClient") |
There was a problem hiding this comment.
We actually will want to avoid starting a background task here and stick to only using function tracing for these client methods. This wrapper can be edited to early exit out if no transaction is found. If one is found, then the above function tracing logic should make sense to keep.
There was a problem hiding this comment.
@umaannamalai - not sure on this - how would the client methods get picked up then if no current transaction exists? I tested only using FunctionTrace in the following scenario, and no data is picked up if the method where the client methods being called inside is not annotated (instrumented). I think part of the goal of the instrumentation is to allow customers to collect tracing for these methods without having to manually instrument.
Example (not picked up without using BackgroundTask):
async def main():
...
zeebe_client = ZeebeClient(grpc_channel)
await zeebe_client.deploy_resource('send-mail.bpmn')
asyncio.run(main())
| task_type = getattr(job, "type", None) or "UnknownType" | ||
| txn_name = f"{process_id}/{task_type}" | ||
|
|
||
| with BackgroundTask(application_instance(), txn_name, group="ZeebeTask"): |
There was a problem hiding this comment.
We may want to swap the background task here with an actual WebTransaction.
There was a problem hiding this comment.
Pyzeebe Workers/Tasks communicate via gRPC and are basically asyncio background tasks - wouldn't BackgroundTask be the appropriate type to use here?
This PR adds support for the Camunda Pyzeebe Module
@worker.task/@router.taskNeed help with writing some tests for this instrumentation though