# Scrutiny InfluxDB Schema Notes

Based on analysis of your `explore_output.txt`, here's what I discovered:

## InfluxDB Structure

### Measurements
- `smart` - SMART attribute data
- `temp` - Temperature data (simpler format)

### Tags (Device Identifiers)
- `device_wwn` - World Wide Name, unique identifier (e.g., `0x5000c500744487c5`)
- `device_protocol` - Protocol type (`ATA`, `NVME`, etc.)

### Fields in `smart` Measurement

**Basic Metrics:**
- `temp` - Temperature in Celsius
- `power_on_hours` - Total power-on hours
- `power_cycle_count` - Number of power cycles

**SMART Attributes** (pattern: `attr.{id}.{property}`):

For each SMART attribute ID (e.g., 5, 187, 188, 194, 197, 198), Scrutiny stores:
- `attr.{id}.attribute_id` - The attribute ID itself
- `attr.{id}.raw_value` - **Raw value (what we need for calculations!)**
- `attr.{id}.raw_string` - String representation
- `attr.{id}.transformed_value` - Normalized value (0-100)
- `attr.{id}.value` - Current value
- `attr.{id}.thresh` - Threshold
- `attr.{id}.worst` - Worst value seen
- `attr.{id}.status` - Status indicator
- `attr.{id}.status_reason` - Status explanation
- `attr.{id}.failure_rate` - Scrutiny's own failure rate calculation
- `attr.{id}.when_failed` - Failure timestamp (if applicable)

## Key SMART Attributes for Failure Prediction

BackBlaze analysis (used by SnapRAID) focuses on these attributes:

| ID  | Name | Description |
|-----|------|-------------|
| 5   | Reallocated Sectors Count | Sectors remapped due to errors |
| 187 | Reported Uncorrectable Errors | Errors that couldn't be corrected |
| 188 | Command Timeout | Commands that timed out |
| 197 | Current Pending Sector Count | Sectors waiting for remapping |
| 198 | Offline Uncorrectable Sector Count | Errors found during offline scan |

## Your Devices (from explore_output.txt)

Found 5 devices with these WWNs:
1. `0x5000c500744487c5`
2. `0x5000c500c455c45e`
3. `0x5000c500c46b0832`
4. `0x5000c500c570663e`
5. `0x5000c500e584b9c8`

## Device Metadata Location

**Important:** Serial number, model, device path (`/dev/sdX`) are **NOT** stored in InfluxDB!

They are stored in:
1. **Scrutiny's SQLite database** (`/opt/scrutiny/config/scrutiny.db`)
2. **Scrutiny's REST API** endpoints:
   - `/api/summary` - All devices with metadata
   - `/api/device/{wwn}/smart` - Individual device data

## Solution Used

The `smart_logger_v2.py` script:
1. **Fetches device metadata** from Scrutiny's `/api/summary` endpoint
2. **Fetches SMART data** from InfluxDB (faster than API for historical queries)
3. **Calculates failure probability** using BackBlaze tables
4. **Exports to PostgreSQL** with full metadata

## Example InfluxDB Query

```flux
from(bucket: "metrics")
    |> range(start: -1h)
    |> filter(fn: (r) => r._measurement == "smart")
    |> filter(fn: (r) =>
        r._field == "temp" or
        r._field == "power_on_hours" or
        r._field == "attr.5.raw_value" or
        r._field == "attr.187.raw_value" or
        r._field == "attr.188.raw_value" or
        r._field == "attr.197.raw_value" or
        r._field == "attr.198.raw_value"
    )
    |> last()
    |> pivot(rowKey:["device_wwn"], columnKey: ["_field"], valueColumn: "_value")
```

This groups all fields by device WWN, making it easy to get all SMART data per device.