This repository contains source code for Azure Monitor for containers Linux and Windows Agent
Feel free to contact engineering team owners in case you have any questions about this repository or project.
- Visual Studio Code for authoring
- Go lang for building go code. Go lang version 1.15.14 (both Linux & Windows)
Note: If you are using WSL2, make sure you have cloned the code onto ubuntu not onto windows
- WSL2.
- configure Docker-for-windows-wsl2
- Ubuntu 14.04 or higher to build Linux Agent.
- Docker to build the docker image for Linux Agent
Note: if you are using WSL2, you can ignore Docker since Docker for windows will be used.
- Windows 10 Professional machine to build Windows Agent
- Docker for Windows to build docker image for Windows Agent
- .NET Core SDK to build the Windows Agent code
- gcc for windows to build go code
The general directory structure is:
├── .pipelines/ - files related to azure devops ci and cd pipelines
├── build/ - files to related to compile and build the code
│ ├── version - build version used for docker prvider and go shared object(so) files
│ ├── common/ - common to both windows and linux installers
│ │ ├── installer - files related to installer
| | | |── scripts/ - script files related to configmap parsing
│ ├── linux/ - Makefile and installer files for the Docker Provider
│ │ ├── Makefile - Makefile to build the docker provider
│ │ ├── installer - files related to installer
| | | |── bundle/ - shell scripts to create shell bundle
| | | |── conf/ - plugin configuration files
| | | |── datafiles/ - data files for the installer
| | | |── scripts/ - script files related to livenessproble, tomlparser etc..
| | | |── InstallBuilder/ - python script files for the install builder
│ ├── windows/ - scripts to build the .net and go code
| | |── Makefile.ps1 - powershell script to build .net and go lang code and copy the files to omsagentwindows directory
│ │ ├── installer - files related to installer
| | | |── conf/ - fluent, fluentbit and out_oms plugin configuration files
| | | |── scripts/ - script files related to livenessproble, filesystemwatcher, keepCertificateAlive etc..
| | | |── certificategenerator/ - .NET code for the generation self-signed certificate of the windows agent
├── charts/ - helm charts
│ ├── azuremonitor-containers/ - azure monitor for containers helm chart used for non-AKS clusters
├── alerts/ - alert queries
├── kubernetes/ - files related to Linux and Windows Agent for Kubernetes
│ ├── linux/ - scripts to build the Docker image for Linux Agent
│ │ ├── dockerbuild - script to build docker provider, docker image and publish docker image
│ │ ├── DockerFile - DockerFile for Linux Agent Container Image
│ │ ├── main.sh - Linux Agent container entry point
│ │ ├── setup.sh - setup file for Linux Agent Container Image
│ │ ├── acrworkflows/ - acr work flows for the Linux Agent container image
│ │ ├── defaultpromenvvariables - default environment variables for Prometheus scraping
│ │ ├── defaultpromenvvariables-rs - cluster level default environment variables for Prometheus scraping
│ │ ├── defaultpromenvvariables-sidecar - cluster level default environment variables for Prometheus scraping in sidecar
│ ├── windows/ - scripts to build the Docker image for Windows Agent
│ │ ├── dockerbuild - script to build the code and docker imag, and publish docker image
│ │ ├── acrworkflows/ - acr work flows for the Windows Agent container image
│ │ ├── DockerFile - DockerFile for Windows Agent Container Image
│ │ ├── main.ps1 - Windows Agent container entry point
│ │ ├── setup.ps1 - setup file for Windows Agent Container Image
│ ├── omsagent.yaml - kubernetes yaml for both Linux and Windows Agent
│ ├── container-azm-ms-agentconfig.yaml - kubernetes yaml for agent configuration
├── scripts/ - scripts for onboarding, troubleshooting and preview scripts related to Azure Monitor for containers
│ ├── troubleshoot/ - scripts for troubleshooting of Azure Monitor for containers onboarding issues
│ ├── onboarding/ - scripts related to Azure Monitor for containers onboarding.
│ ├── preview/ - scripts related to preview features ...
│ ├── build/ - scripts related to build such as installing pre-requisites etc.
│ ├── deployment/ - scripts related to deployment goes here.
│ ├── release/ - scripts related to release goes here.
├── source/ - source code
│ ├── plugins/ - plugins source code
│ │ ├── go/ - out_oms plugin code in go lang
│ │ ├── ruby/ - plugins code in ruby
│ │ | ├── health/ - code for health feature
│ │ | ├── lib/ - lib for app insights ruby and this code of application_insights gem
│ │ | ... - plugins in, out and filters code in ruby
│ ├── toml-parser/ - code for parsing of toml configuration files
├── test/ - source code for tests
│ ├── e2e/ - e2e tests to validate agent and e2e workflow(s)
│ ├── unit-tests/ - unit tests code
│ ├── scenario/ - scenario tests code
├── !_README.md - this file
├── .gitignore - git config file with include/exclude file rules
├── LICENSE - License file
├── Rakefile - Rake file to trigger ruby plugin tests
└── ReleaseProcess.md - Release process instructions
└── ReleaseNotes.md - Release notes for the release of the Azure Monitor for containers agent
ci_prodbranch contains codebase currently in production (or being prepared for release).ci_devbranch contains version in development.
To contribute: create your private branch off of ci_dev, make changes and use pull request to merge back to ci_dev.
Pull request must be approved by at least one engineering team members.
We recommend using Visual Studio Code for authoring. Windows 10 with Ubuntu App can be used for both Windows and Linux Agent development and recommened to clone the code onto Ubuntu app so that you dont need to worry about line ending issues LF vs CRLF.
- Install go1.15.14, dotnet, powershell, docker and build dependencies to build go code for both Linux and Windows platforms
bash ~/Docker-Provider/scripts/build/linux/install-build-pre-requisites.sh
- Verify python, docker and golang installed properly and also PATH and GOBIN environment variables set with go bin path.
For some reason go env not set by install-build-pre-requisites.sh script, run the following commands to set them
export PATH=$PATH:/usr/local/go/bin export GOBIN=/usr/local/go/bin - If you want to use Docker on the WSL2, verify following configuration settings configured on your Ubuntu app
echo $DOCKER_HOST # if either DOCKER_HOST not set already or doesnt have tcp://localhost:2375 value, set DOCKER_HOST value via this command echo "export DOCKER_HOST=tcp://localhost:2375" >> ~/.bashrc && source ~/.bashrc # on Docker Desktop for Windows make sure docker running linux mode and enabled Expose daemon on tcp://localhost:2375 without TLS
Note: If you are using WSL2, ensure
Docker for windowsrunning with Linux containers mode on your windows machine to build Linux agent image successfully
cd ~/Docker-Provider/kubernetes/linux/dockerbuild
sudo docker login # if you want to publish the image to acr then login to acr via `docker login <acr-name>`
# build provider, docker image and publish to docker image
bash build-and-publish-docker-image.sh --image <repo>/<imagename>:<imagetag>
Note: format of the imagetag will be
ci<release><MMDDYYYY>. possible values for release are test, dev, preview, dogfood, prod etc.
You can also build and push images for multiple architectures. This is powered by docker buildx
cd ~/Docker-Provider/kubernetes/linux/dockerbuild
sudo docker login # if you want to publish the image to acr then login to acr via `docker login <acr-name>`
# build and publish using docker buildx
bash build-and-publish-docker-image.sh --image <repo>/<imagename>:<imagetag> --multiarch
or directly use the docker buildx commands
# multiple platforms
cd ~/Docker-Provider
docker buildx build --platform linux/arm64/v8,linux/amd64 -t <repo>/<imagename>:<imagetag> --build-arg IMAGE_TAG=<imagetag> -f kubernetes/linux/Dockerfile.multiarch --push .
# single platform
cd ~/Docker-Provider
docker buildx build --platform linux/amd64 -t <repo>/<imagename>:<imagetag> --build-arg IMAGE_TAG=<imagetag> -f kubernetes/linux/Dockerfile.multiarch --push .
If you prefer to build docker provider shell bundle and image separately, then you can follow below instructions
cd ~/Docker-Provider/build/linux
make
cd ~/Docker-Provider/kubernetes/linux/
docker build -t <repo>/<imagename>:<imagetag> --build-arg IMAGE_TAG=<imagetag> .
docker push <repo>/<imagename>:<imagetag>
To build the windows agent, you will have to build .NET and Go code, and docker image for windows agent.
Docker image for windows agent can only build on Windows machine with Docker for windows with Windows containers mode but the .NET code and Go code can be built either on Windows or Linux or WSL2.
Install pre-requisites based on OS platform you will be using to build the windows agent code
powershell # launch powershell with elevated admin on your windows machine
Set-ExecutionPolicy -ExecutionPolicy bypass # set the execution policy
cd %userprofile%\Docker-Provider\scripts\build\windows # based on your repo path
.\install-build-pre-requisites.ps1 #
powershell # launch powershell with elevated admin on your windows machine
Set-ExecutionPolicy -ExecutionPolicy bypass # set the execution policy
net use z: \\wsl$\Ubuntu-16.04 # map the network drive of the ubuntu app to windows
cd z:\home\sshadmin\Docker-Provider\scripts\build\windows # based on your repo path
.\install-build-pre-requisites.ps1 #
Note: format of the windows agent imagetag will be
win-ci<release><MMDDYYYY>. possible values for release are test, dev, preview, dogfood, prod etc.
Execute below instructions on elevated command prompt to build windows agent code and docker image, publishing the image to acr or docker hub
cd %userprofile%\Docker-Provider\kubernetes\windows\dockerbuild # based on your repo path
docker login # if you want to publish the image to acr then login to acr via `docker login <acr-name>`
powershell -ExecutionPolicy bypass # switch to powershell if you are not on powershell already
.\build-and-publish-docker-image.ps1 -image <repo>/<imagename>:<imagetag> # trigger build code and image and publish docker hub or acr
If you do not want to build the image from scratch every time you make changes during development,you can choose to build the docker images that are separated out by
- Base image and dependencies including agent bootstrap(setup.ps1)
- Agent conf and plugin changes
To do this, the very first time you start developing you would need to execute below instructions in elevated command prompt of powershell. This builds the base image(omsagent-win-base) with all the package dependencies
cd %userprofile%\Docker-Provider\kubernetes\windows\dockerbuild # based on your repo path
docker login # if you want to publish the image to acr then login to acr via `docker login <acr-name>`
powershell -ExecutionPolicy bypass # switch to powershell if you are not on powershell already
.\build-dev-base-image.ps1 # builds base image and dependencies
And then run the script to build the image consisting of code and conf changes.
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> # trigger build code and image and publish docker hub or acr
By default, multi-arc docker image will be built, but if you want generate test image either with ltsc2019 or ltsc2022 base image, then you can follow the instructions below
For building image with base image version ltsc2019
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> -windowsBaseImageVersion ltsc2019
For building image with base image version ltsc2022
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> -windowsBaseImageVersion ltsc2022
For the subsequent builds, you can just run -
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> # trigger build code and image and publish docker hub or acr
By default, multi-arc docker image will be built, but if you want generate test image either with ltsc2019 or ltsc2022 base image, then you can follow the instructions below
For building image with base image version ltsc2019
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> -windowsBaseImageVersion ltsc2019
For building image with base image version ltsc2022
.\build-and-publish-dev-docker-image.ps1 -image <repo>/<imagename>:<imagetag> -windowsBaseImageVersion ltsc2022
Note - If you have changes in setup.ps1 and want to test those changes, uncomment the section consisting of setup.ps1 in the Dockerfile-dev-image file.
cd ~/Docker-Provider/build/windows # based on your repo path on WSL2 Ubuntu app
pwsh #switch to powershell
.\Makefile.ps1 # trigger build and publish of .net and go code
Note: Docker image for windows container can only built on windows hence you will have to execute below commands on windows via accessing network share or copying published bits omsagentwindows under kubernetes directory on to windows machine
net use z: \\wsl$\Ubuntu-16.04 # map the network drive of the ubuntu app to windows
cd z:\home\sshadmin\Docker-Provider\kubernetes\windows # based on your repo path
docker build -t <repo>/<imagename>:<imagetag> --build-arg IMAGE_TAG=<imagetag> .
docker push <repo>/<imagename>:<imagetag>
Navigate to https://github-private.visualstudio.com/microsoft/_build?definitionScope=%5CCDPX%5Cdocker-provider to see Linux and Windows Agent build pipelines. These pipelines are configured with CI triggers for ci_dev and ci_prod.
Docker Images will be pushed to CDPX ACR repos and these needs to retagged and pushed to corresponding ACR or docker hub. Only onboarded Azure AD AppId has permission to pull the images from CDPx ACRs.
Please reach out the agent engineering team if you need access to it.
Here are the instructions to onboard the feature branch to Azure Dev Ops pipeline
- Navigate to https://github-private.visualstudio.com/microsoft/_apps/hub/azurecdp.cdpx-onboarding.cdpx-onboarding-tab
- Select the repository as "docker-provider" from repository drop down
- click on validate repository
- select the your feature branch from Branch drop down
- Select the Operation system as "Linux" and Build type as "buddy"
- create build definition
- enable continous integration on trigger on the build definition
This will create build definition for the Linux agent. Repeat above steps except that this time select Operation system as "Windows" to onboard the pipeline for Windows agent.
Integrated to Azure DevOps release pipeline for the ci_dev and ci_prod.With this, for every commit to ci_dev branch, latest bits automatically deployded to DEV AKS clusters in Build subscription and similarly for for every commit to ci_prod branch, latest bits automatically deployed to PROD AKS clusters in Build subscription.
For dev, agent image will be in this format mcr.microsoft.com/azuremonitor/containerinsights/cidev:cidev.
For prod, agent will be in this format mcr.microsoft.com/azuremonitor/containerinsights/ciprod:ciprod<MM><DD><YYYY>.
Navigate to https://github-private.visualstudio.com/microsoft/_release?_a=releases&view=all to see the release pipelines.
Navigate to Kubernetes directory and update the yamls with latest docker image of Linux and Windows Agent and other relevant updates.
For DEV and PROD branches, automatically deployed latest yaml with latest agent image (which automatically built by the azure devops pipeline) onto CIDEV and CIPROD AKS clusters in build subscription. So, you can use CIDEV and CIPROD AKS cluster to validate E2E. Similarly, you can set up build and release pipelines for your feature branch.
- Enable Monitoring addon with Managed Idenity Auth Mode either using Portal or CLI or Template
- Deploy ARM template with enabled = false to create DCR, DCR-A and link the workspace to Portal
Note - Make sure to update the parameter values in existingClusterParam.json file and have enabled = false in template file
az deployment group create --resource-group <ResourceGroupName> --template-file ./existingClusterOnboarding.json --parameters @./existingClusterParam.json
- Get the MSI token (which is valid for 24 hrs.) value via
kubectl get secrets -n kube-system omsagent-aad-msi-token -o=jsonpath='{.data.token}' - Disable Monitoring addon via
az aks disable-addons -a monitoring -g <rgName> -n <clusterName> - Uncomment MSI auth related yaml lines, replace all the placeholder values, MSI token value and image tag in the omsagent.yaml
- Deploy the omsagent.yaml via
kubectl apply -f omsagent.yaml> Note: use the image toggle for release E2E validation - validate E2E for LA & Metrics data flows, and other scenarios
- Deploy the omsagent.yaml with your agent image. In the yaml, make sure
ISTESTenvironment variable set totrueif its not set already - Update the Service Principal CLIENT_ID, CLIENT_SECRET and TENANT_ID placeholder values and apply e2e-tests.yaml to execute the tests
Note: Service Principal requires reader role on log analytics workspace and cluster resource to query LA and metrics
cd ~/Docker-Provider/test/e2e # based on your repo path kubectl apply -f e2e-tests.yaml # this will trigger job to run the tests in sonobuoy namespace kubectl get po -n sonobuoy # to check the pods and jobs associated to tests - Download (sonobuoy)[https://github.com/vmware-tanzu/sonobuoy/releases] on your dev box to view the results of the tests
results=$(sonobuoy retrieve) # downloads tar file which has logs and test results sonobuoy results $results # get the summary of the results tar -xzvf <downloaded-tar-file> # extract downloaded tar file and look for pod logs, results and other k8s resources if there are any failures
- Add the test python file with your test code under
testsdirectory - Build the docker image, recommended to use ACR & MCR
cd ~/Docker-Provider/test/e2e/src # based on your repo path
docker login <acr> -u <user> -p <pwd> # login to acr
docker build -f ./core/Dockerfile -t <repo>/<imagename>:<imagetag> .
docker push <repo>/<imagename>:<imagetag>
- update existing agentest image tag in e2e-tests.yaml & conformance.yaml with newly built image tag with MCR repo
Clusters are used in release pipeline already has the yamls under test\scenario deployed. Make sure to validate these scenarios. If you have new interesting scenarios, please add/update them.
This project has adopted the [Microsoft Open Source Code of Conduct] (https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ] (https://opensource.microsoft.com/codeofconduct/faq/) or contact [email protected] with any additional questions or comments.