Merge pull request #96017 from gwynnemonahan/OSDOCS-15280

OSDOCS-15280 [NETOBSERV] Line break for configuring-operator.adoc ass…

Author: mburke5678

modules/network-observability-configuring-FLP-sampling.adoc

@@ -6,6 +6,7 @@
 [id="network-observability-config-FLP-sampling_{context}"]
 
 = Updating the Flow Collector resource
+
 As an alternative to editing YAML in the {product-title} web console, you can configure specifications, such as eBPF sampling, by patching the `flowcollector` custom resource (CR):
 
 .Procedure

modules/network-observability-enriched-flows.adoc

@@ -6,14 +6,13 @@
 [id="network-observability-enriched-flows_{context}"]
 = Export enriched network flow data
 
-You can send network flows to Kafka, IPFIX, the Red{nbsp}Hat build of OpenTelemetry, or all three at the same time. For Kafka or IPFIX, any processor or storage that supports those inputs, such as Splunk, Elasticsearch, or Fluentd, can consume the enriched network flow data. For OpenTelemetry, network flow data and metrics can be exported to a compatible OpenTelemetry endpoint, such as Red{nbsp}Hat build of OpenTelemetry, Jaeger, or Prometheus. 
+You can send network flows to Kafka, IPFIX, the Red{nbsp}Hat build of OpenTelemetry, or all three at the same time. For Kafka or IPFIX, any processor or storage that supports those inputs, such as Splunk, Elasticsearch, or Fluentd, can consume the enriched network flow data. For OpenTelemetry, network flow data and metrics can be exported to a compatible OpenTelemetry endpoint, such as Red{nbsp}Hat build of OpenTelemetry, Jaeger, or Prometheus.
 
 .Prerequisites
 * Your Kafka, IPFIX, or OpenTelemetry collector endpoints are available from Network Observability `flowlogs-pipeline` pods.
 
 
 .Procedure
-
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for the *NetObserv Operator*, select *Flow Collector*.
 . Select *cluster* and then select the *YAML* tab.
@@ -56,10 +55,10 @@ spec:
 ----
 <1> You can export flows to IPFIX, OpenTelemetry, and Kafka individually or concurrently.
 <2> The Network Observability Operator exports all flows to the configured Kafka topic.
-<3> You can encrypt all communications to and from Kafka with SSL/TLS or mTLS. When enabled, the Kafka CA certificate must be available as a ConfigMap or a Secret, both in the namespace where the `flowlogs-pipeline` processor component is deployed (default: netobserv). It must be referenced with `spec.exporters.tls.caCert`. When using mTLS, client secrets must be available in these namespaces as well (they can be generated for instance using the AMQ Streams User Operator) and referenced with `spec.exporters.tls.userCert`. 
+<3> You can encrypt all communications to and from Kafka with SSL/TLS or mTLS. When enabled, the Kafka CA certificate must be available as a ConfigMap or a Secret, both in the namespace where the `flowlogs-pipeline` processor component is deployed (default: netobserv). It must be referenced with `spec.exporters.tls.caCert`. When using mTLS, client secrets must be available in these namespaces as well (they can be generated for instance using the AMQ Streams User Operator) and referenced with `spec.exporters.tls.userCert`.
 <4> You have the option to specify transport. The default value is `tcp` but you can also specify `udp`.
 <5> The protocol of OpenTelemetry connection. The available options are `http` and `grpc`.
-<6> OpenTelemetry configuration for exporting logs, which are the same as the logs created for Loki. 
+<6> OpenTelemetry configuration for exporting logs, which are the same as the logs created for Loki.
 <7> OpenTelemetry configuration for exporting metrics, which are the same as the metrics created for Prometheus. These configurations are specified in the `spec.processor.metrics.includeList` parameter of the `FlowCollector` custom resource, along with any custom metrics you defined using the `FlowMetrics` custom resource.
 <8> The time interval that metrics are sent to the OpenTelemetry collector.
 <9> *Optional*:Network Observability network flows formats get automatically renamed to an OpenTelemetry compliant format. The `fieldsMapping` specification gives you the ability to customize the OpenTelemetry format output. For example in the YAML sample, `SrcAddr` is the Network Observability input field, and it is being renamed `source.address` in OpenTelemetry output. You can see both Network Observability and OpenTelemetry formats in the "Network flows format reference".

modules/network-observability-flowcollector-kafka-config.adoc

@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-flowcollector-kafka-config_{context}"]
 = Configuring the Flow Collector resource with Kafka
+
 You can configure the `FlowCollector` resource to use Kafka for high-throughput and low-latency data feeds. A Kafka instance needs to be running, and a Kafka topic dedicated to {product-title} Network Observability must be created in that instance. For more information, see link:https://access.redhat.com/documentation/en-us/red_hat_amq/7.7/html/using_amq_streams_on_openshift/using-the-topic-operator-str[Kafka documentation with AMQ Streams].
 
 .Prerequisites

modules/network-observability-flowcollector-view.adoc

@@ -5,6 +5,7 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-flowcollector-view_{context}"]
 = View the FlowCollector resource
+
 You can view and edit YAML directly in the {product-title} web console.
 
 .Procedure
@@ -44,7 +45,7 @@ spec:
         cpu: 100m
       limits:
         memory: 800Mi
-    logTypes: Flows                           
+    logTypes: Flows
     advanced:
       conversationEndTimeout: 10s
       conversationHeartbeatInterval: 30s

modules/network-observability-resources-table.adoc

@@ -4,6 +4,7 @@
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-resources-table_{context}"]
 = Resource considerations
+
 The following table outlines examples of resource considerations for clusters with certain workload sizes.
 
 [IMPORTANT]