I'm trying to get some additional information about the message we received (basically its application-level outcome) into the Application Insights RequestTelemetry object for a WCF service.
Application Insights is logging request telemetry already. I created an ITelemetryInitializer that is being run, but at the time it runs I have no way that I can find to access information about the request, much less application-specific data from the request's context.
Is there somewhere I can put data that will be accessible by the ITelemetryInitializer at the time it runs?
public class WcfServiceTelemetryInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
if (telemetry is RequestTelemetry rTelemetry)
{
// HttpContext.Current is populated at this point, but doesn't seem to be available within my application code.
// So is System.ServiceModel.OperationContext.Current
}
}
}
I had to face similar issue as the author described. Tried by implementing ITelemetryInitializer/ITelemetryProcessor but did not work.
Ended up writing my own MessageTraceTelemetryModule class implementing IWcfTelemetryModule and IWcfMessageTrace.
In the OnTraceResponse method, I added my custom property to the request telemetry by extracting value from OperationContext (which is accessible here!):
internal class MessageTraceTelemetryModule : IWcfTelemetryModule, IWcfMessageTrace
{
public void OnTraceResponse(IOperationContext operation, ref Message response)
{
if (OperationContext.Current.IncomingMessageProperties.TryGetValue("clientID", out object value))
{
operation.Request.Properties.Add("clientID", value.ToString());
}
}
}
New custom property visible in Application Insights telemetry - ClientID custom property Pic.
Note that the clientID property is being set in the OperationContext in Message Inspector:
public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
{
if(!OperationContext.Current.IncomingMessageProperties.ContainsKey("clientID"))
OperationContext.Current.IncomingMessageProperties.Add("clientID", clientID);
}
Brief Context:
I implemented AAD Token based Authentication in a SOAP based WCF Service.
I needed to store the clientID from the token (which is validated in message inspector) and add the same as a custom property in the application insights request telemetry.
References:
Message Inspectors Documentation
Application Insights for WCF Documentation
In case it helps anyone, Application Insights automatically adds custom dimensions from data you store in System.Diagnostics.Activity.Current.AddBaggage(), or at least it does in asp.net 5. That might be available at the right place for you in WCF land.
e.g.
var currentActivity = System.Diagnostics.Activity.Current;
if (currentActivity != null)
{
currentActivity.AddBaggage("MyPropertyName", someData);
}
To log custom property, you can try like this...
public class CustomTelemetry : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
var requestTelemetry = telemetry as RequestTelemetry;
if (requestTelemetry == null) return;
requestTelemetry.Properties.Add("CustomProperty", "DummyValue");
}
}
And register CustomTelemetry at start of the application
TelemetryConfiguration.Active.TelemetryInitializers.Add(new CustomTelemetry());
Here is the Original Answer
MS Doc - Application Insights API for custom events and metrics
Related
Recently we encountered an issue where our servers times out because of huge traffic surge, and those request telemetries were logged into AI as success with response code zero. Is there any way to configure response code zero to be termed as failure. Since request telemetries are captured automatically by AI so we dont have any handle on that
You can do it by using ITelemetryInitializer in your .NET core project.
To be termed as failure when response code is zero, you can set the Success property of request telemetry data as false. The sample code as below(using .NET core 2.2 for this test). And please make sure you're using the latest version of Microsoft.ApplicationInsights.AspNetCore 2.13.1.
Here is the custom ITelemetryInitializer:
public class MyTelemetryInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
if (telemetry is RequestTelemetry)
{
var requestTelemetry = telemetry as RequestTelemetry;
//you can change the ResponseCode to "0" in your project
if (requestTelemetry.ResponseCode == "200")
{
// set Success property to false
requestTelemetry.Success = false;
}
}
}
}
then register it in the Startup.cs -> ConfigureServices method:
public void ConfigureServices(IServiceCollection services)
{
//your other code
//here, register the custom ITelemetryInitializer
services.AddSingleton<ITelemetryInitializer, MyTelemetryInitializer>();
}
After executing the code, in azure portal -> your application insights -> Logs, you can see the Success property of request are made as false:
I have implemented a custom authentication scheme in a web service based on the ASP.NET Core webhost. I want to add Application Insights to this service.
When I successfully authenticate the user, I do something like this
telemetry.Context.User.Id = authenticatedUserName;
the telemetry object is the TelemetryClient I get from dependency injection.
Now, the problem is that the user ID does not show up among the requests, and I am not sure why.
This works
customEvents | where user_Id != "" and name == "MyCustomEvent"
but not this
request | where user_Id != ""
or this
dependencies | where user_Id != ""
Is there somewhere else where I should set the user ID for the request? I'd rather not create a custom event just for this.
I also tried setting the User property on the HttpContext object, but it does not seem to have any effect.
You should use ITelemetryInitializer for your purpose.
The following is my test steps(asp.net core 2.1):
Step 1:Add the Aplication Insights telemetry by right click your project -> Add -> Application Insights telemetry. The screenshot as below:
Step 2:Add a new class which implements the ITelemetryInitializer:
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
namespace WebApplication33netcore
{
public class MyTelemetryInitializer: ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
var request = telemetry as RequestTelemetry;
if (request != null)
{
//set the user id here with your custom value
request.Context.User.Id = "ivan111";
}
}
}
}
Step 3:Register your telemetry initializer in ConfigureServices method in Startup.cs. For details, refer to here:
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
//Add the following code to register your telemetry initializer
services.AddSingleton<ITelemetryInitializer>(new MyTelemetryInitializer());
}
Step 4:Check the test result:
In visual studio Application Insights Search:
Then check it in Analytics:
Actually, the answer was surprisingly simple.
HttpContext ctx = ...
var requestTelemetry = ctx.Features.Get<RequestTelemetry>()
requestTelemetry.Context.User.Id = authenticationResult.UserName;
We have an Azure web role deployed that has been using Application Insights (ver. 1.0.0.4220), however, we're going over our data quota. Is it possible to configure Application Insights ignore a specific URL?
We have a status web service that gets a huge amount of traffic but never throws any errors. If I could exclude this one service URL I could cut my data usage in half.
Out of the box it is not supported. Sampling feature is coming but that would not be configurable by specific url. You can implement your own channel that would have your custom filtering. Basically your channel will get event to be sent, you check if you want to send it or not and then if yes pass to standard AI channel. Here you can read more about custom channels.
There are two things that changed since this blog post has been written:
channel should implement only ITelemetryChannel interface (ISupportConfiguration was removed)
and instead of PersistenceChannel you should use Microsoft.ApplicationInsights.Extensibility.Web.TelemetryChannel
UPDATE: Latest version has filtering support: https://azure.microsoft.com/en-us/blog/request-filtering-in-application-insights-with-telemetry-processor/
My team had a similiar situation where we needed to filter out urls that were successful image requests (we had a lot of these which made us hit the 30k datapoints/min limit).
We ended up using a modified version of the class in Sergey Kanzhelevs blog post to filter these out.
We created a RequestFilterChannel class which is an instance of ServerTelemetryChannel and extended the Send method. In this method we test each telemetry item to be sent to see if it is an image request and if so, we prevent it from being sent.
public class RequestFilterChannel : ITelemetryChannel, ITelemetryModule
{
private ServerTelemetryChannel channel;
public RequestFilterChannel()
{
this.channel = new ServerTelemetryChannel();
}
public void Initialize(TelemetryConfiguration configuration)
{
this.channel.Initialize(configuration);
}
public void Send(ITelemetry item)
{
if (item is RequestTelemetry)
{
var requestTelemetry = (RequestTelemetry) item;
if (requestTelemetry.Success && isImageRequest((RequestTelemetry) item))
{
// do nothing
}
else
{
this.channel.Send(item);
}
}
else
{
this.channel.Send(item);
}
}
public bool? DeveloperMode
{
get { return this.channel.DeveloperMode; }
set { this.channel.DeveloperMode = value; }
}
public string EndpointAddress
{
get { return this.channel.EndpointAddress; }
set { this.channel.EndpointAddress = value; }
}
public void Flush()
{
this.channel.Flush();
}
public void Dispose()
{
this.channel.Dispose();
}
private bool IsImageRequest(RequestTelemetry request)
{
if (request.Url.AbsolutePath.StartsWith("/image.axd"))
{
return true;
}
return false;
}
}
Once the class has been created you need to add it to your ApplicationInsights.config file.
Replace this line:
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel"/>
with a link to your class:
<TelemetryChannel Type="XXX.RequestFilterChannel, XXX" />
Alternatively, you can disable the automated request collection and keep only exception auto-collection, just remove the RequestTrackingModule line from applicationinsights.config.
If you still need to collect some of the requests, not just filter all out, you can then call TrackRequest() (in the object of TelemetryClient class) from your code in the appropriate place after you know that you certainly need to log this request to AI.
Update: Filtering feature has been released some time ago and allows for exclusion of certain telemetry items way easier.
I'm using ServiceStack (version 3.9.44.0) as a Windows Service (so I'm not using IIS) and I use both its abilities both as an API and for serving web pages.
However, I haven't been able to find how exactly I should enable compression when the client supports it.
I imagined that ServiceStack would transparently compress data if the client's request included the Accept-Encoding:gzip,deflate header, but I'm not seeing any corresponding Content-Encoding:gzip in the returned responses.
So I have a couple of related questions:
In the context of using ServiceStack as a standalone service (without IIS), how do I enable compression for the responses when the browser accepts it.
In the context of a C# client, how do similarly I ensure that communication between the client/server is compressed.
If I'm missing something, any help would be welcome.
Thank you.
If you want to enable compression globally across your API, another option is to do this:
Add this override to your AppHost:
public override IServiceRunner<TRequest> CreateServiceRunner<TRequest>(ActionContext actionContext)
{
return new MyServiceRunner<TRequest>(this, actionContext);
}
Then implement that class like this:
public class MyServiceRunner<TRequest> : ServiceRunner<TRequest>
{
public MyServiceRunner(IAppHost appHost, ActionContext actionContext) : base(appHost, actionContext)
{
}
public override void OnBeforeExecute(IRequestContext requestContext, TRequest request)
{
base.OnBeforeExecute(requestContext, request);
}
public override object OnAfterExecute(IRequestContext requestContext, object response)
{
if ((response != null) && !(response is CompressedResult))
response = requestContext.ToOptimizedResult(response);
return base.OnAfterExecute(requestContext, response);
}
public override object HandleException(IRequestContext requestContext, TRequest request, Exception ex)
{
return base.HandleException(requestContext, request, ex);
}
}
OnAfterExecute will be called and give you the chance to change the response. Here, I am compressing anything that is not null and not already compressed (in case I'm using ToOptimizedResultUsingCache somewhere). You can be more selective if you need to but in my case, I'm all POCO objects with json.
References
ServiceStack New Api
For those interested, a partial answer to my own question, you can use the extension method ToOptimizedResult() or, if you are using caching ToOptimizedResultUsingCache().
For instance, returning a compressed result:
public class ArticleService : Service
{
public object Get(Articles request) {
return base.RequestContext.ToOptimizedResult(
new List<Articles> {
new Article {Ref = "SILVER01", Description = "Silver watch"},
new Article {Ref = "GOLD1547", Description = "Gold Bracelet"}
});
}
}
References
CachedServices.cs example
CompressedResult.cs
Google Group question on Compression in ServiceStack
I have created a plugin which inspects a param in the query string and loads up a user object based on this ID and populates
any request DTO with it. (All my request DTO's inherit from BaseRequest which has a CurrentUser property)
public class CurrentUserPlugin : IPlugin
{
public IAppHost CurrentAppHost { get; set; }
public void Register(IAppHost appHost)
{
CurrentAppHost = appHost;
appHost.RequestFilters.Add(ProcessRequest);
}
public void ProcessRequest(IHttpRequest request, IHttpResponse response, object obj)
{
var requestDto = obj as BaseRequest;
if (requestDto == null) return;
if (request.QueryString["userid"] == null)
{
throw new ArgumentNullException("No userid provided");
}
var dataContext = CurrentAppHost.TryResolve<IDataContext>();
requestDto.CurrentUser = dataContext.FindOne<User>(ObjectId.Parse(requestDto.uid));
if (requestDto.CurrentUser == null)
{
throw new ArgumentNullException(string.Format("User [userid:{0}] not found", requestDto.uid));
}
}
}
I need to have this User object available in my services but I don't want to inspect the DTO every time and extract from there. Is there a way to make data from plugins globally available to my services? I am also wondering if there is another way of instantiating this object as for my unit tests, the Plugin is not run - as I call my service directly.
So, my question is, instead of using Plugins can I inject a user instance to my services at run time? I am already using IoC to inject different Data base handlers depending on running in test mode or not but I can't see how to achieve this for User object which would need to be instantiated at the beginning of each request.
Below is an example of how I inject my DataContext in appHost.
container.Register(x => new MongoContext(x.Resolve<MongoDatabase>()));
container.RegisterAutoWiredAs<MongoContext, IDataContext>();
Here is an example of my BaseService. Ideally I would like to have a CurrentUser property on my service also.
public class BaseService : Service
{
public BaseService(IDataContext dataContext, User user)
{
DataContext = dataContext;
CurrentUser = user; // How can this be injected at runtime?
}
public IDataContext DataContext { get; private set; }
public User CurrentUser { get; set; }
}
Have you thought about trying to use the IHttpRequest Items Dictionary to store objects. You can access these Items from any filter or service or anywhere you can access IHttpRequest. See the src for IHttpRequest.
Just be mindful of the order that your attributes, services and plugins execute and when you store the item in the Items dictionary.
Adding:
We don't want to use HttpContext inside of the Service because we want use Service in our tests directly.
Advantages for living without it
If you don't need to access the HTTP
Request context there is nothing stopping you from having your same
IService implementation processing requests from a message queue which
we've done for internal projects (which incidentally is the motivation
behind the asynconeway endpoint, to signal requests that are safe for
deferred execution).
http://www.servicestack.net/docs/framework/accessing-ihttprequest
And we don't use http calls to run tests.
So our solution is:
public class UserService
{
private readonly IDataContext _dataContext;
public UserService(IDataContext dataContext)
{
_dataContext = dataContext;
}
public User GetUser()
{
var uid = HttpContext.Current.Request.QueryString["userId"];
return _dataContext.Get<User>(uid);
}
}
and
container.Register(x => new UserService(x.Resolve<IDataContext>()).GetUser()).ReusedWithin(ReuseScope.Request);
This is service signature:
public SomeService(IDataContext dataContext, User user) { }
Any suggestions?
I need to have this User object available in my services but I don't want to inspect the DTO every time and extract from there
How will your application know about the user if you're not passing the 'userid' in the querystring? Could you store the user data in the Session? Using a Session assumes the client is connected to your app and persists a Session Id (ss-id or ss-pid cookie in ServiceStack) in the client that can be looked up on the Server to get the 'session data'. If you can use the Session you can retrieve the data from your service doing something like
base.Session["UserData"] or base.SessionAs<User>();
Note: you will need to save your User data to the Session
Is there a way to make data from plugins globally available to my services? but I can't see how to achieve this for User object which would need to be instantiated at the beginning of each request.
This sounds like you want a global request filter. You're kind of already doing this but you're wrapping it into a Plugin.