Azure Failures

[mike-england]

• Package Name: azure-monitor-opentelemetry
• Package Version: 1.3.0
• Operating System: Debian (bookworm)
• Python Version: 3.10

Describe the bug
I'm worried I'm opening up an old 'bug': #33741 but I'm still having problems with Failures being reported to Azure Application Insights. The opentelemtry-python-contrib project has updated to include support for Flask 3 (version 1.23.0/0.44b0) and I can confirm that it's working as expected. However, when I include OTEL_PYTHON_EXCLUDED_URLS to keep one of my endpoints from reporting, they're still showing up as a request and a failed one

To Reproduce
Steps to reproduce the behavior:
I'm going to include some sample code in a docker file that you can try:

app.py:

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

import flask

app = flask.Flask(__name__)

@app.route("/")
def test():
    print('got one')
    return "Test flask request"

@app.route("/health")
def health():
    print('health endpoint')
    return "Health request"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Dockerfile:

FROM python:3.10-slim

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

COPY requirements.txt .
RUN python -m pip install -r requirements.txt

WORKDIR /app
COPY . /app

RUN adduser -u 5678 --disabled-password --gecos "" appuser && chown -R appuser /app
USER appuser

CMD ["python", "app.py"]

requirements.txt:

Flask==3.0.0
azure-monitor-opentelemetry==1.3.0

And to run it:

docker build -t azuretelemetry . && docker run --rm -p 8080:8080 -e APPLICATIONINSIGHTS_CONNECTION_STRING=$APPLICATIONINSIGHTS_CONNECTION_STRING -e OTEL_EXPERIMENTAL_RESOURCE_DETECTORS=$OTEL_EXPERIMENTAL_RESOURCE_DETECTORS -e OTEL_PYTHON_EXCLUDED_URLS=$OTEL_PYTHON_EXCLUDED_URLS azuretelemetry

Where OTEL_PYTHON_EXCLUDED_URLS="health,swagger.*"

Expected behavior
Endpoint requests are ignored

Screenshots

Any suggestions? Is this a different project that would need to take care of this? Am I doing something wrong?

[kashifkhan]

Thank you for the feedback @mike-england . We will investigate and get back to you asap.

[jeremydvoss]

I'll be looking into this.

[jeremydvoss]

I've confirmed that the OTEL_PYTHON_EXCLUDED_URLS works as intended with full URLs, URL endings, and even wildcards. This is a question for the Flask instrumentation itself. So, I recommend creating an issue in the OTel contrib repo instead. But, let's see if we can solve it here. can you provide the full urls of the telemetry that you want to be filtered? could you also confirm that the environment variable is successfully being set in docker and visible from the app?

[mike-england]

Thanks for looking into this Jeremy. I can confirm the variables being set: # env OTEL_PYTHON_EXCLUDED_URLS=health,swagger.* OTEL_EXPERIMENTAL_RESOURCE_DETECTORS=azure_app_service I'm accessing my localhost endpoint: http://localhost:8080/health I can also confirm that the requests are not showing under the operation name, they just show as these phantom "None" response codes. Are you able to run the docker image and code I sent? Maybe there's something different about my azure app insights setup?

…

On Wed, Mar 6, 2024 at 3:02 PM Jeremy Voss ***@***.***> wrote: I've confirmed that the OTEL_PYTHON_EXCLUDED_URLS works as intended with full URLs, URL endings, and even wildcards. This is a question for the Flask instrumentation itself. So, I recommend creating an issue in the OTel contrib repo <https://github.com/open-telemetry/opentelemetry-python-contrib/issues> instead. But, let's see if we can solve it here. can you provide the full urls of the telemetry that you want to be filtered? could you also confirm that the environment variable is successfully being set in docker and visible from the app? — Reply to this email directly, view it on GitHub <#34616 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJIQJCU2AXXKWGSQZ76ICWDYW6N6TAVCNFSM6AAAAABEGEK3XOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBSGAYDCNZXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jeremydvoss @lzchen.

[annatisch]

Hi @jeremydvoss - if I'm following this correctly, it looks like this isn't an issue with the Azure components specifically. Can this be closed or is there still work for us to do in relation to this issue?

[mike-england]

For the record, this still shows up a lot in our azure telemetry. Has anyone tried the docker images I included to reproduce the issue?