| name | r2-loki-log-service |
| description | Design and scope a Grafana Loki log viewing and analysis service backed by Cloudflare R2 object storage. Make sure to use this skill whenever the user asks about Cloudflare R2 logs, Loki, Grafana log dashboards, whether a logging service needs custom development, or alternatives such as DuckDB, ClickHouse, Trino, OpenSearch, Cloudflare R2 SQL, or data-lake log analytics. |
R2 Loki Log Service
Use this skill to help design or implement a logging service where Grafana Loki stores log chunks and indexes in Cloudflare R2 via S3-compatible object storage.
First response
Classify the user's situation before proposing Loki:
- New or streaming logs: Recommend Loki + Grafana Alloy + Grafana, with R2 as Loki's object store. This is mostly deployment and configuration.
- Existing arbitrary files in R2: Explain that Loki does not directly search random
.log, .json, .json.gz, or .csv files already in a bucket. Recommend a replay/import pipeline or a data-lake analytics path.
- Analytics-heavy historical reporting: Prefer R2 + Parquet/Iceberg + DuckDB, ClickHouse, Trino, Snowflake, or Cloudflare R2 SQL/Data Catalog.
- Search/alerting dashboards: Loki is a good fit when labels, time ranges, log streams, Grafana panels, and alerting are the main workflow.
If current version details, Helm values, deprecation dates, or Cloudflare product names matter, verify against official Grafana and Cloudflare docs before finalizing.
Core workflow
- Identify log source: Kubernetes, Docker, VM files, application stdout/stderr, Cloudflare Logpush, or historical R2 files.
- Decide whether Loki is the right primary system. Do not force Loki onto data-lake or BI-style requirements.
- Choose deployment shape:
- Small or proof-of-concept: Loki single binary.
- Production or Kubernetes: Loki Helm chart, usually simple scalable or distributed mode.
- Use Grafana Alloy for collection unless the environment already has a supported collector. Avoid starting new Promtail-based designs; Promtail is deprecated, so verify its current support status if it appears.
- Configure Loki with TSDB schema and S3-compatible storage for R2.
- Design labels conservatively. Use stable, low-cardinality labels such as
service, env, cluster, namespace, pod, host, and level. Do not label high-cardinality values such as user_id, request_id, raw URL, IP address, or trace IDs unless there is a deliberate reason.
- Add Grafana datasource, dashboards, retention, compaction, alerting, and operational monitoring.
- For historical R2 logs, choose either replay into Loki or a separate analytics stack.
Reference
Read references/loki-r2.md when the task needs configuration examples, rollout checklists, or a decision matrix.
Output style
Give practical implementation guidance. Prefer a short architecture, a decision table, concrete config snippets, and a rollout checklist. Explicitly call out what is configuration-only versus what needs custom development.
