🚀 Feature: Associating Entities with Metrics

[nitin302]

Which component is this feature for?

LangChain Azure OpenAI Instrumentation, But ideally for all component.

🔖 Feature description

Similar to what we are doing for https://www.traceloop.com/docs/openllmetry/tracing/association, can we also set this to metrics? This will help understand LLM metrics better per entity that we want to track.

Particularly, I am interesting in Langchain metrics with Azure OpenAI.

🎤 Why is this feature needed ?

Helps associate Entities with Metrics which is useful to drill down metrics by Entity.

✌️ How do you aim to achieve this?

When we call Traceloop.set_association_properties we can propagate these to metric attributes as well along with traces.

🔄️ Additional Information

No response

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

Are you willing to submit PR?

None

[nirga]

Thanks @nitin302! We were also looking into this. The main blocker is that there isn't a similar SpanProcessor for otel metrics as far as we saw - so there's no way to attach those attributes after-the-fact for metrics. We're looking for ways to do that without having to change all the instrumentations - and are open to suggestions :)

[nitin302]

Thanks for your quick reply!

I also think there is no straightforward way other than changing all instrumentations. But nevertheless chatgpt suggests monkey patching which might be suitable? I also think the risk of change in behaviour of OpenTelemetry metric might be very low as it is in "Stable" status.

Monkey Patching (Not Recommended, but Possible)

If you're comfortable with monkey patching (modifying existing classes at runtime), you could technically modify the add() method of the OpenTelemetry metric types to include custom logic. However, this approach is generally discouraged because it modifies the behavior of third-party libraries at runtime, making the code harder to maintain and debug.

For example:

from opentelemetry.sdk.metrics import Counter

# Monkey-patch the add method of the Counter class
original_add = Counter.add

def hooked_add(self, value, attributes=None):
    # Add custom hook logic here
    print(f"Hooked add called with value: {value} and attributes: {attributes}")
    
    # Call the original add method
    return original_add(self, value, attributes)

# Apply the monkey patch
Counter.add = hooked_add

# Create a meter and a counter
meter = metrics.get_meter(__name__)
request_counter = meter.create_counter("requests_total", unit="1")

# Record metrics
request_counter.add(1, {"method": "GET", "endpoint": "/hello"})

Risks of Monkey Patching:

Harder to Debug: It becomes difficult to trace where and how a method has been modified.
Potential for Breakage: Changes in OpenTelemetry or other dependencies might break the patch.
Not Explicit: The original code is changed without clear indication, which could confuse other developers or make debugging more difficult.

[nirga]

Interesting solution! I opened an issue for otel, let's see first what they respond:
open-telemetry/opentelemetry-python#4230