Skip to content
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

ENH: metrics in secret extension #3922

Merged

Conversation

chenqi0805
Copy link
Collaborator

Description

This PR adds metrics on AWS secrets extension plugin

Issues Resolved

Resolves #[Issue number to be closed when this PR is merged]

Check List

  • New functionality includes testing.
  • New functionality has a documentation issue. Please link to it in this PR.
    • New functionality has javadoc added
  • Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@@ -33,6 +35,7 @@ public AwsSecretPlugin(final AwsSecretPluginConfig awsSecretPluginConfig) {
this.pluginConfigPublisher = new AwsSecretsPluginConfigPublisher();
pluginConfigValueTranslator = new AwsSecretsPluginConfigValueTranslator(secretsSupplier);
scheduledExecutorService = Executors.newSingleThreadScheduledExecutor();
pluginMetrics = PluginMetrics.fromNames("secrets", "aws");
Copy link
Member

Choose a reason for hiding this comment

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

I tend to think that this should be fromNames("aws", "secrets")

I'm not sure that we will even have other secrets, so this seems to create an unnecessary extra layer.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is to be consistent with

Copy link
Member

Choose a reason for hiding this comment

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

The documentation indicates that we go from a componentId to a componentScope.

* @param componentId It can be either pluginId or Data Prepper core component id
* @param componentScope It can be pipeline name or Data Prepper core component

I think the component in this case is the aws-plugin. So I would be in favor of using aws as the componentId.

@asifsmohammed , Any thoughts from you end?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think what George has in the PR is right order. We do <componentScope> + "." + <componentId>

try {
secretsSupplier.refresh(secretConfigId);
secretsRefreshSuccessCounter.increment();
pluginConfigPublisher.notifyAllPluginConfigObservable();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Question: I am not sure how long this operations is going to take, can it increase the timer metric which tracks refresh duration?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes. I include it in the timer to track the total time. But this operation should all be in-memory and I expect it to be much less time consuming compared to get secret call

@chenqi0805 chenqi0805 merged commit e5cf555 into opensearch-project:main Jan 18, 2024
47 checks passed
@chenqi0805 chenqi0805 deleted the enh/metrics-in-secret-extension branch January 18, 2024 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants