The Azure quickstart runs the log forwarder as Azure Container Apps jobs in your subscription. If you run a Kubernetes cluster such as AKS, you can run the same jobs there as CronJobs instead, and delete the Container App jobs. Do this after the quickstart has finished with log forwarding selected. Nothing changes in Atatus. The same logs keep arriving, from every region you already collect from, and the jobs continue from where the Container App jobs stopped. After the move, the cluster, the CronJobs and their upgrades are yours to manage. Atatus does not create, update or remove them.

What moves

The quickstart creates these Container App jobs in the resource group atatus-log-forwarder: Each one becomes a Kubernetes CronJob with the same name, schedule, image and settings. These stay where they are, because the CronJobs use them:
  • The storage accounts in atatus-log-forwarder. Azure writes your logs there, and the jobs read them and keep their progress there.
  • The atatus-integration App Registration and its roles.
  • The diagnostic settings on your resources.

Before you start

You need:
  • A cluster with Linux amd64 nodes. The forwarder image is not built for arm64.
  • Outbound access on port 443 from the pods to *.blob.core.windows.net, management.azure.com, login.microsoftonline.com and the Atatus log intake.
  • az, kubectl and jq. Azure Cloud Shell has all three.
  • Permission to read and delete the jobs in atatus-log-forwarder (Contributor on that resource group), and to create a namespace, Secrets and CronJobs in the cluster.
Each run needs little capacity: a forwarder run usually finishes in a few seconds.

Step 1: Connect kubectl to your cluster

For AKS:
At least one node must show Ready.

Step 2: Move the jobs

Run this script. For each Container App job it:
  1. Copies the image, schedule, settings and secrets into a Kubernetes Secret and CronJob with the same name, in the namespace atatus.
  2. Parks the Container App job on a once-a-year schedule. The job stops running, but still exists, so you can go back until you delete it in step 4.
az prints a warning that the output contains secret values. That is expected: the script reads them so it can copy them into the Kubernetes Secrets. The last command lists one CronJob for each Container App job you had.

Step 3: Check that the pods work

Do both checks before you delete anything. The pods deliver the logs. Wait two minutes, then print the end of the latest run of each CronJob:
A forwarder run ends with a line like this. 0 failure(s) means Atatus accepted the logs:
The reconcile job runs every 10 minutes, so it may show no run yet. To run it now:
It ends with a line that starts with reconciled:. Atatus still receives logs. In Atatus, open the Azure account. The Log Collection tab should show the forwarder as seen in the last few minutes, and Logs should show new Azure records. A finished pod shows Completed, with 0/1 under Ready. That is normal for a pod that has done its work and exited. A real failure shows Error, CrashLoopBackOff or ImagePullBackOff.

Step 4: Delete the Container App jobs

Do this once step 3 is clean. Until you delete them, the parked jobs still run once a year, on 1 January. This deletes only jobs that are parked:
Do not delete the atatus-log-forwarder resource group. It holds the storage accounts the pods read from.

After the move

  • Settings you change in Atatus. They keep working as before. The jobs ask Atatus what to collect at the start of every run, so turning log collection on or off, and changing regions, resource types, tag filters or subscriptions, takes effect within 10 minutes.
  • New regions. When you create resources in a region you do not collect from yet, the reconcile job deploys a Container Apps forwarder for that region. To stay on Kubernetes only, either limit log regions on the Log Collection tab in Atatus to the regions you already have, or run the script in step 2 again when a new job appears. It moves only jobs that are not parked.
  • A job that comes back. Check az containerapp job list -g atatus-log-forwarder a day after step 4. If a job has reappeared, run steps 2 and 4 again.
  • Secrets. The Kubernetes Secrets in the atatus namespace hold your Atatus license key, the storage account keys and the App Registration client secret. Limit who can read Secrets in that namespace. If you rotate any of these, update the Secret as well.
  • Upgrades. The CronJobs keep the image tag the Container App jobs had. With the default latest tag, each run uses the newest forwarder image and there is nothing to upgrade.
  • CPU and memory. Each run requests 0.1 vCPU and 128 MiB, and may use up to 0.5 vCPU and 1 GiB. If the backlog figure in a forwarder’s log grows from run to run, raise the limits:
Do not run the quickstart again with log forwarding selected. It deploys the Container App jobs again, next to your CronJobs, and two reconcile jobs must not run at the same time. Run it only to go back to Container Apps, after deleting the atatus namespace.

Troubleshooting

Go back to Container Apps

Before step 4, the Container App jobs still exist. aca-jobs-before.txt lists each job’s original schedule. Remove the pods and restore the schedules:
After step 4, delete the namespace as above, then run the quickstart again with log forwarding selected.

Remove log forwarding later

The order matters. The diagnostic settings sit on your resources, and the reconcile job holds the only list of where they are.
  1. In Atatus, delete the integration, or switch Enable log collection off.
  2. Leave the CronJobs running. Within 10 minutes the reconcile job removes the diagnostic settings and the stored logs. Wait for this line in its log:
    If you check the log later and that line has gone, look for a line that contains teardown completed at followed by a time and ends with not reconciling. The reconcile job logs it on every run after teardown, and it means the same thing.
  3. If you deleted the integration, delete the Kubernetes resources and the resource group the same day. A reconcile CronJob left running for more than a day after the integration is deleted can add the diagnostic settings back.
    If you only switched log collection off, leave everything in place. Collection resumes when you switch it on again.