Skip to content
This repository was archived by the owner on Sep 17, 2025. It is now read-only.

Add local storage and retry logic for Azure Metrics Exporter + flush telemetry on exit#845

Merged
lzchen merged 10 commits intocensus-instrumentation:masterfrom
lzchen:local
Jan 30, 2020
Merged

Add local storage and retry logic for Azure Metrics Exporter + flush telemetry on exit#845
lzchen merged 10 commits intocensus-instrumentation:masterfrom
lzchen:local

Conversation

@lzchen
Copy link
Copy Markdown
Contributor

@lzchen lzchen commented Jan 15, 2020

Similar to how AzureLogHandler and AzureExporter have local storage and retry logic, metrics exporter now implements these as well.

Also exports all current metrics on application exit.

Resolves [#786]

@lzchen lzchen changed the title Add local storage and retry logic for Azure Metrics Exporter Add local storage and retry logic for Azure Metrics Exporter + flush telemetry on exit Jan 21, 2020
Copy link
Copy Markdown
Member

@c24t c24t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change look good except for a stray print. The class structure including BaseExporter here looks like it could use some attention.



class MetricsExporter(object):
class MetricsExporter(TransportMixin):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MetricsExporter isn't a BaseExporter because we're using the export thread from get_exporter_thread instead of BaseExporter's worker?

It looks like there's a fair amount of duplicated code here, and that BaseExporter should be refactored or made specific to tracing.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it seems like MetricsExporter and AzureLogHandler have very similar behaviour in terms of the exporter thread. I would like to eventually have all of them be a BaseExporter. Was there any discussions with you and Reiley why this shouldn't be the case (why it was like this in the first place)? In any case, I'd like to keep those refactoring changes separate from a feature PR like this one, but I will cut a ticket open for it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[#852]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there any discussions with you and Reiley why this shouldn't be the case (why it was like this in the first place)?

It looks like BaseExporter was factored out in #642, but that PR didn't touch the StackdriverStatsExporter, which influenced the design of the other stats exporters. In any case this can be a problem for another PR.

Copy link
Copy Markdown
Member

@c24t c24t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No more blocking comments from me, thanks!

@lzchen lzchen merged commit e877825 into census-instrumentation:master Jan 30, 2020
@lzchen lzchen deleted the local branch January 30, 2020 18:26
@lzchen lzchen mentioned this pull request Feb 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants