OBSDOCS-642: Add docs for creating the LogFileMetricExporter CR

Author: abrennan89

logging/log_collection_forwarding/cluster-logging-collector.adoc

@@ -12,6 +12,8 @@ All supported modifications to the log collector can be performed though the `sp
 
 include::modules/configuring-logging-collector.adoc[leveloffset=+1]
 
+include::modules/creating-logfilesmetricexporter.adoc[leveloffset=+1]
+
 include::modules/log-collector-resources-scheduling.adoc[leveloffset=+1]
 
 include::modules/cluster-logging-collector-pod-location.adoc[leveloffset=+1]

modules/creating-logfilesmetricexporter.adoc

@@ -0,0 +1,71 @@
+// Module included in the following assemblies:
+//
+// * logging/log_collection_forwarding/cluster-logging-collector.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="creating-logfilesmetricexporter_{context}"]
+= Creating a LogFileMetricExporter resource
+
+In {logging} version 5.8 and newer versions, the LogFileMetricExporter is no longer deployed with the collector by default. You must manually create a `LogFileMetricExporter` custom resource (CR) to generate metrics from the logs produced by running containers.
+
+If you do not create the `LogFileMetricExporter` CR, you may see a *No datapoints found* message in the {product-title} web console dashboard for *Produced Logs*.
+
+.Prerequisites
+
+* You have administrator permissions.
+* You have installed the {clo}.
+* You have installed the {oc-first}.
+
+.Procedure
+
+. Create a `LogFileMetricExporter` CR as a YAML file:
++
+.Example `LogFileMetricExporter` CR
+[source,yaml]
+----
+apiVersion: logging.openshift.io/v1alpha1
+kind: LogFileMetricExporter
+metadata:
+  name: instance
+  namespace: openshift-logging
+spec:
+  nodeSelector: {} # <1>
+  resources: # <2>
+    limits:
+      cpu: 500m
+      memory: 256Mi
+    requests:
+      cpu: 200m
+      memory: 128Mi
+  tolerations: [] # <3>
+# ...
+----
+<1> Optional: The `nodeSelector` stanza defines which nodes the pods are scheduled on.
+<2> The `resources` stanza defines resource requirements for the `LogFileMetricExporter` CR.
+<3> Optional: The `tolerations` stanza defines the tolerations that the pods accept.
+
+. Apply the `LogFileMetricExporter` CR by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f <filename>.yaml
+----
+
+.Verification
+
+A `logfilesmetricexporter` pod runs concurrently with a `collector` pod on each node.
+
+* Verify that the `logfilesmetricexporter` pods are running in the namespace where you have created the `LogFileMetricExporter` CR, by running the following command and observing the output:
++
+[source,terminal]
+----
+$ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging
+----
++
+.Example output
+[source,terminal]
+----
+NAME                           READY   STATUS    RESTARTS   AGE
+logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
+logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s
+----

modules/logging-release-notes-5-8-0.adoc

@@ -6,13 +6,17 @@ This release includes link:https://access.redhat.com/errata/RHBA-2023:6139[OpenS
 
 [id="logging-release-notes-5-8-0-deprecation-notice"]
 == Deprecation notice
+
 In Logging 5.8, Elasticsearch, Fluentd, and Kibana are deprecated and are planned to be removed in Logging 6.0, which is expected to be shipped alongside a future release of {product-title}. Red Hat will provide critical and above CVE bug fixes and support for these components during the current release lifecycle, but these components will no longer receive feature enhancements. The Vector-based collector provided by the {clo} and LokiStack provided by the {loki-op} are the preferred Operators for log collection and storage. We encourage all users to adopt the Vector and Loki log stack, as this will be the stack that will be enhanced going forward.
 
 [id="logging-release-notes-5-8-0-enhancements"]
 == Enhancements
 
 [id="logging-release-notes-5-8-0-log-collection"]
 === Log Collection
+
+* With this update, the LogFileMetricExporter is no longer deployed with the collector by default. You must manually create a `LogFileMetricExporter` custom resource (CR) to generate metrics from the logs produced by running containers. If you do not create the `LogFileMetricExporter` CR, you may see a *No datapoints found* message in the {product-title} web console dashboard for *Produced Logs*. (link:https://issues.redhat.com/browse/LOG-3819[LOG-3819])
+
 * With this update, you can deploy multiple, isolated, and RBAC-protected `ClusterLogForwarder` custom resource (CR) instances in any namespace. This allows independent groups to forward desired logs to any destination while isolating their configuration from other collector deployments. (link:https://issues.redhat.com/browse/LOG-1343[LOG-1343])
 +
 [IMPORTANT]
@@ -28,6 +32,7 @@ In order to support multi-cluster log forwarding in additional namespaces other
 
 [id="logging-release-notes-5-8-0-log-storage"]
 === Log Storage
+
 * With this update, LokiStack administrators can have more fine-grained control over who can access which logs by granting access to logs on a namespace basis. (link:https://issues.redhat.com/browse/LOG-3841[LOG-3841])
 
 * With this update, the {loki-op} introduces `PodDisruptionBudget` configuration on LokiStack deployments to ensure normal operations during {product-title} cluster restarts by keeping ingestion and the query path available. (link:https://issues.redhat.com/browse/LOG-3839[LOG-3839])
@@ -43,12 +48,14 @@ In order to support multi-cluster log forwarding in additional namespaces other
 
 [id="logging-release-notes-5-8-0-log-console"]
 === Log Console
+
 * With this update, you can enable the Logging Console Plugin when Elasticsearch is the default Log Store. (link:https://issues.redhat.com/browse/LOG-3856[LOG-3856])
 
 * With this update, {product-title} application owners can receive notifications for application log-based alerts on the {product-title} web console *Developer* perspective for {product-title} version 4.14 and later. (link:https://issues.redhat.com/browse/LOG-3548[LOG-3548])
 
 [id="logging-release-notes-5-8-0-known-issues"]
 == Known Issues
+
 * Currently, there is a flaw in handling multiplexed streams in the HTTP/2 protocol, where you can repeatedly make a request for a new multiplex stream and immediately send an `RST_STREAM` frame to cancel it. This created extra work for the server set up and tore down the streams, resulting in a denial of service due to server resource consumption. There is currently no workaround for this issue. (link:https://issues.redhat.com/browse/LOG-4609[LOG-4609])
 
 * Currently, when using  FluentD as the collector, the collector pod cannot start on the {product-title} IPv6-enabled cluster. The pod logs produce the `fluentd pod [error]: unexpected error error_class=SocketError error="getaddrinfo: Name or service not known` error. There is currently no workaround for this issue. (link:https://issues.redhat.com/browse/LOG-4706[LOG-4706])
@@ -59,7 +66,6 @@ In order to support multi-cluster log forwarding in additional namespaces other
 
 * Currently, when deploying the {logging} version 5.8 on a FIPS-enabled cluster, the collector pods cannot start and are stuck in `CrashLoopBackOff` status, while using FluentD as a collector. There is currently no workaround for this issue. (link:https://issues.redhat.com/browse/LOG-3933[LOG-3933])
 
-
 [id="logging-release-notes-5-8-0-CVEs"]
 == CVEs
 * link:https://access.redhat.com/security/cve/CVE-2023-40217[CVE-2023-40217]