mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 03:47:04 +01:00
76 lines
3.3 KiB
Plaintext
76 lines
3.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * observability/logging/log_collection_forwarding/configuring-log-forwarding.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="cluster-logging-collector-log-forward-logs-from-application-pods_{context}"]
|
|
= Forwarding application logs from specific pods
|
|
|
|
As a cluster administrator, you can use Kubernetes pod labels to gather log data from specific pods and forward it to a log collector.
|
|
|
|
Suppose that you have an application composed of pods running alongside other pods in various namespaces. If those pods have labels that identify the application, you can gather and output their log data to a specific log collector.
|
|
|
|
To specify the pod labels, you use one or more `matchLabels` key-value pairs. If you specify multiple key-value pairs, the pods must match all of them to be selected.
|
|
|
|
.Procedure
|
|
|
|
. Create or edit a YAML file that defines the `ClusterLogForwarder` CR object. In the file, specify the pod labels using simple equality-based selectors under `inputs[].name.application.selector.matchLabels`, as shown in the following example.
|
|
+
|
|
.Example `ClusterLogForwarder` CR YAML file
|
|
[source,yaml]
|
|
----
|
|
apiVersion: logging.openshift.io/v1
|
|
kind: ClusterLogForwarder
|
|
metadata:
|
|
name: <log_forwarder_name> <1>
|
|
namespace: <log_forwarder_namespace> <2>
|
|
spec:
|
|
pipelines:
|
|
- inputRefs: [ myAppLogData ] <3>
|
|
outputRefs: [ default ] <4>
|
|
inputs: <5>
|
|
- name: myAppLogData
|
|
application:
|
|
selector:
|
|
matchLabels: <6>
|
|
environment: production
|
|
app: nginx
|
|
namespaces: <7>
|
|
- app1
|
|
- app2
|
|
outputs: <8>
|
|
- <output_name>
|
|
...
|
|
----
|
|
<1> In legacy implementations, the CR name must be `instance`. In multi log forwarder implementations, you can use any name.
|
|
<2> In legacy implementations, the CR namespace must be `openshift-logging`. In multi log forwarder implementations, you can use any namespace.
|
|
<3> Specify one or more comma-separated values from `inputs[].name`.
|
|
<4> Specify one or more comma-separated values from `outputs[]`.
|
|
<5> Define a unique `inputs[].name` for each application that has a unique set of pod labels.
|
|
<6> Specify the key-value pairs of pod labels whose log data you want to gather. You must specify both a key and value, not just a key. To be selected, the pods must match all the key-value pairs.
|
|
<7> Optional: Specify one or more namespaces.
|
|
<8> Specify one or more outputs to forward your log data to.
|
|
|
|
. Optional: To restrict the gathering of log data to specific namespaces, use `inputs[].name.application.namespaces`, as shown in the preceding example.
|
|
|
|
. Optional: You can send log data from additional applications that have different pod labels to the same pipeline.
|
|
.. For each unique combination of pod labels, create an additional `inputs[].name` section similar to the one shown.
|
|
.. Update the `selectors` to match the pod labels of this application.
|
|
.. Add the new `inputs[].name` value to `inputRefs`. For example:
|
|
+
|
|
----
|
|
- inputRefs: [ myAppLogData, myOtherAppLogData ]
|
|
----
|
|
|
|
. Create the CR object:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc create -f <file-name>.yaml
|
|
----
|
|
|
|
[role="_additional-resources"]
|
|
.Additional resources
|
|
|
|
* For more information on `matchLabels` in Kubernetes, see link:https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements[Resources that support set-based requirements].
|