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

Less verbose logs on func start #2139

Merged
merged 3 commits into from Aug 25, 2020
Merged

Less verbose logs on func start #2139

merged 3 commits into from Aug 25, 2020

Conversation

pragnagopa
Copy link
Member

@pragnagopa pragnagopa commented Aug 5, 2020

Fixes #2141 Fixes #2143 Fixes #2110

This PR:

  • Added --verbose flag. Running with --verbose flag will give users existing logging behavior
  • If running in CI environment - https://github.com/watson/ci-info/blob/master/index.js#L52-L59, --verbose flag is set.
  • Displays all the functions (incorporated code from @anthonychu)
  • Strips out date from log messages.
  • By default func host start will have less verbose system logs:
    • Default log level for system logs is Warning
    • Deafult log level for user logs is Information
  • If Default log level is specified in host.json - both user logs and system logs level is set to the value specified in host.json
  • If host.json has default loglevel set to None - Only whitelisted logs that VS Code uses will be logged
  • If host.json lists any category then defaults do not apply

Sample output on func host start with default host.json

func.exe host start
Azure Functions Core Tools (3.0.1 Commit hash: N/A)
Function Runtime Version: 3.0.1.0
Hosting environment: Production
Content root path: C:\pgopa\vsCode\jsDebug
Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.

Functions:

        HttpTrigger: [GET,POST] http://localhost:7071/api/HttpTrigger

For detailed output, run func with --verbose flag.
Worker process started and initialized.
Host lock lease acquired by instance ID '00000000000000000000000022DF9FE8'.
JavaScript HTTP trigger function processed a request.

Sample output on func host start with following host.json

{
	"version": "2.0",
	"logging": {
		"LogLevel": {
			"Function.HttpTrigger": "Trace",
			"Microsoft.Azure.WebJobs.Script.Description.WorkerFunctionInvoker": "Trace",
			"Microsoft.Azure.WebJobs.Script.WebHost.Middleware.SystemTraceMiddleware": "Information"
		}
	}
}

NOTE: To see middleware tracing user explicitly needs to add that category in host.json
Output :

Azure Functions Core Tools (3.0.1 Commit hash: N/A)
Function Runtime Version: 3.0.1.0
Hosting environment: Production
Content root path: C:\pgopa\vsCode\jsDebug
Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.

Functions:

        HttpTrigger: [GET,POST] http://localhost:7071/api/HttpTrigger

For detailed output, run func with --verbose flag.
Worker process started and initialized.
Host lock lease acquired by instance ID '00000000000000000000000022DF9FE8'.
Executing HTTP request: {
  requestId: "0b7d77b8-df93-4bb7-be6b-34e3ab2cb0f8",
  method: "GET",
  userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36",
  uri: "/api/HttpTrigger"
}
Executing 'Functions.HttpTrigger' (Reason='This function was programmatically called via the host APIs.', Id=8c804b69-e49c-4577-8ffb-0210875b4073)
Sending invocation id:8c804b69-e49c-4577-8ffb-0210875b4073
JavaScript HTTP trigger function processed a request.
Executed 'Functions.HttpTrigger' (Succeeded, Id=8c804b69-e49c-4577-8ffb-0210875b4073, Duration=258ms)
Executed HTTP request: {
  requestId: "0b7d77b8-df93-4bb7-be6b-34e3ab2cb0f8",
  identities: "(WebJobsAuthLevel:Admin)",
  status: "200",
  duration: "454"
}

@pragnagopa
Copy link
Member Author

This PR builds on previous PR: #2135 that forces whitelisted logs if LogLevel is set to None

Building on the same approach, running func start --quite will set Default LogLevel to None.

@anthonychu
Copy link
Member

Is this related to #1131?

@pragnagopa
Copy link
Member Author

Is this related to #1131?

Yes, I just linked the issue to the PR!

@pragnagopa
Copy link
Member Author

@anthonychu - Please note that sample output has following log:

[8/5/2020 10:57:06 PM] Host lock lease acquired by instance ID '00000000000000000000000022DF9FE8'. - this is a forced log that VS code debugger relies on.

@anthonychu
Copy link
Member

This is different that what we discussed in #1131 though. I think we need to discuss.

@pragnagopa pragnagopa changed the title Add option for quite Set Default LogLevel to None Aug 6, 2020
@pragnagopa
Copy link
Member Author

Updated the PR, to turn off logs by default.

@anthonychu - what is the experience we are aiming for function invocation logs?

@pragnagopa
Copy link
Member Author

Just looked through the details: #1131 (comment)

  • This PR is scoped to changing output on func start . I will open separate issues for func azure functionapp publish
  • Will update the PR incorporating changes mentioned: 7dd097e...anthonychu:less-verbose

@anthonychu
Copy link
Member

@pragnagopa Sorry we didn't get a chance to sync up first before you started on this. @ankitkumarr and @fabiocav have more context, I can help catch you up.

It's more than just setting logs to None. Logs coming from the host and Core Tools should be at Warning, and logs from customer code should remain at Information.

I have updated this comment #1131 (comment) with the latest on what we landed on from the discussions over the past couple of months. While this covers multiple commands, let's scope this work to func start.

I have a proof of concept to demonstrate what we're looking for. This diff might be useful to explain some of the changes: 7dd097e...anthonychu:less-verbose

Sample of what we're looking for is here:

@anthonychu
Copy link
Member

@pragnagopa Looks like you commented while I was typing up my reply. I think we're on the same page. 😄

Base automatically changed from pgopa/whiteListLogs to v3.x August 6, 2020 19:21
@pragnagopa pragnagopa changed the base branch from v3.x to pgopa/fixForceLogs August 7, 2020 00:02
@pragnagopa pragnagopa changed the title Set Default LogLevel to None [WIP]Set Default LogLevel for user logs to Info, default log level for system logs to Warning Aug 7, 2020
@pragnagopa pragnagopa changed the title [WIP]Set Default LogLevel for user logs to Info, default log level for system logs to Warning Less verbose logs on func start Aug 10, 2020
@pragnagopa pragnagopa changed the base branch from pgopa/fixForceLogs to v3.x August 10, 2020 15:52
@pragnagopa
Copy link
Member Author

Updated PR description, added unit tests. Please review.

@pragnagopa
Copy link
Member Author

ping for reviews!

@anthonychu
Copy link
Member

@pragnagopa One thing discussed in #1131 that got lost in the noise is defaulting to existing logging behavior in CI environments. Can check for this using something similar to this: https://github.com/watson/ci-info/blob/master/index.js#L52-L59

Other than that, it looks great based on the description. Thanks!

@pragnagopa
Copy link
Member Author

@anthonychu - not sure if there is a standard way to figure out CI environment. Added check for variables you pointed out: https://github.com/watson/ci-info/blob/master/index.js#L52-L59

We can expand the list in future if needed.

@anthonychu
Copy link
Member

@pragnagopa Thanks! We don’t need to catch them all, those variables should detect most of them.

src/Azure.Functions.Cli/Common/Utilities.cs Outdated Show resolved Hide resolved
src/Azure.Functions.Cli/Common/Utilities.cs Outdated Show resolved Hide resolved
src/Azure.Functions.Cli/Common/Utilities.cs Outdated Show resolved Hide resolved

public UserSecretsConfigurationBuilder(string scriptPath)
public UserSecretsConfigurationBuilder(string scriptPath, LoggingFilterHelper loggingFilterHelper)
Copy link
Member Author

Choose a reason for hiding this comment

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

@gzuber - can you please ACK these changes? Had to re-base and update this code so that all the logs go through default logging filters

@pragnagopa
Copy link
Member Author

pragnagopa commented Aug 25, 2020

@brettsam / @ankitkumarr - Green build! Can you please take final pass?

.Callback(v => VerboseLogging = v);

var parserResult = base.ParseArgs(args);
bool verboseLoggingArgExists = parserResult.UnMatchedOptions.Where(o => o.LongName.Equals("verbose", StringComparison.OrdinalIgnoreCase)).Any();
Copy link
Contributor

Choose a reason for hiding this comment

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

We can probably just do parserResult.UnMatchedOptions.Any(o => o.LongName.Equals("verbose", StringComparison.OrdinalIgnoreCase)) I think.

Copy link
Member Author

Choose a reason for hiding this comment

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

done!

Parser
.Setup<bool>("verbose")
.WithDescription("When false, hides system logs other than warnings and errors.")
.SetDefault(false)
Copy link
Contributor

Choose a reason for hiding this comment

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

If we remove the default value here, would we still need verboseLoggingArgExists? We can probably just check if VerboseLogging is null or not.

Copy link
Member Author

Choose a reason for hiding this comment

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

Parser is not binding properly to type bool? . I tried updating the nuget package same behavior.

@pragnagopa
Copy link
Member Author

@anthonychu fyi - merging this PR. Will update the release notes to include this change.

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.

None yet

5 participants