Replies: 2 comments 1 reply
-
You misunderstand how statsd works. Statsd protocol in the way that you are publishing stuff to a known server. it does not However - we have a work in progress https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-49+OpenTelemetry+Support+for+Apache+Airflow to add open-telemetry support to replace the current statsd so statsd "exposing" is not likely to be anywhere close to do, rather than that you will be able to configure your own open-telemetry compliant stack. in any case , if you do feel addittional resources are needed, you are free to have your own chart and add airlfow one as a subchart - and I think that will be the recommended solution even in case we have open-telemetry. I don't think we are are going to "expose" the metrics in a different way than currently. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the clarification. I integrated ingress resource creation into my ci/cd pipeline ; as our (prometheus) setup is scraping endpoints using urls; meaning I needed a hostname for the statsd-service. However, I have seen airflow 2.7 is including some metric visualizations as part of the UI. |
Beta Was this translation helpful? Give feedback.
-
Depending on your stack it might be necessary to expose the statsD service to components outside of your cluster to gather your airflow metrics.
It would be useful to include this option under the ingress section of the the helm chart as currently you would need to create the ingress resource yourself.
Possibly something to add to the 1.10 helm chart milestone?
Started in discussion as it might not be a general requested feature in the helm chart.
Beta Was this translation helpful? Give feedback.
All reactions