Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error with logging instrumentation - AttributeError: 'ProxyTracerProvider' object has no attribute 'resource' #810

Closed
mvkrishna86 opened this issue Nov 12, 2021 · 9 comments · Fixed by #890
Labels
bug Something isn't working

Comments

@mvkrishna86
Copy link

Describe your environment

LoggingInstrumentor().instrument() is throwing an error

Traceback (most recent call last):
  File "manage.py", line 30, in <module>
    main()
  File "manage.py", line 14, in main
    LoggingInstrumentor().instrument(set_logging_format=True)
  File "/home/vamsikrishnam/otel/lib/python3.8/site-packages/opentelemetry/instrumentation/instrumentor.py", line 109, in instrument
    result = self._instrument(  # pylint: disable=assignment-from-no-return
  File "/home/vamsikrishnam/otel/lib/python3.8/site-packages/opentelemetry/instrumentation/logging/__init__.py", line 81, in _instrument
    resource = provider.resource if provider else None
AttributeError: 'ProxyTracerProvider' object has no attribute 'resource'

Steps to reproduce
Below packages installed and trying to instrument with below two lines:

LoggingInstrumentor().instrument(set_logging_format=True)
DjangoInstrumentor().instrument()

(otel) vamsikrishnam@NHHYDL-00217:~/django$ pip list | grep opentele
opentelemetry-api                      1.7.1
opentelemetry-exporter-otlp            1.7.1
opentelemetry-exporter-otlp-proto-grpc 1.7.1
opentelemetry-exporter-otlp-proto-http 1.7.1
opentelemetry-instrumentation          0.26b1
opentelemetry-instrumentation-django   0.26b1
opentelemetry-instrumentation-logging  0.26b1
opentelemetry-instrumentation-wsgi     0.26b1
opentelemetry-propagator-b3            1.7.1
opentelemetry-proto                    1.7.1
opentelemetry-sdk                      1.7.1
opentelemetry-semantic-conventions     0.26b1
opentelemetry-util-http                0.26b1

What is the expected behavior?
What did you expect to see?
logging should be instrumented properly.

What is the actual behavior?
What did you see instead?
logging should be instrumented properly and populate the otelTraceID and otelSpanID in the logs.

Additional context
Add any other context about the problem here.

$ python3 --version
Python 3.8.10

manage.py:

#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys
import logging
from opentelemetry.instrumentation.django import DjangoInstrumentor
from opentelemetry.instrumentation.logging import LoggingInstrumentor


def main():
    """Run administrative tasks."""
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'django_project.settings')
    logging.basicConfig(level = logging.DEBUG)
    LoggingInstrumentor().instrument(set_logging_format=True)
    DjangoInstrumentor().instrument()
    # LoggingInstrumentor().instrument(set_logging_format=True,log_level=logging.DEBUG)

    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == '__main__':
    main()
@mvkrishna86 mvkrishna86 added the bug Something isn't working label Nov 12, 2021
@mvkrishna86 mvkrishna86 changed the title error with logging instrumentation error with logging instrumentation - AttributeError: 'ProxyTracerProvider' object has no attribute 'resource' Nov 12, 2021
@owais
Copy link
Contributor

owais commented Nov 12, 2021

You need to set up the SDK and tracing pipeline before you can use any instrumentors. Please refer to this: https://opentelemetry-python.readthedocs.io/en/latest/getting-started.html

@owais
Copy link
Contributor

owais commented Nov 12, 2021

provider = TracerProvider()
processor = BatchSpanProcessor(ConsoleSpanExporter())
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

@ocelotl
Copy link
Contributor

ocelotl commented Nov 12, 2021

You need to set up the SDK and tracing pipeline before you can use any instrumentors. Please refer to this: https://opentelemetry-python.readthedocs.io/en/latest/getting-started.html

This is right, but we should not fail like this (with an attribute error) if SDK or tracing has not yet been set.

@owais
Copy link
Contributor

owais commented Nov 15, 2021

We shouldn't. I meant to bring it up in weekly SIG this Thursday.

@proffalken
Copy link

proffalken commented Dec 7, 2021

@owais I'm seeing a similar thing in #821, I believe that I've set things up properly, if I use the ConsoleSpanExporter then I get the traces output to the CLI, but as soon as I switch to OTLPHTTP my TraceID's are always 0 in the logs.

Could there be a bigger issue here?

@lzchen
Copy link
Contributor

lzchen commented Jan 3, 2022

@proffalken
Is your issue related to this issue's topic? As well, have you looked at the explanation for the linked issue? Perhaps it may solve your use case.

@proffalken
Copy link

@lzchen - apologies, I'd forgotten that I'd commented here, the linked issue resolved my particular problem.

@mariojonke
Copy link
Contributor

You need to set up the SDK and tracing pipeline before you can use any instrumentors. Please refer to this: https://opentelemetry-python.readthedocs.io/en/latest/getting-started.html

This is right, but we should not fail like this (with an attribute error) if SDK or tracing has not yet been set.

Imo, the instrumentation shouldn't make any assumptions about the SDK at all since it does not define a dependency to it. Furtheremore, there might be 3rd party SDKs in the wild that might handle things like resources differently.

@julianocosta89
Copy link
Member

julianocosta89 commented Jan 29, 2022

Hello all,
QQ related to the same topic.

Is the logging instrumentation supposed to work with the auto-instrumentation?

I'm asking because when I use the opentelemetry-instrument in my sample I get this exact same error.
Just checking if maybe I'm doing something wrong, or if that's a limitation.

I have this sample with the logging instrumentation commented out, just in case someone wants to reproduce the issue.
https://github.com/julianocosta89/microservices-demo/tree/main/src/emailservice

owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
owais added a commit to owais/opentelemetry-python-contrib that referenced this issue Feb 1, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes open-telemetry#810
ocelotl added a commit that referenced this issue Feb 3, 2022
Now service name is extracted from the provider defensively and lazily.
This accounts for an SDK that does not provide access to "resource" via
TracerProviders and for lazy initialization of TracerProviders.

Fixes #810

Co-authored-by: Diego Hurtado <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants