my team recently migrated from a VM hosted web app to Azure App Services. After doing this migration, I noticed that the dependencies that previously showed up in app insights are no longer being logged. Previously, app insights would log all 3rd party API calls and all SQL DB calls. Now that it is hosted on Azure App Service the only dependency that is being logged are the occasional AJAX calls which are made on some of our pages. 3rd party API calls and SQL DB calls no longer displayed. Non dependencies are also being logged when running as an App Service (Requests, Exceptions, Traces, etc). Additionally, when running locally, I'm able to see all dependencies logged as expected - this problem appears to only happen when using Azure App Services.
Here is the current setup:
C# Web Application .NET 4.7 AppInsights is installed via NuGet
packages
ApplicationInsights.config file is in web app's root folder
The Application_Start method in Global.asax.cs sets the
TelemetryConfiguration.Active.InstrumentationKey value to the corresponding app insights key (I've confirmed this is being properly set to the proper app insights resource)
Here is what I've tried doing:
Confirmed that the app insights dlls and ApplicationInsights.config files are all properly deployed to the App Service by using the "App Service Editor"
Installing the "Application Insights extension for Azure App Service" extension (version 2.6.5) to the web app
Enable Application Insights within the web app itself by navigating the "Application Insights" then selected enabled under "Collect application monitoring data using Application Insights". All other settings for app insights I enabled on that same page
Please let me know if there is any other additional info that would be helpful to provide.
packages.config relevant packages:
<package id="Microsoft.ApplicationInsights" version="2.5.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.5.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.5.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.Web" version="2.5.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.WindowsServer" version="2.5.0" targetFramework="net47" />
<package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.5.0" targetFramework="net47" />
ApplicationInsights.config:
<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer, Microsoft.AI.DependencyCollector"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.AzureWebAppRoleEnvironmentTelemetryInitializer, Microsoft.AI.WindowsServer"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.BuildInfoConfigComponentVersionTelemetryInitializer, Microsoft.AI.WindowsServer"/>
<Add Type="Microsoft.ApplicationInsights.Web.WebTestTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.SyntheticUserAgentTelemetryInitializer, Microsoft.AI.Web">
<!-- Extended list of bots:
search|spider|crawl|Bot|Monitor|BrowserMob|BingPreview|PagePeeker|WebThumb|URL2PNG|ZooShot|GomezA|Google SketchUp|Read Later|KTXN|KHTE|Keynote|Pingdom|AlwaysOn|zao|borg|oegp|silk|Xenu|zeal|NING|htdig|lycos|slurp|teoma|voila|yahoo|Sogou|CiBra|Nutch|Java|JNLP|Daumoa|Genieo|ichiro|larbin|pompos|Scrapy|snappy|speedy|vortex|favicon|indexer|Riddler|scooter|scraper|scrubby|WhatWeb|WinHTTP|voyager|archiver|Icarus6j|mogimogi|Netvibes|altavista|charlotte|findlinks|Retreiver|TLSProber|WordPress|wsr-agent|http client|Python-urllib|AppEngine-Google|semanticdiscovery|facebookexternalhit|web/snippet|Google-HTTP-Java-Client-->
<Filters>search|spider|crawl|Bot|Monitor|AlwaysOn</Filters>
</Add>
<Add Type="Microsoft.ApplicationInsights.Web.ClientIpHeaderTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.OperationNameTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.UserTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.AuthenticatedUserIdTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.AccountIdTelemetryInitializer, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.SessionTelemetryInitializer, Microsoft.AI.Web"/>
</TelemetryInitializers>
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector">
<ExcludeComponentCorrelationHttpHeadersOnDomains>
<!--
Requests to the following hostnames will not be modified by adding correlation headers.
Add entries here to exclude additional hostnames.
NOTE: this configuration will be lost upon NuGet upgrade.
-->
<Add>core.windows.net</Add>
<Add>core.chinacloudapi.cn</Add>
<Add>core.cloudapi.de</Add>
<Add>core.usgovcloudapi.net</Add>
<Add>localhost</Add>
<Add>127.0.0.1</Add>
</ExcludeComponentCorrelationHttpHeadersOnDomains>
<IncludeDiagnosticSourceActivities>
<Add>Microsoft.Azure.EventHubs</Add>
<Add>Microsoft.Azure.ServiceBus</Add>
</IncludeDiagnosticSourceActivities>
</Add>
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule, Microsoft.AI.PerfCounterCollector">
<!--
Use the following syntax here to collect additional performance counters:
<Counters>
<Add PerformanceCounter="\Process(??APP_WIN32_PROC??)\Handle Count" ReportAs="Process handle count" />
...
</Counters>
PerformanceCounter must be either \CategoryName(InstanceName)\CounterName or \CategoryName\CounterName
NOTE: performance counters configuration will be lost upon NuGet upgrade.
The following placeholders are supported as InstanceName:
??APP_WIN32_PROC?? - instance name of the application process for Win32 counters.
??APP_W3SVC_PROC?? - instance name of the application IIS worker process for IIS/ASP.NET counters.
??APP_CLR_PROC?? - instance name of the application CLR process for .NET counters.
-->
</Add>
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.DeveloperModeWithDebuggerAttachedTelemetryModule, Microsoft.AI.WindowsServer"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.UnhandledExceptionTelemetryModule, Microsoft.AI.WindowsServer"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.UnobservedExceptionTelemetryModule, Microsoft.AI.WindowsServer">
<!--</Add>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.FirstChanceExceptionStatisticsTelemetryModule, Microsoft.AI.WindowsServer">-->
</Add>
<Add Type="Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule, Microsoft.AI.Web">
<Handlers>
<!--
Add entries here to filter out additional handlers:
NOTE: handler configuration will be lost upon NuGet upgrade.
-->
<Add>Microsoft.VisualStudio.Web.PageInspector.Runtime.Tracing.RequestDataHttpHandler</Add>
<Add>System.Web.StaticFileHandler</Add>
<Add>System.Web.Handlers.AssemblyResourceLoader</Add>
<Add>System.Web.Optimization.BundleHandler</Add>
<Add>System.Web.Script.Services.ScriptHandlerFactory</Add>
<Add>System.Web.Handlers.TraceHandler</Add>
<Add>System.Web.Services.Discovery.DiscoveryRequestHandler</Add>
<Add>System.Web.HttpDebugHandler</Add>
</Handlers>
</Add>
<Add Type="Microsoft.ApplicationInsights.Web.ExceptionTrackingTelemetryModule, Microsoft.AI.Web"/>
<Add Type="Microsoft.ApplicationInsights.Web.AspNetDiagnosticTelemetryModule, Microsoft.AI.Web"/>
</TelemetryModules>
<TelemetryProcessors>
<Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryProcessor, Microsoft.AI.PerfCounterCollector"/>
<Add Type="Microsoft.ApplicationInsights.Extensibility.AutocollectedMetricsExtractor, Microsoft.ApplicationInsights"/>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
<ExcludedTypes>Event</ExcludedTypes>
</Add>
<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
<IncludedTypes>Event</IncludedTypes>
</Add>
</TelemetryProcessors>
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel"/>
</ApplicationInsights>
Related
I am getting the following error when trying to do a slot swap for our app service:
##[error]Error: Failed to swap App Service 'service1' slots - 'staging' and 'production'. Error: BadRequest - Cannot swap slots for site 'service1' because the application initialization in 'staging' slot either took too long or failed. Please check AppInit module configuration or try using swap with preview if application initialization time is very long. (CODE: 400)
This is what our web.config file looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\XXXXXXXXXX.Services.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
<applicationInitialization>
<add initializationPage="/api/warmup" />
</applicationInitialization>
<tracing>
<traceFailedRequests>
<clear />
<add path="/api/warmup">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,Rewrite,iisnode" verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="200-600" />
</add>
</traceFailedRequests>
</tracing>
</system.webServer>
</location>
</configuration>
The API that is used for initialization and tracing - /api/warmup - this is functioning with no issues, I am able to invoke the API manually in both the production and staging slot, successfully. In fact, in the pipeline file, I invoke this API prior to invoking the slot swap task, yet the slot swap task fails after about 45 seconds.
Further, no trace file is generated in the /LogFiles folder, and I'm not sure where next to look. I would assume a trace file would be created even when I manually invoke the API, but it's not being created, so is there maybe an issue with the web.config file?
I figured the issue - i had Configuration key WEBSITE_SWAP_WARMUP_PING_STATUSES set to 200,202. Once I removed the key, the swap completed successfully.
I'm trying to add/remove certain http headers from responses coming back from a 'pure' web api application (i.e. no MVC) published to Azure.
I added the following web.config to the project in VS2019:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
<add name="X-Frame-Options" value="SAMEORIGIN"/>
<remove name="X-Powered-By"/>
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
This works fine in my dev environment with IISExpress. It also works fine when the app is published to Azure for app services that are not configured for multi-instance scaling. However, when the app service is configured for multi-instance scaling (three instances in my case) then responses from the app contain 'X-Powered-By' and no 'X-Content-Type-Options' or 'X-Frame-Options'.
Publishing creates the following web.config in Out folder on my dev machine:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\<apname>.exe" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="inprocess" />
</system.webServer>
</configuration>
I also verified that the above web.config is present in the root of the app service in Azure.
Is there anything else that needs to be done in app service configuration in Azure for this to work with multi-instance scaling?
After testing, you do not need to make any changes. In the code or web.config, your solution is currently possible, provided that it is deployed in a windows-based webapp. If it is deployed under linux, then the web.config file is not effective. The web.config file is only applicable to iis. Under linux, the configuration file that needs to be used should be .htaccess.
Put web.config under the wwwroot path, which is the root directory of the project.
Based on windows azure webapp, the post-deployment effect should be consistent with the local iis effect. After testing, after I deploy, you can see the screenshots, and the effect in your web.config has been achieved.
Note:
Some headers cannot be deleted, but they can be overwritten. They need to be coded in the program. You are not involved in this question yet.
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<-- replace server vaule -->
<add name="Server" value="N/A" />
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
Test Steps:
Method 1 with web.config
Create a sample project like below.
Deploy to azure, please see my files on scm site.
Method 2 without web.config (workaround, also works in linux)
Add below code in Startup.cs, it also works for me .
app.Use(async (context, next) =>
{
context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
context.Response.Headers.Remove("X-Powered-By");
await next.Invoke();
});
I have deployed a Asp.Net Core 2 app to IIS. The app is running fine but it keeps creating the following directory structure in the disk root:
D:\MYAPPNAME\MYAPPNAME\1.0.0
Even if i manually delete the folder, it gets created again when the app runs. What may cause this behaviour?
EDIT
After further investigation, i reproduced the issue using the VS 2017 template for asp-net core2 mvc application.
After adding Microsoft.Extensions.Logging.TraceSource nuget package and configuring the logs in app.config the unwated folder gets created...
This is the relevant part of the App.config
<system.diagnostics>
<sources>
<source name="TestApp" switchValue="All">
<listeners>
<clear />
<add name="RotatingFileLog" />
</listeners>
</source>
<source name="Microsoft" switchValue="All">
<listeners>
<clear />
<add name="RotatingFileLog" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="RotatingFileLog" type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" initializeData="FileLogWriter" logFileCreationSchedule="Daily" traceOutputOptions="DateTime" BaseFileName="test" location="Custom" CustomLocation="E:\logs\test\" Delimiter="|" AutoFlush="True" Append="True"></add>
</sharedListeners>
<trace autoflush="true" indentsize="4">
<listeners>
<clear />
<add name="RotatingFileLog" />
</listeners>
</trace>
</system.diagnostics>
It has turned out that Microsoft.VisualBasic.Logging.FileLogTraceListener was creating the folder. I switched to another listener, in this case Essential.Diagnostics.RollingFileTraceListener
I was using WebPageTest to test the performance of my Azure Web App (ASP.Net vNext Web API/Angular). I got an F for both "Compress Transfer" and "Cache Static Content".
After searching StackOverflow and Google, I added the following to my web.config:
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
<httpCompression>
<dynamicTypes>
<clear />
<remove mimeType="*/*" />
<add enabled="true" mimeType="text/*"/>
<add enabled="true" mimeType="message/*"/>
<add enabled="true" mimeType="application/x-javascript"/>
<add enabled="true" mimeType="application/javascript"/>
<add enabled="true" mimeType="application/json"/>
<add enabled="false" mimeType="*/*"/>
<add enabled="true" mimeType="application/atom+xml"/>
<add enabled="true" mimeType="application/atom+xml;charset=utf-8"/>
</dynamicTypes>
<staticTypes>
<clear />
<remove mimeType="*/*" />
<add enabled="true" mimeType="text/*"/>
<add enabled="true" mimeType="message/*"/>
<add enabled="true" mimeType="application/javascript"/>
<add enabled="true" mimeType="application/atom+xml"/>
<add enabled="true" mimeType="application/xaml+xml"/>
<add enabled="true" mimeType="application/json"/>
<add enabled="false" mimeType="*/*"/>
</staticTypes>
</httpCompression>
and
<staticContent>
<!-- Set expire headers to 30 days for static content-->
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
After redeploying my Web App, I re-ran the test and I am still getting an F for both of them. Even though I have added these settings to web.config, it does not appear that Azure Web App is honoring them.
Also, I found out that some Web App tiers do not allow compression but I am running on an S2 and I verified that it does allow compression.
Any help would be appreciated!
Thanks!
gzip compression is enabled by default for Azure Web Apps. You can see the rules in your sites LocalSiteRoot/Config/applicationhost.config. Looking at the response headers (which can easily be done with developer tools) should confirm that gzip is being used. It is possible that one of the resources that your site loads is not compressed, and this is causing the WebPageTest to fail. I would look at a network capture and the response headers, and see if you can find the offending resources if you're concerned.
To go to the local site root, you can use FTP, or go to your SCM site at https://.scm.azurewebsites.net/DebugConsole and then click the globe icon.
Also I suspect that your 2 javascript files are not getting compressed since the Content-Type header is not getting populated, so the rule is not capturing it because it does not recognize the mimetype.
Just to back up #theadriangreen here - it will be a header problem. I've found adding the types in the web.config to be unreliable.
What you need to do instead is edit the applicationHost.config file stored in the deepest dark part of azure. The easiest way to do this, is to install the IIS Manager extension either in the Azure portal or in Kudu. Kudu can be accessed via .scm.azurewebsites.net.
There you can edit the file, and it'll save a xdt for you - which once you restart the app you should find that the xdt gets applied.
Alternatively, you can just add an applicationHost.xdt to your App root and you are good to go. Here is a sample.
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<httpCompression>
<dynamicTypes>
<add mimeType="application/json;charset=utf-8" enabled="true" xdt:Transform="InsertAfter(/configuration/system.webServer/httpCompression/dynamicTypes/add[(#mimeType='application/json')])" />
</dynamicTypes>
</httpCompression>
</system.webServer>
</configuration>
References:-
https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples
https://blogs.msdn.microsoft.com/benjaminperkins/2015/03/03/making-changes-to-the-applicationhost-config-on-azure-websites/
https://github.com/shibayan/IISManager
I am trying to log in to Azure Active Directory from my web page in cloud services. The log in screen comes up and I am able to log in OK. However when it sends me to my homepage it says "page cannot be displayed". In the Azure Active Directory configuration I added SSL localhost to the APP URI and Reply URL and configured the properties in VS2013 to show SSL = True and set the project URL to the localhost. I was able to access the page before I added the log in screen.
Relevant web.config settings:
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="ida:FederationMetadataLocation" value="login.windows.net/conpro.com/FederationMetadata/2007-06/…; />
<add key="ida:Realm" value="localhost:44307/"; />
<add key="ida:AudienceUri" value="localhost:44307/"; />
</appSettings>
Your web.config URI values need to include https://. I'd suggest taking a look at this sample app as well.