# ...
spec:
storage:
schemas:
- version: v13
effectiveDate: 2024-10-25
You can use an API endpoint by using the OpenTelemetry Protocol (OTLP) with Logging. As OTLP is a standardized format not specifically designed for Loki, OTLP requires an additional Loki configuration to map data format of OpenTelemetry to data model of Loki. OTLP lacks concepts such as stream labels or structured metadata. Instead, OTLP provides metadata about log entries as attributes, grouped into the following three categories:
Resource
Scope
Log
You can set metadata for multiple entries simultaneously or individually as needed.
The OpenTelemetry Protocol (OTLP) output log forwarder is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope. |
To configure a LokiStack
custom resource (CR) for OTLP ingestion, follow these steps:
Ensure that your Loki setup supports structured metadata, introduced in schema version 13 to enable OTLP log ingestion.
Set the schema version:
When creating a new LokiStack
CR, set version: v13
in the storage schema configuration.
For existing configurations, add a new schema entry with |
Configure the storage schema as follows:
# ...
spec:
storage:
schemas:
- version: v13
effectiveDate: 2024-10-25
Once the effectiveDate
has passed, the v13 schema takes effect, enabling your LokiStack
to store structured metadata.
When you set the Loki Operator to the openshift-logging
mode, Loki Operator automatically applies a default set of attribute mappings. These mappings align specific OTLP attributes with stream labels and structured metadata of Loki.
For typical setups, these default mappings are sufficient. However, you might need to customize attribute mapping in the following cases:
Using a custom collector: If your setup includes a custom collector that generates additional attributes that you do not want to store, consider customizing the mapping to ensure these attributes are dropped by Loki.
Adjusting attribute detail levels: If the default attribute set is more detailed than necessary, you can reduce it to essential attributes only. This can avoid excessive data storage and streamline the logging process.
When using the Loki Operator in openshift-logging
mode, attribute mapping follow OpenShift default values, but you can configure custom mappings to adjust default values.
In the openshift-logging
mode, you can configure custom attribute mappings globally for all tenants or for individual tenants as needed. When you define custom mappings, they are appended to the OpenShift default values. If you do not need default labels, you can disable them in the tenant configuration.
A major difference between the Loki Operator and Loki lies in inheritance handling. Loki copies only |
Within LokiStack
, attribute mapping configuration is managed through the limits
setting. See the following example LokiStack
configuration:
# ...
spec:
limits:
global:
otlp: {} (1)
tenants:
application: (2)
otlp: {}
1 | Defines global OTLP attribute configuration. |
2 | Defines the OTLP attribute configuration for the application tenant within the openshift-logging mode. You can also configure infrastructure and audit tenants in addition to application tenants. |
You can use both global and per-tenant OTLP configurations for mapping attributes to stream labels. |
Stream labels derive only from resource-level attributes, which the LokiStack
resource structure reflects. See the following LokiStack
example configuration:
spec:
limits:
global:
otlp:
streamLabels:
resourceAttributes:
- name: "k8s.namespace.name"
- name: "k8s.pod.name"
- name: "k8s.container.name"
You can drop attributes of type resource, scope, or log from the log entry.
# ...
spec:
limits:
global:
otlp:
streamLabels:
# ...
drop:
resourceAttributes:
- name: "process.command_line"
- name: "k8s\\.pod\\.labels\\..+"
regex: true
scopeAttributes:
- name: "service.name"
logAttributes:
- name: "http.route"
You can use regular expressions by setting regex: true
to apply a configuration for attributes with similar names.
Avoid using regular expressions for stream labels, as this can increase data volume. |
Attributes that are not explicitly set as stream labels or dropped from the entry are saved as structured metadata by default.
In the openshift-logging
mode, certain attributes are required and cannot be removed from the configuration due to their role in OpenShift functions. Other attributes, labeled recommended, might be dropped if performance is impacted. For information about the attributes, see OpenTelemetry data model attributes.
When using the openshift-logging
mode without custom attributes, you can achieve immediate compatibility with OpenShift tools. If additional attributes are needed as stream labels or some attributes need to be droped, use custom configuration. Custom configurations can merge with default configurations.
To reduce default attributes in the openshift-logging
mode, disable recommended attributes:
# ...
spec:
tenants:
mode: openshift-logging
openshift:
otlp:
disableRecommendedAttributes: true (1)
1 | Set disableRecommendedAttributes: true to remove recommended attributes, which limits default attributes to the required attributes or stream labels.
|
Loki labels (Grafana documentation)
Structured metadata (Grafana documentation)
OpenTelemetry attribute (OpenTelemetry documentation)