azure-functions-durable-python: Activity traces cannot be linked to an Orchestrator
I have an Azure Durable Functions app using Python. It’s a very simple model, where an orchestrator just schedules one activity.
There is some logging going on inside my activity functions, but I’m currently not able to join them to any orchestrator who could have called it.
The tracking data for a single instance can be found using a relatively simple Kusto query, such as:
let targetInstanceId = "ddd1aaa685034059b545eb004b15d4eb";
let start = datetime(2018-03-25T09:20:00);
traces
| where timestamp > start and timestamp < start + 30m
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = customDimensions["prop__functionName"]
| extend instanceId = customDimensions["prop__instanceId"]
| extend state = customDimensions["prop__state"]
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend sequenceNumber = tolong(customDimensions["prop__sequenceNumber"])
| where isReplay != true
| where instanceId == targetInstanceId
| sort by timestamp asc, sequenceNumber asc
| project timestamp, functionName, state, instanceId, sequenceNumber, appName = cloud_RoleName
Although this displays the orchestrator as well as the current activity state, it doesn’t include activity logging from my Python app.
I can find the logging using another simple kusto query:
let start = datetime(2020-09-23T09:50:00);
traces
| where operation_Name == 'NAME_OF_MY_ACTIVITY'
| where timestamp >= start and timestamp < start + 30m
| limit 20
This does in fact yield my logging, but doesn’t provide me with any clues to which orchestrator instance this activity “belonged”:
customDimensions['prop__instanceId']
is emptyoperation_ParentId
points to theid
inside therequests
table- … which is where the trail ends
So basically I see the two pieces:
- Orchestrator on the one side, with activity status but without activity logging
- Activity logging on the other side, without any clues (as far as I can see) how to link this to the accompanying orchestrator
It would be great if these two could be linked together. An example how I expected it to work (but I might be mistaken) is that prop__instanceId
is available inside the activity-level traces
(or requests
) logging as well.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (2 by maintainers)
Adding @bachuv who is going to be taking a deeper look at our distributed tracing support.
Thanks @davidmrdavid , that was clarifying! I made the changes in our dev environment, and it seems to have had effect!
Hi @epa095, I apologize for the confusion.
In general, Distributed Tracing is still considered a
preview
feature so it’s not ready yet for production usage across all Durable Functions PLs: C#, JS, Python, etc. That said, some of its functionality may already be working in Python, which is why @bachuv linked the documentation above. I realize the docs are technically in the durable-extension repo (C#) but the instructions should apply insofar as modifying thehost.json
andlocal.settings.json
steps go. Once the feature is GA’ed, we will have documentation specifically for non-C# languages, but currently this is considered an advanced use case due to it being preview and so the instructions above are all we currently have pre-written. That said, if you’re trying to unable this scenario with Python, and having issues, we can certainly discuss this and guide you through the steps!