Este contenido no está disponible en el idioma seleccionado.
Chapter 1. Configuring log forwarding
The ClusterLogForwarder
(CLF) allows users to configure forwarding of logs to various destinations. It provides a flexible way to select log messages from different sources, send them through a pipeline that can transform or filter them, and forward them to one or more outputs.
Key Functions of the ClusterLogForwarder
- Selects log messages using inputs
- Forwards logs to external destinations using outputs
- Filters, transforms, and drops log messages using filters
- Defines log forwarding pipelines connecting inputs, filters and outputs
1.1. Setting up log collection Copiar enlaceEnlace copiado en el portapapeles!
This release of Cluster Logging requires administrators to explicitly grant log collection permissions to the service account associated with ClusterLogForwarder. This was not required in previous releases for the legacy logging scenario consisting of a ClusterLogging and, optionally, a ClusterLogForwarder.logging.openshift.io resource.
The Red Hat OpenShift Logging Operator provides collect-audit-logs
, collect-application-logs
, and collect-infrastructure-logs
cluster roles, which enable the collector to collect audit logs, application logs, and infrastructure logs respectively.
Setup log collection by binding the required cluster roles to your service account.
1.1.1. Legacy service accounts Copiar enlaceEnlace copiado en el portapapeles!
To use the existing legacy service account logcollector
, create the following ClusterRoleBinding:
oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector
Additionally, create the following ClusterRoleBinding if collecting audit logs:
oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
1.1.2. Creating service accounts Copiar enlaceEnlace copiado en el portapapeles!
Prerequisites
-
The Red Hat OpenShift Logging Operator is installed in the
openshift-logging
namespace. - You have administrator permissions.
Procedure
- Create a service account for the collector. If you want to write logs to storage that requires a token for authentication, you must include a token in the service account.
Bind the appropriate cluster roles to the service account:
Example binding command
oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.1.2.1. Cluster Role Binding for your Service Account Copiar enlaceEnlace copiado en el portapapeles!
The role_binding.yaml file binds the ClusterLogging operator’s ClusterRole to a specific ServiceAccount, allowing it to manage Kubernetes resources cluster-wide.
- 1
- roleRef: References the ClusterRole to which the binding applies.
- 2
- apiGroup: Indicates the RBAC API group, specifying that the ClusterRole is part of Kubernetes' RBAC system.
- 3
- kind: Specifies that the referenced role is a ClusterRole, which applies cluster-wide.
- 4
- name: The name of the ClusterRole being bound to the ServiceAccount, here cluster-logging-operator.
- 5
- subjects: Defines the entities (users or service accounts) that are being granted the permissions from the ClusterRole.
- 6
- kind: Specifies that the subject is a ServiceAccount.
- 7
- Name: The name of the ServiceAccount being granted the permissions.
- 8
- namespace: Indicates the namespace where the ServiceAccount is located.
1.1.2.2. Writing application logs Copiar enlaceEnlace copiado en el portapapeles!
The write-application-logs-clusterrole.yaml file defines a ClusterRole that grants permissions to write application logs to the Loki logging application.
- 1
- rules: Specifies the permissions granted by this ClusterRole.
- 2
- apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
- 3
- loki.grafana.com: The API group for managing Loki-related resources.
- 4
- resources: The resource type that the ClusterRole grants permission to interact with.
- 5
- application: Refers to the application resources within the Loki logging system.
- 6
- resourceNames: Specifies the names of resources that this role can manage.
- 7
- logs: Refers to the log resources that can be created.
- 8
- verbs: The actions allowed on the resources.
- 9
- create: Grants permission to create new logs in the Loki system.
1.1.2.3. Writing audit logs Copiar enlaceEnlace copiado en el portapapeles!
The write-audit-logs-clusterrole.yaml file defines a ClusterRole that grants permissions to create audit logs in the Loki logging system.
- 1
- rules: Defines the permissions granted by this ClusterRole.
- 2
- apiGroups: Specifies the API group loki.grafana.com.
- 3
- loki.grafana.com: The API group responsible for Loki logging resources.
- 4
- resources: Refers to the resource type this role manages, in this case, audit.
- 5
- audit: Specifies that the role manages audit logs within Loki.
- 6
- resourceNames: Defines the specific resources that the role can access.
- 7
- logs: Refers to the logs that can be managed under this role.
- 8
- verbs: The actions allowed on the resources.
- 9
- create: Grants permission to create new audit logs.
1.1.2.4. Writing infrastructure logs Copiar enlaceEnlace copiado en el portapapeles!
The write-infrastructure-logs-clusterrole.yaml file defines a ClusterRole that grants permission to create infrastructure logs in the Loki logging system.
Sample YAML
- 1
- rules: Specifies the permissions this ClusterRole grants.
- 2
- apiGroups: Specifies the API group for Loki-related resources.
- 3
- loki.grafana.com: The API group managing the Loki logging system.
- 4
- resources: Defines the resource type that this role can interact with.
- 5
- infrastructure: Refers to infrastructure-related resources that this role manages.
- 6
- resourceNames: Specifies the names of resources this role can manage.
- 7
- logs: Refers to the log resources related to infrastructure.
- 8
- verbs: The actions permitted by this role.
- 9
- create: Grants permission to create infrastructure logs in the Loki system.
1.1.2.5. ClusterLogForwarder editor role Copiar enlaceEnlace copiado en el portapapeles!
The clusterlogforwarder-editor-role.yaml file defines a ClusterRole that allows users to manage ClusterLogForwarders in OpenShift.
- 1
- rules: Specifies the permissions this ClusterRole grants.
- 2
- apiGroups: Refers to the OpenShift-specific API group
- 3
- obervability.openshift.io: The API group for managing observability resources, like logging.
- 4
- resources: Specifies the resources this role can manage.
- 5
- clusterlogforwarders: Refers to the log forwarding resources in OpenShift.
- 6
- verbs: Specifies the actions allowed on the ClusterLogForwarders.
- 7
- create: Grants permission to create new ClusterLogForwarders.
- 8
- delete: Grants permission to delete existing ClusterLogForwarders.
- 9
- get: Grants permission to retrieve information about specific ClusterLogForwarders.
- 10
- list: Allows listing all ClusterLogForwarders.
- 11
- patch: Grants permission to partially modify ClusterLogForwarders.
- 12
- update: Grants permission to update existing ClusterLogForwarders.
- 13
- watch: Grants permission to monitor changes to ClusterLogForwarders.
1.2. Modifying log level in collector Copiar enlaceEnlace copiado en el portapapeles!
To modify the log level in the collector, you can set the observability.openshift.io/log-level
annotation to trace
, debug
, info
, warn
, error
, and off
.
Example log level annotation
1.3. Managing the Operator Copiar enlaceEnlace copiado en el portapapeles!
The ClusterLogForwarder
resource has a managementState
field that controls whether the operator actively manages its resources or leaves them Unmanaged:
- Managed
- (default) The operator will drive the logging resources to match the desired state in the CLF spec.
- Unmanaged
- The operator will not take any action related to the logging components.
This allows administrators to temporarily pause log forwarding by setting managementState
to Unmanaged
.
1.4. Structure of the ClusterLogForwarder Copiar enlaceEnlace copiado en el portapapeles!
The CLF has a spec
section that contains the following key components:
- Inputs
-
Select log messages to be forwarded. Built-in input types
application
,infrastructure
andaudit
forward logs from different parts of the cluster. You can also define custom inputs. - Outputs
- Define destinations to forward logs to. Each output has a unique name and type-specific configuration.
- Pipelines
- Define the path logs take from inputs, through filters, to outputs. Pipelines have a unique name and consist of a list of input, output and filter names.
- Filters
- Transform or drop log messages in the pipeline. Users can define filters that match certain log fields and drop or modify the messages. Filters are applied in the order specified in the pipeline.
1.4.1. Inputs Copiar enlaceEnlace copiado en el portapapeles!
Inputs are configured in an array under spec.inputs
. There are three built-in input types:
- application
- Selects logs from all application containers, excluding those in infrastructure namespaces.
- infrastructure
Selects logs from nodes and from infrastructure components running in the following namespaces:
-
default
-
kube
-
openshift
-
Containing the
kube-
oropenshift-
prefix
-
- audit
- Selects logs from the OpenShift API server audit logs, Kubernetes API server audit logs, ovn audit logs, and node audit logs from auditd.
Users can define custom inputs of type application
that select logs from specific namespaces or using pod labels.
1.4.2. Outputs Copiar enlaceEnlace copiado en el portapapeles!
Outputs are configured in an array under spec.outputs
. Each output must have a unique name and a type. Supported types are:
- azureMonitor
- Forwards logs to Azure Monitor.
- cloudwatch
- Forwards logs to AWS CloudWatch.
- elasticsearch
- Forwards logs to an external Elasticsearch instance.
- googleCloudLogging
- Forwards logs to Google Cloud Logging.
- http
- Forwards logs to a generic HTTP endpoint.
- kafka
- Forwards logs to a Kafka broker.
- loki
- Forwards logs to a Loki logging backend.
- lokistack
- Forwards logs to the logging supported combination of Loki and web proxy with OpenShift Container Platform authentication integration. LokiStack’s proxy uses OpenShift Container Platform authentication to enforce multi-tenancy
- otlp
- Forwards logs using the OpenTelemetry Protocol.
- splunk
- Forwards logs to Splunk.
- syslog
- Forwards logs to an external syslog server.
Each output type has its own configuration fields.
1.4.3. Configuring OTLP output Copiar enlaceEnlace copiado en el portapapeles!
Cluster administrators can use the OpenTelemetry Protocol (OTLP) output to collect and forward logs to OTLP receivers. The OTLP output uses the specification defined by the OpenTelemetry Observability framework to send data over HTTP with JSON encoding.
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.
Procedure
Create or edit a
ClusterLogForwarder
custom resource (CR) to enable forwarding using OTLP by adding the following annotation:Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The OTLP output uses the OpenTelemetry data model, which is different from the ViaQ data model that is used by other output types. It adheres to the OTLP using OpenTelemetry Semantic Conventions defined by the OpenTelemetry Observability framework.
1.4.4. Pipelines Copiar enlaceEnlace copiado en el portapapeles!
Pipelines are configured in an array under spec.pipelines
. Each pipeline must have a unique name and consists of:
- inputRefs
- Names of inputs whose logs should be forwarded to this pipeline.
- outputRefs
- Names of outputs to send logs to.
- filterRefs
- (optional) Names of filters to apply.
The order of filterRefs matters, as they are applied sequentially. Earlier filters can drop messages that will not be processed by later filters.
1.4.5. Filters Copiar enlaceEnlace copiado en el portapapeles!
Filters are configured in an array under spec.filters
. They can match incoming log messages based on the value of structured fields and modify or drop them.
Administrators can configure the following types of filters:
1.4.6. Enabling multi-line exception detection Copiar enlaceEnlace copiado en el portapapeles!
Enables multi-line error detection of container logs.
Enabling this feature could have performance implications and may require additional computing resources or alternate logging solutions.
Log parsers often incorrectly identify separate lines of the same exception as separate exceptions. This leads to extra log entries and an incomplete or inaccurate view of the traced information.
Example java exception
java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null at testjava.Main.handle(Main.java:47) at testjava.Main.printMe(Main.java:19) at testjava.Main.main(Main.java:10)
java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
at testjava.Main.handle(Main.java:47)
at testjava.Main.printMe(Main.java:19)
at testjava.Main.main(Main.java:10)
-
To enable logging to detect multi-line exceptions and reassemble them into a single log entry, ensure that the
ClusterLogForwarder
Custom Resource (CR) contains adetectMultilineErrors
field under the.spec.filters
.
Example ClusterLogForwarder CR
1.4.6.1. Details Copiar enlaceEnlace copiado en el portapapeles!
When log messages appear as a consecutive sequence forming an exception stack trace, they are combined into a single, unified log record. The first log message’s content is replaced with the concatenated content of all the message fields in the sequence.
The collector supports the following languages:
- Java
- JS
- Ruby
- Python
- Golang
- PHP
- Dart
1.4.7. Forwarding logs over HTTP Copiar enlaceEnlace copiado en el portapapeles!
To enable forwarding logs over HTTP, specify http
as the output type in the ClusterLogForwarder
custom resource (CR).
Procedure
Create or edit the
ClusterLogForwarder
CR using the template below:Example ClusterLogForwarder CR
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Additional headers to send with the log record.
- 2
- Optional: URL of the HTTP/HTTPS proxy that should be used to forward logs over http or https from this output. This setting overrides any default proxy settings for the cluster or the node.
- 3
- Destination address for logs.
- 4
- Values are either
true
orfalse
. - 5
- Secret name for destination credentials.
- 6
- This value should be the same as the output name.
- 7
- The name of your service account.
1.4.8. Forwarding logs using the syslog protocol Copiar enlaceEnlace copiado en el portapapeles!
You can use the syslog RFC3164 or RFC5424 protocol to send a copy of your logs to an external log aggregator that is configured to accept the protocol instead of, or in addition to, the default Elasticsearch log store. You are responsible for configuring the external log aggregator, such as a syslog server, to receive the logs from OpenShift Container Platform.
To configure log forwarding using the syslog protocol, you must create a ClusterLogForwarder
custom resource (CR) with one or more outputs to the syslog servers, and pipelines that use those outputs. The syslog output can use a UDP, TCP, or TLS connection.
Prerequisites
- You must have a logging server that is configured to receive the logging data using the specified protocol or format.
Procedure
Create or edit a YAML file that defines the
ClusterLogForwarder
CR object:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify a name for the output.
- 2
- Optional: Specify the value for the
APP-NAME
part of the syslog message header. The value must conform with The Syslog Protocol. The value can be a combination of static and dynamic values consisting of field paths followed by||
, and then followed by another field path or a static value. The maximum length of the final values is truncated to 48 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with||
. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}. - 3
- Optional: Specify the value for
Facility
part of the syslog-msg header. - 4
- Optional: Specify the value for
MSGID
part of the syslog-msg header. The value can be a combination of static and dynamic values consisting of field paths followed by||
, and then followed by another field path or a static value. The maximum length of the final values is truncated to 32 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with||
. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}. - 5
- Optional: Specify the record field to use as the payload. The
payloadKey
value must be a single field path encased in single curly brackets{}
. Example: {.<value>}. - 6
- Optional: Specify the value for the
PROCID
part of the syslog message header. The value must conform with The Syslog Protocol. The value can be a combination of static and dynamic values consisting of field paths followed by||
, and then followed by another field path or a static value. The maximum length of the final values is truncated to 48 characters. You must encase a dynamic value curly brackets and the value must be followed with a static fallback value separated with||
. Static values can only contain alphanumeric characters along with dashes, underscores, dots and forward slashes. Example value: <value1>-{.<value2>||"none"}. - 7
- Optional: Set the RFC that the generated messages conform to. The value can be
RFC3164
orRFC5424
. - 8
- Optional: Set the severity level for the message. For more information, see The Syslog Protocol.
- 9
- Optional: Set the delivery mode for log forwarding. The value can be either
AtLeastOnce
, orAtMostOnce
. - 10
- Specify the absolute URL with a scheme. Valid schemes are:
tcp
,tls
, andudp
. For example:tls://syslog-receiver.example.com:6514
. - 11
- Specify the settings for controlling options of the transport layer security (TLS) client connections.
- 12
- Specify which log types to forward by using the pipeline:
application,
infrastructure
, oraudit
. - 13
- Specify a name for the pipeline.
- 14
- The name of your service account.
Create the CR object:
oc create -f <filename>.yaml
$ oc create -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.4.8.1. Adding log source information to the message output Copiar enlaceEnlace copiado en el portapapeles!
You can add namespace_name
, pod_name
, and container_name
elements to the message
field of the record by adding the enrichment
field to your ClusterLogForwarder
custom resource (CR).
This configuration is compatible with both RFC3164 and RFC5424.
Example syslog message output with enrichment: None
2025-03-03T11:48:01+00:00 example-worker-x syslogsyslogserverd846bb9b: {...}
2025-03-03T11:48:01+00:00 example-worker-x syslogsyslogserverd846bb9b: {...}
Example syslog message output with enrichment: KubernetesMinimal
2025-03-03T11:48:01+00:00 example-worker-x syslogsyslogserverd846bb9b: namespace_name=cakephp-project container_name=mysql pod_name=mysql-1-wr96h,message: {...}
2025-03-03T11:48:01+00:00 example-worker-x syslogsyslogserverd846bb9b: namespace_name=cakephp-project container_name=mysql pod_name=mysql-1-wr96h,message: {...}
1.5. Forwarding logs to Amazon CloudWatch from STS-enabled clusters Copiar enlaceEnlace copiado en el portapapeles!
Amazon CloudWatch is a service that helps administrators observe and monitor resources and applications on Amazon Web Services (AWS). You can forward logs from OpenShift Logging to CloudWatch securely by leveraging AWS’s Identity and Access Management (IAM) Roles for Service Accounts (IRSA), which uses AWS Security Token Service (STS).
The authentication with CloudWatch works as follows:
- The log collector requests temporary AWS credentials from Security Token Service (STS) by presenting its service account token to the OpenID Connect (OIDC) provider in AWS.
- AWS validates the token. Afterward, depending on the trust policy, AWS issues short-lived, temporary credentials, including an access key ID, secret access key, and session token, for the log collector to use.
On STS-enabled clusters such as Red Hat OpenShift Service on AWS, AWS roles are pre-configured with the required trust policies. This allows service accounts to assume the roles. Therefore, you can create a secret for AWS with STS that uses the IAM role. You can then create or update a ClusterLogForwarder
custom resource (CR) that uses the secret to forward logs to CloudWatch output. Follow these procedures to create a secret and a ClusterLogForwarder
CR if roles have been pre-configured:
- Creating a secret for CloudWatch with an existing AWS role
- Forwarding logs to Amazon CloudWatch from STS-enabled clusters
If you do not have an AWS IAM role pre-configured with trust policies, you must first create the role with the required trust policies. Complete the following procedures to create a secret, ClusterLogForwarder
CR, and role.
1.5.1. Creating an AWS IAM role Copiar enlaceEnlace copiado en el portapapeles!
Create an Amazon Web Services (AWS) IAM role that your service account can assume to securely access AWS resources.
The following procedure demonstrates creating an AWS IAM role by using the AWS CLI. You can alternatively use the Cloud Credential Operator (CCO) utility ccoctl
. Using the ccoctl
utility creates many fields in the IAM role policy that are not required by the ClusterLogForwarder
custom resource (CR). These extra fields are ignored by the CR. However, the ccoctl
utility provides a convenient way for configuring IAM roles. For more information see Manual mode with short-term credentials for components.
Prerequisites
- You have access to an Red Hat OpenShift Logging cluster with Security Token Service (STS) enabled and configured for AWS.
- You have administrator access to the AWS account.
- AWS CLI installed.
Procedure
Create an IAM policy that grants permissions to write logs to CloudWatch.
Create a file, for example
cw-iam-role-policy.json
, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the IAM policy based on the previous policy definition by running the following command:
aws iam create-policy \ --policy-name cluster-logging-allow \ --policy-document file://cw-iam-role-policy.json
aws iam create-policy \ --policy-name cluster-logging-allow \ --policy-document file://cw-iam-role-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note the
Arn
value of the created policy.
Create a trust policy to allow the logging service account to assume an IAM role:
Create a file, for example
cw-trust-policy.json
, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create an IAM role based on the previously defined trust policy by running the following command:
aws iam create-role --role-name openshift-logger --assume-role-policy-document file://cw-trust-policy.json
$ aws iam create-role --role-name openshift-logger --assume-role-policy-document file://cw-trust-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note the
Arn
value of the created role.Attach the policy to the role by running the following command:
aws iam put-role-policy \ --role-name openshift-logger --policy-name cluster-logging-allow \ --policy-document file://cw-role-policy.json
$ aws iam put-role-policy \ --role-name openshift-logger --policy-name cluster-logging-allow \ --policy-document file://cw-role-policy.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Verify the role and the permissions policy by running the following command:
aws iam get-role --role-name openshift-logger
$ aws iam get-role --role-name openshift-logger
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
ROLE arn:aws:iam::123456789012:role/openshift-logger ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:openshift-logging:openshift-logger PRINCIPAL arn:aws:iam::123456789012:oidc-provider/<OPENSHIFT_OIDC_PROVIDER_URL>
ROLE arn:aws:iam::123456789012:role/openshift-logger ASSUMEROLEPOLICYDOCUMENT 2012-10-17 STATEMENT sts:AssumeRoleWithWebIdentity Allow STRINGEQUALS system:serviceaccount:openshift-logging:openshift-logger PRINCIPAL arn:aws:iam::123456789012:oidc-provider/<OPENSHIFT_OIDC_PROVIDER_URL>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.2. Creating a secret for AWS CloudWatch with an existing AWS role Copiar enlaceEnlace copiado en el portapapeles!
Create a secret for Amazon Web Services (AWS) Security Token Service (STS) from the configured AWS IAM role by using the oc create secret --from-literal
command.
Prerequisites
- You have created an AWS IAM role.
- You have administrator access to Red Hat OpenShift Logging.
Procedure
In the CLI, enter the following to generate a secret for AWS:
oc create secret generic sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/openshift-logger
$ oc create secret generic sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/openshift-logger
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example Secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.3. Forwarding logs to Amazon CloudWatch from STS-enabled clusters Copiar enlaceEnlace copiado en el portapapeles!
You can forward logs from logging for Red Hat OpenShift deployed on clusters with Amazon Web Services (AWS) Security Token Service (STS)-enabled to Amazon CloudWatch. Amazon CloudWatch is a service that helps administrators observe and monitor resources and applications on AWS.
Prerequisites
- Red Hat OpenShift Logging Operator has been installed.
- You have configured a credential secret.
- You have administrator access to Red Hat OpenShift Logging.
Procedure
Create or update a
ClusterLogForwarder
custom resource (CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the service account.
- 2
- Specify a name for the output.
- 3
- Specify the
cloudwatch
type. - 4
- Specify the group name for the log stream.
- 5
- Specify the AWS region.
- 6
- Specify
iamRole
as the authentication type for STS. - 7
- Specify the name of the secret and the key where the
role_arn
resource is stored. - 8
- Specify the service account token to use for authentication. To use the projected service account token, use
from: serviceAccount
. - 9
- Specify which log types to forward by using the pipeline:
application,
infrastructure
, oraudit
. - 10
- Specify the names of the output to use when forwarding logs with this pipeline.
1.5.4. Configuring content filters to drop unwanted log records Copiar enlaceEnlace copiado en el portapapeles!
Collecting all cluster logs produces a large amount of data, which can be expensive to move and store. To reduce volume, you can configure the drop
filter to exclude unwanted log records before forwarding. The log collector evaluates log streams against the filter and drops records that match specified conditions.
The drop
filter uses the test
field to define one or more conditions for evaluating log records. The filter applies the following rules to check whether to drop a record:
- A test passes if all its specified conditions evaluate to true.
- If a test passes, the filter drops the log record.
-
If you define several tests in the
drop
filter configuration, the filter drops the log record if any of the tests pass. - If there is an error evaluating a condition, for example, the referenced field is missing, that condition evaluates to false.
Prerequisites
- You have installed the Red Hat OpenShift Logging Operator.
- You have administrator permissions.
-
You have created a
ClusterLogForwarder
custom resource (CR). -
You have installed the OpenShift CLI (
oc
).
Procedure
Extract the existing
ClusterLogForwarder
configuration and save it as a local file.oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
$ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
<name>
is the name of theClusterLogForwarder
instance you want to configure. -
<namespace>
is the namespace where you created theClusterLogForwarder
instance, for exampleopenshift-logging
. -
<filename>
is the name of the local file where you save the configuration.
-
Add a configuration to drop unwanted log records to the
filters
spec in theClusterLogForwarder
CR.Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the type of filter. The
drop
filter drops log records that match the filter configuration. - 2
- Specify configuration options for the
drop
filter. - 3
- Specify conditions for tests to evaluate whether the filter drops a log record.
- 4
- Specify dot-delimited paths to fields in log records.
-
Each path segment can contain alphanumeric characters and underscores,
a-z
,A-Z
,0-9
,_
, for example,.kubernetes.namespace_name
. -
If segments contain different characters, the segment must be in quotes, for example,
.kubernetes.labels."app.version-1.2/beta"
. -
You can include several field paths in a single
test
configuration, but they must all evaluate to true for the test to pass and thedrop
filter to apply.
-
Each path segment can contain alphanumeric characters and underscores,
- 5
- Specify a regular expression. If log records match this regular expression, they are dropped.
- 6
- Specify a regular expression. If log records do not match this regular expression, they are dropped.
- 7
- Specify the pipeline that uses the
drop
filter.
NoteYou can set either the
matches
ornotMatches
condition for a singlefield
path, but not both.Example configuration that keeps only high-priority log records
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example configuration with several tests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the
ClusterLogForwarder
CR by running the following command:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.5. API audit filter overview Copiar enlaceEnlace copiado en el portapapeles!
OpenShift API servers generate audit events for every API call. These events include details about the request, the response, and the identity of the requester. This can lead to large volumes of data.
The API audit filter helps manage the audit trail by using rules to exclude non-essential events and to reduce the event size. Rules are checked in order, and checking stops at the first match. The amount of data in an event depends on the value of the level
field:
-
None
: The event is dropped. -
Metadata
: The event includes audit metadata and excludes request and response bodies. -
Request
: The event includes audit metadata and the request body, and excludes the response body. -
RequestResponse
: The event includes all data: metadata, request body and response body. The response body can be very large. For example,oc get pods -A
generates a response body containing the YAML description of every pod in the cluster.
You can only use the API audit filter feature if the Vector collector is set up in your logging deployment.
The ClusterLogForwarder
custom resource (CR) uses the same format as the standard Kubernetes audit policy. The ClusterLogForwarder
CR provides the following additional functions:
- Wildcards
-
Names of users, groups, namespaces, and resources can have a leading or trailing
*
asterisk character. For example, theopenshift-\*
namespace matchesopenshift-apiserver
oropenshift-authentication
namespaces. The\*/status
resource matchesPod/status
orDeployment/status
resources. - Default Rules
Events that do not match any rule in the policy are filtered as follows:
-
Read-only system events such as
get
,list
, andwatch
are dropped. - Service account write events that occur within the same namespace as the service account are dropped.
- All other events are forwarded, subject to any configured rate limits.
To disable these defaults, either end your rules list with a rule that has only a
level
field or add an empty rule.-
Read-only system events such as
- Omit Response Codes
-
A list of integer status codes to omit. You can drop events based on the HTTP status code in the response by using the
OmitResponseCodes
field, which lists HTTP status codes for which no events are created. The default value is[404, 409, 422, 429]
. If the value is an empty list,[]
, no status codes are omitted.
The ClusterLogForwarder
CR audit policy acts in addition to the OpenShift Container Platform audit policy. The ClusterLogForwarder
CR audit filter changes what the log collector forwards, and provides the ability to filter by verb, user, group, namespace, or resource. You can create multiple filters to send different summaries of the same audit stream to different places. For example, you can send a detailed stream to the local cluster log store, and a less detailed stream to a remote site.
-
You must have the
collect-audit-logs
cluster role to collect the audit logs. - The following example provided is intended to illustrate the range of rules possible in an audit policy and is not a recommended configuration.
Example audit policy
1.5.6. Filtering application logs at input by including the label expressions or a matching label key and values Copiar enlaceEnlace copiado en el portapapeles!
You can include the application logs based on the label expressions or a matching label key and its values by using the input
selector.
Procedure
Add a configuration for a filter to the
input
spec in theClusterLogForwarder
CR.The following example shows how to configure the
ClusterLogForwarder
CR to include logs based on label expressions or matched label key/values:Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the
ClusterLogForwarder
CR by running the following command:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.7. Configuring content filters to prune log records Copiar enlaceEnlace copiado en el portapapeles!
If you configure the prune
filter, the log collector evaluates log streams against the filters before forwarding. The collector prunes log records by removing low value fields such as pod annotations.
Prerequisites
- You have installed the Red Hat OpenShift Logging Operator.
- You have administrator permissions.
-
You have created a
ClusterLogForwarder
custom resource (CR). -
You have installed the OpenShift CLI (
oc
).
Procedure
Extract the existing
ClusterLogForwarder
configuration and save it as a local file.oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
$ oc get clusterlogforwarder <name> -n <namespace> -o yaml > <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
<name>
is the name of theClusterLogForwarder
instance you want to configure. -
<namespace>
is the namespace where you created theClusterLogForwarder
instance, for exampleopenshift-logging
. -
<filename>
is the name of the local file where you save the configuration.
-
Add a configuration to prune log records to the
filters
spec in theClusterLogForwarder
CR.ImportantIf you specify both
in
andnotIn
parameters, thenotIn
array takes precedence overin
during pruning. After records are pruned by using thenotIn
array, they are then pruned by using thein
array.Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the type of filter. The
prune
filter prunes log records by configured fields. - 2
- Specify configuration options for the
prune
filter.-
The
in
andnotIn
fields are arrays of dot-delimited paths to fields in log records. -
Each path segment can contain alpha-numeric characters and underscores,
a-z
,A-Z
,0-9
,_
, for example,.kubernetes.namespace_name
. -
If segments contain different characters, the segment must be in quotes, for example,
.kubernetes.labels."app.version-1.2/beta"
.
-
The
- 3
- Optional: Specify fields to remove from the log record. The log collector keeps all other fields.
- 4
- Optional: Specify fields to keep in the log record. The log collector removes all other fields.
- 5
- Specify the pipeline that the
prune
filter is applied to.Important-
The filters cannot remove the
.log_type
,.log_source
,.message
fields from the log records. You must include them in thenotIn
field. -
If you use the
googleCloudLogging
output, you must include.hostname
in thenotIn
field.
-
The filters cannot remove the
Apply the
ClusterLogForwarder
CR by running the following command:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.6. Filtering the audit and infrastructure log inputs by source Copiar enlaceEnlace copiado en el portapapeles!
You can define the list of audit
and infrastructure
sources to collect the logs by using the input
selector.
Procedure
Add a configuration to define the
audit
andinfrastructure
sources in theClusterLogForwarder
CR.The following example shows how to configure the
ClusterLogForwarder
CR to defineaudit
andinfrastructure
sources:Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specifies the list of infrastructure sources to collect. The valid sources include:
-
node
: Journal log from the node -
container
: Logs from the workloads deployed in the namespaces
-
- 2
- Specifies the list of audit sources to collect. The valid sources include:
-
kubeAPI
: Logs from the Kubernetes API servers -
openshiftAPI
: Logs from the OpenShift API servers -
auditd
: Logs from a node auditd service -
ovn
: Logs from an open virtual network service
-
Apply the
ClusterLogForwarder
CR by running the following command:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.7. Filtering application logs at input by including or excluding the namespace or container name Copiar enlaceEnlace copiado en el portapapeles!
You can include or exclude the application logs based on the namespace and container name by using the input
selector.
Procedure
Add a configuration to include or exclude the namespace and container names in the
ClusterLogForwarder
CR.The following example shows how to configure the
ClusterLogForwarder
CR to include or exclude namespaces and container names:Example
ClusterLogForwarder
CRCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe
excludes
field takes precedence over theincludes
field.Apply the
ClusterLogForwarder
CR by running the following command:oc apply -f <filename>.yaml
$ oc apply -f <filename>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow