How to Export Logs to Your Own Log Store

Nevis ID can ship the application logs of your instance to a log store that you own and operate. Once enabled, the logs of your instance are pushed continuously to a Loki-compatible endpoint that you provide, so you can keep them in your own observability stack, apply your own retention policy, and correlate them with the logs of your other systems.

This is an optional feature. It is switched on per instance by Nevis, based on the connection details you supply.

Not the same as the log export API

This feature streams raw application logs to your own log store. It is unrelated to the CSV log export endpoint of other Nevis products, which returns audit events on request.

How it works

A dedicated log shipping agent runs inside your Nevis ID instance for every environment. The agent collects the logs of the Nevis components running in that environment, enriches each log line with metadata (see What you receive), and pushes it to your endpoint over HTTPS.

Some key properties:

• Push based. Nevis pushes to your endpoint. You do not need to grant Nevis inbound access to anything, but your endpoint must be reachable from the internet.
• Tenant isolated. Nevis does not route the exported logs through a shared or cross-tenant system.
• Per environment. Each environment of your instance (for example LIVE and the non-production environments) ships its logs separately, distinguishable by a label.
• Multiple destinations. More than one export target can be configured if you need to deliver the same logs to several log stores.

Prerequisites

Before requesting activation, make sure you have the following in place.

1. A Loki-compatible HTTP endpoint that accepts log pushes and is reachable from the public internet. This can be a Grafana Loki instance, Grafana Cloud Logs, or any gateway in front of them (for example an API gateway).
2. A tenant ID (also called org ID). It is sent with every request in the X-Scope-OrgID header. If your log store is single tenant, use the value it expects. Many setups use fake for this.
3. Credentials for the endpoint, using one of the two supported authentication methods:
   • Basic authentication: a username and a password.
   • Bearer token: a single token sent in the Authorization header.
4. Sufficient capacity and retention on your side. Nevis does not throttle or sample the exported logs.

Step 1: Collect the connection details

Prepare the following values for each destination you want logs delivered to.

Detail	Required	Description
Name	yes	A short identifier for this destination, for example acme-loki. Used to distinguish targets if you configure more than one.
Endpoint	yes	The base URL of your Loki-compatible endpoint. See the warning below.
Tenant ID	yes	Your Loki tenant or org ID, sent as the X-Scope-OrgID header.
Authentication method	yes	Either basic authentication or bearer token.
Username	for basic auth	The username for basic authentication.
Credential	yes	The password (for basic authentication) or the token (for bearer). Send this separately, see Step 2.
Payload format	no	protobuf (default) or json. See Choosing the payload format.

The endpoint must be a base URL

Provide the base URL only, for example https://loki.example.com or https://gateway.example.com/observability. The push path /loki/api/v1/push is appended automatically.

If you include the push path in the value you send, the resulting request goes to .../loki/api/v1/push/loki/api/v1/push, which matches no route on your side. Depending on your setup this surfaces as an HTTP 404. With an API gateway that falls back to its default authentication on an unmatched route, it can surface as a misleading HTTP 403 instead.

Choosing the payload format

The logs are pushed in one of two wire formats. Unless your endpoint requires otherwise, keep the default.

Payload format	Wire format	When to use
protobuf (default)	Snappy-compressed Protobuf	Standard Loki endpoints. This is the native Loki push format.
json	gzip-compressed JSON	Endpoints that reject the Content-Encoding: snappy request header, typically answering with HTTP 415 Unsupported Media Type. Some API gateways, including AWS API Gateway, behave this way.

If you are unsure, start with the default and switch to json only if you see 415 responses on your endpoint.

Step 2: Request activation

Log export is enabled by Nevis. Open a request on the Nevis Support portal and include:

• your instance name and the environments the export should cover,
• the connection details from Step 1, except the credential,
• the payload format, if you need a value other than the default.

Provide the credential itself over a channel agreed with Nevis Support, never in the body of a ticket. It is stored encrypted and is only ever handed to the shipping agent at runtime.

note

Log export is activated as part of a deployment of your instance. Coordinate the timing with Nevis Support so it can be scheduled together with your next maintenance window.

Step 3: Verify the delivery

Once Nevis confirms that the feature is active, check your own log store:

1. Query for the label source="nevis_id". Log lines should appear within a few minutes.
2. Confirm that the nevis_id_instance and nevis_id_namespace labels match the instance and environments you requested.
3. Check the HTTP status codes on your endpoint. Successful pushes return 204 No Content.

If nothing arrives, see Troubleshooting.

What you receive

Each exported log line carries the raw log message as its body, plus the following labels.

Label	Description
source	Always nevis_id. Use this to select all logs coming from Nevis ID.
nevis_id_instance	Identifies your Nevis ID instance.
nevis_id_namespace	The environment the log line originates from, for example the LIVE environment or a test environment.
nevis_id_app	The Nevis component that produced the log line, for example nevisidm or nevisproxy.
nevis_id_log_stream	The output stream of the process, stdout or stderr.
nevis_id_trace_id	The trace ID of the request, if one could be determined. See below.

Trace ID extraction

If a log line contains a trace_id=<value> fragment with a 32 character hexadecimal value, that value is lifted into the nevis_id_trace_id label. This lets you group all log lines belonging to the same request across components in your own log store.

Log lines without a recognizable trace ID are exported unchanged, with the label absent.

Troubleshooting

Symptom on your endpoint	Likely cause	What to do
HTTP 415 Unsupported Media Type	Your endpoint or gateway rejects the Content-Encoding: snappy header used by the default Protobuf format.	Ask Nevis Support to switch the payload format to json.
HTTP 403 Forbidden or HTTP 404 Not Found	The configured endpoint included the /loki/api/v1/push path, so the request goes to a doubled path that matches no route.	Ask Nevis Support to correct the endpoint to the base URL.
HTTP 401 Unauthorized	Wrong or expired credential, or a mismatch between the authentication method configured on each side.	Rotate the credential with Nevis Support and confirm whether your endpoint expects basic authentication or a bearer token.
No requests arrive at all	The endpoint is not reachable from the public internet, or export is not yet active for that environment.	Verify that your endpoint resolves and accepts connections from outside your network, then contact Nevis Support.
Logs arrive, but from one environment only	Export was activated for a subset of your environments.	Contact Nevis Support to extend it to the remaining environments.

Rotating credentials

Changing the credential on your side without telling Nevis stops the delivery. Raise a support request before the rotation so the new value can be applied in the same maintenance window.

Limitations

• Only Loki-compatible endpoints are supported today. There is no direct integration with Elasticsearch, Splunk, or S3-style object storage.
• The exported logs are the application logs of the Nevis components. Audit events and management console activity are not part of this export.
• Nevis does not buffer the logs indefinitely. If your endpoint stops accepting pushes, the shipping agent applies backpressure rather than discarding lines immediately, but log lines are lost once the underlying container log files are rotated. How long that takes depends on the log volume of your instance, so treat an unavailable endpoint as urgent rather than assuming a fixed grace period.
• Filtering and sampling are not configurable. All collected log lines of the covered environments are exported.