I am just trying out Application Insights availability tests.
I let them run over night to our public website and got only "fails"
When I drill in to the separate test runs, I see that the server responded with "200 OK", sending the expected html markup.
But in "Exceptins" it says
System.UriFormatException: Invalid URI: The format of the URI could not be determined.System.UriFormatException: Invalid URI: The format of the URI could not be determined.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at Microsoft.VisualStudio.TestTools.WebTesting.HtmlDocument.ParseForDependentRequests(Boolean urlsOnly)
at Microsoft.VisualStudio.TestTools.WebStress.WebTestCaseVariation.BuildDependentRequestsList(WebTestInstrumentedTransaction instrumentedTransaction)
at Microsoft.VisualStudio.TestTools.WebStress.WebTestCaseVariation.AddParsedDependentRequests(ExecutionState executionState)
Does anyone have an idea what's going on there? What am I missing?
Most likely this exception occurs when webtest engine tries to parse dependent requests information to validate resources. Either webtest incorrectly parses dependency resource or web page contains an invalid reference.
WebTest should give a better error explaining to which resource it is complaining.
To workaround this problem (if it is acceptable) - you can disable "Parse dependent requests" option (see below). Note - webtest will not be testing dependent resources.
Related
I have co-related all the required dynamic values, added cookies & headers in the recorded load test script. But, I can't able to get a successful login into the application.
It throws an error Action.c(312): Error -26630: HTTP Status-Code=401 (Unauthorized) in the login transaction itself.
Action.c(312): Error -26630: HTTP Status-Code=401 (Unauthorized) for "https://myapplicationURL" [MsgId: MERR-26630]
Is there any other missing values need to be added in the script, Please let me know.
Thanks in advance.
Seems that you haven't correlated the the dynamic values. Or the credentials that you are using are not valid.
You can debug this problem by looking into the snapshots of your previous requests.
So we have a simple .net core 5.0 service that only serves some simple pages with mvc. We are starting to get 400 Errors (details below) on some of the requests. Our frontend is embedded in an iframe which forces us to use our own domain for our api-calls. The 400 errors disappears when we use the azure internal-urls. (*.azurewebsites.net instead of *.ourdomain.net). When I get to the "diagnose and solve problems" -> "availability and performance" -> HTTP 4XX ERRORS i can se below errors. Any ideas on what can cause this error?
Bad Request. The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications.
So, the biggest problem above is that we do not get the correct errormessage. After a lot of experimentation we activated the ConnectionLogging for Kestrel.
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options =>
{
options.ConfigureEndpointDefaults(listenOptions =>
{
listenOptions.UseConnectionLogging();
});
})
And after that we found some more intressting logs. One that said:
Connection id "0HMFSA73IA4LS" bad request data: "Malformed request: invalid headers."
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.
After some more investigation we could diff a succesful request from a failing request. And the problem was related to the certificate of *.ourdomain.se. In a part of the certificate we hade a string thats named "Stockholms län" in the cases where it failed the string decoded to l�n and when it succeeded the string decoded to l%C3%A4n. We are now investigating if this is a load balancer problem. But this app is running hostingmodel outofprocess. By changing this to inprocess and wrap our Kestrel in IIS the errors disapears.
I have a function app with:
a few functions triggered by a Timer Trigger
and some triggered by the HTTP Trigger.
I have also an Azure API Management service set up for the function app, where the HTTP Triggered functions have their endpoints defined.
I am trying to trigger one of my timer triggered functions manually as per the guide here https://learn.microsoft.com/en-us/azure/azure-functions/functions-manually-run-non-http
I am however getting a 404 result in Postman, despite the seemingly correct URL and x-functions-key.
The function:
The key:
The request:
I also noticed that:
if I don't include the x-functions-key header, then I get 401 Unauthorized result
and if I include an incorrect key, then I get 403 Forbidden.
Could it be related to the API management service being set up for the function app?
How can I troubleshoot this further?
I have managed to solve it.
It turns out that Azure Functions timer trigger requires six parts cron expression (I was only aware of the five part style)
Without that, it does not work - sadly this is not easily noticeable in the UI.
I have realized that by investigating Application Insights logs:
The function page shows that everything is fine:
Changing the CRON format has fixed the 404 issue and I started getting 202 Accepted response.
As a bonus note, I have to add:
Even though the response was 202 Accepted, the triggering didn't work correctly, because my function return type was Task<IActionResult> which is not accepted for timer triggered functions.
Again, only ApplicationInsights showed that anything is wrong:
The 'MonkeyUserRandom' function is in error: Microsoft.Azure.WebJobs.Host: Error indexing method 'MonkeyUserRandom'. Microsoft.Azure.WebJobs.Host: Cannot bind parameter '$return' to type IActionResult&. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
That's a bonus tip for a 'manual triggering of non-http function does not work'.
I test it in my side, it works fine. Please refer to the below screenshot:
Please check if you request https://xxx.azurewebsites.net/admin/functions/TimerTrigger1 but not https://xxx.azurewebsites.net/admin/functions/TimerTrigger. Note it's "TimerTrigger1".
I requst with ..../TimerTrigger at first test because the document shows us QueueTrigger, and it response 404.
I am getting following error when I use pagination of view.
Unable to render the data. If the problem persists, contact your web
server administrator.Correlation
ID:c64a4e9d-64d2-3009-f658-7f1c8b0faebc
When I checked the Logs from ULSViewer I got these errors messages
Error while executing web part: System.ArgumentException: The
specified view is invalid. at
Microsoft.SharePoint.SPViewCollection.get_Item(Guid guid) at
Microsoft.SharePoint.ApplicationPages.InplaceViewEditor.get_View()
at
Microsoft.SharePoint.ApplicationPages.InplaceViewEditor.RenderListView()
at
Microsoft.SharePoint.ApplicationPages.InplaceViewEditor.Execute(String
strCmd) at
Microsoft.SharePoint.ApplicationPages.InplaceViewEditor.OnLoad(EventArgs
e)
Forced due to logging gap, cached # 12/24/2015 10:59:32.88, Original
Level: Verbose] No data was found on the incoming client request
Proxy response returned error: 'The remote server returned an error:
(601).'
Could you please check and let me know what is the issue? I am not able to resolve it.
Thanks in advance.
Best Regards,
Manoj.
Have you added the custom web parts or add custom code?
For troubleshooting the issue, you could check things below:
Create a new list view to check if the same issue will occur.
Do an IIS reset to check if it can work.
I want to do something when/if an insert operation on Azure Table Storage fails. Assume that I want to return false from the below code when I receive an error. _table is of type CloudTable and the code below works.
public bool InsertEntity(TableEntity entity)
{
var insertOperation = TableOperation.Insert(entity);
var result = _table.Execute(insertOperation);
return (result.HttpStatusCode == (int)System.Net.HttpStatusCode.OK);
}
I get the result 203 when the operation succeeds. But there are other possible results like "200 OK".
How can I write a piece of code that will allow me to understand from the status code that something went wrong?
Using the .NET SDK, any situation that needs to be handled will throw an exception. i.e. Any status code that is not 2xx will cause an exception.
To handle situations where something went wrong, I don't have to manually check the status code of the result for every request. All I have to do is to write exception handling code. Like below:
try
{
var result = _table.Execute(insertOperation);
}
catch (Exception)
{
Log("Something went wrong in table operation.");
}
From this page:
REST API operations for Azure storage services return standard HTTP
status codes, as defined in the HTTP/1.1 Status Code Definitions.
So every successful operation against table service will return 2XX status code. To find out about the exact code returned, I would recommend checking out each operation on the REST API Documentation page. For example, Create Table operation returns 201 status code if the operation is successful.
Similarly, for errors in table service you will get error code in 400 range (that would mean you provided incorrect data e.g. 409 (Conflict) error if you're trying to create a table which already exists) or in 500 range (for example, table service is unavailable). You can find the list of all Table Service Error Codes here: https://msdn.microsoft.com/en-us/library/azure/dd179438.aspx.
Basically, any return in 2xx is "OK". In this example:
https://msdn.microsoft.com/en-us/library/system.net.httpstatuscode%28v=vs.110%29.aspx
203 Non-Authoritative Information:
Indicates that the returned metainformation is from a cached copy
instead of the
origin server and therefore may be incorrect.
This Azure white paper elaborates further:
http://go.microsoft.com/fwlink/?LinkId=153401
9.6.5 Error handling and reporting
The REST API is designed to look like a standard HTTP server interacting with existing HTTP clients
(e.g., browsers, HTTP client libraries, proxies, caches, and so on).
To ensure the HTTP clients handle errors properly, we map each Windows
Azure Table error to an HTTP status code.
HTTP status codes are less expressive than Windows Azure Table error
codes and contain less information about the error. Although the HTTP
status codes contain less information about the error, clients that
understand HTTP will usually handle the error correctly.
Therefore, when handling errors or reporting Windows Azure Table
errors to end users, use the Windows Azure Table error code along with
the HTTP status code as it contains more information about the error.
Additionally, when debugging your application, you should also consult
the human readable element of the XML error
response.
These links are also useful:
Microsoft Azure: Status and Error Codes
Clean way to catch errors from Azure Table (other than string match?)
If you are using Azure Storage SDK accessing Azure Table Storage, the SDK would throw a StorageException on the client side for unexpected Http Status Codes returned from the table storage service. To extract the actual HttpStatusCode you would need to wrap your code in a try {} catch(StorageException ex){} block. And then parse the actual exception object to extract the HttpStatusCode embedded in it.
Have a look at Azure Storage Exception parser I implemented in Nuget:
https://www.nuget.org/packages/AzureStorageExceptionParser/
This extracts HttpStatusCode and many other useful fields from Azure StorageExceptions. You can use the same library accross table, blob, queue clients etc. as they all follow the same StorageException pattern.
Note that there will be some exceptions thrown by the Azure Storage SDK that are not StorageExceptions, those are mostly client side request validation type of exceptions and naturally they do not contain any HttpStatusCode. (Hence you would need to have a catch for specifically StorageExceptions to extract HttpStatusCode s).
As a separate note, Azure Storage SDK has a fairly robust retry mechanism for failed requests. Below is the snippet from SDK source code where they decide if the failed response is retrieable or not.
https://github.com/Azure/azure-storage-net/blob/master/Lib/Common/RetryPolicies/ExponentialRetry.cs
if ((statusCode >= 300 && statusCode < 500 && statusCode != 408)
|| statusCode == 501 // Not Implemented
|| statusCode == 505 // Version Not Supported
|| lastException.Message == SR.BlobTypeMismatch)
{
return false; //aka. do not Retry if w are here otherwise Retry if within max retry count..
}