I have a multi-tenant SaaS app that has been running behind Azure Traffic Manager (Configured using the Priority method) for some time now. (Tenants are identified by subdomain, ie tenant1.mydomain.com, tenant1.mydomain.com, etc)
Now I have added an endpoint to my Azure Traffic Manager, and specified a Custom Header Setting as follows: host:[tenantX].mydomain.com.
My expectation is that all requests for tenantX.mydomain.com should be now routed to the new endpoint I have added, but logging shows that this is not the case...all requests are still going to the priority 1 endpoint.
Am I missing something, or is this not supposed to be what Azure Traffic Manager's Custom Header settings are supposed to used for? Or should I be changing the routing method? If so, to what?
The Custom Header settings are used to specify a host header ensuring that it hits the correct site when Traffic Manager performs health monitoring. It does not set which requests get routed to which endpoints. You only could define the routing methods via the six traffic-routing methods to determine how to route network traffic to the various service endpoints.
For example, in this blog, you will see that it needs to set the hostname under custom header settings to let Ambassador know which container application in the Kubernetes cluster it should forward the endpoint monitoring request.
Custom header settings This configuration setting helps you add
specific HTTP headers to the health checks that Traffic Manager sends
to endpoints under a profile. The custom headers can be specified at a
profile level to be applicable for all endpoints in that profile and /
or at an endpoint level applicable only to that endpoint. You can use
custom headers for having health checks to endpoints in a multi-tenant
environment be routed correctly to their destination by specifying a
host header. You can also use this setting by adding unique headers
that can be used to identify Traffic Manager originated HTTP(S)
requests and processes them differently. You can specify up to eight
header:value pairs seprated by a comma. For example,
"header1:value1,header2:value2".
Related
I'm facing some issues getting the correct custom header in Traffic Manager to check health for multiple sites behind an Application Gateway. These applications are on a single listener in the Application Gateway.
No matter the header variations I am using, I am still getting the "Degraded" status on health monitoring.
Let's say my applications are as such: app1.example.com, app2.example.com
What would be the correct custom header settings in Traffic Manager? I was thinking such as below.
host:app1.example.com,host:app2.example.com
Thank you for your time.
Thank you Morariu for your comment. I am converting your comment as an answer to help other community member.
Fixed the monitoring "Degraded" status by add allow the Traffic Manager health checks in the NSG for the Application Gateway subnet.
Reference: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-probe-overview
For adding multiple hosts in the customer header
Reference: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-monitoring
We have below technical stack
Imperva WAF
API Management
WebApi in WebApp
This is current implementation
Client IPs are authenticated at WAF level
WAF IPs are whitelisted at APIM
APIM IP is whitelisted at WebApp level
Everything is working fine and as expected.
Now when i went to APIM -> Analytics -> Request, i see WAF IPs are listed here and not the client ones. So in this case we will not be able to track who is using what
I know we have option to track thru subscription key, but that is not enough.
Can anybody please suggest how to configure to get correct IPs?
I believe you can find your answer in here.
You merely need to configure your server to retrieve the correct IP from the relevant header.
Quoting the relevant part:
Original Client IP is required In case your application requires a real client IP address, please make sure you have enabled retrieval of this value from either: "X-Forwarded-For" or "Incap-Client-IP" header. When working with Imperva your server will see Imperva IPs instead of real client IPs. However, Imperva inserts by default the original client IP address into two HTTP headers: "X-Forwarded-For" and Imperva header "Incap-Client-IP".
But notice, you should take the first IP in a given XFF value, otherwise, the use of the second header real-client-IP might be affected by 3rd party proxies, etc.
Hope that helps.
After raising support request to Microsoft, we got what we want
This is how we accomplished
When Imperva WAF calls APIM endpoint, it also passes Incap-Client-IP in header
Within APIM -> APIs -> All APIs -> Settings -> Enter header property you want to add in request log of App Insights
Under request log -> custom dimension -> you can see InCap-Client-IP property is added in App Insights
Now we can export this in csv format and can track usage based on client IP.
This is not possible with built-in reports in Azure APIM. If you can make WAF forward client IP to APIM in header then you could build your own reporting infrastructure, but that would be pretty elaborate.
My traffic manager with performance routing method has two endpoints.They are in different region. I wanted to validate when I make a request to webpage, which endpoints served that requests. Is there a way to validate that, like any third party website or some tool in Azure itself?
You can use Traffic View to achieve the purpose. In Azure portal, find your Traffic Manager. Then click Traffic view in left and enable Traffic view.
After that, you can check DNS QUERY SOURCE IP and ENDPOINT to see where the request come from and which endpoint serve this request.
The result likes this screenshot:
I wanted to manage API's published in the Azure API management to be included in the traffic manager for high availability. But when I choose external endpoint option and included API management API hostname it is showing invalid host name.
https://xxxxx.azure-api.net like this domain name have placed
If you have two DNS names that can be used as a active/active or active/passive for your API endpoints, you can add them to a Traffic Manager profile and set the routing method you want to use. As indicated in an earlier answer, use only the DNS name and not the protocol identifier (http/https) when you add an endpoint to a Traffic manager profile
Traffic manager only wants the DNS name (FQDN) for external endpoints not the protocol. So drop the http: or https: from your API management address and it will accept that as an external endpoint.
Or is your problem not with adding the endpoint, but with the health endpoint monitoring? That can happen as the endpoint for the API Management gateway will return a 404 by default as it does not have a publicly exposed default page.
I want to provide failover proof url for my service endpoint to users using traffic management. I have a service instance running at http://vm1.cloudapp.net/myservice:8888/index.html. If this instance goes down then the service auto starts on vm2 at http://vm2.cloudapp.net/myservice:8888/index.html n vice versa.
I want azure to hide the underlying service urls to user and expose the service at http://myservice.trafficmanager.net
Is this possible? If so, how ? From reading the documentation of traffic manager service, it looks like you can failover only at DNS level and not at url endpoint level
There are several parts to this.
Firstly, you are right that Traffic Manager works at the DNS level. It doesn't see your HTTP traffic and hence doesn't see the full URL. Since your two services instances have different DNS names, there's no issue here--you configure Traffic Manager with both names as separate 'endpoints', and Traffic Manager will direct traffic to those endpoints by providing one or other in each DNS response.
Secondly, you want to hide the URL paths. Since Traffic Manager works at the DNS level, it doesn't see your HTTP traffic and hence doesn't see the URL, only the domain name. Therefore this is something you have to handle at the application level (just as you would for a single-instance service that doesn't use Traffic Manager).
The only thing to be careful of is to make sure you configure the correct URL port and path in the Traffic Manager endpoint monitoring configuration. Just make sure that Traffic Manager shows your endpoints as 'Online', and you're good.
Jonathan