Bump applicationinsights from 2.9.5 to 3.0.1 in /ops/services/app_functions/report_stream_batched_publisher/functions
Bumps applicationinsights from 2.9.5 to 3.0.1.
Release notes
Sourced from applicationinsights's releases.
3.0.0
#1282 Fix Auto Exception Collection. #1292 Update Warning Tests and Add Console Logging by Default. #1296 Update agent backoff logic. #1298 Update Support Status of Native Metrics & Env Vars. #1300 Clean Up Shim Files & Fix Check for Extended Metrics Env Var. #1302 Add Shim Performance Testing. #1306 Update Unsupported Messages & Remove Deprecated SemAttrs.
3.0.0 beta 12
#1300 Clean Up Shim Files & Fix Check for Extended Metrics Env Var. #1298 Update Support Status of Native Metrics & Env Vars. #1296 Update agent backoff logic #1292 Update Warning Tests and Add Console Logging by Default. #1282 Fix Auto Exception Collection. #1275 Add Note Regarding Our Support for Node Versions. #1272 Auto collection of logs aligning to OpenTelemetry. #1271 Update Prefix Version in Auto-Attach Scenarios. #1270 Update Instrumentation Options Type in Docs and Export from Index. #1268 Detect Distro Already Loaded in Agent. #1266 Update Node.js runtime check in Agent. #1264 Update Beta Code Examples README.
3.0.0 beta 11
#1262 Extend the shim to support live metrics and the browser SDK Loader. #1256 Shift to using the diag API for logging. #1254 Update the shim support table to reflect changes in Azure Monitor OpenTelemetry. #1248 Fix serialization of logged errors. #1227 Remove duplicated types. #1228 Fix request performance counters not being calculated correctly. #1236 Fix Linux platform check in the agent.
3.0.0 beta 10
#1221 Increase Testing Code Coverage. #1223 Add env check to initialize OTLP Metrics in AKS. #1228 Remove duplicate types. #1228 Fix issue with performance counters not being calculated correctly.
3.0.0 beta.9
#1203 Fix JSON Configuration in the shim. #1206 Stringify objects when building a
LogRecord#1208 Use@βazure/monitor-opentelemetry#1209 Rename Options interface to AzureMonitorOpenTelemetryOptions #1210 Update the README to include shim support information.3.0.0 beta.8
#1201 Shadow Azure Monitor OpenTelemetry Distro #1197 Add OTLP Exporters and Perf Counters #1194 Consume latest Azure Monitor OpenTelemetry
... (truncated)
Commits
- See full diff in compare view
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
@dependabot rebase
Based on my digging around...
Looks like v3 of applicationinsights uses Azure Monitor OpenTelemetry.
Our function tests are failing because tagOverrides does not seem to be supported in v3 vs v2.
I think this might be related to the Node.js version of OpenTelemetry not supporting certain overrides. My guess is that even though they don't explicitly call out Operation Id it might be included in what's not being supported π
(see screenshot below)
We are currently using tagOverrides property to override the "Operation Id" of our custom events. (It's the same value as the Parent Id that we also track) I'm not sure why we wanted to override this in the first place π§
If overriding this is important to us, then I don't think we should upgrade to this version.
Let me know what you all think... π€
Based on my digging around... Looks like v3 of
applicationinsightsuses Azure Monitor OpenTelemetry.Our function tests are failing because
tagOverridesdoes not seem to be supported in v3 vs v2.I think this might be related to the Node.js version of OpenTelemetry not supporting certain overrides. My guess is that even though they don't explicitly call out
Operation Idit might be included in what's not being supported π (see screenshot below)We are currently using [`tagOverrides` property to override the "Operation Id"](https://github.com/search?q=repo%3ACDCgov%2Fprime-simplereport+ai.operation.id&type=code) of our custom events. (It's the same value as the Parent Id that we also track) I'm not sure why we wanted to override this in the first place π§
If overriding this is important to us, then I don't think we should upgrade to this version.
Let me know what you all think... π€
I think if it's the case that we just pull that value from the parent ID, we should be fine without it. Guessing the overrides is helpful in tracing events through Azure because there's one point of reference for where the event got kicked off, but having the parent ID should be good enough. Johanna didn't seem to call it out explicitly in her PR putting it in, so I think we'd be good removing it and just using the parent ID.
Thanks for looking into it!
Based on my digging around... Looks like v3 of
applicationinsightsuses Azure Monitor OpenTelemetry. Our function tests are failing becausetagOverridesdoes not seem to be supported in v3 vs v2. I think this might be related to the Node.js version of OpenTelemetry not supporting certain overrides. My guess is that even though they don't explicitly call outOperation Idit might be included in what's not being supported π (see screenshot below)We are currently using
tagOverridesproperty to override the "Operation Id" of our custom events. (It's the same value as the Parent Id that we also track) I'm not sure why we wanted to override this in the first place π§ If overriding this is important to us, then I don't think we should upgrade to this version. Let me know what you all think... π€I think if it's the case that we just pull that value from the parent ID, we should be fine without it. Guessing the overrides is helpful in tracing events through Azure because there's one point of reference for where the event got kicked off, but having the parent ID should be good enough. Johanna didn't seem to call it out explicitly in her PR putting it in, so I think we'd be good removing it and just using the parent ID.
Thanks for looking into it!
Ok! Will update this and remove that override!
Deployed to dev2 and looking into this exception π
Exception while executing function: Functions.QueueBatchedReportStreamUploader Result: Failure
Exception: Cannot read properties of undefined (reading 'trackEvent')
Stack: TypeError: Cannot read properties of undefined (reading 'trackEvent')
at TelemetryClient.trackEvent (/home/site/wwwroot/node_modules/applicationinsights/out/src/shim/telemetryClient.js:106:22)
at /home/site/wwwroot/dist/QueueBatchedReportStreamUploader/index.js:53:19
at Generator.next (<anonymous>)
at fulfilled (/home/site/wwwroot/dist/QueueBatchedReportStreamUploader/index.js:28:58)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
v3 of applicationinsights needs an environment variable called APPLICATIONINSIGHTS_CONNECTION_STRING (see README snippet below)
Configure the local SDK by calling appInsights.setup('YOUR_CONNECTION_STRING');, using the connection string you grabbed in step 2. Or put it in the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable and call appInsights.setup() without parameters.
We currently have that environment variable set up in the api.tf file (dev2's for example)
but we don't have that set for the function app because we were previously relying on APPINSIGHTS_INSTRUMENTATIONKEY but that is no longer supported
I think that should get our app insights to initialize correctly, but I will have to do more testing on dev2 after the env variable is introduced...
Do I just add
APPLICATIONINSIGHTS_CONNECTION_STRING = data.azurerm_application_insights.app_insights.connection_string
to ops/services/app_functions/report_stream_batched_publisher/infra/main.tf to add it as an ENV variable? π€
cc @alismx, @shanice-skylight
v3 of
applicationinsightsneeds an environment variable calledAPPLICATIONINSIGHTS_CONNECTION_STRING(see README snippet below)Configure the local SDK by calling appInsights.setup('YOUR_CONNECTION_STRING');, using the connection string you grabbed in step 2. Or put it in the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable and call appInsights.setup() without parameters.
We currently have that environment variable set up in the
api.tffile (dev2's for example) but we don't have that set for the function app because we were previously relying onAPPINSIGHTS_INSTRUMENTATIONKEYbut that is no longer supportedI think that should get our app insights to initialize correctly, but I will have to do more testing on dev2 after the env variable is introduced...
Do I just add
APPLICATIONINSIGHTS_CONNECTION_STRING = data.azurerm_application_insights.app_insights.connection_stringtoops/services/app_functions/report_stream_batched_publisher/infra/main.tfto add it as an ENV variable? π€cc @alismx, @shanice-skylight
I think you're on the right path! Because of the name of the data object in the _data.tf file it would probably be APPLICATIONINSIGHTS_CONNECTION_STRING = data.azurerm_application_insights.app.connection_string
v3 of
applicationinsightsneeds an environment variable calledAPPLICATIONINSIGHTS_CONNECTION_STRING(see README snippet below)Configure the local SDK by calling appInsights.setup('YOUR_CONNECTION_STRING');, using the connection string you grabbed in step 2. Or put it in the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable and call appInsights.setup() without parameters.
We currently have that environment variable set up in the
api.tffile (dev2's for example) but we don't have that set for the function app because we were previously relying onAPPINSIGHTS_INSTRUMENTATIONKEYbut that is no longer supportedI think that should get our app insights to initialize correctly, but I will have to do more testing on dev2 after the env variable is introduced... Do I just add
APPLICATIONINSIGHTS_CONNECTION_STRING = data.azurerm_application_insights.app_insights.connection_stringtoops/services/app_functions/report_stream_batched_publisher/infra/main.tfto add it as an ENV variable? π€ cc @alismx, @shanice-skylightI think you're on the right path! Because of the name of the data object in the
_data.tffile it would probably beAPPLICATIONINSIGHTS_CONNECTION_STRING = data.azurerm_application_insights.app.connection_string
Ohh thank you for the help! I'll try that out π
Yay! It worked
Deployed on dev2
Ready for review @fzhao99 @mpbrown @DanielSass
One thing I am noticing is that the event that is logged doesn't contain the ParentId as I had hoped...
I'll add it under properties
Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code
hmmm for some reason adding that causes 00-PARENTID-00 to be added π€ See this in application insights
Edit: Actually this looks fine as it matches what was happening before π
A newer version of applicationinsights exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.
Oh my what a doozy -- thanks so much for getting this done!
We are currently using [`tagOverrides` property to override the "Operation Id"](https://github.com/search?q=repo%3ACDCgov%2Fprime-simplereport+ai.operation.id&type=code) of our custom events. (It's the same value as the Parent Id that we also track) I'm not sure why we wanted to override this in the first place π§
