Dvir B.

Commented on Can We Restore a Deleted Project on Phoenix UI?·Posted inPhoenix Support

Thanks a lot for the reply 🙏

Can We Restore a Deleted Project on Phoenix UI?

Hello, if one of our developers accidentally deleted a project on phoenix UI, is it something we can restore? does it also mean the data under this project? (out deployment of phoenix is "attached" to a dedicated postgres db)

3Comments

Commented on Asynchronous LLM Calls: Trace Differences in Phoen...·Posted inPhoenix Support

Dvir B.

Thanks a lot Mikyo, we'll take a look into int

Commented on Asynchronous LLM Calls: Trace Differences in Phoen...·Posted inPhoenix Support

Dvir B.

RunLLM yes

Posted in Phoenix Support·

Dvir B.

Asynchronous LLM Calls: Trace Differences in Phoenix Support

Hi Phoenix Support , we're using phoenix for a while now. recently, we built a new app backed by llama-index. Some of the LLM calls there are wrapped by either FunctionCallingProgram or OpenAIPydanticProgram, for working with structured responses. We've noticed that when these programs are called regularly, we can view the named parameters (or inputs) to the program through the traces. However, when we call these program asynchronously, using their acall method, these inputs are not exposed as part of the trace, and the only thing we have there is the formatted template prompt already including the relevant parameters (without being able to see which parameters were sent). Is that a behaviour your familiar with? that asynchronous calls are traced differently from "regular" calls? the implementations of the calls on both cases is identical except for the async llm call.

6Comments

Commented on Issues with Phoenix Upgrade: Resource Exhausted Wa...·Posted inPhoenix Support

Dvir B.

seems like /v1/traces should be added to the collector endpoint. that solved it

Commented on Issues with Phoenix Upgrade: Resource Exhausted Wa...·Posted inPhoenix Support

Dvir B.

I did it, and now i get the following error: ERROR:opentelemetry.exporter.otlp.proto.http.trace_exporter:Failed to export batch code: 405, reason: Method Not Allowed

Commented on Issues with Phoenix Upgrade: Resource Exhausted Wa...·Posted inPhoenix Support

Dvir B.

Not sure what am i doing wrong. I launch the tracing app using phoenix serve then, i try to instrument my calls by setting:

PHOENIX_COLLECTOR_ENDPOINT = os.getenv('PHOENIX_COLLECTOR_ENDPOINT')
trace_provider = register(project_name='variations',
                                  batch=True,
                                  endpoint=PHOENIX_COLLECTOR_ENDPOINT,
                                  )
        trace_provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(PHOENIX_COLLECTOR_ENDPOINT)))

instrumentor = LangChainInstrumentor()
instrumentor.instrument(trace_provider=trace_provider, config=TraceConfig(base64_image_max_length=0))

When i look at the stdout of the served app, i see that upon initialization it indicates that the gRPC uses a different port. i also see 404 errors keep coming up (attached snapshot) The instrumented program indicates the following upon the initialization of the instrumentor:

/usr/local/lib/python3.10/dist-packages/phoenix/otel/otel.py:277: UserWarning: Could not infer collector endpoint protocol, defaulting to HTTP.
  warnings.warn("Could not infer collector endpoint protocol, defaulting to HTTP.")
🔭 OpenTelemetry Tracing Details 🔭
|  Phoenix Project: variations
|  Span Processor: BatchSpanProcessor
|  Collector Endpoint: http://0.0.0.0:5151
|  Transport: HTTP
|  Transport Headers: {}
|  
|  Using a default SpanProcessor. `add_span_processor` will overwrite this default.
|  
|  `register` has set this TracerProvider as the global OpenTelemetry default.
|  To disable this behavior, call `register` with `set_global_tracer_provider=False`.

and when performing a call that should be instrumented i get the following:

WARNING:opentelemetry.exporter.otlp.proto.grpc.exporter:Transient error StatusCode.UNAVAILABLE encountered while exporting traces to 0.0.0.0:5151, retrying in 32s.
2024-10-14 09:55:28,931 - opentelemetry.exporter.otlp.proto.grpc.exporter - WARNING - Transient error StatusCode.UNAVAILABLE encountered while exporting traces to 0.0.0.0:5151, retrying in 32s.

Commented on Issues with Phoenix Upgrade: Resource Exhausted Wa...·Posted inPhoenix Support

Dvir B.

and the endpoint variable there makes the env var PHOENIX_COLLECTOR_ENDPOINT unnecessary? they essentially should point to the same address?

Commented on Issues with Phoenix Upgrade: Resource Exhausted Wa...·Posted inPhoenix Support

Dvir B.

Roger Y. thanks again! so, now my initialization looks like that:

trace_provider = register(batch=True)
instrumentor = LangChainInstrumentor()
instrumentor.instrument(trace_provider=trace_provider, config=TraceConfig(base64_image_max_length=0))

but i get the same behavior. I noticed that in the example you sent the initialization is performed as follows:

from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk import trace as trace_sdk
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor

endpoint = "http://127.0.0.1:4317"
tracer_provider = trace_sdk.TracerProvider()
tracer_provider.add_span_processor(SimpleSpanProcessor(OTLPSpanExporter(endpoint)))
tracer_provider.add_span_processor(SimpleSpanProcessor(ConsoleSpanExporter()))

should i modify my initialization? considering that the phoenix server is hosted locally