-
Notifications
You must be signed in to change notification settings - Fork 115
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
AWS services spec #415
AWS services spec #415
Conversation
|
||
- **`context.destination.address`**: optional. Not available in some cases. Only set if the actual connection is available. | ||
- **`context.destination.port`**: optional. Not available in some cases. Only set if the actual connection is available. | ||
- **`context.destination.region`**: mandatory. The AWS region where the bucket is. |
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 a new field.
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.
As mentioned over at elastic/ecs#1282, I'd prefer if we called this context.destination.cloud.region
. We might later want to add availability zone (could be useful for detecting cross-AZ traffic), and it would be nice to have a common prefix that is cloud-specific.
💚 Build Succeeded
Expand to view the summary
Build stats
Trends 🧪 |
Does SQS support headers for distributed tracing? We might want to call them out if they exist, or mention that distributed tracing isn't possible if they don't exist. |
@basepi Yes SQS supports "message attributes" which are effectively headers. Is there anything in particular you'd like to see in the spec about them? |
@estolfo I would add to the SQS section something like "Message attributes should be used in lieu of headers for distributed tracing." And maybe explicitly mention that distributed tracing is not possible for SNS? (Not sure if that's important or not) |
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.
A bit of a quibble over the new field name, but otherwise LGTM.
|
||
- **`context.destination.address`**: optional. Not available in some cases. Only set if the actual connection is available. | ||
- **`context.destination.port`**: optional. Not available in some cases. Only set if the actual connection is available. | ||
- **`context.destination.region`**: mandatory. The AWS region where the bucket is. |
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.
As mentioned over at elastic/ecs#1282, I'd prefer if we called this context.destination.cloud.region
. We might later want to add availability zone (could be useful for detecting cross-AZ traffic), and it would be nice to have a common prefix that is cloud-specific.
Co-authored-by: Andrew Wilkins <[email protected]>
Co-authored-by: Andrew Wilkins <[email protected]>
This is a spec for instrumenting the following AWS services: