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
Remove InstrumentationLibrary dimension in CloudWatch EMF Logs if it is undefined #1256
Conversation
…is not defined in metrics
fieldsPairs[OtlibDimensionKey] = OTLib | ||
dimensionArray = append(dimensionArray, append(dimensionSlice, OtlibDimensionKey)) | ||
// add OTel instrumentation lib name as an additional dimension if it is defined | ||
if instrumentationLibName != noInstrumentationLibraryName { |
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.
What happens if we set "unknown", "unset", or similar instead of filtering? Doesn't it allow the metrics to be more symmetric (e.g., when analyzing metrics based on this dimension, all the data will be present instead of having a gap)?
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.
The assumption is that the metrics generated by OTel SDKs should not have NonNull InstrumentationLibrary
and this dimension should never be filtered out on these metrics. The complaints are from AWSECSMetadataReceiver
and StatsDReceiver
users saying why they are having OTelLib
dimension in their metrics but they're not using any of instrumentation lib to generate metrics. Thanks
Hi @anuraaga , @shaochengwang . Please help to review |
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.
Discussed with Min a bit and I understand that in cloudwatch it's normal to leave out the dimension when the value isn't present so LGTM
if len(originalDimensionSlice) > 0 && len(dimensionZero) > 0 { | ||
rollupDimensionArray = append(rollupDimensionArray, dimensionZero) | ||
} |
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.
What will happen if one metric has several dimensions but do not have instrumentationLibName defined? Can it have Zero dimension rollup?
For example, Metric1
has Dimension A
and B
, but do not have instrumentationLibName
. If customer enables ZeroDimensionRollup
, will he still get the Metric1
without any dimension? It looks like you didn't append []
into rollupDimensionArray
if instrumentationLibName == noInstrumentationLibraryName
. Or is this something we expect?
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.
Yes, we should generate zero dimension metric for this case. Made the update and added test cases to cover these combinations. Thanks.
…dded test cases to cover all the combinations
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!
Description:
In the current AWSEMFExporter, InstrumentationLibrary name is a fixed dimension when converting OTel metrics to CloudWatch EMF(structure logs) metrics. From the testing, there are some cases OTel metrics can be generated without InstrumentationLibrary attached. Eg,
AWSECSMetadataReceiver
generates ECS container Infra metrics without InstrumentationLibrary. In this case, we'd like to not add InstrumentationLibrary name as the dimension since it will generated the dimension value withUndefined
.Link to tracking Issue:
N/A
Testing:
unit test