Instrumenting incoming HTTP requests with the X-Ray SDK for .NET
You can use the X-Ray SDK to trace incoming HTTP requests that your application serves on an EC2 instance in Amazon EC2, AWS Elastic Beanstalk, or Amazon ECS.
Use a message handler to instrument incoming HTTP requests. When you add the X-Ray message handler to your application, the X-Ray SDK for .NET creates a segment for each sampled request. This segment includes timing, method, and disposition of the HTTP request. Additional instrumentation creates subsegments on this segment.
Note
For AWS Lambda functions, Lambda creates a segment for each sampled request. See AWS Lambda and AWS X-Ray for more information.
Each segment has a name that identifies your application in the service map. The segment can be named statically, or you can configure the SDK to name it dynamically based on the host header in the incoming request. Dynamic naming lets you group traces based on the domain name in the request, and apply a default name if the name doesn't match an expected pattern (for example, if the host header is forged).
Forwarded Requests
If a load balancer or other intermediary forwards a request to your application,
X-Ray takes the client IP from the X-Forwarded-For
header in the
request instead of from the source IP in the IP packet. The client IP that is recorded for a forwarded
request can be forged, so it should not be trusted.
The message handler creates a segment for each incoming request with an http
block that contains the following information:
-
HTTP method – GET, POST, PUT, DELETE, etc.
-
Client address – The IP address of the client that sent the request.
-
Response code – The HTTP response code for the completed request.
-
Timing – The start time (when the request was received) and end time (when the response was sent).
-
User agent — The
user-agent
from the request. -
Content length — The
content-length
from the response.
Sections
Instrumenting incoming requests (.NET)
To instrument requests served by your application, call RegisterXRay
in the
Init
method of your global.asax
file.
Example global.asax - message handler
using System.Web.Http;
using Amazon.XRay.Recorder.Handlers.AspNet;
namespace SampleEBWebApplication
{
public class MvcApplication : System.Web.HttpApplication
{
public override void Init()
{
base.Init();
AWSXRayASPNET.RegisterXRay(this, "MyApp
");
}
}
}
Instrumenting incoming requests (.NET Core)
To instrument requests served by your application, call UseXRay
method before any other middleware in the
Configure
method of your Startup class as ideally X-Ray middleware should be the first middleware to process
the request and last middleware to process the response in the pipeline.
Note
For .NET Core 2.0, if you have a UseExceptionHandler
method in the application, make sure to
call UseXRay
after UseExceptionHandler
method to ensure exceptions are
recorded.
Example Startup.cs
using Microsoft.AspNetCore.Builder;
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseXRay("MyApp
");
// additional middleware
...
}
using Microsoft.AspNetCore.Builder;
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseExceptionHandler("/Error");
app.UseXRay("MyApp
");
// additional middleware
...
}
The UseXRay
method can also take a configuration object as a second
argument.
app.UseXRay("MyApp", configuration);
Configuring a segment naming strategy
AWS X-Ray uses a service name to identify your application and distinguish it from the other applications, databases, external APIs, and AWS resources that your application uses. When the X-Ray SDK generates segments for incoming requests, it records your application's service name in the segment's name field.
The X-Ray SDK can name segments after the hostname in the HTTP request header. However, this header can be forged, which could result in unexpected nodes in your service map. To prevent the SDK from naming segments incorrectly due to requests with forged host headers, you must specify a default name for incoming requests.
If your application serves requests for multiple domains, you can configure the SDK to use a dynamic naming strategy to reflect this in segment names. A dynamic naming strategy allows the SDK to use the hostname for requests that match an expected pattern, and apply the default name to requests that don't.
For example, you might have a single application serving requests to three subdomains–
www.example.com
, api.example.com
, and static.example.com
.
You can use a dynamic naming strategy with the pattern *.example.com
to identify
segments for each subdomain with a different name, resulting in three service nodes on the service
map. If your application receives requests with a hostname that doesn't match the pattern,
you will see a fourth node on the service map with a fallback name that you specify.
To use the same name for all request segments, specify the name of your application when
you initialize the message handler, as shown in the previous section. This has
the same effect as creating a FixedSegmentNamingStrategy
and passing it to the
RegisterXRay
method.
AWSXRayASPNET.RegisterXRay(this, new FixedSegmentNamingStrategy("MyApp
"));
Note
You can override the default service name that you define in code with the
AWS_XRAY_TRACING_NAME
environment variable.
A dynamic naming strategy defines a pattern that hostnames should match, and a default
name to use if the hostname in the HTTP request does not match the pattern. To name segments
dynamically, create a DynamicSegmentNamingStrategy
and pass it to the
RegisterXRay
method.
AWSXRayASPNET.RegisterXRay(this, new DynamicSegmentNamingStrategy("MyApp
", "*.example.com
"));