> Initial situation:

• The OCP cluster (with global proxy configured) was upgraded from 4.12 to 4.14.
• During the maintenance window, also the openshift-logging was upgraded to the version 5.9.0 as highlighted at [1]
• The Customer proxy variable (http_proxy, https_proxy and no_proxy) are extended to the collector POD (FluentD) [2]
• The OCP logging was configured to forward the collector logs to an external log management platform (endpoint http://external.elasticsearch.com)

> Problem Description:

• The FluentD (collector POD) of the openshift-logging 5.9.0 doesn't respect the no_proxy variable injected into the POD: no_proxy=<no proxy entries >
  The final result of this behaviour is that the FluentD was trying to reach the external ELK (external.elasticsearch.com) through the Customer's Proxy instead of via direct connection as effect of the no_proxy

It seems the same described in bug: https://issues.redhat.com/browse/LOG-4784

> Current Status
After applying the solution 7043785 (https://access.redhat.com/solutions/7043785), the issue was mitigated:

1 - "oc edit ClusterLogging instance -n openshift-logging" and change the spec.managementState to Unmanaged

2 - "oc edit ds collector -n openshift-logging" and delete env variables HTTP_PROXY and HTTPS_PROXY from collector daemonset.

[1]

# oc get csv
NAME DISPLAY VERSION REPLACES PHASE
cluster-logging.v5.9.0 Red Hat OpenShift Logging 5.9.0 cluster-logging.v5.8.5 Succeeded
elasticsearch-operator.v5.8.5 OpenShift Elasticsearch Operator 5.8.5 elasticsearch-operator.v5.8.4 Succeeded
[...]

[2]
in the FluentD process environ exactly like it was before the OCP 4.12 to OCP 4.13 to OCP 4.14 recent update and it's correctly excluding all the .example.com hosts;

# cat /proc/$(pgrep fluentd)/environ

--- output ommited ---