Less verbose logging option (ex: func start --silent) #1131
Comments
|
cc: @johnpapa |
|
I would say that this should be the default option, and have a --verbose flag for the full logs |
|
I like that too @ahmedelnably - but I wasn't sure if it would be too braking of a change of behavior. i do think that less is better by default. |
|
One additional comment ... I love love love seeing the APIs listed in the output. That should be on by default, IMO |
|
To be very honest, the output proves that all the functions were loaded when applicable. I think I like this verbosity. |
|
This can be done with environment variables as a workaround |
|
@mhoeger @johnpapa Let's restart this discussion and see if we can make any improvements here. /cc @bnb @aaronpowell @ankitkumarr Thanks to @brettsam and @JustinGrote in #1440, I think we've identified a way to suppress almost any log related to function execution, and some logs at startup. Based on that conversation, I've put together some of the settings in a repo with examples and a readme: https://github.com/anthonychu/functions-log-suppression The configuration is complex and error-prone. Agree that there should be a way to only show user-initiated logs, and perhaps do this by default. Some things to think about:
|
|
Here's a proposal. Please provide feedback, but would like to start making these changes soon. Goals
func start
Refer to sample here: #1131 (comment) Proof of concept can be found here: Function invocation
func azure functionapp publishIn general, the deployment output needs to be cleaned up a bit. We might not want to hide them by default as we don't want folks to have to re-deploy with Display a summary after deployment that outlines important things such as:
ConsiderationsVS Code debuggingVS Code currently looks for the output
Update: This will be addressed by https://github.com/Azure/azure-functions-host/issues/6252 Backward compatibility?Will this break anything that currently depends on func output? It might. To prevent breakage in CI/CD scenarios, check [these variables] to detect CI environments and automatically use verbose output. |
|
@EricJizbaMSFT @fiveisprime Any concerns here for VS Code? @vijayrkn Would this cause any issues for VS? |
|
The proposed silent output is better, but I'd still like to see more removed plus more whitespace that visually helps separate the different bits of context
Strongly agree with this.
I do generally like this approach, yes. I've typically seen -v, -vv, -vvv, -vvvv, and -vvvvv used for the different log levels at least in the JavaScript world. npm has documented levels here - silent, error, warn, notice, HTTP, timing, info, verbose, and silly. I think a few of these could potentially apply here.
Environment variables as a way to define this would be a base expectation for me.
Yes.
Sounds like you've identified two other log levels here
see my feedback about log output at the beginning of this comment. I think at the bare minimum chunking the information would be extremely helpful in the same way it would be on the web - helps improve scanning for most important information.
Is the Not sure if this is a good time for this discussion, but |
|
VS does not rely on the output. So I am not expecting any impact. The only question would be - Is it required to surface this option in the VS UI somewhere to trigger the verbose option. |
|
I like this a lot better. I'd still like to see a brief output of "this function was called" of some variety or at least have that option. Hey @antempus do you have any thoughts on this? |
|
Thanks @bnb. We can definitely clean up the initial output more. Currently planning to leave the ASCII art in, as I think some Azure Functions fans would miss it (I mean, it has its own T-shirt I thought about taking out the id from the function executing/executed messages, but if there are multiple functions executing at once and/or the functions are long running, they could be useful for correlation. @btholt We're still planning to output function executing/executed messages. Thanks @vijayrkn. I don't think we need a UI to turn this on. Is the text of the command currently configurable in VS? |
|
normally msbuild output is configurable but custom exe output is not configurable in VS. |
|
The only thing that affects VS Code has been mentioned already. We look for "Host lock lease acquired by instance ID" to know when to start debugging, but @pragnagopa is changing that in this issue. Assuming we can coordinate timing, it might make it easier if we remove the "host lock" message at the same time we add Pragna's new message. That way I can keep looking for "host lock" for users on an older version of the func cli, but it won't trigger debugging for users on the latest func cli (which has the new message). |
|
I believe that @bnb covered most of my concerns pretty succinctly, although the ASCII should stay
This is important from my experience in debugging durable functions but once it's deployed, it can be done via App Insights logs traces.
I agree, but there was discussion about suppressing the logs from the function runtime, but I noticed that this was also suppressing any logs from code instrumented, though that may have been an error on my part; I'd like so see only the function logs and not the runtime logs. From @anthonychu's proposal
I like the idea, but if we're adding in a flag for a single log level to the function runtime, would it make sense to instead have a log level param rather than specifically
Please add this; for larger function apps this gives us actionable information for refinement. |
|
Fwiw, I'd give a big +1 for removing the ASCII art. It takes up a lot of real estate, which comes at a premium in most CLI windows. I think it's common to prioritize utility over being "cool/fun/tshirt-worthy" for a CLI, which is why I'm not aware of any other popular cli that does something like this (e.g. git, node, npm, docker, dotnet, az). The ascii art was cool the first time I saw it, but every time after that it was just annoying. Finally, removing the art fits squarely under the top two goals mentioned:
|
|
@EricJizbaMSFT Good point and makes sense. We can remove the logo from |
|
I mean, I kinda like it, helps me know what I'm doing sometimes, how about |
|
+1 for keeping ascii! It helps me visually distinguish runs with Although I do have to admit I just like it too! And I hate reading so I'll take all the visual cues I can get :P |
Now I am conflicted, I think @JustinGrote's solution fits here. |
Lol @anthonychu might be a bit quick to "pick a side" - I fully realize the ascii stuff could have strong opinions both ways and will probably need more deliberation |
|
It works for PowerShell. Powershell vs powershell -nologo |
|
How about a mini version of the ascii art for default. And the big one for verbose! Also - I think the functions would be super readable if they are laid out and using chalk to color the types and endpoints |
|
+1 on the colourisation idea from @johnpapa, it can help find the different "level" messages, and also if developers are able to control their colours, that helps find messages easily. |
|
Thanks for looping me in! Here are some thoughts:
Definitely! Also enabling the use of env variables for default preferences would be a great addition. I always appreciate when this can be done once and almost forget about it unless I need a special debugging mode.
From the competitive analysis I conducted a while ago:
The displayed output is concise, readable and allows for easy identification of important information regarding the function deployment. A similar output could be massively helpful in such contexts Finally regarding ASCII art - maybe a smaller version would be nice as well as allowing to "hide" using again an env or config file? |
Huge +1 to this. It consumes a lot of space for little utility other than being nice branding. Perhaps add in the env var now with the plan to eventually flip it so that you need an env var to show it if you'd like it there |
|
A downside to the ASCII art is logging and instrumentation - if it gets written to a file we're not doing anyone any good :) and we end up bloating their logs which can cost people $$. I know we dig our branding at MS but it's entirely unnecessary and I agree if we have a Here's the output from the Firebase emulator, which I find nice and clean and well laid out. The prompt at the end (
|
|
@anthonychu just wanted to say that the new output is amazing and honestly what I've wanted since my first day at Microsoft. Thank you for working on this |
|
@anthonychu Aww, but we've grown so fond of the lightning bolt ascii art! |
|
Assigning the issue to sprint 81 so we can define the tasks and scope the work. |
|
This is assigned to sprint 81 as a stretch goal. |
|
Moving this issue to epics as this issue captures multiple improvements. Following issues track improvements identified
|
#teamAsciiArt All the other changes are fantastic tho |
Baby functions asciiart |
If this trends, I guess we can think about it :) |
|
Hahah good to have you back @fabiocav. I will admit I had to build some functions today and the console output being so minimal is something I could get used to. |
|
Yeah, I was on the fence about some of the changes, but it's a nice experience. |
|
ASCII art discussion: #2222 |
I'd also say if you could add all functions and their triggers to the output. Like a servicebus trigger, eventgrid, etc.. they are listed in the azure portal so assume it's possible. |
|
@CraftyFella That's one of the things we added. Let us know if you're not seeing it.
|
|
do anyone have any idea how we can see the all the detailed output while debugging it. I am unable to find it anywhere! |
|
@vikalpjain91 Set the default log level in host.json to {
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
},
"logLevel": {
"default": "Information"
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[1.*, 2.0.0)"
}
} |
|
@vikalpjain91 - You can also add |
and others
On func start, the output logs are very verbose. It would be nice if we could have a version of
func startthat only shows warnings and errors.For example:
Instead of:
The text was updated successfully, but these errors were encountered: