Setting Up Alert for AKS Pod Restarts Using Log Analytics Workspace and Grafana

 Azure Kubernetes Services (AKS)  pod restarts can be obtained from the KubePodInventory of the connected log analytics workspace. This data can be depicted in a graph in grafana as described in the post "Pod Restart Counts Grafana Chart with Azure Monitor for AKS". Let's explore how to use same information to create an alert using Grafana to notify when pod restarts are happening in apps in a given kubernetes namespace. 

The expectation is to fire alerts from Grafana as shwon below. Note that the alerts can target to send emails, slack notficaition etc. which is not discussed in this post.

Using "grep" with "kubectl logs" to Filter Container/Pod Logs

 kubectl logs command helps us to inspect logs of pods in AKS/kubernetes and useful to diagnose issues. However, when there is too much logs it is harder to read through and find out errors easily. Further, filtering out logs for a given timestamp may be useful at times to identify the issues. In this post let's explore usage of grep with kubectl logs command to filter logs. 

Let's take first example to filter for a timestamp in keda operator pod logs. Here -i says to ignore case in logs.

kubectl logs keda-operator-79d756dd66-69gsc -n keda | grep -i '2025-03-04T07:20:24'

Setup Azure File Share Capacity Alert to Slack with Terraform

 Setting up an Azure File Share capacity alert is useful to know when you reach at least 80% of allocated quota for the file share. This will give the teams ample time to increase the allocation to avoid out of space issues. If we are using standard tier for storage account then we need to use one storage account for each file share, to get the correct alert. Sending the alert to slack channel is a useful way to get properly alerted to take action on time. Let's use an example learn how to setup alerts for multiple Azure file shares uing terraform.

Expectation is to get the alerts to slack channel as shown below.

Use AKS Workload Identity to Login with "az login" in a Container with Azure CLI

 We have discussed "Setting Up Azure Workload Identity for Containers in Azure Kubernetes Services" previously. We can use Azure CLI  to interact with Azure resources in a container which is using base docker image "mcr.microsoft.com/azure-cli:latest-amd64". Instead of using specific credential information directly in the Azure CLI script in the container, we can use the workload identity to do an az login in a container where workload identity is enabled. Let's look at how to do that in this post.

Use Dynamic Block Conditionally in Terraform with a Nested Block

 We have discussed  usage of dynamic blocks conditionally in terraform in the post "Use Dynamic Block Conditionally in Terraform". Sometimes we need to use dynamic with nested blocks. In this post look at such an example of using dynamic block with network rules for Azure event hubs.

We are going to setup a nested dynamic block as shown below.

Disable Soft Delete for Azure File Shares with Terraform

 Azure file shares can be used as mounted persisted volume in AKS clusters to provide necessary storage to pods in AKS. Azure file shares are enabled with soft delete for files by default. However, when the pod mounted storage is used as temporary storage for processing, there is no need to keep the capability of soft deletion. Let's look at how we can disable soft delete for file share storage when deploying the file share with terraform.

Resolving "ERROR: Account has previously been signed out of this application.. Status: Response_Status.Status_AccountUnusable" When Terraform Plan

 While trying to execute terraform plan locally after an az login we sometimes envounter below error.

│ Error: populating Resource Provider cache: listing Resource Providers: loading results: authorizing request: running Azure CLI: exit status 1: ERROR: Account has previously been signed out of this application.. Status: Response_Status.Status_AccountUnusable, Error code: 0, Tag: 540940121

│ Please explicitly log in with:│ az login --scope https://management.azure.com/.default

│ with provider["registry.terraform.io/hashicorp/azurerm"],│   on main.tf line 17, in provider "azurerm":│   17: provider "azurerm" {

Use Dynamic Block Conditionally in Terraform

 Dynamic block allows to create nested multi level block structures in terraform code. Conditional usage of such blocks are really useful in many scenarios. For example, when we create Azure Cosmos DB, if we want to have read regions only in production environment, but only have one region setup for dev and QA environments we can, leverage the capabilities in Dynamic block of terraform. Let's explore with an example.