chore: rename hostname into pod_name dimension and fix documentation …

…accordingly

src/content/docs/logs/forward-logs/kubernetes-plugin-log-forwarding.mdx

@@ -61,8 +61,8 @@ To configure your Kubernetes cluster to send the log forwarder internal metrics
 ### Additional metric details
 The `newrelic-logging` Helm chart uses [Fluent Bit](https://fluentbit.io/) together with New Relic's [newrelic-fluent-bit-output plugin](https://github.com/newrelic/newrelic-fluent-bit-output) to send logs to New Relic. The `fluentBit.sendMetrics` configuration option enables the collection of their individual metrics:
 
-  * **[Fluent Bit internal metrics](https://docs.fluentbit.io/manual/administration/monitoring#for-v2-metrics)**: emitted by Fluent Bit in Prometheus format and delivered to New Relic's Prometheus Export endpoint. **These are the recommended ones to troubleshoot a Kubernetes cluster** because they can be faceted by `cluster_name`, `node_name` and `hostname` (pod name).
-  * **[newrelic-fluent-bit-output's internal plugin metrics](https://github.com/newrelic/newrelic-fluent-bit-output?tab=readme-ov-file#troubleshooting-metrics)**: collected by the output plugin and sent to New Relic's Metric API. These metrics do not contain dimensions, so they cannot be narrowed down to a particular cluster or host. Despite this, capturing them for a single cluster is useful to assess the overall latency when delivering the logs to the New Relic Logs API or to observe potential packaging problems.
+  * **[Fluent Bit internal metrics](https://docs.fluentbit.io/manual/administration/monitoring#for-v2-metrics)**: emitted by Fluent Bit in Prometheus format and delivered to New Relic's Prometheus Export endpoint. They can be faceted by `cluster_name`, `node_name` and `pod_name`.
+  * **[newrelic-fluent-bit-output's internal plugin metrics](https://github.com/newrelic/newrelic-fluent-bit-output?tab=readme-ov-file#troubleshooting-metrics)**: collected by the output plugin and sent to New Relic's Metric API. These metrics only contain the `cluster_name` dimension, so they can be narrowed down to a particular cluster but not to a particular host or pod. They are useful to assess the overall latency when delivering the logs to the New Relic Logs API or to observe potential packaging problems.
 
 We capture Fluent Bit's internal metrics by using its [prometheus_scrape INPUT plugin](https://docs.fluentbit.io/manual/pipeline/inputs/prometheus-scrape-metrics) in conjunction with its [prometheus_remote_write OUTPUT plugin](https://docs.fluentbit.io/manual/pipeline/outputs/prometheus-remote-write). All the Prometheus `counter` metrics are actually _cumulative counters_, but we automatically perform a _delta conversion_ when they are ingested at New Relic to ease querying them using NRQL later. You can find more details [here](/docs/data-apis/understand-data/metric-data/cumulative-metrics/).