Closed josh-k-cb closed 3 years ago
@Josh-Kewley-BC Thanks for your comment. We will review the issue and get back to you shortly.
@Josh-Kewley-BC A couple of questions:
Otherwise, the json file goes into the same folder as the Java agent jar file and then you deploy the app in App Service.
Hi there,
I'm using this option on an Linux app service plan, no custom containers. I'd like to be able to customize the instance using the applicationinsights.json for features such as logging level:
@Josh-Kewley-BC We are a few weeks from releasing a version where some of the configurations (logging level is one of them) will be exposed in the portal. Will that work for you?
Current client is CI/CD only, so I was looking for a file-based solution to config. Is the application.json not meant to work with the auto-instrumented option?
@Josh-Kewley-BC Got it. If you are enabling application insights from the portal, you cannot use json file. That said, if you want to use the json file, it is fully possible - just do it prior to deploying the app into the app services. It takes literally one command line command to enable the application insights Java 3.0 agent for your application. Just follow the steps in the doc you were referring to - https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent
I'd suggest providing context in the documentation to differentiate between the codeless approach which requires deploying a versioned jar file and the codeless approach which can be lit up using ARM. For example, this page only differentiates between SDK and 'agent' based monitoring when apparently there are 3 options (SDK, ARM Agent, jar agent): https://docs.microsoft.com/en-us/azure/azure-monitor/app/azure-web-apps?tabs=net
Also, the docs talk about what happens if both the SDK and agent are running (agent wins) but doesn't cover what happens if the automatic agent (provisioned through ARM) and jar-based agent (deployed with the app) are in place.
@Josh-Kewley-BC Thank you for the feedback. You are right, we will be updating the documents very soon, I will definitely take a notice on making the changes you sugest!
Follow up question, since this is where I started. How can I control the logging level threshold with the ARM-based monitor?
@Josh-Kewley-BC You can set the appropriate environment variable: https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-standalone-config#auto-collected-logging
Closing this issue for now since a new version is close to being released and the doc will be update anyways with the new information ( in which @MS-jgol will consider your feedback when making the updates =D ) @Josh-Kewley-BC let us know if you have any additional questions.
Thank you for your patience.
@MS-jgol following up on this conversation as our team prepares to revisit our AI approach. For a Spring Boot app running on a Linux app service plan, is the recommended approach to deploy the standalone 3.x agent jar with the app rather than leverage the side-car offering which is provided when auto-instrumenting AI for an app service as shown above?
Perhaps I mistakenly assumed they were the same offering. Are they not the same agent with the same capabilities documented here?
@Josh-Kewley-BC What is your timeline? We are in the process of rolling out application insights 3.0 agent - there is a lot of great changes there, and as of now it may or may not be available in the regions you are in. The roll out should be completed in a few weeks (aiming end of April). There is some UI works there as well - we will let you paste the whole configuration file and have all the same controls you have with the standalone agent (this capability is completely new). The document you are referring to is for Java 3.0 agent that is being rolled out right now. For the versions available right now, we do not provide the same functionality. There so many changes, I strongly recommend - if around a month is reasonable for you - to wait for the work to be rolled out and completed. Otherwise, I'd go with the standalone option as you described.
Let me know what you think.
@MS-jgol - when you say you are rolling it out, do you mean as the auto-instrumented feature for app service? Based on that, is the current auto-instrumented service running on our app service version 2 of the agent? I ask because it says it's in preview, and I assumed that meant it was v3.
After you roll out v3, will you recommend deployment via jar file and json doc, or will you recommend the auto-instrumented approach for app service?
Sorry for the ongoing questions - just want to be sure I completely understand.
@Josh-Kewley-BC I apologize for not being very clear :) There are two parts:
When I mention the rollout, the version 3 of Application Insights is being rolled out to App Service, it not completed yet, but definitely in process. In addition, the configuration will be fully available, These are very big changes. Until now, the option to enable in portal would ship version 2.x, and it does not have all the functionality that agent 3.0 has.
Once the deployment is completed, I totally recommend to go with the portal integration, very excited about it, actually! And, you can still add the full json with all the customizations and configurations directly from the portal once all parts of the App Service integration are in place (that's what we are aiming for by the end of April).
Thank you so much for the clarification. I will take this back to the team. Good luck with the rollout!
Hi there,
We are using the auto-instrumentation option of app service to connect our Java back end to AI. The instructions on this page talk about downloading a jar and using a json file in the same directory as the jar to configure app insights. If the application is auto-instrumented, where should the applicationinsghts.json be located?
This documentation page should probably differentiate between the self-instrumentation option of including the jar and the auto-instrumentation featured offered through portal configs.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.