trace / README.md
mrmarvelous's picture
Upload folder using huggingface_hub
3d77779 verified
|
Raw
History Blame Contribute Delete
5.63 kB
---
title: TRACE v1
emoji: πŸ”§
colorFrom: blue
colorTo: indigo
sdk: docker
pinned: false
---
# Trace
So here's the deal: your AI agent wakes up at 3 AM to a production incident. It sees some dashboards blinking red, but doesn't know what's actually wrong.
![alt text](docs/image.png)
TRACE teaches the agent to:
- **Look at the dashboards** (CPU, memory, error rates)
- **Dig into the logs** (inspect_logs = ask "what happened?")
- **Figure out the root cause** (by trying fixes and seeing if they work)
- **Fix it** (restart services, scale up workers, etc.)
## The Twist
This isn't an easy game. We made it realistic:
βœ… **Agent can't just see everything** β€” logs and deep metrics are hidden. You gotta ask for them.
βœ… **Every scenario is the same if you replay it** β€” no randomness to hide behind
βœ… **Actions are structured** β€” every fix needs a target (e.g., `api_workers`)
βœ… **Rewards build up** β€” one bad decision doesn't break everything immediately
βœ… **We only grade on results** β€” did you fix it in time? That's what matters.
## Get It Running
**Setup** (one time):
```bash
python -m venv venv
./venv/Scripts/activate # Windows
pip install -e .
```
**Then**:
```bash
# Terminal 1: Start the server
uvicorn server.app:app --host 0.0.0.0 --port 7860
# Terminal 2: Run tests to make sure it works
pytest tests/ -v
# Terminal 3: Try the demo agent
python inference.py
```
## What's Inside πŸ“¦
```
TRACE/
β”œβ”€β”€ pyproject.toml # Project config (OpenEnv wants this)
β”œβ”€β”€ openenv.yaml # Tells OpenEnv how to run us
β”œβ”€β”€ Dockerfile # For containerization
β”œβ”€β”€ README.md # This file
β”‚
β”œβ”€β”€ server/ # The API server
β”‚ └── app.py # Actually runs /reset, /step, /state, /health
β”‚
β”œβ”€β”€ trace/ # The environment logic
β”‚ β”œβ”€β”€ models.py # Data structures
β”‚ β”œβ”€β”€ scenarios.py # The 3 incidents
β”‚ β”œβ”€β”€ simulator.py # Runs the scenario step by step
β”‚ β”œβ”€β”€ rewards.py # Calculates points
β”‚ └── graders.py # Final score
β”‚
β”œβ”€β”€ tests/ # Everything's tested
β”‚ β”œβ”€β”€ test_scenarios.py # Do scenarios work?
β”‚ β”œβ”€β”€ test_rewards.py # Do points work?
β”‚ └── test_env.py # Does the whole thing work?
β”‚
└── inference.py # Demo: how an agent would play
```
## Three Incidents to Solve
### 1. Easy: The Traffic Spike (5 steps max)
Your API is getting crushed. CPU is maxed out. Something's overloaded.
**What you see:** CPU at 85%, latency jumping, errors starting
**What you don't see:** It's just too much traffic
**What to do:** Add more workers (`scale_workers`)
---
### 2. Medium: The Cascade (7 steps max)
Your queue service has a memory leak. As memory fills up, it starts dropping requests. Other services timeout waiting for it. Everything falls apart together.
**What you see:** Queue backing up, workers getting slower, more errors
**What you don't see:** There's a memory leak you need to restart to fix
**What to do:** Restart the queue service
---
### 3. Hard: The Two-Problem Incident (8 steps max)
Someone deployed new code that queries the database inefficiently. Now the DB connection pool is exhausted. Plus there's a high CPU spike that's... actually a symptom, not the problem.
**What you see:** Tons of errors, crazy high latency, CPU spike, DB is slow
**What you don't see:** The deploy broke the queries, and the pool is full
**What to do:** Restart the database (and maybe rollback the release)
## API (How to Talk to TRACE)
### Start an incident
```bash
POST /reset
{"task_id": "easy_cpu_spike", "seed": 42}
β†’ You get the first observation (dashboards showing the problem)
```
### Take an action
```bash
POST /step
{"action": {"action_type": "scale_workers", "target": "api_workers", "value": 5}}
β†’ You get the new state, points earned this step, and whether it's fixed
```
### Check status anytime
```bash
GET /state
β†’ Current dashboards, points so far, step count
```
### Is the server alive?
```bash
GET /health
β†’ {"status": "healthy"}
```
## How Scoring Works
**You get points for smart moves**, deductions for dumb ones. But points don't count until the episode ends (no cliff-falling mid-incident).
**During the incident:**
- +1 for asking smart questions (logging, metrics checks)
- +5 for actually fixing something
- -0.5 for doing the same thing twice
- -2 for making things worse
- +10 for successfully resolving it
- -5 if you claim it's fixed but it's not
**Final score:**
```
Did you fix it? β†’ 60% of score
How fast did you fix it? β†’ 40% of score
```
So speed matters, but not as much as actually *fixing* things.
## Deploy It
**Local** (for testing):
```bash
docker build -t trace:latest .
docker run -p 7860:7860 trace:latest
```
**To the cloud** (Hugging Face Spaces):
Push to the `meta-trace` repo and enable auto-deploy. Done.
---
## Check If It Works
```bash
openenv validate # Does the API work?
./validate-submission.sh # Full checks
```
Should see:
- βœ… Server comes up
- βœ… Scenarios work and are reproducible
- βœ… Rewards actually accumulate
- βœ… Agent can fix incidents
- βœ… Tests pass
---
**Want the deep dive?** See [agent.md](agent.md).
**Ready to build?** `pip install -e .` and go!