Export logs via OTLP

vScope can forward its logs to a third-party observability backend using the OpenTelemetry Protocol (OTLP) over HTTP with a JSON payload. Logs are buffered on disk and pushed to your endpoint in batches, so delivery is reliable and survives restarts.

New to OpenTelemetry? See the OpenTelemetry documentation for an overview of what it is and how OTLP fits in.

This guide shows how to configure the export and how to confirm that logs are arriving at your endpoint.

Note

The Log Export (OTLP) settings are only available to vScope administrators.

---

Before you start

You will need:

• A running OTLP/HTTP receiver that accepts logs — for example an OpenTelemetry Collector — reachable from the machine running vScope.
• The complete logs endpoint URL, including the path (commonly https://<host>:4318/v1/logs).
• Any credentials your endpoint requires (bearer token, basic auth, OAuth 2.0, etc.).

---

Configure the export

1. In vScope, go to Settings → Log Export (OTLP).

2. Under General settings:

   • Turn on Enabled.
   • Enter the Endpoint URL. This is the full URL of the logs endpoint, e.g. https://collector.example.com:4318/v1/logs.
   • Choose the HTTP method, POST or PUT. Most collectors (including the OpenTelemetry Collector) expect POST.
   • Leave Trust all certificates off. Only enable it if your endpoint uses a self-signed certificate that vScope cannot otherwise validate.

3. Under Authentication, pick the Type that matches your endpoint and fill in the fields that appear:

   • No authentication – for an open endpoint or one secured another way.
   • Basic – username and password.
   • Authorization header – a header name (defaults to Authorization) and its value, e.g. Bearer <token>.
   • Token (query parameter) – a query-parameter name and token value.
   • OAuth 2.0 (Client Credentials, Password, or JWT Bearer) – a token URL plus the client/secret/key details for the flow.

   You can also add Custom headers (Name/Value) that are sent on every request, regardless of the authentication type.

4. Under Delivery, tune how logs are sent:

   Setting	Description
   Minimum log level	Lowest level to export: TRACE, DEBUG, INFO, WARN, ERROR, or FATAL. Anything below is skipped.
   Service name	Sent as the service.name resource attribute on every record.
   Batch size	Maximum number of log events sent per request.
   Interval (seconds)	How often vScope pushes buffered logs. Minimum is 60 seconds.
   Max buffered events	How many events are kept on disk while waiting to be sent. When the limit is exceeded, the oldest events are dropped.

5. Click Save.

Caution

A credential with an endpoint URL is required before the export can be enabled — saving an enabled configuration without one is rejected.

---

Test the connection

Before relying on the export, use the built-in test:

1. On the same page, in the Authentication section, click Test connection.
2. vScope sends a single sample log record to your endpoint using the current settings.
   • Test succeeded – the endpoint accepted the record. Your endpoint and credentials are correct.
   • Test failed – the message shows why (for example 401 for bad credentials, or a connection error for an unreachable endpoint). Fix the setting it points to and test again.

The test uses the values currently in the form, so you can verify changes before saving them.

---

How delivery and retries work

vScope uses the HTTP response status returned by your endpoint to decide whether a batch was accepted:

• 2xx (for example 200) — success. Those logs are acknowledged and removed from the buffer, and the next push continues with newer logs.
• Any other response — a non-2xx status (such as 401, 404, or 500), or a connection/timeout error, is treated as a failure. The logs stay in the buffer and vScope resends them on the next interval, retrying until your endpoint reports success. A failed attempt never discards logs on its own — only the Max buffered events limit can drop the oldest events.

In short, your endpoint must return a 2xx status to confirm it has accepted the logs. Until it does, vScope keeps the same logs and tries again.

Note

Because delivery is retried until it succeeds, a misbehaving endpoint that keeps returning a non-2xx status will cause the Buffered count to grow. Watch the Status section (below) to catch this.

---

Verify that logs are arriving

After saving an enabled configuration, vScope starts buffering logs and pushes them on the configured interval (at least every 60 seconds).

Check the status in vScope

The Status section on the settings page reflects the live state:

• Healthy (green) – the most recent batch was delivered successfully. Last success shows when.
• Error (red) – the most recent attempt failed. Last error shows the reason and time. Buffered logs are kept and retried on the next interval, so a temporary outage is not lost.
• Buffered – events currently waiting on disk to be sent. This should stay low; a steadily growing number means the endpoint is not accepting logs.
• Dropped – events discarded because the Max buffered events limit was reached. A non-zero value means logs were lost (typically a long endpoint outage or a too-small buffer).

Check on the receiving end

Confirm the records actually arrive at your backend. If you are testing with an OpenTelemetry Collector, a minimal configuration that prints what it receives is:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [debug]

Point the Endpoint URL at http://<collector-host>:4318/v1/logs and watch the collector output. Each delivered batch is printed with its log records and attributes.

Tip

If you set the Minimum log level to DEBUG you will see a steady stream of records, which makes it easy to confirm the pipeline is working. Raise it again (for example to INFO or WARN) once you have verified delivery.

---

Troubleshooting

• Status stays “Error”. Open the Last error message. A 401/403 means the authentication is wrong; a connection or timeout error means the endpoint is unreachable from the vScope server (check the URL, port, firewall, and any proxy).
• Test succeeds but no periodic logs appear. The buffer only contains events at or above the Minimum log level. On a quiet system there may be little to send — lower the level temporarily to confirm.
• Buffered count keeps growing. The endpoint is reachable for the test but rejecting batches, or it is down. Check the Last error and your receiver’s logs.
• Dropped count is increasing. Logs are being produced faster than they can be delivered, or the endpoint has been down long enough to fill the buffer. Increase Max buffered events, or resolve the delivery problem.
• Nothing happens for up to a minute after saving. This is expected — the push interval is at least 60 seconds.
• TLS certificate errors. If your endpoint uses a self-signed certificate, enable Trust all certificates (otherwise use a certificate vScope trusts).