[DRAFT] feat(span-first): telemetry processor#3400
[DRAFT] feat(span-first): telemetry processor#3400buenaflor wants to merge 18 commits intofeat/span-firstfrom
Conversation
… envelope builders for logs and spans. Update SentryClient and Hub to utilize the new telemetry processor. Refactor span and log classes to support telemetry item structure. Add NoOp implementations for telemetry processing. Enhance existing classes to integrate with the new telemetry system.
This commit introduces the DefaultTelemetryProcessor class for managing telemetry item buffering and processing, along with a NoOpTelemetryProcessor for scenarios where telemetry is disabled. Additionally, it adds NoOpTransportQueue and RoundRobinTransportQueue classes for envelope management, ensuring fair scheduling across different data categories. Updates to envelope builders for logs and spans are also included, enhancing the overall telemetry processing framework.
…ndRobinTransportQueue with new implementations. Update SentryClient to utilize DefaultTelemetryProcessor and NoOpTelemetryProcessor. Remove obsolete transport queue classes to streamline envelope management.
…nstantiation. Update example app to comment out sessionSampleRate and onErrorSampleRate options, and add a new TooltipButton for creating test spans.
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Features
- telemetry processor ([#3400](https://github.com/getsentry/sentry-dart/pull/3400))If none of the above apply, you can opt out of this check by adding |
…emetryItem across various envelope builders and the in-memory telemetry buffer. This change enhances the encoding handling for telemetry items, ensuring consistency in the processing framework.
e5f7fde to
4f42f22
Compare
Removed comment about parent span usage.
…g and buffer management. Added debug and warning logs for buffer registration and item processing, improving telemetry tracking and error handling.
…r testing and add MockTelemetryBuffer for unit tests. Implement comprehensive tests for buffer registration, item routing, and flushing behavior.
…EnvelopeBuilder, and introducing SingleEnvelopeBuilder for improved envelope management. Update DefaultTelemetryProcessor to utilize the new builder, enhancing the overall telemetry item handling. Add comprehensive tests for the new envelope builders and in-memory telemetry buffer functionality.
Introduce MockTelemetryItem and MockSpan classes to facilitate testing of telemetry processing. Update existing tests to utilize these mocks, enhancing the coverage and reliability of telemetry buffer and envelope builder functionalities. Remove obsolete mock classes to streamline the test suite.
Remove obsolete MockTelemetryItem and MockSpan classes, replacing them with MockTelemetryItem and MockSpanV2 for enhanced testing capabilities. Update relevant tests to utilize the new mock classes, ensuring better coverage and reliability in telemetry processing tests.
…es and updating SentryOptions to utilize a telemetry processor. This change enhances the logging mechanism and streamlines the telemetry handling process. Update tests to reflect the new telemetry processor integration.
| test('sets log batcher on options when logs are enabled', () async { | ||
| expect(fixture.options.logBatcher is NoopLogBatcher, true); | ||
|
|
||
| fixture.options.enableLogs = true; | ||
| fixture.getSut(); | ||
|
|
||
| expect(fixture.options.logBatcher is NoopLogBatcher, false); | ||
| }); |
There was a problem hiding this comment.
this is tested in telemetry processor test file
| } | ||
|
|
||
| /// In-memory buffer with time and size-based flushing. | ||
| class InMemoryTelemetryBuffer<T extends TelemetryItem> |
There was a problem hiding this comment.
pretty much copy pasted the sentry log batcher
…mplementedError throws into a single method. Update SentryWidgetsBindingObserver to replace log batching with telemetry processing, and adjust related tests to reflect these changes. This enhances the clarity and maintainability of the codebase.
… related classes for improved type safety. Modify DefaultTelemetryProcessor and its tests to utilize generic types for buffer registration and item addition, enhancing clarity and maintainability in telemetry handling.
…to clean up the codebase.
| }) : _spanId = SpanId.newId(), | ||
| _hub = hub ?? HubAdapter(), | ||
| _name = name; | ||
| _startTimestamp = DateTime.now().toUtc(), |
There was a problem hiding this comment.
Don't we have some date wrapper, also used in testing?
| class SpanEnvelopeBuilder implements EnvelopeBuilder<Span> { | ||
| final SentryOptions _options; | ||
|
|
||
| SpanEnvelopeBuilder(this._options); |
There was a problem hiding this comment.
Could we inject publicKey, release & 'environment' instead of all options, or are they subject to change after init? Could bundle ein Metadata object.
| } | ||
|
|
||
| class LogEnvelopeBuilder extends SingleEnvelopeBuilder<SentryLog> { | ||
| LogEnvelopeBuilder(SentryOptions options) |
There was a problem hiding this comment.
Could we inject sdk instead of all options, or is it subject to change after init?
There was a problem hiding this comment.
don't think it changes, I'll update
| } | ||
|
|
||
| @override | ||
| FutureOr<void> flush() => _performFlush(); |
There was a problem hiding this comment.
There was some naming discussion over at Cocoa, I think the gist was to call this clear instead of flush. Not super important now, just something to consider.
| @@ -0,0 +1,6 @@ | |||
| import 'package:meta/meta.dart'; | |||
|
|
|||
| abstract class TelemetryItem { | |||
There was a problem hiding this comment.
This is so generic, we should probably call it something like Encodable
There was a problem hiding this comment.
Wasn't sure if we're gonna add more things but yea SentryEncodable would be better I think
| } | ||
|
|
||
| /// In-memory buffer with time and size-based flushing. | ||
| class InMemoryTelemetryBuffer<T extends TelemetryItem> |
There was a problem hiding this comment.
Cocoa has additionaly seperated the InMemory Storage from the logic when to dispatch the buffered elements. Not sure this is needed here, here's the PR
There was a problem hiding this comment.
dont think we'll need this, we won't implement file-based buffering or any other storage other than in-memory fwiw - we'll rely on the native SDKs and when we replace it with the native file-based ones in the future we will swap the whole impl, not only the storage
so imo doesn't make sense to separate them for Dart (currently)
when we do have a use case later we can just adjust the impl
|
this PR will be split up |
📜 Description
💡 Motivation and Context
💚 How did you test it?
📝 Checklist
sendDefaultPiiis enabled🔮 Next steps