-
Notifications
You must be signed in to change notification settings - Fork 183
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
Update configuration for helm #417
Update configuration for helm #417
Conversation
<source> | ||
@type zipkin | ||
port 9411 | ||
</source> |
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.
Labeling required. As tracing is last configuration part, previous <match **>
catches all tracing traffic
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.
cc @vsinghal13 , maybe we should update all of our sources to use labels to make clear distinction between logs, metrics, and traces. when we added the logs.source.generic.conf
, we didn't take into consideration non-log data when we added the <match **>
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.
I created jira task for it: SUMO-130461
@type zipkin | ||
endpoint "#{ENV['SUMO_ENDPOINT_TRACES']}" | ||
content_type application/json | ||
overwrite_content_type application/vnd.sumologic.zipkin |
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.
overwrite_content_type
-> override_content_type
or change this value in zipkin plugin
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 barring the couple of comments i left
<label @TRACING> | ||
<filter tracing.**> | ||
@type stdout | ||
</filter> |
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.
By doing this, fluentd will log the traces to STDOUT right? I assume you are doing this for debugging but keep the challenge is we collect the fluentd logs in the K8s collection process and therefore customers will have an ingest spike for this. If so, we should probably make this configurable and not on by default.
@@ -89,6 +89,10 @@ sumologic: | |||
# Source category for the Events source. Default: "{clusterName}/events" | |||
sourceCategory: "" | |||
|
|||
# Traces configuration |
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.
Can we make sure we add a comment indicating this is an alpha/closed beta feature and not intended for use by everyone? Probably work with Pawel on the verbage.
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.
+1
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
{{- (tpl (.Files.Glob "conf/*.conf").AsConfig .) | nindent 2 }} | ||
{{- (tpl (.Files.Glob "conf/metrics/*.conf").AsConfig .) | nindent 2 }} | ||
{{- (tpl (.Files.Glob "conf/logs/*.conf").AsConfig .) | nindent 2 }} | ||
{{- if .Values.sumologic.traces.enable }} | ||
{{- (tpl (.Files.Glob "conf/traces/*.conf").AsConfig .) | nindent 2 }} |
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.
This is definitely safer but as long as we have lines 13-15 above, I don't believe we need to wrap this in {{- if .Values.sumologic.traces.enable }}
. For example, for metrics we actually even just @include metrics.conf
by default, even if metrics is disabled (instead we just don't deploy Prometheus at all)
I think it's fine to leave this as is, but we might want to revisit this in the future for consistency between logs metrics and traces
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.
Jira task for revisiting: SUMO-130462
<source> | ||
@type zipkin | ||
port 9411 | ||
</source> |
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.
cc @vsinghal13 , maybe we should update all of our sources to use labels to make clear distinction between logs, metrics, and traces. when we added the logs.source.generic.conf
, we didn't take into consideration non-log data when we added the <match **>
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
* disable filter_plugin by default * add note about fluentd status (experimental)
Merging with squash to the |
* Add zipkin plugin * Update configuration for helm (#417) * Generate new 'fluentd-sumologic.yaml.tmpl' * Generate new overrides yaml/libsonnet file(s).
Description
Helm configuration for zipkin plugin
Testing performed