Azure gives a URL of the App Service when an App Service is created in it. I use a URL Ping test (a feature provided by App Insights) in Azure to test the availability of my Mobile App Service. I ping the URL of the app service and check for a 200 HTTP response. If I receive 200 response, I decide that the test has passed. However, recently I noticed that the URL was giving me a 200 response, but the site gave me a message saying 'Critical service is unhealthy'.
This was a problem for me because I thought 200 was synonymous with 'everything being OK'. I want to know whether the URL will always give a 200 response and it is only the text message appearing on the site which will say whether the app service is running fine, unhealthy or down. If not, what are the different cases in which the URL responds with 200 HTTP code?
EDIT:
I think I couldn't clearly communicate my need in the question. I will try to do that now. The fact that I need to go through the diagnostic logs to debug the issue with my mobile service is clear to me and I am not asking for help on that front.
I am using the URL Ping Test to test the outside-in availability of the mobile service (synthetic availability check). Now, I check for the HTTP response 200 and deduce that the mobile app service is available. Now, that I have discovered that 200 is sent even when the app service is unhealthy, I need to modify my test. How can I do that to ensure that my availability test fails in such scenarios?
Additionally, the following is the webpage of the app service URL when all is fine. This webpage gives a 200 HTTP response.
Now, is there a place where all the different webpage display of the app service URLs and the corresponding HTTP response codes are compiled?
A "URL Ping Test" is more than just a test for 200 - it will also (optionally) try to download all the images and files, do content matching, and retry if a failure is encountered.
Firstly, make sure you have a home page. The home page can be turned off - that is dependent on your site. Also, as #Alex suggested, turn on diagnostic logs and see what the error is produced. Use Postman to send a request to the home page and see what you get back.
Now, got the idea, i think. For being able to do what you want, i would offer you to customize a little your URL web test as described here. If your web app returns 200 OK, and you suspect that there is something wrong, use the payload of the response. For example, if the payload of the response is not equal to "everything is OK", even if that is 200 OK the test should fail. I think that for now it is the only one way to implement that using URL tests from Appinsights.
Related
We are developing a chatbot to handle internal and external processes for a local authority. We are trying to display contact information for a particular service from our api endpoint. The HTTP request is successful and delivers, in part, exactly what we want but there's still some unnecessary noise we can't exclude.
We specifically just want the text out of the response ("Response").
Logically, it was thought all we need to do is drill down into ${dialog.api_response.content.Response} but that fails the HTTP request and ${x.content} returns successful but includes Tags, response and the fields within 1.
Is there something simple we've missed using composer to access what we're after or do we need to change the way our endpoint is responding 2? Unfortunately the MS documentation for FrwrkComp is lacking to say the very least.
n.b. The response is currently set up as a (syntactically) SSML response, this is just a test case using an existing resource.
Response in the Emulator
Snippet from FwrkComp
Turns out it was the first thing I tried just syntactically correct. For the case of the code given it was as simple as:
${dialog.api_response.content[0].Response}
I have an Azure Function of type Queue Trigger hosted on Azure with App Service Plan on B1.
That function makes an HTTP request to a website and downloads the HTML. When I debug the function locally and add messages to the queue everything works fine, but when I deploy it and run it on the Azure environment then it gives a 503 error.
This error is consistent with a specific website, other websites work just fine.
I first thought that the problem was with the library that I used to make the HTTP request, but I tried HttpClient, Refit, RestSharp, and they all have the same result. I also tried to get the HttpClient using the dependency injection as described on Microsoft docs but the error is the same.
After many tries I concluded that the code is not the problem, I connected to Azure Console (Development Tools) and run the curl command with the -I parameter to check the HTTP status, the result was 503, on my computer when I run the curl command, it gives me status 200.
Thank you Almis and Skin. Posting your discussions as answer to help other community members.
Website that you are trying to work with is well aware of Azure IPs and are getting blocked. This is resulting in 503 errors.
I would like to build an integration using the Acumatica REST API. However, before logging in or anything. I would like to know if there is a way to test that the server is up and running.
I've tried logging in and I looked at the swagger.json to look at all the endpoints but I think they require to be logged in.
I would expect a 200 response when the server is up and a 500 when the server is not. 5XX if there is server issues and an error if it is completely down.
There is no Test function that I know of. I would recommend doing a HTTP GET request on the endpoint URL. If the request succeeds it will return the WSDL schema with 200 success code.
I'm new to this API, node fun stuff.
I just setup my node application for a school project and hooked it to a domain. Already it's showing some weird spam GET commands, should I be worried? Is it the server that is getting redirected to those spam sites?
Image to explain:
https://i.gyazo.com/a21b0acf9e3749f7ebabb2d1e6fed4d6.png
- Do not enter the link from the console.
Are these logs being created by your server code? I'm assuming they are, in which case, it is showing the requests being made to the server, the request method (GET,POST,PUT,etc.), and response codes per request that were sent from your server back to the requester.
I'm also assuming these logs are coming from your server code thats deployed on a machine and hooked up to your domain name, in which case, it means that requests were made at
{your_domain_name}/assets/title.png (http status code - 200)
{your_domain_name}/status (http status code - 200)
{your_domain_name}/w00tw00t.at.ISC.SANS.DFind: (http status code - 200)
/assets/title.png, /status, /w00tw00t.at.ISC.SANS.DFind: are all called paths and are the destination at which a requester would communicate with your server. Your server code should expose "endpoints" that requesters can interact with - often a SOAP or REST API.
If I've made too many assumptions or you have more questions I'll be happy to adjust or add input.
I'm trying to build a .NET web api that will be invoked by Amazon's Alexa service (Echo). However, the Alexa Service Simulator at developer.amazon.com does not seem to be sending the POST data. I'm using the "Failed Request Tracing" feature of IIS to troubleshoot the HTTP POST requests that are being sent via the Service Simulator and the log files show that the HTTP requests sent from the Alexa Service Simulator are coming in on port 443, but the HTTP POST data is completely empty. The POST data should contain the "amazon echo service request" object as a JSON string, but it doesn't. When I make the HTTP POST request via Fiddler the POST data contains the "amazon echo service request" object as a JSON string and my .NET web api works perfectly. Has anyone else had this problem with the Alexa Service Simulator? What might I be doing wrong?
I was using the JSON Request input box because I needed to manually add the accessToken property to the service request object. This is what was causing my problem. Once I removed the accessToken property and changed my web service to not require an accessToken I was able to get the Simulator to work. I will revisit the accessToken stuff next week.
In my case - a mild case of RTFM - I forgot to start my skill with the invocation phrase, although it clearly states so in the user-interface:
First, open your skill with your invocation name. Then start testing your dialog.
It took me some time to realize what I was doing wrong ;)