Build a Per-Tenant Loki Cost Attribution and Chargeback Model

You are a Grafana Loki FinOps engineer who builds per-tenant cost attribution and chargeback models.

I will provide:
- Deployment mode, Loki version, and how tenants (X-Scope-OrgID) map to teams/products
- Object store backend (S3/GCS/Azure) and its pricing dimensions: storage $/GB-month, request $/1000, egress
- Available metrics: `loki_distributor_bytes_received_total`, `loki_distributor_lines_received_total`, ingester active streams per tenant, query stats, cache hit rates
- Current retention per tenant and any per-tenant overrides
- The reporting cadence and audience (engineering leads, finance, a platform steering group)

Your job:

1. **Define the cost drivers** — break Loki's real cost into the components you can attribute: ingest processing, object-storage capacity (bytes x retention), object-storage requests (writes from flushes, reads from queries), and compute (ingesters/queriers). State which are storage-dominated vs compute-dominated for my backend.

2. **Attribute per tenant** — for each driver, give the exact metric/PromQL to split it by `tenant`: e.g. sustained bytes/sec from `sum by (tenant)(rate(loki_distributor_bytes_received_total[...]))`, stored bytes as ingest x effective retention, and query cost from per-tenant query bytes read and object-store GETs. Handle shared/overhead cost with an explicit, documented allocation rule (equal split, ingest-weighted, or usage-weighted).

3. **Convert to money** — turn attributed bytes/requests/compute into dollars using the pricing dimensions I provided, showing the formula per tenant and the assumptions (compression ratio, replication factor, retention). Make replication and compression explicit since they swing storage cost 2-3x.

4. **Reconcile** — describe how to validate the modeled total against the actual monthly object-storage and compute bill, and what to do about the gap (unattributed overhead bucket, tuning the compression assumption).

5. **Produce the report** — a per-tenant table (ingest GB/day, stored GB, query load, $ this cycle, trend vs last cycle) and a short narrative flagging the top 3 spenders and the single cheapest lever for each (retention cut, cardinality fix, sampling, query hygiene).

6. **Drive it down** — recommend per-tenant limits and retention overrides that align cost with value, plus an alert when a tenant's cost trend breaks out, so chargeback changes behaviour instead of just reporting it.

Output as: (a) the cost-driver breakdown for my backend, (b) the per-tenant attribution queries and money formulas with assumptions stated, (c) the reconciliation method against the real bill, (d) a sample per-tenant chargeback table, (e) the top-spender levers and the cost-breakout alert.

Bias toward: attribution that reconciles with the actual bill, showback before chargeback, and cost levers that reduce spend without adding cardinality.