We are experimenting Azure Application Insight within a SharePoint 2013 solution. We managed to configure it manually, and we are collecting data from the development farm.
However, the same configuration looks like not to be working in the test farm, as only a few requests are tracked.
We tried two ways of diagnosing the issue:
With a custom command-line tool that traces an exception, on the test front-end. No errors are shown, and enabling diagnostic tracing on System.Net shows no problem actually occurs in transmission. Eventually, the exception is logged on AppInsight, but not every time.
Implementing a custom WebApi controller that performs the same action, but within of our solution code. This never gets collected.
In the end, what looks very weird is only certain URL are tracked server-side (no problems with client JS), which interestingly are the slowest requests.
I've decompiled all Application Insight assemblies, and of course telemetry transmission in done asynchronusly, but within w3wp.exe there's no chance that the process is aborted and the transmission never occurs...
What else can I try?
You can install Fiddler or Other HTTP Debugging tool on the box to see the data that AI sends.
To View internal Application Insights traces you can Install PerfView and collect traces:
PerfView.exe /onlyProviders=*Microsoft-ApplicationInsights- collect
http://www.microsoft.com/en-us/download/details.aspx?id=28567
http://channel9.msdn.com/Series/PerfView-Tutorial
Related
I have an API App running under Azure App Service, with Application Insights installed to track server side telemetry of API calls. When viewing Application Insights in the Azure portal, I am seeing two events for every one server call. Each event has an exact duplicate with the same timestamp, response time, telemetry, etc. I have verified that only one event is in the web server logs, so I'm not accidentally calling the same function twice from the client.
Here are a couple of screenshots to illustrate:
What could be causing this? And how can I fix it?
There is a one known scenario that may lead to the data duplication:
Application is not onboarded to AI SDK is deployed as an Azure
Web App
AI Extension is installed to the app -> after this step
you start to receive data without need to modify your code
Later on you decided to use more powerful features of AI let's say custom
event tracking and on-boarded your application to AI from VS and
re-deployed.
Now you may end up in the situation when HTTP module is registered twice and you start to receive duplicate request data. It happens because AI nuget packages add HTTP module definition in web.config, but extension installation drops additional assembly into your application bin folder that registers HTTP module dynamically during app start - Microsoft.AI.HttpModule.dll (Microsoft.ApplicationInsights.Extensibility.HttpModule.dll in previous versions). To correctly handle this case you need to remove extension leftovers during your application deployment by choosing "Settings->Remove additional files from destination" in case of deploying from VS.
It looks like I have just happened to find an easy reproducible solution for infamous:
'Load operation failed for query 'GetUser'.
The remote server returned an errror: NotFound'
issue for WCF RIA Services (Silverlight 5) web setup: when using VS2012 Web Publishing Wizard with 'Precompile during publishing' option checked-on then the issue does raise its ugly head. When the 'Precompile during publishing' option is checked off then deployed WCF RIA Services works well with Silverlight client. Please check on your system.
I have used fuslogvw etc.etc. - nothing helped. Never used Web Publishing Wizard before - xcopy was my friend, this time I wanted to automate the whole deploying process - and lost a couple of hours of precious time.
I still don't know what is the cause of the issue but I can proceed with my work. Next time when there will be more free time I will probably use this technique to localize the causes of the subject issue.
Edit for clarification: I have effectively solved the subject issue on my localhost but I have it still appearing in one program but not in another when releasing on an external web hosting environment, and I'm yet to find what causes this issue - do you know any good sources where this issue's various solutions are classified and accompanied with solution walk-throughs?
I'm having an apparent AppDomain issue with tracing from within web pages (as opposed to the WebRole). Basically, if I invoke one of the tracing methods (i.e. Trace.TraceWarning("Ooops!")) the trace message doesn't show up in the Windows Azure Compute Emulator. The message does, however, show up just fine in the Output window.
Any help in this regard would be greatly appreciated.....
I think that for now this is just a limitation of the Compute Emulator... it only shows trace messages from your RoleEntryPoint code.
I have a task that calls the SSRS report server to render the report, then places the freshly rendered report into a SharePoint document library. The report server is set up in SharePoint Integrated Mode.
For smaller reports, everything works perfectly. However, if a report take longer than about 90 seconds to generate, the call to render throws an exception of "The operation has timed out".
My proxy's timeout value is set to -1.
(RSExecClient.Timeout = System.Threading.Timeout.Infinite)
The httpRuntime's exeuction timeout is set to "9000" for both the SharePoint web site's, well as the report server's, web.config files.
Also, I have set the DatabaseQueryTimeout to "0" in the rsreportserver.config file.
I am connecting to the ssrs web service using "https:///_vti_bin/ReportServer/ReportExecution2005.asmx".
I also noticed that I could connect through "http://:8080/ReportServer/ReportExecution2005.asmx", however it seems I have to handle authentication and authorization myself, which caused other troubles.
Does anyone know what I am doing wrong, or at least of a logging location that I can go to for more information?
Thanks,
Michael
try checking the timeout property on the database connection itself (DataSource).
Keep in mind there are .config fies where the httpruntime is defined one for the Report
Server and another for the Report Manager. I got bitten with this a few days ago.
SSRS logs files and locations are documented here:
http://msdn.microsoft.com/en-us/library/ms157403.aspx
There are some senarios that you face reprting service timing out because of the memory issue.
The issue is reporting services release memory and it will take time to allocate it back. There are couple of setting which you can find in the following link.
http://msdn.microsoft.com/en-us/library/ms159206.aspx
try to set WorkingSetMinimum to higher number and you will see and imporovment when you restart reporting services next time but be careful not to overuse your memory for reporting service
I'm just taking my first steps with Azure and the first thing I see in the development fabric is a bunch of console style logging windows. So I figure that's going to be handy and decide to figure out how to write stuff there and stumble upon this:
Microsoft.ServiceHosting.ServiceRuntime.RoleManager.WriteToLog("Information", "Message);
Cool, except I don't see anything in the log. Saw a post somewhere that after first install you need to reboot before this will work, so I tried that but still nothing.
I've checked with a break point that the code is executing and I've checked the logging level in the dev fabric.
Is this supposed to work, or am I completely off base?
Just to add some more information about what I'm doing:
Started with VS08's new project wizard for Cloud Service
In the wizard added a single ASP.NET Web Role project
In the Page_Load method in Default.aspx.cs I added the WriteToLog line shown above
Ran the project and in the dev fabric UI, drilled down the tree to web role instance "0"
Nothing in the displayed log except some role instance start up messages followed by a bunch of health status messages.
Tried reloading the page a few times, the breakpoint in Page_Load gets hit but nothing in the log.
Logging Level is set to information, and the other events are level information so I don't think it's a logging level issue.
Logging level is the common gotcha, but there's also a delay before logs start showing up in the dev fabric, so make sure that this message is getting logged at least 10 seconds after the application starts.
After some more googling, seems like this is a known issue:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481184