**Description**


It would be great if the metrics we publish in Airflow change to include TAGs for "variable" parts of those (such as dag_id, task_id, pool name) rather than being part of the metrics.

See here: https://airflow.apache.org/docs/1.10.12/metrics.html, https://airflow.readthedocs.io/en/latest/logging-monitoring/metrics.html  - those variable parts should be tags.

We might consider to change those metrics by default in 2.0 and possibly introduce a backport in 1.10.13 to allow people to migrate.


**Use case / motivation**

Having the variable parts of the metrics makes it really difficult to aggregate the metrics. Seems that statsd python library does not support tags, but there are possible solutions by installing extensions:

https://stackoverflow.com/questions/49852654/sending-statsd-metrics-with-tags-from-python-client

**Related Issues**

<!-- Is there currently another issue associated with this? -->

self,
        unfinished_tis: Sequence[TI],
        finished_tis: list[TI],
        session: Session,
    ) -> tuple[bool, bool]:
        dep_context = DepContext(
            flag_upstream_failed=True,
            ignore_in_retry_period=True,
            ignore_in_reschedule_period=True,
            finished_tis=finished_tis,
        )
        
        
        return (
            any(ut.are_dependencies_met(dep_context=dep_context, session=session) for ut in unfinished_tis),
            dep_context.have_changed_ti_states,
        )
    def _emit_true_scheduling_delay_stats_for_finished_state(self, finished_tis: list[TI]) -> None:
        """
        This is a helper method to emit the true scheduling delay stats, which is defined as
        the time when the first task in DAG starts minus the expected DAG run datetime.
        This method will be used in the update_state method when the state of the DagRun
        is updated to a completed status (either success or failure). The method will find the first
        started task within the DAG and calculate the expected DagRun start time (based on
        dag.execution_date & dag.timetable), and minus these two values to get the delay.
        The emitted data may contain outlier (e.g. when the first task was cleared, so
        the second task's start_date will be used), but we can get rid of the outliers
        on the stats side through the dashboards tooling built.