My requirement is under a particular subscription, i am expected to get logs of an Azure App service which would contain below log data like...
Headers,
Parameters,
Endpoints,
Request Payload(full),
Response payload(full),
HTTP response code,
Request ID.
I have tried using Azure Monitor REST API, but was not able to capture the above log elements in it
Kindly suggest, if there is any way to get it done
You could go to Diagnose and solve problems under your app, then choose Diagnostics Tools and there is a diagnostic tool Collect a Network Trace. Then choose collect Network Trace. After this finish, it will show you a zip file link you could download it.
The below is my cap file, suppose this is what you want.
Related
I have an application installed on a VM that publishes a page via OData.
I need to be able to trigger a high urgency alert based on one specific value published by the page.
I am little aware of Application Insights to monitor applications in Azure. But I am not sure if there is a way to read the data from the API and trigger an alert.
What options do I have to accomplish this in Azure?
Pls allow me to share my idea here.
creating app insights alert
enable app insights for azure vm
First, adding app insights to your application can made AI to capture your requests, dependencies, logs and some other messages, including calling API.
In my thoughts, I can log the response message of the API and set alert for some specific keywords. I created an azure function, and it will call MS graph API when triggered, and log the response. This function has integrated AI, so I created an alert by kql:
traces
| where timestamp > ago(30m) and message contains "xxx"
and set alert rule based on number of results greater than 0. When the alert was triggered, it will send email to my mailbox to mention me.
This means any time my API returned the response contains specific words, I will receive an email about it.
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.
We have an Azure App Service Plan running a Web Job, I can see the CPU percentage used in the Azure portal when I look at the Service Plan, and I want to get this information from the REST API. I can get the information, however I don't know what I'm doing wrong as the information I get doesn't match up with what the portal shows.
Here's the URL I'm getting:
https://management.azure.com/subscriptions/{MySubscriptionId}/resourceGroups/My-Resouce-Group/providers/Microsoft.Web/serverFarms/My-App-Service-Plan/providers/microsoft.insights/metrics?$filter=name.value%20eq%20'CpuPercentage'%20and%20(aggregationType%20eq%20'None'%20or%20aggregationType%20eq%20'Average'%20or%20aggregationType%20eq%20'Minimum'%20or%20aggregationType%20eq%20'Maximum'%20or%20aggregationType%20eq%20'Total'%20or%20aggregationType%20eq%20'Count')%20and%20startTime%20eq%202017-10-03T08:55:00Z%20and%20endTime%20eq%202017-10-03T09:00:00Z&api-version=2016-09-01
At 8:55 the portal shows just under 20% CPU usage, however what I get back from the REST API at this time is this:
"total":1.0,"count":1.0,"average":1.0,"minimum":1.0,"maximum":1.0
What do I need to do to get the data that is shown in the portal?
According to your description, I have create a test demo on my side, it works well.
The result is the same.
I guess may be something wrong with your filter parameters.
I suggest you could try my url and test again.
https://management.azure.com/subscriptions/{subscription}/resourceGroups/{name}/providers/Microsoft.Web/serverFarms/{name}/providers/microsoft.Insights/metrics?api-version=2016-09-01&$filter=(name.value%20eq%20'CpuPercentage')%20and%20(aggregationType%20eq%20'Average'%20or%20aggregationType%20eq%20'Minimum')%20and%20startTime%20eq%202017-10-04T01:26:41.812Z%20and%20endTime%20eq%202017-10-04T02:26:41.812Z%20and%20timeGrain%20eq%20duration'PT1M'
Result:
Besides, you could also get the filter directly from azure portal.
You could use browser F12 to check the request details from azure monitor.
Details, you could refer to this image:
Is there a way to log Service Bus exceptions and errors if I don't have access to the client that submits the queue messages? As in, from the Service Bus queue itself?
Have a look at the Azure metrics REST API here:
https://msdn.microsoft.com/en-us/library/azure/dn163589.aspx
It is a bit fiddly to get up and running with as you need to create and install a management certificate on Azure. The link below explains how:
https://msdn.microsoft.com/en-us/library/azure/gg551722.aspx
You start by hitting the supported metrics resource for the queue or topic you want to monitor - the URL below is a redacted example:
https://management.core.windows.net/[SubscriptionID]/services/servicebus/Namespaces/[Namespace]/queues/[Queue]/Metrics
It brings back a big chunk of JSON that includes links to the supported metrics resources. This includes counts of the failed requests and internal server errors.
Beyond that it's worth using a logger mechanism on your clients that lets you remotely aggregate more detailed messages. This will give you a fuller picture of why your clients might be failing to send and receive .
I have an Azure WebJob built using the Azure Web Jobs SDK. It consumes messages off of a queue and produces messages on another queue. It has thousands of successes and a handful of failures. Unfortunately, the only way I can find too look back over the function calls is by paging through all of them.
Is there some way I can get a list of the failures and get additional details about them such as what was logged or what exception was thrown?
An option is to log/save the message that failed and then retry it with your debugger attached to the webjob.
Also, Whatever is written to console output and console error will go to a log file for the specific triggered webjob run. So before throwing an exception in your try/catch block make sure you log the exception with the details so that you can acceess it later via FTP or the UI.
Here are the details on how/where is everything logged in azure websites. You can access the logs via FTP.
You can also access the information via the REST API. Details here.
Hope this helps,