I have an azure cloud service and I am struggling and feel I have exhausted all avenues on trying to identify what is going wrong. When I try hit one of the actions I get an internal server 500 however I can't see no stack trace of this at all!
I have enabled diagnostics via the setting:
<system.diagnostics>
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics" />
</listeners>
</trace>
</system.diagnostics>
And within azure portal I have setup the connection string which I am monitoring via Azure Management Studio. However, for the life of me I cannot see whats going wrong.
I have remoted onto the box to and tried it locally and nothing is seen in the event log, no exception.
What I have done, is change the setting via portal to another value and back to the original and for some reason that seems to make the app work. However, this workaround is unacceptable and for future reference I would like to see the error it is throwing.
Cheers, DS.
From my experience with Cloud Services, I'd advice you to set up a free NewRelic account, add the NewRelic package to your Cloud Service, and check NewRelic's findings.
It's extremely helpful and it will dig up and tell you exactly in which part of your code is the error and the stack trace.
Debugging Apps in the Cloud without something like NewRelic or AppInsights feels almost like shooting in the dark.
Related
I have an existing App which has logging enabled on Log4net , which runs on VS 2012.
The logs are sent on a database table, I woiuld like to move it to use azure tables.
I have added the following lines in web.config as well as downloaded the Azure SDK.
<system.diagnostics>
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
</system.diagnostics>
What else do I need to do to start logging using azure tables ?
For a start is there a way I can run the website on local and configure things to be logged on azure table on the storage emulator.
You do not need to add to the web.config of your web app. To enable logging to an Azure Storage Table, go to the configure page of your web app in the Azure Management portal at https://manage.windowsazure.com. (The preview portal currently doesn't support this).
In the application diagnostics section, set application logging (table storage) to ON, specify your logging level, and then click the manage table storage button to specify the storage account and table name you want to write logs to. Then click the SAVE button at the bottom of the page and you're done.
I have an API deployed as an Azure Website (not a worker role). The code for the site has Trace statements dotted through it that I would like to capture in an Azure Table via the Azure Diagnostics.
I'm using Trace.TraceError, Trace.TraceInformation, etc.
I've followed the instructions here, which essentially say that all that is required is to flick the switch in the management portal and set a location for Application Diagnostics: https://azure.microsoft.com/en-us/documentation/articles/web-sites-enable-diagnostic-log/
I have ensured that the Microsoft.WindowsAzure.Diagnostics reference is added to the project, and I have also tried adding the following to the Web.config (even though the instructions don't say this is necessary):
<system.diagnostics>
<trace autoflush="true" indentsize="4" >
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics" />
</listeners>
</trace>
</system.diagnostics>
Despite this, the only output I get to the Azure Blob and/or Table (that I specified in the portal) is the following:
24/06/2015 14:02:49 AlasdairOTCDev Verbose SnapshotHelper::RestoreSnapshotInternal SUCCESS - process 11284 -1
24/06/2015 14:02:48 AlasdairOTCDev Verbose SnapshotHelper::RestoreSnapshotInternal SUCCESS - File.Copy 11284 -1
Trace levels are set to Verbose in the portal.
What am I doing wrong, and how can I debug this?
Many thanks for any assistance that can be provided as I'm rapidly running out of hair to pull out...
It turns out the root of the problem was with our build.
There was an issue where our build script was not compiling the TRACE symbol. Builds compiled locally did include this (which is why it all appeared to work locally) but when we built and deployed to Azure it was being missed out.
Without the TRACE symbol, none of the logging statements were activated.
You don't need the reference to Microsoft.WindowsAzure.Diagnostics in your project. That is for Cloud Services and the article you referenced does not mention it since it is for Azure Web Apps (formerly Websites).
Assuming you are using an Azure Web App (not a cloud service web role), then you have to use the current Azure Management portal at https://manage.windowsazure.com if you want to configure your web app to store application diagnostics to an Azure Storage Table or Azure Storage Blob Container. In the configure page for the web app, your configuration should look like this for a table storage.
(Currently, the preview portal at https://portal.azure.com only lets you configure application diagnostics logging using the web app's file system)
For anyone who still encounters this problem, besides for the excellent answers given on this page (enable tracing on azure, and making sure TRACE is set to true in your build), make sure you actually flush the traces!
In your code you need something like this:
System.Diagnostics.Trace.TraceError("Can you see me?");
System.Diagnostics.Trace.Flush();
Or
System.Diagnostics.Trace.AutoFlush = true;
System.Diagnostics.Trace.TraceError("Can you see me?");
With most Azure services I can run an emulator on my local machine, for example the storage emulator. This allows me to store the credentials to my real azure storage account as an app setting on my azure web site. And locally I have the credentials to the emulator in my web.config.
But how to achieve the same kind of security with Azure DocumentDB? I would prefer not to store the credentials in my local web.config, but at the same time I need to be able to run the application locally when developing. As I understand there is no emulator for the DocumentDB? And the endpoint and auth key is the same for all DocumentDB's I create?
So, to sum up my question, what is the best practice to handle the auth key / end point when developing and using Azure DocumentDB?
You are doing the right thing by storing your connection strings in your Azure Website environment so they are not in your web.config and therefore not in your source control system. And your local development process works well for you only because you are using the emulator which doesn't require any credentials. That is not always going to be the case though as you pointed out with Document DB and potentially with other resources you may be using to store data.
The guidance for storing and deploying app settings and connection strings is to keep those in separate config files locally that are never checked into your source control system. Then, in your web.config file, reference these files. This keeps the confidential information out of your web.config.
For example, for connection strings it would be something like this:
<connectionStrings configSource="ConnectionStrings.config">
</connectionStrings>
For app settings it would be something like this:
<appSettings file="..\..\AppSettingsSecrets.config">
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
...
</appSettings>
More information on this technique is available here.
Another alternative is to store the key as an environment variable and get your code to read it.
On another note, your development environment should have a separate docdb, one that is not your production environment. Since docdb does not offer an emulator and no free-tier, this leads to higher costs for development.
Is it possible to a custom configuration section inside of an Azure Cloud Service Configuration, the same way you would in a regular ASP.NET website?
I.e in a regular ASP.NET site your Web.Config would have something like this:
<configuration>
<configSections>
<section name="myCustomConfig" type="MyNamespace.MyType" />
</configSections>
<myCustomConfig someProperty="someValue" />
</configuration>
How is this done in Cloud Services and shared across multiple different roles?
At this time I do not believe this is possible. There is a post for it on user voice you can vote up: http://www.mygreatwindowsazureidea.com/forums/169386-cloud-services-web-and-worker-role-/suggestions/459944-enable-custom-configuration-sections-in-csdef-cscf.
As a way around this you could put configuration into a file that is stored in BLOB storage. On start up, or when it is needed, all instances could then go pull the file to get the configuration. To deal with changes to the configuration you could either have the instances pulling the configuration from time to time as a refresher, or you could tap into the environment changed event in RoleEntryPoint that is used to detect changes to the Service Configuration. Add a setting to the service configuration that is a version number of your shared config file or something, just anything that could be modified to trigger the RoleEnvironment.Changing event.
I am trying to understand how I can configure my .NET website to display each domain or groups of domains as Applications in the New Relic RPM console.
There is an article explaining here how to do it for PHP
https://newrelic.com/docs/php/per-directory-settings
Applications can be named individually in the application's web config file. This is done by adding the following to the <appSettings> element:
<appSettings>
<add key="NewRelic.AppName" value="my_web_app" />
<add key="NewRelic.AgentEnabled" value="true" />
</appSettings>
Multiple instances of an application can report to the same name in the New Relic UI by giving each application instance the same name as shown above.
Of course, you can separate applications by giving them different names.
You can use this naming feature to group application instances by name as you need. Your application instances can be running on the same server, on different servers, or on a mix of these.
See this page for some additional information on application naming.
Note that you can also enable/disable monitoring of an application or application instance using the NewRelic.AgentEnabled key in the app settings section.
At this time, the .NET agent doesn't support differentiating which
application to report to based on the hostname of each request.
https://discuss.newrelic.com/t/report-websites-or-applications-running-in-the-same-iis-app-pool-as-different-new-relic-applications/36828
UPDATE December 2017: Please go to the URL above and vote for the feature if you think this feature would be useful.