Application Insights - how to exclude localhost - azure

I have added application insights by standard way to my application, it works fine, I collect telemetry data from local website and from working project, published on Azure. But there are many data is sent from localhost, how can I say to not send any data from localhost? Thank you

As Brendan said, you could remove InstrumentationKey in ApplicationInsights.config on your localhost and set it only for release version in code:
TelemetryConfiguration.Active.InsrumentationKey = "MyKey" .
Also, you could Disabling telemetry by setting the following code as this article said.
TelemetryConfiguration.Active.DisableTelemetry = true;
For more detail about how to ignore localhost on Application Insights, you could refer to this case.

Related

Azure Function App remove headers set by a Nest.js App

Thanks for the time reading this.
I am developing an App using Nest.js framework, running it on Azure App service.
I am using a library which set some headers before sending the response to the client.
When I run my code on local runtime, everything seems working properly.
But, when I use Azure Function App local runtime, headers seems to disappear.
There is a screenshot of the request using local runtime
As you can see in the “Response Headers” section there some headers set.
And then a screenshot of the same server code running on Azure Function App local runtime
As you can see in the “Response Headers” section some headers are missing.
My question is, how do I configure Azure Function App so that it does not remove headers set by my Nest.js App ?
I’ve been looking into MS documentation about that, but I did not find anything.
Thank you. for your help

Azure Functions, NodeJS and Application Insights

I have written some simple functions and enabled Application Insights,
Its all showing as connected and I can see that's its tracking http statues, eg I get a failed request count and server response times etc.
I understand that I can add application insights to node with the following code
let appInsights = require("applicationinsights");
appInsights.setup("[your ikey]").start();
But I was hoping it would just work without this, I can see that the function is outputting logs when I use the log stream
But when I use app insights I don't see anything in any of the log tables
Do I need to add insights via code to my function or I am missing some secret config option.
That's also a good idea to add application insights module into your node project to achieve monitor feature for your function. Both code and codeless are good choices.
In my opinion, the biggest difference between code and codeless monitor is the custom telemetry data. But I think in most scenarios, default information collected is enough for daily using, official doc says:
Application Insights collects log, performance, and error data, and
automatically detects performance anomalies.
So I think it's ok for you when you could get traces and error messages after adding appinsights module and recreate a new appinsights instance. And you can also try to use codeless configuration I mentioned in the comment(azure portal-> your function written by nodejs-> Application insights-> enable-> create new resource)

How to send email locally in .net core without credentials

I want to test sending emails in my web app which is using .net core 3 with C#.
The issue is I am on a corporate network which blocks port 587 (for now).
I saw an article which says you can use this
mailClient.DeliveryMethod = SmtpDeliveryMethod.PickupDirectoryFromIis;
But I am hosting with .net core which is not configured for IIS so I get an error "IIS delivery is not supported".
Is IIS the only way to test sending emails locally?
You can specify the option SmtpDeliveryMethod.SpecifiedPickupDirectory
The mail will be picked up from the directory specified in the property SmtpClient.PickupDirectoryLocation
You can see the reference pages for:
SmtpDeliveryMethod.SpecifiedPickupDirectory
SmtpClient.PickupDirectoryLocation
For example:
var client = new SmtpClient {
DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory,
PickupDirectoryLocation = #"c:\myMailFolder"
};
You can run a moq (fake) SMTP server as part of your app. The emails won't be delivered to the recipients but stored in-memory so they can be inspected.
I'm the author of the SmtpMoq.NET for .NET Core that does exactly that. Please check here and here for details how to utilize it.
Additional benefit will be that you can automate your integration tests and verify if the emails are correctly sent.
Hope this helps.

Application Insights does not log successful requests

I have added Azure Application Insights to a number of my .Net WebAPI applications. I've noticed that I do not receive successful request telemetry from these applications. I do receive dependency telemetry and failed requests but not the actual telemetry that the request has been made. By fudging the URL or the request and forcing a failure, I can see that get sent to AI, so my issue is definitely not with the instrumentation key.
I initialize the instrumentation key as follows:
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey =
ConfigurationManager.AppSettings["ApplicationInsightsKey"];
I have attempted to remove AI from the application entirely and added it again using the Configure Application Insights option but it still does not work. There is another of my web apps that uses AI that was configured a while back and it works perfectly, I have replaced the set up of the broken app with that of the working app and also made the package versions line up but I still only get telemetry for failed requests. The capture below from the Live Stream shows this, the red arrow points to the dependency calls made for the successful request, yet nothing shows in the Request Rate graph for it. In contrast there is a failure before it, and that is logged.
I just found the answer for this in a solved issue on the Application Insights Github. The solution is to open your ApplicationInsights.config and scroll to the telemetry module Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule below it comment out the line System.Web.Handlers.TransferRequestHandler
This issue has been fixed and is due to go out in version 2.5 of the packages. You can read through the issue here https://github.com/Microsoft/ApplicationInsights-dotnet-server/issues/175
Try below one, it works for me:
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration configuration = Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = System.Web.Configuration.WebConfigurationManager.AppSettings["InstrumentationKey"];

Could not retrieve the CDN endpoints in subscription with ID

Searched Google and so - no luck.
Just got this message in Azure for 3 CDN endpoints.
There seems no way to know what is going on without MS support. It is a test account and I do not recall setting this. I have been through similar obfuscated MS error messages only to discover that Azure had crashed.
What does it mean?
This isn't really a direct answer, but could help with the general problem of "what happens if the CDN goes down?".
There is a recent development called the "Progressive Web App".
Basically unless served by localhost, everything has to be over https, but script is cached as a local application in your browser.
When your app makes requests to the registered domain, these are intercepted by a callback you put in your serviceWorker.js, so you can cache even application data locally, and sync the local data occasionally with the server (or on receive events if you're using webSockets).
Since the Service Worker intercepts REST calls to the registered domain, this in theory makes it fairly easy to add to just about any framework.
https://developers.google.com/web/fundamentals/getting-started/codelabs/your-first-pwapp/
Sometimes there is a (global) problem with the CDN. It happend before.
You can check the azure CDN status on this page: https://azure.microsoft.com/en-us/status/
At this moment everything looks good, you still have problems?

Resources