I am currently implementing Health monitoring on my ASP.Net Web forms .NET 4.
It gives me below sections of details when there is an un-handled exception on my site.
Summary
Application Information
Events
Process information:
Exception information:
Request information: Thread information:
I would like to also capture user agent details. is it possible?
Can any one point me to the right source on how to achieve this?
Also interested to know how can i capture this exception details in to my database, if the exception is not from database.
Well i found this on msdn, hope any one in need will get benifited with these links.
How to store events to SQL Server
How to forward events to WMI
How to forward events to e-mail
Custom Failure Audit Default at
http://msdn.microsoft.com/en-us/library/system.web.management.webfailureauditevent(v=vs.100).aspx
http://support.microsoft.com/kb/893664
Related
When an exception occurs during execution of a Web.Api controller method in our system, the request is sent to Application Insights as a failure and we send the exception to Application Insights with telemetry.TrackException(actionExecutedContext.Exception);
Behavior:
request is shown as a failure with URL and some other data in the details
exception is shown under Server exceptions with the stack trace shown in the details.
However, when looking at the details of a failed request (due to a server exception), the Exception part does not show the correlated exception - just the default Learn how to track exceptions for failed requests.
When looking at what is sent to Application Insights inside Visual Studio 2017, I see that the exception and request are correlated (same Operation Id).
But it seams that this gets lost on the way to the detail page.
We use ASP.NET WebApi with OWIN, default Application Insights installation (of nuget packages) and applicationinsights-owinextensions (including the steps described there to setup the OWIN extension).
I think How to link exceptions to requests in Application Insights on Azure? does not apply because the data is shown as correlated in the Visual Studio AppInsights Viewer and when clicking Show telemetry for: this operation inside the details view of the exception inside AppInsights.
Maybe related:
Application Insights shows 2 requests for a failure. The first one shows the HTTP Method (e.g. GET) the second one misses the HTTP Method and has a duration that is slightly longer.
Thanks for hints :-)
As you are using applicationinsights-owinextensions, I checked the code for OperationIdTelemetryInitializer that is used to initialize operation id. I believe the reason you're not seeing telemetry linked correctly on detail blades is that this code is not setting operation.parentId field. To verify whether this is correct you can examine the payload sent to check whether parent.id field is set. The initializer that we are shipping in the officially supported .NET SDK sets operation.id, as well as operation.parentId.
So my recommendation is, once you confirm, that parentId is indeed not set, would be to to either fix the OperationIdTelemetryInitializer used in owin-extensions so it starts setting parentId, or replace it in ApplicationInsights.config with your custom one. The latter approach would make it easy to confirm this theory.
The solution was to remove the Microsoft.ApplicationInsights.Web.OperationCorrelationTelemetryInitializer from the application insights config file.
This initializer gets in the way of the initializer from applicationinsights-owinextensions nuget package.
Hi All BizTalk Developers,
I need some input and guidance on how to design an Orchestration that can take few parameters as Input and log them in SQL server table (tblTrackingData)
I want to start this orchestration at various points, for example when I am calling a webservice so I want to log the request in DB and when I get the response then I want to log the response xml also in the same table.
In case of any exception I want to log error message and other details in the same table for tracking purpose.
Can some one guide me, direct me to some existing blogs/posts on how to handle this generic tracking / exceptions etc by starting a new Orchestration.
The purpose of a new Orchestration is to call it from anywhere, please suggest if it could be handled in a better way also.
Thanks.
The best advice, don't do this.
The reason? Everything you describe is already done by BizTalk Server automatically by BizTalk Tracking and the Event Log.
I can tell you from experience, you will not need anything else beyond Tracking and the Event Log.
I do recommend you implement proper exception handling within you app and log custom events, but they would also be written to a Windows Event Log only as well.
Is there any error logging option in APIGee?
I am enabling a proxy endpoint in APIGee for a customer. If there is any error in the flow, how can I log it to a persistent store?
Specifically, I am using javascript policies and parsing some of the returned by back-end service, format to a different format. If there is any parsing error, where and how can I log it?
I am able to catch the error with try catch block.
Can I send an email in the catch block to a specific email address?
Thanks,
Deepak
You can catch the error in your catch block and then set the appropriate variable to contain the detailed error message you might have ran into.You can use syslog/messagelogging policy to send all the request details along with any parsing exception that you might have. You need some kind of a logging server at your end to be sent the logs to or you could also use public log management services, such as loggly. Refer to this section for more details - http://apigee.com/docs/api-services/content/log-messages-using-messagelogging
Vineet I think you are looking to solve the following problems here:
During the coding process you want to debug and understand what is going on? Something that lets you log.debug equivalent.
You want to also trigger exception flows or external processes when things go wrong in your proxy flow.
For #1 you can assign variables and trace using apigee's debug view. Any flow variable assignment in Apigee policies is printed in the debug view, if the policy is executed. So that provides you with log.debug mechanism, whenever you trace.
For #2 you can take a variety of approaches based on rest of your systems and processes. The previous answer by #Mike Dunker is a good approach. I can suggest a few more alternates
As an alternate you can also use Apigee's analytics views to monitor errors, albeit after the fact.
You can set up external monitoring scripts on your backend or on the apigee endpoint based on some synthetic transaction that touches upon the entire logic of your flow. When the services return error you can measure metrics and/or raise alert from your monitoring system.
If you have an on-premise installation of Apigee, you may want to consume apigee log files on the servers and raise appropriate actions on errors.
You can raise a desired error message to a JMS queue when error happens. Refer to Apigee's JMS support here
I have a very simple webservice which is hosted on IIS, if you call any webmethod this basically throws some exception. There is third party application install in the same system where webservice hosted which intercept webmethod and get all information about unhandled exception (like method name, exceptiontype, stacktrace, code etc). Anyone who needs this exception info can subscribe for the eventobject with third party application. So I wrote event subscription code in IIS process itself.
So flow is like this, test client will call webmethod which basically throws some exception, third party application catches those exception and whoever subscribe for exceptioninfo will get those information in XML format.
Now I want that XML information to be accessed in my test client, is there any way to achieve this? I am not sure if this is feasible also or not as I am new to webservice world and please excuse me if this doesn't make any sense.
I found two solution for this problem,
1) Using HttpModule edit the Http response and add the exception info xml in the response itself.
2) have different exe which will run in background and subscribe for the exception info events using API provided by 3rd Party application. Once the exe receive exception information for any failed transaction, exe will write the same information in some shared storage. In my case I am using Azure Table Storage.
I'm working on a traditional ASP.NET application making WCF service calls.
Should I put a try catch around the WCF call and display the error details at the top of the current page; let the error redirect the user to a custom error page; or leave it up IIS / .NET framework?
Which approach is least likely to confuse future developer?
Never to the yellow screen of death. The detailed information about the error can give hints to a hacker to break your site.
If the page cannot be displayed without the service request, then redirect to a custom error page.
If only a small portion of information will be missing on a page which is not key to its function, then better display a friendly message to the user that this particular piece of information is not available at the moment.
This will depend on your application requirements. Can you continue processing if the web service call fails? If not you probably should log the exception and redirect the user to a 500 page. I would use Application_Error method in global.asax to do this. If you can continue the processing then you should put a try/catch around your web service call and handle the appropriate FaultException. You should never let customers see the yellow screen in production.
If you expect that the WCF call can throw an exception and you know which exception types you can get, then yes, you should catch the exception and perform the appropriate action. Usually it is a good idea to tell the user just that an error made the operation to fail, and log the exception detail for further examination by you or the technical support.