I am using azure function with ILogger to log exception and tracing in Application Insights. I use log.LogError with an exception object as a second parameter. However, whatever log it only comes under traces in app insights and doesn't logs the entire exception object. Is there a way to get exception object with the entire stack?
Also, the dependency is empty and I make multiple HTTP calls and I am expecting it to log all HTTP calls as dependency.
The LogError extension method takes the exception object as the first parameter. Give that a try and your Exception object should show up correctly in App Insights.
public static void LogError (this Microsoft.Extensions.Logging.ILogger logger, Exception exception, string message, params object[] args);
Related
I've created a simple Azure function which is triggered on a service bus queue.
I'd like to inject a the full message payload into the trigger. Now there are 2 libraries available for working with Azure Service Bus - the older https://www.nuget.org/packages/Microsoft.Azure.ServiceBus/ and the newer https://www.nuget.org/packages/Azure.Messaging.ServiceBus/
If I inject in the message payload using Microsoft.Azure.ServiceBus.Message works, however using the newer Azure.Messaging.ServiceBus.ServiceBusMessage gives a run-time error.
Ideally would like to use the newer library - is there any config change required to make this work?
The error is
Executed 'IncomingMessageProcessingFunction' (Failed, Id=01b3f0c1-fe4d-4d0f-89db-7814a4a0ddbe, Duration=2756ms)
[2021-09-13T10:56:47.944Z] System.Private.CoreLib: Exception while executing function: IncomingMessageProcessingFunction. Microsoft.Azure.WebJobs.Host: Exception binding parameter 'myQueueItem'. Microsoft.Azure.WebJobs.ServiceBus: Binding parameters to complex objects (such as 'ServiceBusMessage') uses Json.NET serialization or XML object serialization.
[2021-09-13T10:56:47.946Z] 1. If ContentType is 'application/json' deserialize as JSON
[2021-09-13T10:56:47.948Z] 2. If ContentType is not 'application/json' attempt to deserialize using Message.GetBody, which will handle cases like XML object serialization
[2021-09-13T10:56:47.949Z] 3. If this deserialization fails, do a final attempt at JSON deserialization to catch cases where the content type might be incorrect
[2021-09-13T10:56:47.951Z] The JSON parser failed: Error converting value 123 to type 'Azure.Messaging.ServiceBus.ServiceBusMessage'. Path '', line 1, position 3.
Works
[FunctionName("IncomingMessageProcessingFunction")]
public static void Run([ServiceBusTrigger("incomingmessageprocessingqueue", Connection = "SERVICEBUS")]Microsoft.Azure.ServiceBus.Message myQueueItem, ILogger log)
{
log.LogInformation($"C# ServiceBus queue trigger function processed message: {myQueueItem.Body}");
I'm developing a Service Bus Trigger in Azure Functions v1 locally with Visual Studio 2017. I want to test the example from the official docs without having to put a message in the service bus. So I trigger it via Postman at endpoint POST http://localhost:7071/admin/functions/ServiceBusQueueTriggerCSharp with body { "input": "foo" }.
This fails with a script host error: Exception while executing function: ServiceBusQueueTriggerCSharp. Microsoft.Azure.WebJobs.Host: One or more errors occurred. Exception binding parameter 'deliveryCount'. Microsoft.Azure.WebJobs.Host: Binding data does not contain expected value 'deliveryCount'.
I tried removing the deliveryCount argument, but then it fails at enqueueTimeUtc. Removing that too works. Is there a way to keep these arguments and test the Function locally?
I understand that these two arguments wouldn't make much sense when triggered via HTTP, but they could be given default values. messageId has a non-zero value.
Example for reference:
[FunctionName("ServiceBusQueueTriggerCSharp")]
public static void Run(
[ServiceBusTrigger("myqueue", AccessRights.Manage, Connection = "ServiceBusConnection")]
string myQueueItem,
Int32 deliveryCount, // this fails
DateTime enqueuedTimeUtc, // this fails too
string messageId,
TraceWriter log)
{
log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
log.Info($"DeliveryCount={deliveryCount}");
log.Info($"MessageId={messageId}");
}
As of right now, if you want to be able to work with these additional metadata properties, you'll need to use a real service bus message.
In theory, the admin endpoint could be smart enough to allow you to pass additional binding data (such as deliveryCount in this case) as query parameters. I filed the following feature request to track:
https://github.com/Azure/azure-functions-host/issues/2955
i am encountering a problem i'm not familiar with.
So i'm trying to log exceptions from a test Azure Function but when i throw an exception and return a 400 bad request, application insight registers the log as a successful request.
As i understand it it is probably register the function's successful run but what i don't understand is how i then should log the exception.
So what i have done so far is this.
(I Will be referring to Application Insights as AI from here on out)
I started by created an AI-Resource.
Then i took the instrument key and applied it to the app settings of my function.
After that i installed the AI NUGET to my function bu creating a Projet.json file and then pasting something like this which installed the necessary assemblies and such.
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.ApplicationInsights": "2.4.0"
}
}
}
}
after this i initialize the TelemetryClient in the function and try to log and exception in a catch:
Initiation:
string key = TelemetryConfiguration.Active.InstrumentationKey = System.Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);
TelemetryClient telemetry = new TelemetryClient() {
InstrumentationKey = key
};
Catch:
catch (Exception e)
{
Dictionary<string,string> properties = new Dictionary<string,string>();
properties.Add("Function Payload", data.ToString());
properties.Add("Function Exception", e.ToString());
telemetry.TrackException(e, properties);
return req.CreateResponse(HttpStatusCode.BadRequest, e);
}
Test running the function i get:
2018-03-07T14:24:36.171 [Info] Function started (Id=0292b455-314d-4c4c-872a-2b8137a72305)
2018-03-07T14:24:37.092 [Info] Function completed (Success, Id=0292b455-314d-4c4c-872a-2b8137a72305, Duration=931ms)
In Application insights i can can only see bad requests for StatusCode: 500
but 400 Bad requests gets logged as Successful requests.
And also the TrackException functionality doesn't log any of the custom properties...
So what am i missing?
MORE DETAILS ABOUT EXCEPTION LOGGING:
#Mikhail is right that we treat this as a success because the function is a success. We didn't want to use status codes to guess whether there was a successful operation or not, so we look for whether the function threw an exception.
Your exception isn't appearing in that screen because it hasn't been property correlated with this function execution. If you go to App Insights Analytics and query for that ExceptionTelemetry, you should see it.
In order to correlate it with a specific function, you'd need to set the OperationId, which is the same as the function's InvocationId. There is a sample that shows how to do this with Events, Metrics, and Dependencies, but doing it for Exceptions is the same (you can ignore the User.Id assignment): https://learn.microsoft.com/en-us/azure/azure-functions/functions-monitoring#custom-telemetry-in-c-functions
Update: From what you've shown of your function above, you may be able to get away with doing something like:
catch (Exception e)
{
log.Error("Function Payload " + data.ToString());
throw;
}
That would return a 500 (rather than a 400), and Functions would log the trace to Application Insights, and then log the exception as well as the Request failure. If you're not using your TelemetryClient anywhere else, you could remove that from your code.
The server (Azure Function) processed the request without errors, you returned a result from it, so from the point of view of Function App runtime the request was processed successfully. You can see that from the log too:
... Function completed (Success, ...
So, it makes sense that the Function App registers the call as success in Application Insights too. At least, that's how they chose to implement it.
the "for this operation" not showing exceptions implies that the exception that you sent does not have the same operationId as the azure function. operation
id is how application insights "links" related telemetry together.
your "exeption logging" screenshot is not an exception, but a request, so the custom properties logged on your exception won't be there.
if you want your azure function to fail, and show as a failed request, and log an exception, why are you catching the exception and logging it yourself? doesn't catching the exception then cause the azure function to succeed? why not just let the exception trickle out and let the function runtime do that part for you? (doesn't it?)
I am trying to follow the instructions in Insights Preview where I can create custom telemetry. I followed the instructions exactly. But maybe I've got it configured wrong.
I have the APPINSIGHTS_INSTRUMENTATIONKEY set in the local.settings.json file and it seems to work fine. But when I add a new TelemetryClient I start getting those duplicate errors (below). It happens when the function gets invoked.
I really would like the telemetry data from AF to go to the same AI instrumentation key so I can see it together.
I also pulled the Microsoft.Extensions.Logging out as I wanted to use AI only, if that makes any difference.
Anyone have any suggestions?
See below...
TIA
ERROR: Exception in Command Processing for EventSource Microsoft-ApplicationInsights-Core: An instance of EventSource with Guid 74af9f20-af6a-5582-9382-f21f674fb271 already exists.
ERROR: Exception in Command Processing for EventSource Microsoft-ApplicationInsights-Core: An instance of EventSource with Guid 74af9f20-af6a-5582-9382-f21f674fb271 already exists.
Microsoft.WindowsAzure.ServiceRuntime Critical: 102 : Unexpcted Exception During Runtime Startup:
System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> <CrtImplementationDetails>.ModuleLoadException: The C++ module failed to load while attempting to initialize the default appdomain.
---> System.Runtime.InteropServices.COMException: Invalid operation. (Exception from HRESULT: 0x80131022)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at <CrtImplementationDetails>.GetDefaultDomain()
at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr function, Void* cookie)
at <CrtImplementationDetails>.LanguageSupport.InitializeDefaultAppDomain(LanguageSupport* )
at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* )
at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
--- End of inner exception stack trace ---
at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
at .cctor()
--- End of inner exception stack trace ---
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.InitializeEnvironment()
at Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment..cctor()
ERROR: Exception in Command Processing for EventSource Microsoft-ApplicationInsights-Data: An instance of EventSource with Guid a62adddb-6b4b-519d-7ba1-f983d81623e0 already exists.
I started over with a fresh AF project (and a glass of wine) to keep it simple.
The following code works:
private static TelemetryConfiguration config = new TelemetryConfiguration { InstrumentationKey = System.Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process)};
private static TelemetryClient telemetryClient = new TelemetryClient(config);
This code (directly from the Preview post) does not:
private static TelemetryClient telemetryClient = new TelemetryClient();
private static string key = TelemetryConfiguration.Active.InstrumentationKey = System.Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);
An unfortunate side effect is that the telemetry doesn't show up in te VS2017 Application Insights window automatically. You have to use the settings gear to select the AI repository you want and then you can see it. Minutes later, but better than nothing.
I'm using a Webjob with the Windows Azure Storage SDK. When a new item shows up in a Queue, a method in my class is invoked. According to the SDK docs, if I take a TextWriter as a parameter to my method, the SDK will provide me with a TextWriter that I can write to which will show up in the Webjob's logging infrastructure. This makes it pretty easy to diagnose issues and troubleshoot things.
public async static void ProcessQueueMessage([QueueTrigger("queueName")]MyModelType model, TextWriter logger)
{
await logger.WriteLineAsync(string.Format("Processing Item {0}", model.SasUrl));
// Some work here
await logger.WriteLineAsync(string.Format("Done Processing Item {0}", model.SasUrl));
}
However, very frequently, within the body of my method, the TextWriter is being disposed of. I'm getting the following exception on the 2nd logger.WriteLineAsync:
System.ObjectDisposedException was unhandled by user code
HResult=-2146232798
Message=Cannot write to a closed TextWriter.
Source=mscorlib
ObjectName=""
StackTrace:
at System.IO.__Error.WriterClosed()
at System.IO.StringWriter.Write(Char[] buffer, Int32 index, Int32 count)
at System.IO.TextWriter.WriteLine(String value)
at System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
at System.IO.TextWriter.SyncTextWriter.WriteLineAsync(String value)
at NameOfProject.Program.<ProcessQueueMessage>d__8.MoveNext() in c:\Dev\Path\To\Program.cs:line 173
InnerException:
I can't find others having this problem, so I can't imagine there is a bug in the SDK or webjobs infrastructure.
Is there a way to tell if the logger is disposed of ahead of the call?
Is there a way to create a new logger within my method that will participate in the WebJobs logging subsystems and UI?
That's because your method returns void. Try returning Task instead