-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add AEI data source #493
Add AEI data source #493
Conversation
b67af1a
to
a29e3e6
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #493 +/- ##
==========================================
- Coverage 79.35% 79.34% -0.01%
==========================================
Files 388 389 +1
Lines 10577 10722 +145
Branches 1573 1594 +21
==========================================
+ Hits 8393 8507 +114
- Misses 1548 1574 +26
- Partials 636 641 +5
|
d7883f3
to
ada5d94
Compare
71f866c
to
d209350
Compare
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
@RequiresApi(VERSION_CODES.R) | ||
internal class AeiDataSourceImpl( | ||
private val backgroundWorker: BackgroundWorker, | ||
private val configService: ConfigService, |
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 thought we had wanted to make the orchestrator push config info to the data sources rather than have them directly depend on them. Is the current state due to how everything is hooked up to the legacy stuff right now, or will this be necessary going forward?
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 orchestrator does control whether a feature is enabled/disabled but that's it right now.
There isn't any such approach for config that alters limits/how data is captured. IMO just passing a ConfigService
or even a *Behavior
class is probably the simplest option
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 think i was more worried about how the dependency graph would work but if every data capture service is at a higher level then that's OK.
I think I would prefer a Behaviour as we can eventually abstract that away if we want to set configuration for data sources that may not have access to the config service - even in a separate module in the SDK
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.
One comment about the config service usage, but looks good to me in general.
d209350
to
8201255
Compare
Goal
Implements the capture of AEI via the
DataSource
interface which allows them to be sent as OTel logs. It's important to note this does not alter any payloads yet. The existingApplicationExitInfoService
will continue to add directly to the payload.A future PR will contain the changeset for enabling the new data capture mechanism. This uncouples work & allows us to merge more without blocking changes.
Testing
Added unit test coverage.