Bump to v2.0.8: Bootstrap VMWatch Process if vmWatchSettings present#33
Merged
frank-pang-msft merged 41 commits intofeature/v2/bootstrapVMWatchfrom Nov 17, 2023
Merged
Conversation
… commands, plus integration test template
zmyzheng
reviewed
Sep 1, 2023
zmyzheng
reviewed
Sep 1, 2023
klugorosado
reviewed
Sep 11, 2023
…irectory to bin/VMWatch/ + implement VMWatch process retries + update integration tests
zmyzheng
approved these changes
Sep 12, 2023
frank-pang-msft
commented
Sep 13, 2023
frank-pang-msft
commented
Sep 13, 2023
Hafthor
reviewed
Sep 13, 2023
Hafthor
left a comment
There was a problem hiding this comment.
just a first pass at this review -- might try to take another look at it later.
… execution of process
…nd read of channel. Also only every 60 seconds
Hafthor
reviewed
Sep 15, 2023
| vmWatchErr = fmt.Errorf("%w\n Additonal Details: %+v", vmWatchErr, r) | ||
| ctx.Log("error", "Recovered %+v", r) | ||
| } | ||
| ctx.Log("error", fmt.Sprintf("Signaling VMWatchStatus is Failed due to reaching max of %d retries", VMWatchMaxProcessAttempts)) |
There was a problem hiding this comment.
note that this defer func will happen whenever the executeVMWatch func exits... it's like a finally block... not a catch block. I think you want this error handling stuff to be conditionally run on if executeVMWatch does not reach the bottom of the func.. like perhaps if vmWatchErr != nil
| err = fmt.Errorf("Error: %w\n Additonal Details: %+v", err, r) | ||
| ctx.Log("error", "Recovered %+v", r) | ||
| } | ||
| killVMWatch(ctx, cmd) |
There was a problem hiding this comment.
I don't think you want to killVMWatch on successful exit of executeVMWatchHelper func.
|
|
||
| // VMWatch should run indefinitely, if process exists we expect an error | ||
| err = cmd.Wait() | ||
| err = fmt.Errorf("[%v][PID %d] Attempt %d: VMWatch process exited. Error: %w\nOutput: %s", time.Now().UTC().Format(time.RFC3339), pid, attempt, err, combinedOutput.String()) |
There was a problem hiding this comment.
I would think you would want to test the return of cmd.Wait() and only fmt.Errorf wrap it when err != nil.
e7e1129 to
7ce2f7f
Compare
zmyzheng
reviewed
Sep 18, 2023
…n Handler Environment (#39) * - moved handlerenv.go and seqno.go from "github.com/Azure/azure-docker-extension/pkg/vmextension" - Added EventsFolder with other missing parameters. * -removed vmextension lib dependency from VMwatch and other Files. - Updates HandlerEnviroment.json test file. - Updated VMwatch Integration Tests. * - Bump to v2.0.8
klugorosado
added a commit
that referenced
this pull request
Jun 4, 2024
…33) ## Overview This PR contains changes to support running VMWatch (amd64 and arm64) as an executable via goroutines and channels. > VMWatch is a standardized, lightweight, and open-sourced testing framework designed to enhance the monitoring and management of guest VMs on the Azure platform, including both 1P and 3P instances. VMWatch is engineered to collect vital health signals across multiple dimensions, which will be seamlessly integrated into Azure's quality systems. By leveraging these signals, VMWatch will enable Azure to swiftly detect and prevent regressions induced by platform updates or configuration changes, identify gaps in platform telemetry, and ultimately improve the guest experience for all Azure customers. ## Behavior VMWatch will run asynchronously as a separate process than ApplicationHealth, so the probing of application health will not be affected by the state of VMWatch. Depending on extension settings, VMWatch can be enabled/disabled, and also specify the test names and parameter overrides to VMWatch binary. The status of VMWatch will be displayed in the extension x.status files and also in GET VM Instance View. Main process will attempt to start VMWatch binary up to 3 times, after which VMWatch status will be set to failed. ## Process Leaks To ensure that VMWatch processes do not accumulate, applicationhealth-shim will be responsible for killing existing VMWatch processes by looking for processes running with the VMWatch binary names according to the architecture type. For unexpected process termination, if for some reason the main applicationhealth-extension process is terminated, we also ensure that the VMWatch process is also killed by subscribing to shutdown/termination signals in the main process, and killing the VMWatch based off process ID. ## Example Binary Execution Example execution from integration testing ` SIGNAL_FOLDER=/var/log/azure/Microsoft.ManagedServices.ApplicationHealthLinux/events VERBOSE_LOG_FILE_FULL_PATH=/var/log/azure/Microsoft.ManagedServices.ApplicationHealthLinux/VE.RS.ION/vmwatch.log ./var/lib/waagent/Extension/bin/VMWatch/vmwatch_linux_amd64 --config /var/lib/waagent/Extension/bin/VMWatch/vmwatch.conf --input-filter disk_io:outbound_connectivity ` ## Release/Packaging In addition to the arm64 or amd64 VMWatch binaries, `vmwatch.conf` will be expected to be present in the bin/VMWatch directory for VMWatch process to read. VMWatch will also be populating and sharing eventsFolder with ApplicationHealth, so events can be viewed in Kusto. The verbose logs of VMWatch will be written to `vmwatch.log`. --------- Co-authored-by: klugorosado <142627157+klugorosado@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR contains changes to support running VMWatch (amd64 and arm64) as an executable via goroutines and channels.
Behavior
VMWatch will run asynchronously as a separate process than ApplicationHealth, so the probing of application health will not be affected by the state of VMWatch. Depending on extension settings, VMWatch can be enabled/disabled, and also specify the test names and parameter overrides to VMWatch binary. The status of VMWatch will be displayed in the extension x.status files and also in GET VM Instance View. Main process will attempt to start VMWatch binary up to 3 times, after which VMWatch status will be set to failed.
Process Leaks
To ensure that VMWatch processes do not accumulate, applicationhealth-shim will be responsible for killing existing VMWatch processes by looking for processes running with the VMWatch binary names according to the architecture type. For unexpected process termination, if for some reason the main applicationhealth-extension process is terminated, we also ensure that the VMWatch process is also killed by subscribing to shutdown/termination signals in the main process, and killing the VMWatch based off process ID.
Example Binary Execution
Example execution from integration testing
SIGNAL_FOLDER=/var/log/azure/Microsoft.ManagedServices.ApplicationHealthLinux/events VERBOSE_LOG_FILE_FULL_PATH=/var/log/azure/Microsoft.ManagedServices.ApplicationHealthLinux/vmwatch.log ./var/lib/waagent/Extension/bin/VMWatch/vmwatch_linux_amd64 --config /var/lib/waagent/Extension/bin/VMWatch/vmwatch.conf --input-filter disk_io:outbound_connectivityRelease/Packaging
In addition to the arm64 or amd64 VMWatch binaries,
vmwatch.confwill be expected to be present in the bin/VMWatch directory for VMWatch process to read. VMWatch will also be populating and sharing eventsFolder with ApplicationHealth, so events can be viewed in Kusto. The verbose logs of VMWatch will be written tovmwatch.log.