Hi, my name is Corbin and in this
video we'll be looking at methods to
avoid and resolve common issues with
instances allocated to app services.
App services have an internal load
balancer that determines which
instance to serve incoming requests.
Seeing 502 errors when navigating to
your site in the browser determines
that there is a bad gateway and
sometimes indicates that there
is some issue with the connection
between the internal load balancer
and the instances serving requests.
Generally, when we suspect
instance related issues,
we can better determine this by checking
application insights live metrics.
Here we can see the following for
each instance allocated to the App
Service plan hosting the App service.
The number of requests and
failed requests per second,
the dependencies per second.
The total CPU consumed and
the total committed memory.
Now if any instance exhibits an abnormally
high value for each of these metrics,
we can check to see if this is a
platform related issue by using
the following troubleshooting
methods outlined in this video.
Azure App services use application
request routing IIS extension
to distribute your connection.
Connecting users between your active
instances serving of the content,
ARR cleverly identifies the user
by assigning them a special cookie
known as the ARR affinity Cookie,
which allows the service to choose the
right instance the user was using to serve.
Subsequent requests made by that user.
This means a client establishes a
session with an instance and it will
keep talking to the same instance
until his session has expired.
There are situations where in
keeping the affinity is not desired.
For example,
if you are getting way too many
requests from a single user and
the requests going to the same
web server instance overloaded.
If maintaining session affinity is not
important and you want better load balancing,
it is recommended to disable
the session affinity cookie.
We can disable the session
affinity cookie by navigating
to the configuration blade
on the app service page in the portal.
Then by clicking the general settings tab,
once this loads,
We can then see the ARR affinity toggle here.
Now in situations where any number
of instances are unresponsive,
we can use a trick we call the scaling trick.
This operation allocates both new
instances to your app service plan
hosting your app services as well
as a new internal load balancer.
For example, in the event where there
is a process hang up caused by another
resource running on the same hardware
hosting your instances and your site,
this is the most efficient
way to move your site to
new instances. Essentially this
functions as a hard reset beyond the
capabilities of the traditional restart.
In order to perform the scaling trick,
we simply navigate to the scaleup blade
on the app service page in the portal,
and select another plan within the
same pricing tier as the origin.
We do this because changing pricing tiers
can change your outbound IP addresses.
I'll go ahead and switch to P1V2.
And click apply.
Once we
perform the scaling trick,
we must then wait around 5 minutes
before scaling back to ensure new
instance and load balancer allocation.
Now we can take this one step further by
enabling the new Health check feature.
Health check increases your applications
availability by removing unhealthy instances.
Your App Service plan should be
scaled to two or more instances to
use health check via scale out,
And when given a path to your
application health check pings this
path on all instances of your app
service at one minute intervals,
and if an instance doesn't respond with
a status code between 200 to 299
inclusive after two or more requests
or fails to respond to the ping,
the system determines it's unhealthy
and removes it.
After removal, health check continues
to ping the unhealthy instance.
If it continues to respond unsuccessfully,
health check restarts the underlying
VM in an effort to return the
instance to a healthy state.
If an instance remains unhealthy
for one hour, it will be,
it will be replaced with a new instance.
Furthermore, when scaling up or out
app service pings the health check path
to ensure new instances are ready.
The health check path should check for
critical components of your application.
For example,
if your application depends on a
database and messaging system,
the health check endpoint should
connect to those components.
If the application cannot connect
to a critical component,
then the path should return a 500
level response code to indicate
the app is unhealthy.
To enable the Health check feature,
we scroll down to monitoring on the
app service page within the portal,
and find health check.
Here we can enable the feature.
Set the path that the health check will ping.
And lastly, we can use the slider
to set the time that an unhealthy
instance remains in a load balancer.
For this application I have deployed
a static CSHTML razor page on a .net
core application called status and it is
relative to the root of the application.
Once this is all configured
and some time is passed,
we could then monitor
the health check feature by
navigating to the metrics tab above.
Here we can see the percentage of
instances that are healthy and if all
instances are returning 200 to 299
response code then it will sit at 100%.
If the discussed methods failed to
resolve the issue, you can additionally
try changing the App Service plan.
This operation requires that the source
plan and the target plan are in the same
resource group and geographical region.
We can find this operation back on the app
service page under change App Service plan.
In the dropdown we just select an
existing plan to move the app to.
The dropdown shows only plans that are in
the same resource group and geographical
region as the current app Service plan,
and if no such plan exists,
it lets you create a plan by default.
You can also create a new plan
manually by selecting create new,
and if you create a new plan,
you can select the pricing
tier of the new plan.
I hope this video helps you
troubleshoot and resolve instance
related issues and for further
information detailing some of the
methods discussed in this video,
as well as a host of other methods
to maintain high availability
for Azure App Services,
please check out the Ultimate Guide
to running healthy apps in the cloud.
Thanks for watching.