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

Feature/keystone beholder integration #14510

Draft
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

patrickhuie19
Copy link
Contributor

@patrickhuie19 patrickhuie19 commented Sep 20, 2024

@@ -197,6 +197,7 @@ func (c *Config) New() (Logger, func() error) {

l = newSentryLogger(l)
l = newPrometheusLogger(l)
// l = newBeholderLogger(l)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

could hook in as early as here but seems excessive (all overloaded funcs will emit a custom message) for this first use case of integrating with Keystone

)

// beholderCustomMessageLogger is used to emit logs as custom messages through Beholder
type beholderCustomMessageLogger struct {
Copy link
Contributor Author

@patrickhuie19 patrickhuie19 Sep 21, 2024

Choose a reason for hiding this comment

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

ordinarily if you want to log, you would just log.

However, we will not have access to metrics through Beholder to start so this wrapper is necessary.

ST3 currently requires log messages to be surfaced through Beholder. This allows the o11y consumer to decide which Loki source to ship the logs to, potentially unblocking external viewership.

Copy link
Contributor

Choose a reason for hiding this comment

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

🤔 Is this needed if we go with option A? IIUC it isn't, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's correct - if we go with option A we don't need the wrapped logger

@patrickhuie19 patrickhuie19 changed the title Feature/keystone beholder alerts Feature/keystone beholder integration Sep 24, 2024
// TODO ks-461

// ks-461 Option A:
logAndSendCustomMessage(e.logger, "initialization failed: %s", retryErr)
Copy link
Contributor

Choose a reason for hiding this comment

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

I slightly prefer this option: this doesn't couple our logger + custom message implementation together so we can flexible diverge the two (logs + custom messages). It'll make things more verbose, but also more explicit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The tricky part with A is getting access to all the sugared values that have been added to the logger. Maybe the best path forward is to look for specific values in the drilled context? For tracing those labels will be valuable as well if added to the context.

Copy link
Contributor

I see you updated files related to core. Please run pnpm changeset in the root directory to add a changeset as well as in the text include at least one of the following tags:

  • #added For any new functionality added.
  • #breaking_change For any functionality that requires manual action for the node to boot.
  • #bugfix For bug fixes.
  • #changed For any change to the existing functionality.
  • #db_update For any feature that introduces updates to database schema.
  • #deprecation_notice For any upcoming deprecation functionality.
  • #internal For changesets that need to be excluded from the final changelog.
  • #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
  • #removed For any functionality/config that is removed.
  • #updated For any functionality that is updated.
  • #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

🎖️ No JIRA issue number found in: PR title, commit message, or branch name. Please include the issue ID in one of these.

@cl-sonarqube-production
Copy link

Quality Gate failed Quality Gate failed

Failed conditions
7 New Major Issues (required ≤ 5)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarLint SonarLint

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.

2 participants