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

[bug][llama_index] Not full tracing captured in llama-index #289

Closed
diicellman opened this issue Mar 18, 2024 · 12 comments
Closed

[bug][llama_index] Not full tracing captured in llama-index #289

diicellman opened this issue Mar 18, 2024 · 12 comments
Assignees
Labels
backlog blocked bug Something isn't working instrumentation: llama-index Related to llama-index instrumentation module language: python Related to Python integration

Comments

@diicellman
Copy link

Describe the bug
I have an instance of Arize Phoenix running in a Docker container. I've been using the instrument.py example for tracing previously, and there were no problems. Today, I pulled the latest Docker container (3.16.0), and now the tracing captures only "chunking" and nothing more. Previously, it captured the full trace for calling query engines, etc.

Here's my specs:
python = 3.10
llama-index = "^0.10.19"
openinference-semantic-conventions = "^0.1.5"
openinference-instrumentation-llama-index = "^1.2.0"
opentelemetry-exporter-otlp = "^1.23.0"
llama-index-readers-telegram = "^0.1.4"
llama-index-llms-anthropic = "^0.1.6"
llama-index-callbacks-arize-phoenix = "^0.1.4"
arize-phoenix = {extras = ["evals"], version = "^3.16.0"}

To Reproduce
Steps to reproduce the behavior

Expected behavior
To see full tracing
trace_details_view

Screenshots
This is what I get after running query_engine, only "chunking"
Screenshot 2024-03-18 at 12 26 28

Desktop (please complete the following information):

  • OS: MacOS
  • Version Sonoma 14

Additional context
Add any other context about the problem here.

@diicellman diicellman added bug Something isn't working triage Issues that require triage labels Mar 18, 2024
@diicellman diicellman changed the title [bug][llama_index] [bug][llama_index] Not full tracing captured in llama-index Mar 18, 2024
@dosubot dosubot bot added the language: python Related to Python integration label Mar 18, 2024
@mikeldking mikeldking removed the triage Issues that require triage label Mar 18, 2024
@mikeldking mikeldking added the triage Issues that require triage label Mar 18, 2024
@github-project-automation github-project-automation bot moved this to 📘 Todo in phoenix Mar 18, 2024
@mikeldking
Copy link
Contributor

@diicellman I saw exactly the same regression in llama-index myself. I haven't had time to dive deep into this one but I personally have pinned llma-index to 0.10.19 for the time being. We will investigate further and get back to you but they soft-deprecated callbacks in 0.10.20 - my guess is that this is causing problems.

@mikeldking mikeldking removed the triage Issues that require triage label Mar 21, 2024
@diicellman
Copy link
Author

Thank you for the reply! I was also thinking that llama-index's callbacks updates could be the cause of the issue.

@anticorrelator anticorrelator moved this from 📘 Todo to 👨‍💻 In progress in phoenix Mar 21, 2024
@mikeldking mikeldking added the instrumentation: llama-index Related to llama-index instrumentation module label Mar 21, 2024
@mikeldking
Copy link
Contributor

So far we've reproduced orphaned chunking spans if streams are not consumed. This is caused because the chunking spans are emitted as soon as they are created but the overall trace is not "closed"

Screenshot 2024-03-21 at 3 24 57 PM

While not the same as above, it does give us some indication that traces are not shutting down as expected in some situations.

@mikeldking
Copy link
Contributor

mikeldking commented Mar 21, 2024

After some investigation we don’t think the callbacks are working as they previously did. We tried running the LlamaDebugHandler notebook (https://colab.research.google.com/github/jerryjliu/llama_index/blob/main/docs/examples/callbacks/LlamaDebugHandler.ipynb) and we don’t see any traces being printed anymore.
Screenshot 2024-03-21 at 3 46 06 PM

We are working with the llama-index team to resolve.

@mikeldking
Copy link
Contributor

@diicellman I just hit this issue again with someone else and just want to double check one thing. It's imperative that instrument() is called BEFORE any llama-index initialization happens. I'm not sure this will solve anything for you but just wanted to double check since this is after changing when instrumentation is called:

Before:
Screenshot 2024-03-21 at 4 49 54 PM

After:
Screenshot 2024-03-21 at 5 53 13 PM

@mikeldking mikeldking moved this from 👨‍💻 In progress to 📘 Todo in phoenix Mar 22, 2024
@diicellman
Copy link
Author

diicellman commented Mar 23, 2024

Thank you for your help! I'm calling the instrument() in the main.py fastapi file on application startup before any llamaindex calls.

@diicellman
Copy link
Author

diicellman commented Mar 23, 2024

I just updated the libraries to the latest version, and I'm encountering the same chunking traces rather than the full ones. I was considering that perhaps the problem is related to asynchronous usage. Both the endpoints in my app and the llama-index's query_engine.aquery() are asynchronous. However, when I made them non-asynchronous, I still got the same chunking traces.

@mikeldking
Copy link
Contributor

I just updated the libraries to the latest version, and I'm encountering the same chunking traces rather than the full ones. I was considering that perhaps the problem is related to asynchronous usage. Both the endpoints in my app and the llama-index's query_engine.aquery() are asynchronous. However, when I made them non-asynchronous, I still got the same chunking traces.

Oh interesting. Is your code on GitHub by chance? Would love to unblock you @diicellman

@diicellman
Copy link
Author

Yes, my code is on GitHub, but it's in a private repository. If you need to review the code, I can provide the crucial parts that are necessary. I'm sorry for any inconveniences this may cause.

@mikeldking
Copy link
Contributor

Moving this to our backlog for now. We've communicated the lack of a trace tree in some contexts to llama-index and they are investigating.

@mikeldking
Copy link
Contributor

We will probably fix this via the new instrumentation that is not callbacks

Copy link

dosubot bot commented Jan 22, 2025

Hi, @diicellman. I'm Dosu, and I'm helping the OpenInference team manage their backlog. I'm marking this issue as stale.

Issue Summary:

  • Reported bug in Arize Phoenix Docker container (version 3.16.0) affecting tracing functionality.
  • Tracing captures only "chunking" instead of full trace.
  • @mikeldking confirmed a similar issue; potential cause linked to llama-index's callbacks.
  • Attempts to resolve by adjusting function calls and updating libraries were unsuccessful.
  • The team is collaborating with llama-index to implement a fix using new instrumentation methods.

Next Steps:

  • Is this issue still relevant to the latest version of the OpenInference repository? If so, please comment to keep the discussion open.
  • Otherwise, the issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

@dosubot dosubot bot added the stale Issue has not had recent activity or appears to be solved. Stale issues will be automatically closed label Jan 22, 2025
@dosubot dosubot bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 29, 2025
@dosubot dosubot bot removed the stale Issue has not had recent activity or appears to be solved. Stale issues will be automatically closed label Jan 29, 2025
@github-project-automation github-project-automation bot moved this from 📘 Todo to ✅ Done in phoenix Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog blocked bug Something isn't working instrumentation: llama-index Related to llama-index instrumentation module language: python Related to Python integration
Projects
Status: Done
Development

No branches or pull requests

4 participants