 Hey everyone, how's it going? This is Trevor from the Arise team and today we're going to be talking about how to host Phoenix and data persistence with Phoenix. So I wanted to give a quick overview of what Phoenix is. For people who aren't as familiar, Phoenix is an open-source AI observability tool that you can use for your Gen AI applications, any computer vision models, and even your traditional ML models. Phoenix does have a lot of tools that are available for you no matter what phase of the journey that you're in. So there's tools for development phase, the testing and staging phase, as well as once you get your model or application into production. And we'll get into some of the more specifics of what Phoenix offers in some of these components during the demo, but you can also check out the Phoenix GitHub repository through this QR code. Make sure to give us a star if you haven't already. So Phoenix is super easy to get started with because you can run it locally, start iterating super quickly during the development and experimentation phases. However, once you're ready to actually move to production, or if you want to be able to collaborate with your teammates on Phoenix, you can deploy Phoenix for those scenarios. And there's a couple of different ways that you can deploy Phoenix. The first is we do offer a managed hosted version of Phoenix, but for today's conversation, we'll be focusing on the self-hosted options. So with self-hosted, we do recommend running Phoenix through images, and you can find all of the Phoenix images on Docker Hub, and you can also deploy Phoenix on Kubernetes. And before kind of diving in a little bit further, I wanted to give you a quick example of what this might look like if you do have a deployed version of phoenix so you'd have your lm application that's running on on a server that application is instrumented to collect all those traces and spans from the application and then you have another server that phoenix is running on and it's as simple as just pointing your instrumentation to whatever endpoint the Phoenix server is running on. I'll show you what that looks like when we actually dive into more of the specifics in a little bit. And then lastly, kind of before diving deeper, I just wanted to touch on what the data persistence options for Phoenix are. So you can either persist data via a SQLite database, or you can use a Postgres database. If you run Phoenix without any configuration, it'll use SQLite by default. However, you can also configure Phoenix to use Postgres instead, which is what we will do today. And for SQLite, it's just default mounted in the directory that's specified by the Phoenix working directory working directory environment variable and for postgres we'll need to set this phoenix sql database url to map to our postgres instance which i'll show you how to do so diving in a little bit deeper now for today's demo and kind of tutorial we'll be running phoenix via a docker container and so kind of the first option with doing this is just using the docker cli. So both of these commands should be pretty familiar. First is just pulling the Phoenix image from Docker Hub using the Docker pull command. And then we'll actually run that container or create the container, run the image using the Docker run command. Here we are mapping port 6006 on the host to 6006 to the container. Same thing with 4317. These IT commands basically just create an interactive terminal session for the container. And then this is specifying again that image that we want to run. So this is one way to get started using or running Phoenix via Docker container. The other way is to do it via Docker compose and specifying a Docker compose YAML file which is what we'll do and then once you have that YAML file it's really just running Docker compose up to start those services really quickly before we kind of dive into the actual code piece just to quickly touch on the ports that are used. So 6006 is going to be used for the web UI, as well as for accepting traces in OTLP format over HTTP. And then port 4317 is going to be used to accept traces, again, in OTLP format over gRPC instead of HTTP. So diving into the actual code of this tutorial. So first specifying our Docker Compose YAML file. If you'll notice, this is actually the exact same as the example in the documentation. So you can just pull this and be able to run this yourself as well. Um, but here we're specifying a couple of services. So the first is our Phoenix service. Um, and here we're specifying that Phoenix image that we want to use. It's going to depend on the database service. This database services are just Postgres database that'll be powering or being used as a data persistence layer. Here we're mapping those ports again. So again, mapping port 6006 for HTTP and then 4317 for jrpc. And then we're also specifying an environment variable. And this Phoenix SQL database URL is that environment variable that I mentioned previously that we'll need to use Postgres as our persistence. And this is just using that Postgres instance URL. And then for the database service, we're using the Postgres image, we're specifying a couple environment variables, mapping port 5432, and then specifying the volume. In this case, we are just specifying local as the driver, as our volume driver. Obviously if you are deploying this, not running it just locally, that would change as well. But for the purposes of this tutorial, I'm just going to leave it as local. And so once we have this Docker compose YAML file, we can actually just run Docker compose up. So you'll notice I'm already in the Phoenix demo working directory, which is where this Docker compose YAML file lives and we can verify that we just do ls right we can see that docker compose yaml file with our example notebook and then we can run docker compose up that's going to start create those containers start those services um and so while we're waiting for this to load uh we'll kind of walk through what the example notebook looks like. So for the tutorial today, it's a very, very, very simple Lama index application. Basically just uses a couple of functions that we define and probably is like maybe 10, 15 lines of code total. So here we're importing all of the classes that we would need for our LamaIndex application. And then here's where we import all of the functions and classes and methods that we need for our instrumentation. And so you'll notice most of it is just importing from the OpenTelemetry package. We also import the Lama index auto instrumenter from the open inference package, as well as resource attributes, which we use. I'll show you kind of what that means in a sec. I won't spend a ton of time on the instrumentation piece or the tracing piece for this tutorial. We do have a lot of other tutorials on tracing and instrumentation, so definitely check those out if this is kind of a new topic. But just for the sake of time, I'm kind of going to gloss over a lot of the details on instrumentation. The main thing I really wanted to point out is this collector endpoint. So in this case, we do have, since I did just run Phoenix locally, we can also kind of verify that. If you see over here, you can see that the Phoenix UI is running locally on port 6006 to log traces over http which is what we'll be doing we basically can specify this endpoint as localhost 6006 v1 traces that's what we did here if we were using grpc again localhost but instead using that grpc port 4317 and then you can also notice that our Postgres database is being used for storage, which is specified here as well. And so this collector endpoint, since this is running locally, that's why we're using this one. Again, if you had Phoenix deployed somewhere, you would obviously change this to map to whatever the URL of your Phoenix deployment is. Next, we're specifying a couple resource attributes, mainly just this project name. And I'll show you how to use this project name in Phoenix in a sec, or once we actually run this. But this is just specifying the project name as hosted Phoenix demo. I'll gloss over kind of these other instrumentation details. And then this is where we call our llama index auto instrumenter, and then actually call this instrument function that we just created. So let me run this first one that has all those import statements and then I'll run this instrument. These are the two functions that we give to our LLM. So in this case it's just an agent that has access to these two functions that it can call. So again super simple just multiplication a times b addition a plus b we'll run that. then for the llm we're going to use gpt4o from openai and then giving those tools specifying the llm and then in this case we're actually using the shakespeare writing assistant um prompt from lama index so hopefully we should get some some answers in kind of like a Shakespeare-like tone. So if I run this, and then our query in this case is, you know, what is 123 plus 2 divided by 5? If we run that, we'll wait for that response. And so we can see the sum of 123 and 2 is 125. Now to divide this sum by 5, we find that the result is 25. Thus, the answer to that query is 25. So kind of a Shakespeare-like tone. But then if we go back and we can actually load up Phoenix, it's running on loco 6006. And here we can see all of our projects. So again, since we specified that hosted Phoenix demo project, you can see I just have that one trace that we just sent in this project, but I also have a couple other projects that I specified in the past. If we click into this hosted Phoenix demo project, then we can see that one trace. We see our what is 123 plus two divided by five as the input. We can see the output that the LLM gave or our agent gave as well. And then we actually click into it and see all the steps that happened kind of under the hood when we submitted that query. So here we have our system prompt, and this is that Shakespeare system prompt from Lama Index. We can have the user, we see the user input, and then we can see both the function calls. So in this case, that addition function call is being called as well as the multiply function. And then finally, we can see that final LLM call with all of the system and user prompts, the assistant, the tool calls, the results of those tool calls, and then the final response from the assistant. The other thing I wanted to show is in addition to kind of visualizing all the data this way, since we are using Postgres as our database We can actually connect directly to our Postgres database as well and we can do that just using the SQL command line tool So if we do p-sql Specify localhost as the host again Obviously that would differ if you have you know a hosted version or deployed version of a Postgres database We can specify the port, 5432-username, Postgres, type in our password. Then we'll connect to the database, Postgres. And then we can list out all the tables in the database. So here we can have our, we see our projects database, or excuse me, projects table, the spans table, the traces table, a couple other tables as well. We can do a couple of select statements, select star from traces limits, for example, and we can see all of those traces. So we can see our trace IDs, the start and end times, what project they're a part of. So if you'll notice, I had five traces in my default project. I had one trace in that other project. And then this was the project that we just created. And so this is kind of meant to show you how you can actually access that Postgres database that's being used to basically process all the data that you send to Phoenix. And that pretty much wraps up the tutorial and demo for today. Definitely check out some of our other demos and tutorials on our YouTube channel, as well as in the Phoenix documentation and Arise documentation. And then make sure to check out the Phoenix repository and give us a star if you haven't already. Thanks for watchin.
How To: Host Phoenix | Persistence
With Arize Phoenix, getting started is relatively straightforward because you can run it locally and start iterating quickly during the development and experiment phases. However, once you’re ready for production — or if you want to collaborate with your teammates — it’s time to deploy Phoenix. 

In addition to a managed hosted version of Phoenix, there are self-hosted options. Data persistence options for Phoenix include a SQLite database (default), or PostgreSQL. 

This demo walks through how to host Phoenix and uses PostgreSQL.

🔗 Helpful Links
Arize Phoenix on GitHub (please consider a ⭐) https://github.com/Arize-ai/phoenix
Hosted Phoenix: https://docs.arize.com/phoenix/hosted-phoenix
Follow Trevor Laviale: https://www.linkedin.com/in/trevor-laviale/

More about Arize Phoenix: Phoenix is an open source tool that helps you trace, evaluate, and iterate on generative AI applications. The hosted version of Phoenix offers the ability to persist application telemetry data generated during AI development in order to better experiment, iterate, and collaborate in development or production. The solution has a foundation in open source and features a fully hosted, online, persistent deployment option for teams that do not want to self host. AI engineers can instantly log traces, persist datasets, run experiments, run evaluations – and share those insights with colleagues.