docs: apply consistent capitalization of "Node" (#2654)

Author: NHingerl

docs/user/architecture/README.md

@@ -30,11 +30,11 @@ Gateways and agents handle the incoming telemetry data. The Telemetry Manager de
 
 The gateways are based on an [OTel Collector](https://opentelemetry.io/docs/collector/) [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) and act as central endpoints in the cluster to which your applications push data in the OTLP format. From here, the data is enriched and filtered, and then dispatched configured in your pipeline resources.
 
-Agents run as [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and pull data from the respective Node.
+Agents run as [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and pull data from the respective node.
 
 - Log Gateway and Agent
 
-  The log gateway provides a central OTLP endpoint for logs. You can also enable the log agent, which collects logs from the stdout/stderr output of all containers on a Node. For details, see [Logs Architecture](./logs-architecture.md).
+  The log gateway provides a central OTLP endpoint for logs. You can also enable the log agent, which collects logs from the stdout/stderr output of all containers on a node. For details, see [Logs Architecture](./logs-architecture.md).
 
   As an alternative to the OTLP-based log feature, you can choose using a log agent based on a [Fluent Bit](https://fluentbit.io/) installation running as a DaemonSet. It reads all containers’ logs in the runtime and ships them according to your LogPipeline configuration. For details, see [Application Logs (Fluent Bit)](./../02-logs.md).
 
@@ -44,7 +44,7 @@ The trace gateway provides a central [OTLP](https://opentelemetry.io/docs/specs/
 
 - Metric Gateway and Agent
 
-  The metric gateway provides a central OTLP endpoint for metrics. You can also enable the metric agent, which scrapes Prometheus-annotated workloads on each Node. For details, see [Metrics Architecture](./metrics-architecture.md).
+  The metric gateway provides a central OTLP endpoint for metrics. You can also enable the metric agent, which scrapes Prometheus-annotated workloads on each node. For details, see [Metrics Architecture](./metrics-architecture.md).
 
 ## Self Monitor
 

docs/user/architecture/logs-architecture.md

@@ -4,8 +4,8 @@ The Telemetry module provides a central Deployment of an [OTel Collector](https:
 
 ![Architecture](./../assets/logs-arch.drawio.svg)
 
-1. Application containers print JSON logs to the `stdout/stderr` channel and are stored by the Kubernetes container runtime under the `var/log` directory and its subdirectories at the related Node. Istio is configured to write access logs to `stdout` as well.
-2. If you choose to use the agent, an OTel Collector runs as a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) (one instance per Node), detects any new log files in the folder, and tails and parses them.
+1. Application containers print JSON logs to the `stdout/stderr` channel and are stored by the Kubernetes container runtime under the `var/log` directory and its subdirectories at the related node. Istio is configured to write access logs to `stdout` as well.
+2. If you choose to use the agent, an OTel Collector runs as a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) (one instance per node), detects any new log files in the folder, and tails and parses them.
 3. An application (exposing logs in OTLP) sends logs to the central log gateway using the `telemetry-otlp-logs` service. Istio is configured to push access logs with OTLP as well.
 4. The gateway and agent discover the metadata and enrich all received data with metadata of the source by communicating with the Kubernetes APIServer. Furthermore, they filter data according to the pipeline configuration.
 5. Telemetry Manager configures the agent and gateway according to the LogPipeline resource specification, including the target backend. Also, it observes the logs flow to the backend and reports problems in the LogPipeline status.

docs/user/filter-and-process/automatic-data-enrichment.md

@@ -29,7 +29,7 @@ The gateway determines the service name based on the following hierarchy of labe
 - `k8s.namespace.name`: The Kubernetes namespace name with which the emitting Pod is associated.
 - `k8s.cluster.name`: A logical identifier of the cluster, which, by default, is the API Server URL. To set a custom name, configure the `enrichments.cluster.name` field in the Telemetry CRD.
 - `k8s.cluster.uid`: A unique identifier of the cluster, realized by the UID of the `kube-system` namespace.
-- `k8s.node.name`: The Kubernetes node name to which the emitting Pod is scheduled.
+- `k8s.node.name`: The Kubernetes Node name to which the emitting Pod is scheduled.
 - `k8s.node.uid`: The Kubernetes Node ID to which the emitting Pod belongs.
 
 ## Pod Label Attributes