New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1554293 - logging-eventrouter event not formatted correctly in El… #10207
Conversation
…asticsearch when using MUX If openshift_logging_install_eventrouter is true, set TRANSFORM_EVENTS true in MUX, as well.
|
/test gcp |
1 similar comment
|
/test gcp |
…asticsearch when using MUX
When fluentd is configured as a collector and MUX, event logs from the event
router need to be processed by MUX not by the collector fluentd for the both
MUX_CLIENT_MODE=maximal and minimal cases. It is because if an event log is
formatted in the collector (note: the event record is put under the kubernetes
key), the log is forwarded to MUX and passed to the k8s-meta plugin and the
existing kubernetes record is overwritten.
To avoid the replacement, if the log is from event router, the tag is rewritten
to ${tag}.raw in input-post-forward-mux.conf, which makes the log treated in
the MUX_CLIENT_MODE=minimal way.
There was another bug in ansible. That is, the environment variable TRANSFORM_
EVENTS was not set in MUX even if openshift_logging_install_eventrouter is set
to true. This PR fixes the issue.
openshift/openshift-ansible#10207
In Fluentd run.sh, "process_kubernetes_events false" is set in the filter-viaq-
data-model plugin to suppress processing the event logs. It is _not_ set, i.e.,
event router log processing is enabled, when TRANSFORM_EVENTS is true and the
fluentd is standalone (no MUX configured) or the fluentd is MUX.
|
/retest |
|
/test gcp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
|
@richm , @jcantrill , @ewolinetz , could you please set backport/3.9, 3.10 and 3.11 if possible? It looks I have no right to update Labels... Thanks! |
|
/cherrypick release-3.11 |
|
@vrutkovs: once the present PR merges, I will cherry-pick it on top of release-3.11 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cherrypick release-3.10 |
|
@vrutkovs: once the present PR merges, I will cherry-pick it on top of release-3.10 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cherrypick release-3.9 |
|
@vrutkovs: once the present PR merges, I will cherry-pick it on top of release-3.9 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nhosoi, richm, vrutkovs The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
/test gcp |
|
/test install |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@vrutkovs: new pull request created: #10241 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@vrutkovs: new pull request created: #10242 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@vrutkovs: new pull request created: #10243 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
…asticsearch when using MUX
When fluentd is configured as a collector and MUX, event logs from the event
router need to be processed by MUX not by the collector fluentd for the both
MUX_CLIENT_MODE=maximal and minimal cases. It is because if an event log is
formatted in the collector (note: the event record is put under the kubernetes
key), the log is forwarded to MUX and passed to the k8s-meta plugin and the
existing kubernetes record is overwritten.
To avoid the replacement, if the log is from event router, the tag is rewritten
to ${tag}.raw in input-post-forward-mux.conf, which makes the log treated in
the MUX_CLIENT_MODE=minimal way.
There was another bug in ansible. That is, the environment variable TRANSFORM_
EVENTS was not set in MUX even if openshift_logging_install_eventrouter is set
to true. This PR fixes the issue.
openshift/openshift-ansible#10207
In Fluentd run.sh, "process_kubernetes_events false" is set in the filter-viaq-
data-model plugin to suppress processing the event logs. It is _not_ set, i.e.,
event router log processing is enabled, when TRANSFORM_EVENTS is true and the
fluentd is standalone (no MUX configured) or the fluentd is MUX.
Correct the order of shutdown fluentd, reset MUX_CLIENT_MODE, then restart.
…asticsearch when using MUX
When fluentd is configured as a collector and MUX, event logs from the event
router need to be processed by MUX not by the collector fluentd for the both
MUX_CLIENT_MODE=maximal and minimal cases. It is because if an event log is
formatted in the collector (note: the event record is put under the kubernetes
key), the log is forwarded to MUX and passed to the k8s-meta plugin and the
existing kubernetes record is overwritten.
To avoid the replacement, if the log is from event router, the tag is rewritten
to ${tag}.raw in input-post-forward-mux.conf, which makes the log treated in
the MUX_CLIENT_MODE=minimal way.
There was another bug in ansible. That is, the environment variable TRANSFORM_
EVENTS was not set in MUX even if openshift_logging_install_eventrouter is set
to true. This PR fixes the issue.
openshift/openshift-ansible#10207
In Fluentd run.sh, "process_kubernetes_events false" is set in the filter-viaq-
data-model plugin to suppress processing the event logs. It is _not_ set, i.e.,
event router log processing is enabled, when TRANSFORM_EVENTS is true and the
fluentd is standalone (no MUX configured) or the fluentd is MUX.
Correct the order of shutdown fluentd, reset MUX_CLIENT_MODE, then restart.
…asticsearch when using MUX
When fluentd is configured as a collector and MUX, event logs from the event
router need to be processed by MUX not by the collector fluentd for the both
MUX_CLIENT_MODE=maximal and minimal cases. It is because if an event log is
formatted in the collector (note: the event record is put under the kubernetes
key), the log is forwarded to MUX and passed to the k8s-meta plugin and the
existing kubernetes record is overwritten.
To avoid the replacement, if the log is from event router, the tag is rewritten
to ${tag}.raw in input-post-forward-mux.conf, which makes the log treated in
the MUX_CLIENT_MODE=minimal way.
There was another bug in ansible. That is, the environment variable TRANSFORM_
EVENTS was not set in MUX even if openshift_logging_install_eventrouter is set
to true. This PR fixes the issue.
openshift/openshift-ansible#10207
In Fluentd run.sh, "process_kubernetes_events false" is set in the filter-viaq-
data-model plugin to suppress processing the event logs. It is _not_ set, i.e.,
event router log processing is enabled, when TRANSFORM_EVENTS is true and the
fluentd is standalone (no MUX configured) or the fluentd is MUX.
Correct the order of shutdown fluentd, reset MUX_CLIENT_MODE, then restart.
…asticsearch when using MUX
When fluentd is configured as a collector and MUX, event logs from the event
router need to be processed by MUX not by the collector fluentd for the both
MUX_CLIENT_MODE=maximal and minimal cases. It is because if an event log is
formatted in the collector (note: the event record is put under the kubernetes
key), the log is forwarded to MUX and passed to the k8s-meta plugin and the
existing kubernetes record is overwritten.
To avoid the replacement, if the log is from event router, the tag is rewritten
to ${tag}.raw in input-post-forward-mux.conf, which makes the log treated in
the MUX_CLIENT_MODE=minimal way.
There was another bug in ansible. That is, the environment variable TRANSFORM_
EVENTS was not set in MUX even if openshift_logging_install_eventrouter is set
to true. This PR fixes the issue.
openshift/openshift-ansible#10207
In Fluentd run.sh, "process_kubernetes_events false" is set in the filter-viaq-
data-model plugin to suppress processing the event logs. It is _not_ set, i.e.,
event router log processing is enabled, when TRANSFORM_EVENTS is true and the
fluentd is standalone (no MUX configured) or the fluentd is MUX.
Correct the order of shutdown fluentd, reset MUX_CLIENT_MODE, then restart.
…asticsearch when using MUX
If openshift_logging_install_eventrouter is true, set TRANSFORM_EVENTS true in MUX, as well.