Splunk Agent Observability Instrumentation for LangChain Apps

Run and Verify the Trace

5 minutes

Run the travel planner, send a request through it, then confirm the multi-agent trace landed in Splunk Agent Observability.

Exercise Run the app and verify the trace
1

Active Environment

Navigate to the base-app directory and activate the virtual environment:

bash 
cd ~/workshop/agentic-ai/base-app
source .venv/bin/activate
2

Run the app

Start the app:

bash 
python3 main.py

In a second terminal, which is signed in to the same environment, send a travel-planning request. You should get the planned itinerary back, confirming the workflow still runs end-to-end with the callback attached:

3

Send a request to the app

In a second terminal, send a travel-planning request. You should get the planned itinerary back, confirming the workflow still runs end-to-end with the callback attached:

bash 
curl http://localhost:8080/travel/plan \
  -H "Content-Type: application/json" \
  -d '{
    "origin": "Philadelphia",
    "destination": "Florida",
    "user_request": "Planning a two day long trip from Philadelphia to Florida. Looking for a boutique hotel, business-class flights and unique experiences.",
    "travelers": 2
  }'

In the Splunk Agent Observability console (https://console.multitenant.galileocloud.io/splunkse) , open the project and log stream your traces landed in. If you uncommented GALILEO_PROJECT and GALILEO_LOG_STREAM in your .env, that’s Workshop19 / TravelPlanner; otherwise it’s the default project and default log stream.

4

Find the trace

Open the most recent trace. Because the callback was attached at the graph level, you should see a single trace for the request containing a nested LLM span for each agent node:

  • coordinator
  • flight_specialist
  • hotel_specialist
  • activity_specialist
  • plan_synthesizer
5

Inspect the spans

Expand any span and verify it captured the system and human messages, the model response, the model name, token counts, and latency.

No trace showing up?

  • Confirm you were able to log-in to the same environment before sending the request payload, by using a separate terminal session.
  • Confirm GALILEO_API_KEY is set in the environment the app runs in (it loads .env via load_dotenv()).
  • Confirm you’re viewing the right project and log stream: the values from GALILEO_PROJECT / GALILEO_LOG_STREAM if you set them, or default / default if you didn’t.
  • If you don’t see the project, you likely don’t have the correct permissions.
  • Check the app logs for Splunk Agent Observability errors in the bash where python3 main.py is running.
  • Confirm that you are in the splunkse organization in the top left of the web page.

A single travel-planning request produces one trace containing five nested LLM spans, rather than five separate traces. Why?

Click here to see the answer
Because the whole LangGraph workflow runs as one root run per request, and the callback was attached to that run’s config. LangGraph executes the five nodes (coordinator, flight, hotel, activity, synthesizer) within that single run, so each node’s llm.invoke(...) becomes a child span under the same trace. If you instead created a new callback and a new run for each node, you’d get five disconnected traces (and sessions) and lose the end-to-end view of the request.