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

fix(azure-functions): redirect console to azure context for logging #542

Closed
wants to merge 93 commits into from

Conversation

mcremer-able
Copy link
Contributor

πŸ”— Linked issue

#383

❓ Type of change

  • πŸ“– Documentation (updates to the documentation or readme)
  • 🐞 Bug fix (a non-breaking change that fixes an issue)
  • πŸ‘Œ Enhancement (improving an existing functionality like performance)
  • ✨ New feature (a non-breaking change that adds functionality)
  • ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

πŸ“š Description

At the moment there is no easy way to run nitro in an azure-funtions context and retain the ability to log out.
This pr redirects the built in console.log(),console.warn(),console.info() and console.error() to the azure provided logging context.
This adresses #383 ,but should be refined in the future to allow a more flexible log target

πŸ“ Checklist

  • I have linked an issue or discussion.
  • I have updated the documentation accordingly.

export async function handle (context, req) {
const url = '/' + (req.params.url || '')

interceptLogging(context)
Copy link
Member

Choose a reason for hiding this comment

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

Will this have issues with logs being associated to the wrong request if there are multiple parallel requests?

If not (that is, if there is only one aggregated logging bucket), then do we need to run this on every incoming request or could we early return if the interceptor has already been run?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As I understand it, it is a single logging bucket for the whole function app.

We could optimize and dont intercept ,if we are already intercepting.
The gains do not outweight the potentiell bugs, in my opinion, with the added complexity we get.

I rather intercept twice than miss a critical log.

@danielroe
Copy link
Member

Regarding my comment:

Will this have issues with logs being associated to the wrong request if there are multiple parallel requests?

I'm checking with the Azure team to ensure that there are no downsides to this approach.

@pi0 pi0 changed the title fix[azure-functions]: redirect console to azure context for logging fix(azure-functions): redirect console to azure context for logging Oct 26, 2022
alvarlagerlof and others added 22 commits January 9, 2023 09:22
Changed deprecated ```useBody()``` to ```readBody()```.

fixes: nitrojs#789
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
manh-gntvn and others added 17 commits January 30, 2023 12:52
…s` (nitrojs#883)

* feat(fetch): allow for futher narrowing of the method option

* style: simplify fetch options type
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* fix: don't overwrite proxy headers if already set

* perf: only call `getHeaders()` once

---------

Co-authored-by: Mike Bellika <mike@altinget.dk>
Typo on the Heroku deployment page
* refactor: improve code readability

* implement stable tree
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@pi0
Copy link
Member

pi0 commented Feb 6, 2023

Any updates on this?

@mcremer-able
Copy link
Contributor Author

ah F thats not what I wanted
Rebase was the wrong command to fetch upstream changes
Any git wizards that can help?

About the concerns that we associate logs of different requests with each other.
The Microsoft docs say that context.log does disriminate based on request, but console.log does not
see docs

@danielroe
Copy link
Member

In that case I think we need a different approach, almost certainly not overwriting console.log but instead exposing azure utilities on event.context.azure, much like we are discussing doing with cloudflare.

@mcremer-able
Copy link
Contributor Author

I will close this as the long-term option will be an event.context.azure object with the necesarry properties.

For the short term I will continue to patch nitro in my CI with the console.log interceptor

@tobiasdiez
Copy link
Contributor

I agree that event.context.azure (or a more general purpose event.context.log) is a good idea and solves the issue for manual log statements. However, often a library that one uses logs output via console.log and this output is simply lost when deployed to azure, making it really hard to debug/investigate issues. Thus, there should also be a way to redirect output to the correct logger.

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.