Migrate New Relic logs to Loki: what the move involves
Logs can move from New Relic to Grafana Loki cleanly at the transport and storage layer, but the query and alerting layer does not carry over automatically. The log shippers, OpenTelemetry Collector pipelines and object storage backend are straightforward to stand up, while NRQL log queries, alert conditions and dashboards must be rebuilt by hand in LogQL and Grafana. A team usually leaves New Relic for log cost, data residency or lock-in reasons, and the decision often hinges on how many saved queries and alert policies depend on NRQL. Platform or SRE engineers usually do the work, often with a migration partner who handles hardening and documentation. Expect the effort to concentrate in the query and alert rebuild, not in shipping bytes.
Before cutover, plan for three components that do not exist in a New Relic account. Loki stores compressed chunks and its index in object storage, and the Loki storage documentation lists Amazon S3, Google Cloud Storage and Azure Blob Storage as recommended production stores, so confirm which one your environment will use. Loki has no built-in authentication layer, so the Loki authentication documentation requires an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Grafana, backed by MySQL or PostgreSQL for production, becomes the query and alerting surface that replaces the New Relic log explorer. Each of these needs an owner, a backup plan and an access model before any logs arrive.
Run the two systems in parallel first. Because New Relic supports OTLP ingest, a Collector pipeline can fan out the same log records to New Relic and to Loki while teams compare results. Decide early how labels will be designed, since Loki indexes labels rather than full log text and high-cardinality labels are costly to query, and set retention deliberately, because the Loki retention documentation notes that retention is disabled by default and logs are kept indefinitely until it is enabled. Ask your migration partner for a written inventory of NRQL log queries and alert conditions, a label and retention design, and a rollback plan. Confirm the Loki release and deployment mode against the Loki releases page and deployment modes documentation before sizing.
Which New Relic log capabilities map to Loki, and which need rework
This table maps each New Relic log capability to its Grafana Loki equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes on query translation, retention and access control, which drive most of the migration effort. Loki covers ingest, storage and dashboards well, but authentication must be added in front of it and some enterprise access features sit outside the open-source Grafana edition.
| Capability | Loki and Grafana equivalent | Status and notes |
|---|---|---|
| Log ingest via OTLP or agents | Loki ingests OpenTelemetry logs over HTTP; Grafana Alloy is Grafana's supported log shipper | Clean. Re-point existing OTLP exporters, or replace New Relic log forwarders with Alloy or Fluent Bit |
| Log parsing and field extraction | Pipeline stages in Alloy or Loki, with LogQL parsers at query time | Needs rework. Grok and parsing rules must be rewritten as pipeline stages or LogQL expressions |
| NRQL log queries | LogQL log and metric queries in Grafana Explore | Needs rework. NRQL filters and aggregations must be translated by hand, since no automated converter is documented |
| Log-based alert conditions | Grafana alerting rules on LogQL metric queries | Needs rework. Thresholds, evaluation windows and notification policies are rebuilt in Grafana |
| Dashboards | Grafana dashboards using a Loki data source, provisioned as YAML or JSON | Needs rework. Panels are recreated; provisioning and Terraform help keep them versioned |
| Retention settings | Compactor-applied retention, disabled by default and set per global, tenant or stream selector | Needs rework. Enable retention_enabled explicitly, because logs are kept indefinitely until it is set |
| Label design | Labels index streams, so high-cardinality fields belong in log content, not labels | Gap in habit. New Relic attributes are not indexed the same way, so label schema needs planning before cutover |
| User access and SSO | Grafana authentication: LDAP, generic OAuth, Entra ID, Okta and others in all editions | Clean for most identity providers. SAML, team sync and SCIM are Enterprise or Grafana Cloud features |
| Authentication for the Loki API | Loki has no built-in authentication; an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front | Gap. Plan and test this layer; confirm tenant headers with auth_enabled and X-Scope-OrgID |
What data and integrations move, and what you rebuild
Log migration splits into three tracks: backfilling history, switching live forwarding, and rebuilding the consumers that read logs. Each track has different limits, so plan them separately. The cards below cover what can move, what must be recreated by hand and what to confirm with New Relic before you depend on any export path.
Historical logs and export limits
Historical logs can only be moved through the export path New Relic documents for your account, and the limits on that path apply to your data set. Do not assume a bulk copy is available. Confirm with New Relic whether your plan and data type qualify, the maximum rows per export, the file format and how long result files remain downloadable. Plan for a cutoff: logs that age out of New Relic retention before export is complete are lost unless you export them first. Loki will only hold what you load into it.
Live forwarding with Grafana Alloy
Grafana Alloy is Grafana's supported log shipper for Loki and a distribution of the OpenTelemetry Collector. It replaces the agent that currently forwards logs to New Relic and can tail files, read container logs and attach labels before sending. Run it in parallel with the New Relic forwarder during cutover so both receive the same stream. Check that parsing rules reproduce the attributes your NRQL queries rely on.
OpenTelemetry logs over HTTP
Services already exporting OTLP to New Relic can send logs to Loki's OTLP endpoint instead, or through an OpenTelemetry Collector that fans out to both backends. This keeps one telemetry pipeline during migration. Confirm that your log SDK version is stable for the languages you use, because log SDK maturity varies by language. Check how resource attributes are mapped to Loki labels before you rely on them for queries.
Fluent Bit, Fluentd and Docker sources
Many hosts and clusters forward logs with Fluent Bit, Fluentd or the Docker logging driver, and Loki accepts all three. Where a New Relic integration writes through one of these tools, you can add a Loki output alongside the existing one. Inventory every source before cutover, including appliances and legacy hosts that cannot run a new agent. Those sources often need a syslog or file-based path that you must design and test yourself.
Chunks and index in object storage
Loki keeps compressed log chunks and its index in object storage, and TSDB is the recommended index store. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores. S3-compatible stores such as MinIO and the local filesystem are supported but not typically recommended for production. Size storage, replication and lifecycle policies with your data residency and backup requirements in mind, and confirm them with your storage vendor.
Rebuilt alerts, notifications and dashboards
New Relic alert conditions, notification channels and dashboards do not convert automatically into Grafana. Recreate each log-based alert as a Grafana alert rule with LogQL queries, and map each notification channel to a Grafana contact point. Keep a list of every alert and dashboard that reads logs, with its owner and its on-call destination, so nothing is lost at cutover. Test each rebuilt alert against replayed events before you disable the New Relic version.
Migration sequence from log inventory to New Relic decommission
This sequence moves log management from New Relic to Grafana Loki in a controlled order, so every source, query and alert is accounted for before anything is switched off. Each step closes with a named artifact that a reader can check before moving on.
Inventory log sources and volumes
Start by listing every service, host, container and agent that sends logs to New Relic, including the forwarder or OpenTelemetry Collector used for each one. Record the approximate daily volume per source, the log formats in use, and which teams own each source. Your platform team usually holds the forwarder configs, and the New Relic account owner can confirm current ingest by source. The output is a source inventory with owner, forwarder, format and volume columns. The step is done when the inventory matches what New Relic reports as ingested for the same period.
Stand up a pilot Loki deployment
Choose a Loki deployment mode that fits the pilot volume, using the documented monolithic mode for small volumes and the simple scalable mode only if your planned growth fits its deprecation timeline. Configure an object store as the production backend, with a supported option such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and enable authentication with an authenticating reverse proxy in front of it. Confirm the Loki release you deploy against the GitHub releases page before pinning the version. The output is a running pilot cluster with a tested write and read path. The step is done when a test log line can be written and queried back through the proxy.
Forward logs to New Relic and Loki in parallel
Add a second output to the existing forwarder or OpenTelemetry Collector so that the pilot sources send the same logs to both New Relic and Loki. Grafana Alloy is Grafana's supported shipper for Loki, and Loki also accepts OpenTelemetry logs over HTTP, so pick the path your team already operates. Apply labels deliberately at this point, keeping to a small set of low-cardinality labels such as service, environment and namespace, and leave high-cardinality values in the log body. The output is a labeled Loki stream per pilot source that matches New Relic record counts over a comparable window. The step is done when the two sides agree within a tolerance your team sets in advance.
Translate and validate NRQL log queries to LogQL
Export the saved NRQL queries used by dashboards, alert conditions and investigations, then rewrite each one as LogQL using the labels chosen in the previous step. Parsing and filtering often need to be rebuilt, because field extraction in New Relic does not carry over automatically. Run each LogQL query against the same time window as its NRQL original and compare counts and sample results. The output is a validated query set in which each entry records the NRQL source, the LogQL version, and the result comparison. The step is done when every query in the set either matches or has a documented reason for the difference.
Rebuild and cut over dashboards and alerts
Recreate the validated queries as Grafana dashboards and alert rules, and store the dashboards and alerting resources as provisioning files so they can be reviewed and reloaded. Set Grafana to a database that suits production, since SQLite is not suited to production and high availability, and configure alert notifications so that duplicate messages are avoided in any high availability setup. Walk each alert with its owning team and get written sign-off on thresholds, routing and recipients. The output is a signed-off alert list paired with the Grafana dashboards that display the same data. The step is done when every production alert that existed in New Relic has a named Grafana replacement and an owner has approved it.
Set retention and run both sides through a full cycle
Configure Loki retention deliberately, since the compactor leaves logs indefinitely until retention is enabled, and set it globally, per tenant or per stream selector to match the retention your compliance owners agreed on. Keep New Relic forwarding running long enough for the team to observe alerts and dashboards across a normal operating cycle, including any scheduled batch jobs. Confirm the retention settings against the stored data in object storage. The output is a retention record that states the rule for each stream and a sign-off that retained data meets the agreed policy. The step is done when both sides have run through a full cycle with no unexplained gaps.
Decommission New Relic log ingestion
Remove the New Relic output from forwarders and Collector pipelines, one source at a time, and confirm each source continues to show logs in Loki. Revoke the New Relic license keys and ingest credentials that the forwarders used, and archive the NRQL query set and alert history for audit reference. Ask New Relic to confirm how any historical data is handled under your contract, and do not assume exports are available unless the contract says so. The output is a decommission record listing each source, the date its New Relic output was removed, and the revoked credentials. The step is done when New Relic receives no log ingest from your environment and the record is filed with the migration artifacts.
How Loki labels, storage and deployment modes shape the design
Loki does not index the full text of each log line. It indexes labels attached to each stream, and the query engine then scans the matching compressed chunks. The practical consequence is that label design decides both query speed and storage cost. Keep labels to low-cardinality values such as service, environment and namespace, and keep request IDs, user IDs and similar high-cardinality values inside the log line where they can be filtered with LogQL. Before cutover, map every New Relic log attribute you filter on today to either a label or a parsed field, and check the count of distinct label combinations against the streams you expect. Confirm the label set with the team that owns the dashboards, because changing labels later creates new streams.
Loki offers three deployment modes. The monolithic mode runs as a single binary and the Loki deployment modes documentation places it at up to about 20 GB of logs per day, which suits a pilot or a small estate. The simple scalable mode separates read, write and backend targets, and the Loki documentation states that it is being deprecated and will be removed with the Loki 4.0 release, so a new deployment should not be built on it. The microservices mode is intended for very large clusters. Choose the mode from your measured daily volume from New Relic's log usage reports, and plan a path to the microservices mode if your growth or retention targets point there.
Loki keeps compressed chunks and its index in object storage. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores. S3-compatible systems such as MinIO and the local filesystem are supported, but the Loki storage documentation notes they are not typically recommended for production, so confirm that any on-premises choice meets your durability requirements. Retention is disabled by default, which means logs are kept indefinitely until you set retention_enabled in the compactor configuration. Decide retention per tenant or per stream selector before the first production load, and align it with the retention periods your New Relic data and your compliance obligations currently require.
How the migration differs by log volume and starting point
A small platform or operations team with a modest log stream usually fits Loki's monolithic deployment mode, where one binary handles reads, writes and compaction. The documentation places this mode at up to about 20 GB of logs per day, so the first question is whether your New Relic log ingest sits comfortably under that figure. Illustrative example: a team with a few services and a single Grafana instance can run one Loki process beside Grafana and an Alloy collector on one host, then move to a larger layout later if volume grows.
- Deployment shape: one Loki binary, one Grafana server and one collector, usually with no separate read or write paths to manage.
- Storage: an object store is still recommended for chunks and index, even at this size, so plan the bucket before the first ingest.
- Retention: retention is disabled by default, so set
retention_enabledand a rule per stream deliberately rather than assuming New Relic-style expiry. - Authentication: Loki has no built-in login, so place an authenticating reverse proxy in front of it even for a single node.
- Parallel run: keep New Relic log forwarding active while the Loki path is validated.
Before the cutover, confirm your daily ingest from New Relic usage reports and check that the monolithic ceiling still holds with headroom for growth.
Teams whose daily log volume exceeds the monolithic range need to choose between simple scalable mode and microservices mode. The Loki documentation describes simple scalable mode as separate read, write and backend targets handling volumes approaching 1 TB per day, but it also states that this mode is being deprecated and will be removed with Loki 4.0. For new builds, that deprecation shifts the planning toward a microservices layout on Kubernetes, which the docs position for very large clusters, while existing simple scalable installs need a dated migration plan.
- Mode choice: confirm with Grafana's current deployment guidance whether a new build should use microservices now, given the documented deprecation.
- Collector tier: run Alloy as agents on nodes and a gateway tier in front of the write path to smooth bursts.
- Object storage: use Amazon S3, Google Cloud Storage or Azure Blob Storage as the production store, since the docs do not typically recommend MinIO or local filesystems for production.
- Index: the TSDB index is the recommended store for Loki 2.8 and newer, so avoid legacy index stores from older guides.
- Upgrades: pin a Loki release from the releases page and schedule upgrades, since the component layout changes between versions.
Ask your platform team to confirm the expected peak ingest and the target deployment mode before selecting instance sizes or storage classes.
Organizations that separate logs by business unit, customer or environment often need tenant isolation. Loki is multi-tenant only when auth_enabled is set to true, and every request must carry an X-Scope-OrgID header that identifies the tenant. Without that setting, all data sits in one shared space, which matters when New Relic accounts or sub-accounts previously kept teams apart.
- Tenant mapping: decide whether each New Relic account, team or environment becomes its own tenant ID before instrumenting.
- Header injection: configure the collector or the reverse proxy to set
X-Scope-OrgIDso application teams cannot choose their own tenant. - Access control: the authenticating proxy, such as OAuth2 Proxy or Pomerium, should map user identities to the tenants they may read.
- Per-tenant retention: retention can be set globally, per tenant or per stream selector, which lets regulated tenants keep logs longer.
- Grafana datasources: create one datasource per tenant or use a header-forwarding setup, and test that dashboards cannot cross tenants.
Before go-live, run a test in which one team's credentials attempt to read another tenant's logs, and document the result for your auditors.
What drives the cost and duration of a Loki log migration
This table lists the factors that change the effort and recurring cost of moving New Relic logs to Loki, with the reason each one matters and how to keep it under control. Read it as a checklist to bring to a scoping conversation, since most of these drivers only become measurable once you inventory your own sources, queries and retention needs. The main takeaway is that the number of log sources, alerts to rebuild and the retention period usually matter more than the choice of software itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of log sources and parsers | Each forwarder, agent or OpenTelemetry Collector pipeline and each custom parsing rule must be re-pointed and tested against Loki labels. | Standardize on one shipper such as Grafana Alloy, and reuse parsing rules across similar services. |
| Log volume and deployment mode | Loki's monolithic mode is documented for up to about 20 GB per day, while simple scalable mode approaches 1 TB per day, so volume determines the topology and its operating load. | Size from your measured New Relic ingest, and confirm the mode before building; simple scalable mode is deprecated and removed in Loki 4.0. |
| NRQL queries and alerts to translate | Every NRQL log query, dashboard panel and alert condition needs a LogQL or Grafana equivalent and a validation step against known events. | Inventory and retire unused dashboards first, and group alerts that share the same query logic. |
| Label design | Poor label choices create high-cardinality streams, which slows queries and raises storage overhead, and changing labels later means reingesting or rebuilding queries. | Limit labels to a small set of stable fields such as service and environment, and keep identifiers in log content. |
| Object storage choice | Loki's recommended production stores are Amazon S3, Google Cloud Storage and Azure Blob Storage, while MinIO and filesystem storage are not typically recommended for production. | Use the storage your cloud or data center already operates, and confirm sizing and access policies with its owner. |
| Retention length and rules | Retention is disabled by default, so logs persist until you enable it, and retention rules can be global, per tenant or per stream with a minimum of 24 hours per rule. | Set retention explicitly per stream, aligned with your legal and audit requirements, before the first production load. |
| Authentication and reverse proxy design | Loki has no built-in authentication, so an authenticating proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium is required, plus X-Scope-OrgID tenant handling when auth is enabled. | Reuse your existing identity provider and reverse proxy patterns, and decide tenancy before onboarding teams. |
| Grafana high availability database | Grafana high availability needs two or more active-active servers sharing MySQL 8.0 or later, or PostgreSQL 12 or later, because SQLite does not scale for production. | Use a managed or already supported database service, and confirm the alerting configuration that prevents duplicate notifications. |
| One-time migration work | Parser rewrites, dashboard and alert rebuilds, cutover testing and parallel running are paid once, usually as internal staff time or fixed-scope services. | Ask for a written scope listing sources, dashboards and alerts, and agree acceptance criteria per item. |
| Recurring operations | Storage growth, Loki and Grafana upgrades, patching, backups and on-call coverage recur for as long as you run the stack. | Plan upgrade cadence using Grafana's published release rhythm, and automate deployment through provisioning and infrastructure as code. |
| Staff time and skills | Work spans Kubernetes or VM operations, LogQL, Grafana administration and security hardening, and whoever owns it must be named and trained. | Confirm which roles are internal and which are covered by a retainer, and document the runbooks before cutover. |
What usually goes wrong when logs move to Loki
Most Loki migrations fail on a small set of decisions made early: how labels are designed, whether retention is switched on, how the endpoint is protected, and how the cutover is verified. Each card below names one of these risks and the check that prevents it.
High-cardinality labels slow queries
Loki indexes only labels, so using values such as user IDs, request IDs or pod hashes as labels creates a very large number of streams and slow queries. Teams moving from New Relic, where every attribute is searchable without planning, often copy the attribute model directly. Keep labels to a small set of low-cardinality values such as cluster, namespace, app and level, and keep high-variance fields in the log line for filtering with LogQL. Review stream counts after the first week of ingest.
Retention left disabled
Loki's compactor keeps logs indefinitely until retention is explicitly enabled, so a fresh deployment will grow object storage without limit. This matters during a migration because teams often copy New Relic's retention expectations without setting an equivalent in Loki. Decide retention per tenant or per stream selector before the first production write, and confirm the retention period with your compliance owner. Check that the compactor is running and that deletion is happening, not just configured.
Unauthenticated Loki endpoint
Loki has no built-in authentication layer, so an exposed push or query endpoint accepts and returns logs to anyone who can reach it. Logs often contain credentials, personal data and internal hostnames, which makes this a data exposure rather than a cosmetic gap. Place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki, restrict the write path to your collectors, and enable multi-tenancy with the X-Scope-OrgID header where teams must be separated.
Duplicate alerts in Grafana HA
Running two or more active-active Grafana servers behind a load balancer without extra alerting configuration can send each alert notification more than once. On-call teams that already rely on New Relic alert policies may then receive duplicate pages during an incident. Confirm the alerting high availability settings for your Grafana version, test a rule that fires on a known error, and count the notifications received before relying on the setup.
Silent gaps during cutover
A cutover can lose logs without any error if one source is repointed late, a forwarder filters a field, or a service is missed in the inventory. New Relic will simply stop showing that service, and nobody notices until an incident needs the logs. Build an inventory of every log source, compare per-source event counts in New Relic and Loki for a fixed window while both receive data, and keep the old forwarding path running until the counts match.
Simple scalable mode despite deprecation
Simple scalable mode is a common choice because it looks like a middle path between a single binary and microservices, but the Loki documentation says it is being deprecated and will be removed with the Loki 4.0 release. A migration built on it will need a second rework. Choose monolithic mode for small volumes, or microservices for very large clusters, and ask your deployment partner or Grafana Labs to confirm the mode that fits your daily log volume and the upgrade path to Loki 4.0.
Securing and operating Loki and Grafana after cutover
Once logs flow into Loki, the first decision is how clients reach it, because Loki has no built-in authentication layer. The Loki authentication documentation requires an authenticating reverse proxy in front of it, such as nginx, HAProxy, OAuth2 Proxy or Pomerium. Choose one, terminate TLS there, and restrict direct access to the Loki ports to the proxy and the Collector or Alloy hosts. If auth_enabled is true, every request must carry an X-Scope-OrgID header, so the proxy should set or verify tenant identity rather than trusting the client. Confirm with your security team whether tenant separation matches your data classification, because a shared tenant gives every reader access to every log stream.
On the ingest side, OpenTelemetry Collector authenticator extensions can check credentials on incoming OTLP connections, for example with OIDC, and the oauth2client extension can attach credentials to outgoing exporter requests. Apply these to the gateway Collector that forwards logs to Loki, and keep tokens out of configuration files by sourcing them from your secrets manager. Review the Collector configuration best practices before you expose any receiver beyond the network segment. For Grafana, work through the security hardening settings: secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication on the metrics endpoint and domain verification against DNS rebinding. Grafana authentication on open-source editions covers LDAP, generic OAuth, Entra ID, Okta and similar providers, but SAML, team sync and SCIM provisioning are documented as Enterprise or Grafana Cloud features, so confirm which of your identity requirements the open-source edition meets.
Keep data sources, dashboards and alert rules in version control. Grafana provisioning loads these resources from YAML or JSON files at startup, and Grafana documents Terraform and Git Sync as further as-code options. Store the Loki data source, alert rules and contact points in a repository with review, so a rebuilt Grafana instance can be restored from code during an incident. Plan for the release cadence in the Grafana upgrade guidance: major releases arrive once a year, minor releases roughly every other month, patch releases at least monthly, and each minor release receives support for 9 months. Loki follows its own release line on GitHub, so schedule upgrades for both together and test them against a staging copy of your alert rules. Finally, have counsel review licensing before go-live: Loki and Grafana are licensed under AGPLv3, which carries source-availability obligations if you modify and offer them over a network. Grafana Labs also sells Enterprise as a non-AGPL option, so record which edition you chose and why.
Questions teams ask before moving logs from New Relic to Loki
How long does a New Relic to Loki log migration take?
No supplied figure gives a fixed duration, so the length depends on the work involved: how many log sources feed New Relic today, how many NRQL queries and alert conditions must be rebuilt, how much history must be kept, and whether a parallel run is required before cutover. Teams usually move one log source or service group at a time, so the timeline grows with the number of sources. Ask for a duration only after the scope is written down, and confirm the retention and parallel-run requirements first. A fixed-scope engagement from DeployOpen is agreed in writing before work starts, with deliverables and timelines set at that point.
Can our in-house team migrate New Relic logs to Loki on its own?
Many teams can, provided they already run Kubernetes or Linux services, know their log pipelines and have someone comfortable with Grafana administration. The harder parts are usually label design, object storage configuration, retention rules and authentication, because Loki has no built-in authentication layer and needs an authenticating reverse proxy in front of it. The team should be able to run the Grafana Alloy or OpenTelemetry Collector pipeline, operate Loki's deployment mode and rebuild alerts in Grafana. If those skills are thin, a fixed-scope engagement can cover the build and handover while your staff keep ownership.
What does the migration need from our engineers and security team?
Expect requests on four fronts: engineers to inventory log sources and change forwarders, a platform owner to provision object storage and the Loki deployment, a security team to choose the authenticating proxy and tenant model, and a Grafana admin to rebuild dashboards and alert rules. The Loki documentation says multi-tenancy is enabled with auth_enabled and that each request carries an X-Scope-OrgID header, so the tenant design should be settled early. Also plan a review of who can read which log streams, since logs often contain personal or regulated data.
Can we move historical New Relic logs into Loki, and what should we confirm?
Do not assume bulk history transfers cleanly. Loki ingests new log streams through forwarders, Grafana Alloy, OpenTelemetry logs over HTTP, Fluent Bit or Fluentd, so historical data would need an export from New Relic and a separate load path. Confirm with New Relic which export options your account plan includes and what format and size limits apply. Also confirm with Grafana Labs and your own team whether old logs must be queryable in Loki or only archived in object storage. Many teams keep history in its original export and cut over new ingestion first.
How are retention and storage costs set in a self-hosted Loki?
Storage cost in Loki follows from how much you keep and where you keep it. Loki stores compressed chunks and its index in object storage, and the documentation names Amazon S3, Google Cloud Storage and Azure Blob Storage as recommended production stores. Retention is disabled by default, so logs are kept indefinitely until retention is switched on in the compactor, and it can be set globally, per tenant or per stream selector, with each rule at least 24 hours. Costs you should model are object storage capacity, requests, compute for the read and write targets, and the staff time to tune retention. Ask your provider for a quote that separates these items and states the retention period assumed.
Does Loki replace our New Relic NRQL log dashboards one for one?
No, not directly. NRQL queries have no automated converter to LogQL, so each dashboard panel and alert condition is rebuilt by hand in Grafana. Loki's model depends on labels selecting streams, then filters and parsers applied to the log lines, which means some NRQL queries will need redesign rather than a literal translation. Plan an inventory of dashboards and alerts, group them by log source, and test each rebuilt panel against known events. Grafana provisioning can keep the rebuilt dashboards and alert rules as code once they are verified.
Which licensing terms apply to Loki and Grafana, and what should we check?
Grafana Labs moved Loki, Grafana and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, and Grafana Enterprise is offered as a non-AGPL commercial option. Read the AGPLv3 obligations with your legal team, particularly if you modify the software or offer it to users over a network. Confirm which Grafana features you need, because the authentication docs list SAML, team sync, active sync and SCIM provisioning as available only in Grafana Enterprise and Grafana Cloud. Check these points against Grafana Labs' licensing page before you commit to a design.
How DeployOpen scopes and runs a Loki log migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from New Relic logs to Grafana Loki, we start with a written scope that names your log sources, forwarders, query and alert inventory, and retention requirements before any work begins.
How we scope
- We inventory log sources, forwarders and OpenTelemetry Collector pipelines currently sending logs to New Relic.
- We list the NRQL log queries, dashboards and alert conditions that need a LogQL and Grafana equivalent.
- We agree in writing the label design, retention periods per stream and the object storage target before build starts.
How we build
- We deploy Loki in the deployment mode that matches your daily log volume, inside your cloud account or data center.
- We configure the forwarders or Collector pipelines to send logs in parallel to New Relic and Loki during validation.
- We rebuild log queries and alerts in Grafana, hardening Grafana and placing Loki behind an authenticating reverse proxy.
How we hand over
- We deliver documentation covering the label schema, retention settings, tenant headers and alert rule inventory.
- We provide a side-by-side check list showing which New Relic queries and alerts were rebuilt, changed or retired.
- We walk your operations team through backup, upgrade steps and the cutover decision once the parallel run is complete.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and upgrade cadence are set in writing before the retainer starts.
- Confirm with us during scoping which Loki and Grafana versions your retainer will track and how patches are applied.
