I created an azure function app, and tested it locally where I using the console, was able to determine that the my application works, and does what it is supposed to do.
Now I have deployed it to Azure cloud, and started the service - but I don't seem to have any indication on whether it is running, no logs showing what state it is in,
nothing.
How do i view the console application log for my application running in the azure cloud?
I have an Azure Function App in the Portal which contains .NET Core 6 Http Trigger Function.
Now, it has run successfully 2 times.
You can observe the function app state in the Log Stream during the execution state and in idle state that there is no new trace, but your function host is running:
You can also observer the metric rates in Function App Overview blade, how many requests and when they came in last 30 minutes, 1 hour, etc. and you can see more metrics in Live Metrics blade from the Application Insights associated with that Function App.
You could also check any performance issues in the Function App using diagnostics.
Refer to Azure Function App Diagnostics Overview doc provided by Microsoft for knowing the issues, latency time related metrics and reports.
Related
Summary: I have 2 different Azure Function Apps (Node.js), sharing a single file storage account, however if I go into the Kudu Invocation Logs for either of them I see the entries from both Apps.
Here is my setup:
1 File Storage (shared by both Function Apps)
Service Bus 1 (sb-prod), with a single queue (somequeue)
Service Bus 2 (sb-staging), with a single queue (somequeue)
Function App 1 (func-prod), with a single function (somefunc)
Function App 2 (func-staging), with a single function (somefunc)
Both func-prod and func-staging are setup for continuous deployment from the same Bitbucket repo, but different branches
When a message is received in sb-prod it triggers somefunc in func-prod
When a message is received in sb-staging it triggers somefunc in func-staging
Note that the queue name and function name are the same in both prod and staging. That all seems to work fine. However if I go into Kudu and look at the Invocation Logs for debugging, it shows the execution of functions across both Function Apps (prod and staging shown in the logs for both). It is not respecting the folder structure on the file storage to only show the logs from the appropriate App. As far as I can tell, this is only a log viewing issue, and the functions aren't being run twice or messages being sent to the wrong function app. Any ideas on how to fix this? Or is this a bug and I would need to add a second storage account to fix it so that Kudu doesn't get confused? Is there any risk with this setup that messages from staging service bus end up in the prod app or vice versa?
By 'Kudu', I assume you mean the WebJobs Dashboard (not related to Kudu). The behavior you are seeing is quirky, but is in fact by design. See https://github.com/Azure/azure-webjobs-sdk/issues/1541 for more info.
Workarounds:
The best is to use App Insights instead of the WebJobs Dashboard
If you must use the WebJobs Dashboard, use distinct storage accounts
I have an app service plan which is hosting 2 Web APIs, the issue I am facing is that I am unable to view details such as: CPU Usage, Memory Percentage, Requests, Average Response time etc.
These can be found under the Overview tab for both App Service and App Service Plan but no data is being recorded, even if I retrieve data for the whole week rather than the last hour only.
I have also confirmed that I am hitting the correct App hosted on the correct Plan. Have I missed anything? Do I need to enable something?
I have also generated around 20k requests in the last few hours so I expect something to show up.
What would be the best way to monitor when our Azure web app is being unloaded when no requests have been made to the web app for a certain amount of time?
Enabling Logstream for the web server doesn't seem to reveal anything of use..
Any hints much appreciated!
You can use Azure Application Insights to create a web test that will alert you when the site is not available anymore. It will ping your site from the data centers you select and perform some action you select (mail, webhook, etc).
However, if you want your web app to stay online, you could upgrade its plan to be at least basic, and under settings enable always on.
In addition to the kim’s response:
If you are running your web app in the Standard pricing tier, Web Apps lets you monitor two endpoints from three geographic locations.
Endpoint monitoring configures web tests from geo-distributed locations that test response time and uptime of web URLs. The test performs an HTTP GET operation on the web URL to determine the response time and uptime from each location. Each configured location runs a test every five minutes.
Uptime is monitored using HTTP response codes, and response time is measured in milliseconds. A monitoring test fails if the HTTP response code is greater than or equal to 400 or if the response takes more than 30 seconds. An endpoint is considered available if its monitoring tests succeed from all the specified locations.
Web Apps also provides you with the ability to troubleshoot issues related to your web app by looking at HTTP logs, event logs, process dumps, and more. You can access all this information using our Support portal at http://.scm.azurewebsites.net/Support
The Azure App Service support portal provides you with three separate tabs to support the three steps of a common troubleshooting scenario:
-Observe current behavior
-Analyze by collecting diagnostics information and running the built-in analyzers
-Mitigate
If the issue is happening right now, click Analyze > Diagnostics > Diagnose Now to create a diagnostic session for you, which collects HTTP logs, event viewer logs, memory dumps, PHP error logs, and PHP process report.
Once the data is collected, the support portal runs an analysis on the data and provides you with an HTML report.
In case you want to download the data, by default, it would be stored in the D:\home\data\DaaS folder.
Hope this helps.
I have created nodejs Web API, hosted as Azure App Service.
What would be the best way to log errors/info/debug/warning?
We're using Azure Log Analytics with some custom node-winston middleware that sends an async request out to the ALA REST service. However, there is a bit of a lag between the event being sent from our node Web App and it appearing in the ALA dashboard so although it will be good for monitoring a production environment it's not great for rapid debugging or testing.
If you just write to console.log then everything does get stored in a log file that you can access through the Kudu console. Kudu also has the ability to do a live tail of the console, as does the azure command line interface. Because of this we're debugging using those and leaving ALA for the future.
Once we figure out what the pattern is for those logs being written (i.e. filename/size/time/etc.) we'll drop a scheduled Azure Function in to regularly archive those logs into cold blob storage.
I'll also add that according to the Twelve Factor App in XI they recommend writing logs to stdout, which is what console.log does. I always take these opinionated frameworks/methodologies as guidance and not strict rules, but at these seem to be grounded in reality and will at the very least spawn some interesting discussions among your team.
As you're using Azure, I would recommend the Application Insights:
https://learn.microsoft.com/en-us/azure/application-insights/app-insights-nodejs
I have the following resources
One Mobile/API app
One MVC app
Three Logic apps
One Azure function deployment with 5 functions
I want to have a single tracking number (correlation ID) to track across all instances at the same time. I'm looking at the Contoso Insurance sample, but I'm rebuilding it by hand (not using Azure Deploy scripts).
I've read the deployment code, but I'm not sure if I can merge app insight logs together, or if it's a hack of some sort.
Observations
When I right click on visual studio, I can only associate to Application insights instances that aren't already connected to a *app (web | mobile | api).
However, in the configuration, I can give Application insights a direct GUID which might allow me to achieve the goal of one App Insights activity log for the entire process
Question
Is it possible to have one app insights log among all Mobile/API/Logic/MVC sites?
Is there a way to have (or should I have) one standard app insights instance per web app, then a special dedicated shared app insights instance for my code to call into and log?
What is contoso insurance doing with Azure App Insights?
Jeff from Logic Apps team here -- So the answer is yes - but there are some caveats. We are working to make the experience seamless and automatic, but for now it will require the following. First as a heads up:
First, for Logic Apps we have what's called the client tracking ID -- this is a header you can set on an incoming HTTP Request or Service Bus message to track and correlate events across actions. It will be sent to all steps (functions, connectors, etc.) with the x-ms-client-tracking-id header.
Logic Apps emits all logs to Azure Monitor - which unfortunately today only has a sink into Event Hubs, Storage, and Log Analytics -- not App Insights.
With all of that in-mind, here's the architecture we see many following:
Have your web apps just emit to App Insights directly. Use some correlation ID as needed. When firing any Logic Apps, pass in the x-ms-client-tracking-id header so you can correlate events.
Log your events to App Insights in the Function app. This blog details some of how to do that, and it is also being worked on for a better experience soon.
In your logic app - either write a Function to consume events off of Azure monitor and push to App Insights, or write a function that is an App Insight "logger" that you can call in your workflow to also get the data into App Insights.
This is how Contoso Insurance is leveraging App Insights as far as I understand. We are working across all teams (App Insights, Azure Monitor, Azure Functions, Logic Apps) to make this super-simple and integrated in the coming weeks/months, but for now achievable with above. Feel free to reach out for any ?s