ApplicationInsights-Java
ApplicationInsights-Java copied to clipboard
microsoft
Configuration examples for Azure Functions
Is your feature request related to a problem? Please describe. I'm currently trying to work out the minimal config to get the slf4j logging from the Azure SDK to appear in Application Insights with the correct operation_Id assigned so that I can correlate the logs.
From reading the documentation and some of the source it sounds like I just need to drop the logback-classic jar on my classpath and all will be good (for now I attempted without providing my own logback.xml as it's clearly documented that I shouldn't need to add an appender myself for this to work).
The current behaviour that I'm seeing is that the default logback config is causing all log levels to go to std out, which do end up in Application Insights with customDimensions.Category = Host.Function.Console but this is difficult to correlate with actual requests as it naturally doesn't include the operation_Id
What more do I need to do for the agent to pick the log lines up correctly?
Describe the solution you would like I'd like to find a minimal Java Function App example with documented expected output in Application Insights (perhaps a screenshot is enough).
Describe alternatives you have considered I've googled a lot... lots of references to manual configuration of the 2.4 agent, lots of examples doing this in standalone apps, not finding anything for Function Apps were the agent configuration happens a little more automagically.
Additional context
hey @sharebear!
there's a preview available in the Azure Functions environment that allows you to automatically attach the javaagent if you want to give that a try instead of manually uploading the javaagent and changing the JVM args:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/monitor-functions#distributed-tracing-for-java-applications-on-windows-public-preview
Ahhh, I'm starting to understand now. I didn't realise that using the agent required a manual upload of the agent jar, I incorrectly understood that the existing application insights integration for functions already did this. Maybe I should look into using v2 until the good stuff comes to the linux runtime.
@sharebear are you using Azure Functions Consumption plan, or Dedicated/Premium plan?
@trask I'm deploying my functions to an App Service Plan (P2v2). For now I've left the slf4j experiments to the side and am just using the logger available through context.logger this works ok for now although also leads to duplicate logs one with the following customDimensions and missing operation_Name
customDimensions | {"LoggingLevel":"INFO","SourceType":"Logger"}
The other that I assume comes via the runtime with the following customDimensions
customDimensions | {"HostInstanceId":"<redacted>","InvocationId":"<redacted>","ProcessId":"18","LogLevel":"Information","Category":"Function.<redacted>.User"}
Not ideal with the dupliate logs, but it's working good enough for now. I might try and revist this at some point during the next month.
@sharebear operation_Name is not part of the customDimensions. Which table were you querying for? can you try to project these 4 fields in your query and then share with me the result:
| project timestamp, customDimensions, sdkVersion, operation_Name
In the meantime, i will try to repro it noticing it was for App Service Plan Function app.
@sharebear We will work with Azure Function Team to address the duplicate logs.
customDimensions | {"LoggingLevel":"INFO","SourceType":"Logger"} is from Java Agent.
customDimensions | {"HostInstanceId":"<redacted>","InvocationId":"<redacted>","ProcessId":"18","LogLevel":"Information","Category":"Function.<redacted>.User"}
is from Azure Functions Host.
I've created a work item to track this issue: #9909730.
Sorry for the slow reply, but it sounds like you've managed to reproduce youreself. Thanks for keeping me updated.
hi @sharebear, sorry for this taking so long. it has been fixed now and should be rolled out to Azure Functions environments by early January.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.
