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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Parser]: add additionnal data in the same log #1819

Open
1 task done
Nightbr opened this issue Apr 18, 2024 · 0 comments
Open
1 task done

[Parser]: add additionnal data in the same log #1819

Nightbr opened this issue Apr 18, 2024 · 0 comments

Comments

@Nightbr
Copy link

Nightbr commented Apr 18, 2024

Hello there 馃憢 ,

first of all, thank you for this amazing project that is well design and beloved by us (and others for sure 鉂わ笍 )

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

We would like to add tenantId in OgmaLogger Interceptor (GraphQL and Express one) to be able to filters in our logs tool (Datadog) and create some dashboards to see the requests per tenantId.
To do this, we need to have this data in the logs of the request.

Describe the solution you'd like

We saw and play with extending the Parser and then use the getMeta from the doc here but it creates a new log that doesn't contains information on the request, the time, ...

Ideally, we would like to have one log per request but be able to add additional properties such as tenantId.

The extends pattern is good, a factory could be great to inject service (ContextService) that will set extra properties. But the main point is to be able to have one log entry.

Teachability, documentation, adoption, migration strategy

  • We could keep the getMeta for extra logs and create a new extraProperties method to handle this use-case
  • We could BC and don't create an extra log with getMeta
  • We could add an extra optional param for getMeta - shouldCreateExtraLog = true default to true

What is the motivation / use case for changing the behavior?

We think this is a must have changes for any multi-tenant apps that wants to have better observability per tenant. This could also be great to easily enhanced and add more custom properties to the request log (userId to see activity per user, apiKeyId same but scoped per apiKey).

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

No branches or pull requests

1 participant