See how the LoadStrike Grafana Loki sink fits into transaction-aware reporting and public Grafana starter assets.
The Grafana Loki integration is the built-in LoadStrike sink for teams that want log-style reporting events in Loki while keeping projected metrics available through a companion OTLP path. The public site also publishes the matching datasource and dashboard starter assets.
That lets self-hosted teams keep a transaction-aware runtime and still route the final reporting story into Grafana-oriented observability workflows they already operate.
Teams already using Loki and Grafana for observability and wanting LoadStrike event data in that same environment.
Request-only tooling often produces endpoint metrics without a clear path for transaction-level event data and grouped correlation detail. That makes the observability handoff harder once the workflow crosses system boundaries.
LoadStrike documents Grafana Loki as a built-in sink, explains the OTLP metrics companion path, and publishes a Loki datasource YAML, dashboard provider YAML, and overview dashboard JSON file for the public workflow.
These public assets already exist for the Grafana Loki workflow.
Read the sink behavior and configuration surface.
Download the datasource provisioning file.
Download the public overview dashboard.
Download the shared dashboard-provider file.
These questions are rendered on the page and mirrored in the matching FAQ structured data when the route is indexable.
Yes. The public downloads include a Loki datasource YAML, a shared dashboard-provider YAML, and a Loki overview dashboard JSON file.
Yes. The public docs describe Grafana Loki as a built-in reporting sink on eligible plans rather than as a custom sink the user must implement manually.
Open the Grafana Loki sink docs, the realtime reporting landing page, and the reports overview so the Loki-specific workflow stays connected to the broader transaction reporting model.
Keep moving from positioning into concrete product detail.
Use the Grafana Loki sink when you want log-style LoadStrike events in Loki and projected metrics through a companion OTLP path.
Realtime reporting streams LoadStrike data to external backends during the run and again when the run finishes.
This page explains how to read a LoadStrike report. Use it when you want to know what each section means and where to look first.
Use these routes when the next question is tool choice rather than implementation detail.
Compare LoadStrike and Apache JMeter across scenario design, protocol coverage, downstream correlation, browser workflows, reporting, and self-hosted operations.
These reporting pages connect the transaction model to the observability systems already documented publicly.
See how the LoadStrike InfluxDB sink fits into transaction-aware reporting workflows and public Grafana starter assets.
See how the LoadStrike TimescaleDB sink fits into transaction-aware reporting workflows and public Grafana starter assets.
Every published route should help you move to the next concrete question instead of ending in a dead end.
See a category where grouped event reporting matters.
Connect cluster execution back to the observability backend.
Review how future result pages should disclose artifacts and topology.
Open the sink-specific docs, start with the downloadable assets that already exist in the public site, and keep the reporting path aligned with the same run artifact that LoadStrike returns from Run().
