xBis7 commented on code in PR #69633: URL: https://github.com/apache/airflow/pull/69633#discussion_r3559096724
########## shared/observability/src/airflow_shared/observability/traces/__init__.py: ########## @@ -60,10 +60,11 @@ def generate_trace_id(self): TASK_SPAN_DETAIL_LEVEL_KEY = "airflow/task_span_detail_level" DEFAULT_TASK_SPAN_DETAIL_LEVEL = 1 TRACE_SAMPLED_KEY = "airflow/trace_sampled" +PARENT_TRACE_CONTEXT_KEY = "airflow/parent_trace_context" Review Comment: I mean that the current code is developed around tracing a dag_run but what if we want to add traces that aren't related to a dag_run? I've been playing with traces for each scheduler iteration <img width="4112" height="2336" alt="image" src="https://github.com/user-attachments/assets/67868f0c-16d0-4a4e-a7a5-528bb5c68755"; /> and I think that in the future it might be very useful for debugging and improving performance, to add other traces for multiple internal operations. This comment isn't related to the current changes but it's for making things more clear for future developers adding more instrumentation. Right now, we have ``` trace-dagrun1 trace-dagrun2 trace-dagrun3 ``` but what if we have ``` trace-dagrun1 trace-scheduler_loop_iteration1 trace-dagprocessor_process_file trace-triggerer_loop_iteration1 trace-executor_heartbeat ``` all these other traces might follow a different approach for adding a parent context key, if they need one at all. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
