I have a web application which makes use of SignalR. Some SignalR connections are using the "server send events" protocol. This results in very long running web requests e.g. signalr/connect which execute as long as the connection is open.
This skews the "server response time" metric and makes it impossible to set an alert on it.
Is there any way to filter out certain requests from this metric?
Controlling the Data
Yes, you can do this. If you want those requests not to be included in the requests at all then just remove the telemetry information from the header for those requests. If you have the telemetry sitting in a master page, then you will have to remove it from there and add to individual pages, where you want.
If you want more granular control then you can control and trigger the telemetry javascript yourself. You can have the long running requests run via Ajax separately and not affecting the telemetry data. Then you can have alerts as you require.
Additionally, controlling the View of the Data
If you just want to filter while viewing then follow these steps:
Open the Application Insights blade.
Then navigate or click on the "Server Response Time" metric from your dashboard.
Then Click on the Filters button in the "Server Responses" blade.
Expand the filter for "Request Name" and select checkbox for only the requests you want.
Click Update once you are done with the filters.
Related
I would like to send a welcome email to the user when the Azure AD admin assigns the user to the application (enterprise or custom). It would be nice to use a custom template to define an access URL and maybe some additional info (how to use, some rules, etc.). I haven't found anything similar in the Azure portal.
Does Azure AD provide such functionality? Or should I build custom implementation (Graph API, EventGrid + Azure Functions, SCIM protocol, etc.)?
From what I understand, at the very base, you want an email to be sent whenever a user is assigned to an enterprise application (or custom - assuming that also falls under same). I assume you do not need to know much about who actually assigned the permissions. Either way, with the query below you should have enough to get going.
As far as I know there's no native support for this in AD (I couldn't find anything at all that's available but I could be wrong) but a workaround for us was to do it using Log Analytics + Azure Logic App. While our use case is slightly different (we use it to monitor and be alerted for logins to a specific account), the same logic might apply to you - I put together a few lines to query log analytics. but I couldn't get the alert part working - Azure could just be sleepy right now.
EDIT: Alert worked the following day. Just needed some time to warm up I guess.
Give it a try:
Make sure Azure AD has diagnostic settings configured to send logs to a Log Workspace
Query the workspace using the following:
AuditLogs
| where TimeGenerated > ago(5m) //Change as required
| where ActivityDisplayName has "Add app role assignment grant to user"
| project Time = TimeGenerated, Activity = ActivityDisplayName, Application=parse_json(TargetResources)[0].displayName, User=parse_json(TargetResources)[1].userPrincipalName
| where Application contains "myapp"
Create an alert from Log Analytics (hopefully you get it working right away - each alert cost USD 1.50/month).
(a) You will need to create an Action Group
(b) Under Action Group, configure your email in the Notifications.
(c) You will need to come back to reconfigure an Action field to the Logic App you will create below.
Create a Logic App and start with an HTTP connector as the trigger to receive the content in JSON format.
Setup a Send an Email (v2) action with all variables and such, or another connector if applicable in your case. Customise the email in HTML
One alternative to using Log Analytics and Alerts could also be to use PowerShell to query AAD logs and then parse the information to Logic App through the HTTP POST Url that shows up when you save the HTTP Connector.
Another alternative to using the HTTP Connector could be to use the O365 connector with trigger When a new email arrives (v3)
Things to consider:
There's at least a 5 minutes delay between the time the event is logged and triggered. This is just the way the alert query works.
You will need to login to Logic App using the mailbox from which you want to send that email. That's something you might want to manage separately - expiring credentials etc.
Hope this gives you some ideas.
I’m trying to make a GET request in order to query data from Azure Search service. I am trying to follw this tutorial:https://www.dotnetcurry.com/microsoft-azure/cognitive-search-rest-apis-angular-app
How can I allow my domain to make a successful GET request without being blocked by CORS policy.
Is there a possible way or custom configuration on Azure to allow default sites to bypass this error? I have tried to add the API key as a parameter to the URL but the same problem raised again.
Thank you
You see this message because your browser blocks requests going to host samplecognitive.search.windows.net which is different from the origin localhost. You must tell Azure Search to send back a "Access-Control-Allow-Origin" header including localhost.
In the Overview tab of Azure Search Service go to "Indexes" and click on your index. Then go to "CORS". Add http://localhost:4200 and click "Save".
I'm following the guidance from Microsoft on decorating traffic to avoid throttling. This guidance specifies that you set a specific User Agent on outgoing requests from the application to SharePoint via CSOM when making API calls.
I have made this change, and would like to now verify that the User Agent is in fact appropriately modified on API calls to SharePoint.
My provider-hosted application is hosted on Azure, and while I can see CSOM calls to SharePoint (https://(mytenancy).sharepoint.com/sites/(mysite)/_vti_bin/client.svc/ProcessQuery) in the Application Map as a dependency, I can't figure out how to view the actual outbound request so as to examine it for the User Agent string.
How can I view the User Agent string on outbound requests from my Azure application? How can I verify that I've set the User Agent string on my calls to the SharePoint API?
Additional Info:
I have tried running the application as well on localhost and employed the use of Wireshark and Fiddler, but I'm only picking up requests to client.svc/ProcessQuery with my browser's User Agent string. I get the feeling I'm not even seeing all the CSOM requests.
User Agent is used for determining browser and browser version , however it seems to be dropped in processing and not available in search or export.
Please have a look at below links for further details.
UserAgent not transfered
UserAgent, Lat/Long and URL expansion data removed
Hope this information helps.
To provide feedback for the team on this specific feature , please refer to this link and upvote.
Support for viewing Raw body requests is something being considered by the Product team. Please refer here for more details on it.
I'm using Application insights with API-Management to monitor my API's. Application Insights is great tool but I'm not able to see body.
I want to see Post request body parameter. Is there any way to add body data on application insights??
You have to configure API Management to log the request payload to Application Insights. See here: Enable Application Insights logging for your API
Navigate to your Azure API Management service instance in the Azure portal.
Select APIs from the menu on the left.
Click on your API.
Go to the Settings tab from the top bar.
Scroll down to the Diagnostics Logs section.
Check the Enable box.
Select your attached logger in the Destination dropdown.
Input 100 as Sampling (%) and tick the Always log errors checkbox.
Under Additional settings, configure up to 8192 bytes of the payload to be logged.
Click Save.
I can't do code changes in existing api. any option without code change would help me
Unfortunately, it is not supported by Application Insights.
I also find the feedback, you could vote it.
It now supports custom Telemetry Initializer as I have shown to you.
This is not supported at the moment. APIM is not exposing Telemetry Initializers to the customer instead it will be providing custom options added to the diagnostic entity that will allow you to control sampling, verbosity and ability to log headers. Body is still being debated. Will user want to see response body returned from backend or sent to client? Body can be modified at different stages. Alternatively, you can use Log-To-EventHub and have the ability to place it at specific points of pipeline. Another idea being considered is Log-To-ApplicationInsights.
Note: Adding for more data to Application Insights takes hit on APIM perf.
The simplest way (ok, the only way I've gotten it to work) would be to log the body yourself using the AppInsights SDK.
According to GitHub, the more recent AppInsights SDKs have initializers running after processing when the stream is closed.
I had Angular2 and Asp.Net Web API applications for that I configured the Application Insights Resource for tracking custom telemetry of those applications. But I used two different AI keys, one for Angular2 application and one for Web API application.
I used to correlation feature to correlate the Two Applications Insights telemetry of Front End calls and Web API calls but operation ID did not match.
Can you please tell me how to correlate the two AI’s telemetry of Front End calls and Web API calls using correlation feature.
Edit: Fixing per the additional information in comment.
You sound like you want to correlate the dependent requests with the server request. This is usually handled by the combination of two pieces:
Set disableCorrelationHeaders = false in the JavaScript snippet config
Ensure your API Service has the OperationCorrelationTelemetryInitializer added in the ApplicationInsights.config under the <TelemetryInitializers> section
The JavaScript setting will set the x-ms-request-id and the x-ms-request-root-id header to be picked up by the telemetry initializer.
The initializer relies on the HttpContext.Request being available.
Using separate instrumentation keys (iKeys) will not matter when it comes to setting the operation id. Where it will matter is when you go to look for this correlated telemetry in the UI. If everything flows to the same iKey it will be able to be retrieved.
The next thing to be mindful of is if your server side telemetry is being sampled. By default the AdaptiveSampling processor is enabled and set to only send 5 telemetry items per second.
Steps to troubleshoot
When the request is sent from the browser use Fiddler or the F12 tools to ensure the x-ms-request-* headers are being set.
Debug your WebAPI application and validate that System.Web.HttpContext.Current.Request.Headers["x-ms-request-id"] or System.Web.HttpContext.Current.Request.Headers["x-ms-request-root-id"] is present
Ensure <Add Type="Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer, Microsoft.AI.Web"/> is added in the <TelemetryInitializers> section of your ApplicationInsights.config
Increase the <MaxTelemetryItemsPerSecond> to a large number like 5000
Make sure you're using v2.2.0 or higher of the .NET SDK