# Was it the target — or your load generator? An `observe` collector samples
# the local host's CPU / memory / disk / network from /proc every second
# during the run (Linux; other platforms log a warning and skip) and overlays
# the series on the run timeline — in the HTML report, the web UI and the
# summary export.
#
# Observed series are ordinary metrics: system_cpu, system_memory,
# system_disk_io, system_network (rename the family with `as_prefix`). CPU
# and memory are 0..1 ratios; disk I/O and network are bytes per second.
# They are valid threshold targets, so a saturated generator FAILS the run
# instead of silently skewing the latency numbers.
#
#   loadr run examples/47-system-observe.yaml
name: system-observe
description: overlay generator cpu/memory/disk/network on the load timeline

defaults:
  http:
    base_url: https://httpbin.org
    timeout: 10s

observe:
  - type: system
    metrics: [ cpu, memory, disk, network ]   # default: all four
    interval: 1s                              # sampling cadence

scenarios:
  browse:
    executor: ramping-vus
    start_vus: 0
    stages:
      - { duration: 30s, target: 30 }   # ramp: watch system_cpu climb with RPS
      - { duration: 1m, target: 30 }
    flow:
      - request:
          name: get
          url: /get
          checks:
            - { type: status, equals: 200 }

thresholds:
  # The generator itself must stay healthy for the numbers to mean anything.
  system_cpu: [ "max < 0.90" ]
  system_memory: [ "max < 0.85" ]
  http_req_duration: [ "p(95)<800" ]
  http_req_failed: [ "rate<0.01" ]
