Cloud Deployment Guides on Grafana Labs

Deploy the Loki Helm chart on AWS

Thu, 09 Apr 2026 02:28:18 +0000

Deploy the Loki Helm chart on AWS

This guide shows how to deploy a minimally viable Loki in microservice mode on AWS using the Helm chart. To run through this guide, we expect you to have the necessary tools and permissions to deploy resources on AWS, such as:

Full access to EKS (Amazon Elastic Kubernetes Service)
Full access to S3 (Amazon Simple Storage Service)
Sufficient permissions to create IAM (Identity Access Management) roles and policies

There are two methods for authenticating and connecting Loki to AWS S3. We will guide you through the recommended method of granting access via an IAM role.

Considerations

Caution
This guide was accurate at the time it was last updated on 31st October, 2024. As cloud providers frequently update their services and offerings, as a best practice, you should refer to the AWS S3 documentation before creating your buckets and assigning roles.

IAM Role: The IAM role created in this guide is a basic role that allows Loki to read and write to the S3 bucket. You may wish to add more granular permissions based on your requirements.
Authentication: Grafana Loki comes with a basic authentication layer. The Loki gateway (NGINX) is exposed to the internet using basic authentication in this example. NGINX can also be replaced with other open-source reverse proxies. Refer to Authentication for more information.
Retention: The retention period is set to 28 days in the values.yaml file. You may wish to adjust this based on your requirements.
Costs: Running Loki on AWS will incur costs. Make sure to monitor your usage and costs to avoid any unexpected bills. In this guide we have used a simple EKS cluster with 3 nodes and m5.xlarge instances. You may wish to adjust the instance types and number of nodes based on your workload.

Prerequisites

Helm 3 or above. Refer to Installing Helm. This should be installed on your local machine.
A running Kubernetes cluster on AWS. A simple way to get started is by using EKSctl. Refer to Getting started with EKSctl.
Kubectl installed on your local machine. Refer to Install and Set Up kubectl.
(Optional) AWS CLI installed on your local machine. Refer to Installing the AWS CLI. This is required if you plan to use EKSctl to create the EKS cluster and modify the IAM roles and policies locally.

EKS Minimum Requirements

Caution
These EKS requirements are the minimum specification needed to deploy Loki using this guide. You may wish to adjust plugins and instance types based on your AWS environment and workload. If you choose to do so, we cannot guarantee that this sample configuration will still meet your needs.

In this guide, we deploy Loki using m5.xlarge instances. This is a instance type that should work for most scenarios. However, you can modify the instance types and count based on your specific needs.

The minimum requirements for deploying Loki on EKS are:

Kubernetes version 1.30 or above.
3 nodes for the EKS cluster.
Instance type depends on your workload. A good starting point for a production cluster is m7i.2xlarge.

Here is the EKSctl cluster configuration file used in this guide:

# A simple example of ClusterConfig object:
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: <INSERT_CLUSTER_NAME>
  region: <INSERT_REGION_FOR_CLUSTER>
  version: "1.31"

iam:
  withOIDC: true

addons:
  - name: aws-ebs-csi-driver

managedNodeGroups:
  - name: loki-workers
    instanceType: m7i.2xlarge
    desiredCapacity: 3
    minSize: 2
    maxSize: 3
    amiFamily: AmazonLinux2023
    iam:
      withAddonPolicies:
        ebs: true
    volumeSize: 80
    volumeType: gp3
    ebsOptimized: true

The following plugins must also be installed within the EKS cluster:

Amazon EBS CSI Driver: Enables Kubernetes to dynamically provision and manage EBS volumes as persistent storage for applications. We use this to provision the node volumes for Loki.
CoreDNS: Provides internal DNS service for Kubernetes clusters, ensuring that services and pods can communicate with each other using DNS names.
kube-proxy: Maintains network rules on nodes, enabling communication between pods and services within the cluster.

You must also install an OIDC (OpenID Connect) provider on the EKS cluster. This is required for the IAM roles and policies to work correctly. If you are using EKSctl, you can install the OIDC provider using the following command:

Tip
If you used the above EKSctl configuration file to create the cluster, you do not need to run this command. The OIDC provider is automatically installed.

eksctl utils associate-iam-oidc-provider --cluster loki --approve

Create S3 buckets

Warning
DO NOT use the default bucket names; chunk, ruler and admin. Choose a unique name for each bucket. For more information see the following security update.

Before deploying Loki, you need to create two S3 buckets; one to store logs (chunks), the second to store alert rules. You can create the bucket using the AWS Management Console or the AWS CLI. The bucket name must be globally unique.

Note
GEL customers will require a third bucket to store the admin data. This bucket is not required for OSS users.

aws s3api create-bucket --bucket  <YOUR CHUNK BUCKET NAME e.g. `loki-aws-dev-chunks`> --region <S3 region your account is on, e.g. `eu-west-2`> --create-bucket-configuration LocationConstraint=<S3 region your account is on, e.g. `eu-west-2`> \
aws s3api create-bucket --bucket  <YOUR RULER BUCKET NAME e.g. `loki-aws-dev-ruler`> --region <S3 REGION your account is on, e.g. `eu-west-2`> --create-bucket-configuration LocationConstraint=<S3 REGION your account is on, e.g. `eu-west-2`>

Make sure to replace the region and bucket name with your desired values. We will revisit the bucket policy later in this guide.

Defining IAM roles and policies

The recommended method for connecting Loki to AWS S3 is to use an IAM role. This method is more secure than using access keys and secret keys which are directly stored in the Loki configuration. The role and policy can be created using the AWS CLI or the AWS Management Console. The below steps show how to create the role and policy using the AWS CLI.

Create a new directory and navigate to it. Make sure to create the files in this directory. All commands in this guide assume you are in this directory.

Create a loki-s3-policy.json file with the following content:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LokiStorage",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::< CHUNK BUCKET NAME >",
                "arn:aws:s3:::< CHUNK BUCKET NAME >/*",
                "arn:aws:s3:::< RULER BUCKET NAME >",
                "arn:aws:s3:::< RULER BUCKET NAME >/*"
            ]
        }
    ]
}

Make sure to replace the placeholders with the names of the buckets you created earlier.

Create the IAM policy using the AWS CLI:

aws iam create-policy --policy-name LokiS3AccessPolicy --policy-document file://loki-s3-policy.json

Create a trust policy document named trust-policy.json with the following content:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::< ACCOUNT ID >:oidc-provider/oidc.eks.<INSERT REGION>.amazonaws.com/id/< OIDC ID >"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.<INSERT REGION>.amazonaws.com/id/< OIDC ID >:sub": "system:serviceaccount:loki:loki",
                    "oidc.eks.<INSERT REGION>.amazonaws.com/id/< OIDC ID >:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Make sure to replace the placeholders with your AWS account ID, region, and the OIDC ID (you can find this in the EKS cluster configuration).

Create the IAM role using the AWS CLI:

aws iam create-role --role-name LokiServiceAccountRole --assume-role-policy-document file://trust-policy.json

Attach the policy to the role:

aws iam attach-role-policy --role-name LokiServiceAccountRole --policy-arn arn:aws:iam::<Account ID>:policy/LokiS3AccessPolicy

Make sure to replace the placeholder with your AWS account ID.

Deploying the Helm chart

Before we can deploy the Loki Helm chart, we need to add the Grafana Community chart repository to Helm. This repository contains the Loki Helm chart.

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```
Create a new namespace for Loki:
Bash
```
kubectl create namespace loki
```

Loki Basic Authentication

Loki by default does not come with any authentication. Since we will be deploying Loki to AWS and exposing the gateway to the internet, we recommend adding at least basic authentication. In this guide we will give Loki a username and password:

To start we will need create a .htpasswd file with the username and password. You can use the htpasswd command to create the file:

Tip
If you don’t have the htpasswd command installed, you can install it using brew or apt-get or yum depending on your OS.
Bash
```
htpasswd -c .htpasswd <username>
```
This will create a file called auth with the username loki. You will be prompted to enter a password.
Create a Kubernetes secret with the .htpasswd file:
Bash
```
kubectl create secret generic loki-basic-auth --from-file=.htpasswd -n loki
```
This will create a secret called loki-basic-auth in the loki namespace. We will reference this secret in the Loki Helm chart configuration.
Create a canary-basic-auth secret for the canary:
Bash
```
kubectl create secret generic canary-basic-auth \
  --from-literal=username=<USERNAME> \
  --from-literal=password=<PASSWORD> \
  -n loki
```
We create a literal secret with the username and password for Loki canary to authenticate with the Loki gateway. Make sure to replace the placeholders with your desired username and password.

Loki Helm chart configuration

Create a values.yaml file choosing the configuration options that best suit your requirements. Below there is an example of values.yaml files for the Loki Helm chart in microservices mode.

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: s3
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    aws:
      region: <S3 BUCKET REGION> # for example, eu-west-2  
      bucketnames: <CHUNK BUCKET NAME> # Your actual S3 bucket name, for example, loki-aws-dev-chunks
      s3forcepathstyle: false
  ingester:
    chunk_encoding: snappy
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention
  compactor:
    retention_enabled: true
    delete_request_store: s3
  ruler:
    enable_api: true
    storage:
      type: s3
      s3:
        region: <S3 BUCKET REGION> # for example, eu-west-2
        bucketnames: <RULER BUCKET NAME> # Your actual S3 bucket name, for example, loki-aws-dev-ruler
        s3forcepathstyle: false
      alertmanager_url: http://prom:9093 # The URL of the Alertmanager to send alerts (Prometheus, Mimir, etc.)

  querier:
    max_concurrent: 4

  storage:
    type: s3
    bucketNames:
      chunks: "<CHUNK BUCKET NAME>" # Your actual S3 bucket name (loki-aws-dev-chunks)
      ruler: "<RULER BUCKET NAME>" # Your actual S3 bucket name (loki-aws-dev-ruler)
      # admin: "<Insert s3 bucket name>" # Your actual S3 bucket name (loki-aws-dev-admin) - GEL customers only
    s3:
      region: <S3 BUCKET REGION> # eu-west-2
      #insecure: false
      # s3forcepathstyle: false

serviceAccount:
  create: true
  annotations:
    "eks.amazonaws.com/role-arn": "arn:aws:iam::<Account ID>:role/LokiServiceAccountRole" # The service role you created

deploymentMode: Distributed

ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false

querier:
  replicas: 3
  maxUnavailable: 2

queryFrontend:
  replicas: 2
  maxUnavailable: 1

queryScheduler:
  replicas: 2

distributor:
  replicas: 3
  maxUnavailable: 2
compactor:
  replicas: 1

indexGateway:
  replicas: 2
  maxUnavailable: 1

ruler:
  replicas: 1
  maxUnavailable: 1


# This exposes the Loki gateway so it can be written to and queried externaly
gateway:
  service:
    type: LoadBalancer
  basicAuth:
    enabled: true
    existingSecret: loki-basic-auth

# Since we are using basic auth, we need to pass the username and password to the canary
lokiCanary:
  extraArgs:
    - -pass=$(LOKI_PASS)
    - -user=$(LOKI_USER)
  extraEnv:
    - name: LOKI_PASS
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: password
    - name: LOKI_USER
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: username

# Enable minio for storage
minio:
  enabled: false

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

Caution
Make sure to replace the placeholders with your actual values.

It is critical to define a valid values.yaml file for the Loki deployment. To remove the risk of misconfiguration, let’s break down the configuration options to keep in mind when deploying to AWS:

Loki Config vs. Values Config:
- The values.yaml file contains a section called loki, which contains a direct representation of the Loki configuration file.
- This section defines the Loki configuration, including the schema, storage, and querier configuration.
- The key configuration to focus on for chunks is the storage_config section, where you define the S3 bucket region and name. This tells Loki where to store the chunks.
- The ruler section defines the configuration for the ruler, including the S3 bucket region and name. This tells Loki where to store the alert and recording rules.
- For the full Loki configuration, refer to the Loki Configuration documentation.
Storage:
- Defines where the Helm chart stores data.
- Set the type to s3 since we are using Amazon S3.
- Configure the bucket names for the chunks and ruler to match the buckets created earlier.
- The s3 section specifies the region of the bucket.
Service Account:
- The serviceAccount section is used to define the IAM role for the Loki service account.
- This is where the IAM role created earlier is linked.
Zone-Aware Replication:
- The Helm chart enables zone-aware ingester replication by default, which creates three ingester StatefulSets (zone-a, zone-b, zone-c) for faster rollouts.
- In this guide, zone-aware replication is explicitly disabled (ingester.zoneAwareReplication.enabled: false) for simplicity. For production deployments, consider enabling it to improve rollout resilience.
Gateway:
- Defines how the Loki gateway will be exposed.
- We are using a LoadBalancer service type in this configuration.

Deploy Loki

Now that you have created the values.yaml file, you can deploy Loki using the Helm chart.

Deploy using the newly created values.yaml file:
Bash
```
helm install --values values.yaml loki grafana-community/loki -n loki --create-namespace
```
It is important to create a namespace called loki as our trust policy is set to allow the IAM role to be used by the loki service account in the loki namespace. This is configurable but make sure to update your service account.

Verify the deployment:

kubectl get pods -n loki

You should see the Loki pods running.

NAME                                    READY   STATUS    RESTARTS   AGE
loki-canary-crqpg                       1/1     Running   0          10m
loki-canary-hm26p                       1/1     Running   0          10m
loki-canary-v9wv9                       1/1     Running   0          10m
loki-chunks-cache-0                     2/2     Running   0          10m
loki-compactor-0                        1/1     Running   0          10m
loki-distributor-78ccdcc9b4-9wlhl       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-km6j2       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-ptwrb       1/1     Running   0          10m
loki-gateway-5f97f78755-hm6mx           1/1     Running   0          10m
loki-index-gateway-0                    1/1     Running   0          10m
loki-index-gateway-1                    1/1     Running   0          10m
loki-ingester-zone-a-0                  1/1     Running   0          10m
loki-ingester-zone-b-0                  1/1     Running   0          10m
loki-ingester-zone-c-0                  1/1     Running   0          10m
loki-querier-89d4ff448-4vr9b            1/1     Running   0          10m
loki-querier-89d4ff448-7nvrf            1/1     Running   0          10m
loki-querier-89d4ff448-q89kh            1/1     Running   0          10m
loki-query-frontend-678899db5-n5wc4     1/1     Running   0          10m
loki-query-frontend-678899db5-tf69b     1/1     Running   0          10m
loki-query-scheduler-7d666bf759-9xqb5   1/1     Running   0          10m
loki-query-scheduler-7d666bf759-kpb5q   1/1     Running   0          10m
loki-results-cache-0                    2/2     Running   0          10m
loki-ruler-0                            1/1     Running   0          10m

Find the Loki Gateway Service

The Loki Gateway service is a LoadBalancer service that exposes the Loki gateway to the internet. This is where you will write logs to and query logs from. By default NGINX is used as the gateway.

Caution
The Loki Gateway service is exposed to the internet. We provide basic authentication using a username and password in this tutorial. Refer to the Authentication documentation for more information.

To find the Loki Gateway service, run the following command:

kubectl get svc -n loki

You should see the Loki Gateway service with an external IP address. This is the address you will use to write to and query Loki.

  NAME                             TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)              AGE
loki-gateway                     LoadBalancer   10.100.201.74    12345678975675456-1433434453245433545656563.eu-west-2.elb.amazonaws.com   80:30707/TCP         46m

Congratulations! You have successfully deployed Loki on AWS using the Helm chart. Before we finish, let’s test the deployment.

Testing Your Loki Deployment

k6 is one of the fastest ways to test your Loki deployment. This will allow you to both write and query logs to Loki. To get started with k6, follow the steps below:

Install k6 with the Loki extension on your local machine. Refer to Installing k6 and the xk6-loki extension.

Create a aws-test.js file with the following content:

 import {sleep, check} from 'k6';
 import loki from 'k6/x/loki';

 /**
 * URL used for push and query requests
 * Path is automatically appended by the client
 * @constant {string}
 */

 const username = '<USERNAME>';
 const password = '<PASSWORD>';
 const external_ip = '<EXTERNAL-IP>';

 const credentials = `${username}:${password}`;

 const BASE_URL = `http://${credentials}@${external_ip}`;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const KB = 1024;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const MB = KB * KB;

 /**
 * Instantiate config and Loki client
 */

 const conf = new loki.Config(BASE_URL);
 const client = new loki.Client(conf);

 /**
 * Define test scenario
 */
 export const options = {
   vus: 10,
   iterations: 10,
 };

 export default () => {
   // Push request with 10 streams and uncompressed logs between 800KB and 2MB
   var res = client.pushParameterized(10, 800 * KB, 2 * MB);
   // Check for successful write
   check(res, { 'successful write': (res) => res.status == 204 });

   // Pick a random log format from label pool
   let format = randomChoice(conf.labels["format"]);

   // Execute instant query with limit 1
   res = client.instantQuery(`count_over_time({format="${format}"}[1m])`, 1)
   // Check for successful read
   check(res, { 'successful instant query': (res) => res.status == 200 });

   // Execute range query over last 5m and limit 1000
   res = client.rangeQuery(`{format="${format}"}`, "5m", 1000)
   // Check for successful read
   check(res, { 'successful range query': (res) => res.status == 200 });

   // Wait before next iteration
   sleep(1);
 }

 /**
 * Helper function to get random item from array
 */
 function randomChoice(items) {
   return items[Math.floor(Math.random() * items.length)];
 }

Replace <EXTERNAL-IP> with the external IP address of the Loki Gateway service.

This script will write logs to Loki and query logs from Loki. It will write logs in a random format between 800KB and 2MB and query logs in a random format over the last 5 minutes.

Run the test:
Bash
```
./k6 run aws-test.js
```
This will run the test and output the results. You should see the test writing logs to Loki and querying logs from Loki.

Now that you have successfully deployed Loki in microservices mode on AWS, you may wish to explore the following:

Deploy the Loki Helm chart on Azure

Thu, 09 Apr 2026 02:28:18 +0000

Deploy the Loki Helm chart on Azure

This guide shows how to deploy a minimally viable Loki in microservice mode on Azure using the Helm chart. In order to successfully complete this guide, you must have the necessary tools and permissions to deploy resources on Azure, such as:

Full access to AKS (Azure Kubernetes Service)
Full access to Azure Blob Storage
Sufficient permissions to create federated credentials and roles in Azure AD (Active Directory)

There are four primary ways to authenticate Loki with Azure:

Hard coding a connection string - this is the simplest method but is not recommended for production environments.
Service principal
Managed identity
Federated token

In this guide, we will use the federated token method to deploy Loki on Azure. This method is more secure than hard coding a connection string and is more suitable for production environments.

Considerations

Caution
This guide was accurate at the time it was last updated on 6th of February, 2026. As cloud providers frequently update their services and offerings, as a best practice, you should refer to the Azure documentation before creating your storage account and assigning roles.

AD Role: In this tutorial we will create a role in Azure Active Directory (Azure AD) to allow Loki to read and write from Azure Blob Storage. This role will be assigned to the Loki service account. You may want to adjust the permissions based on your requirements.
Authentication: Grafana Loki comes with a basic authentication layer. The Loki gateway (NGINX) is exposed to the internet using basic authentication in this example. NGINX can also be replaced with other open-source reverse proxies. Refer to Authentication for more information.
Retention: The retention period is set to 28 days in the values.yaml file. You may wish to adjust this based on your requirements.
Costs: Running Loki on Azure will incur costs. Make sure to monitor your usage and costs to avoid any unexpected bills. In this guide we have used a simple AKS cluster with 3 nodes and Standard_E2ds_v5 instances. You may wish to adjust the instance types and number of nodes based on your workload.

Prerequisites

Helm 3 or above. Refer to Installing Helm. This should be installed on your local machine.
Kubectl installed on your local machine. Refer to Install and Set Up kubectl.
Azure CLI installed on your local machine. Refer to Installing the Azure CLI. This is a requirement for following this guide as all resources will be created using the Azure CLI.

AKS minimum requirements

Before creating an AKS cluster in Azure you need to create a resource group. You can create a resource group using the Azure CLI:

az group create --name <INSERT-NAME> -location <INSERT-AZURE-REGION>

Caution
These AKS requirements are the minimum specification needed to deploy Loki using this guide. You may wish to adjust the instance types based on your Azure environment and workload. If you choose to do so, we cannot guarantee that this sample configuration will still meet your needs.

In this guide, we deploy Loki using Standard_E2ds_v5 instances. This is to make sure we remain within the free tier limits for Azure. Which allows us to deploy up to 10 vCPUs within a region. We recommend for large production workloads to scale these nodes up to Standard_D4_v5.

The minimum requirements for deploying Loki on AKS are:

Kubernetes version 1.30 or above.
3 nodes for the AKS cluster.
Instance type depends on your workload. A good starting point for a production cluster in the free tier is Standard_E2ds_v5 instances and for large production workloads Standard_D4_v5 instances.

Here is how to create an AKS cluster with the minimum requirements:

az aks create \
  --resource-group <MY_RESOURCE_GROUP_NAME> \
  --name <MY_AKS_CLUSTER_NAME> \
  --node-count 3 \
  --node-vm-size Standard_E2ds_v5 \
  --generate-ssh-keys \
  --enable-workload-identity \
  --enable-oidc-issuer

Note in the above command we have enabled workload identity and OIDC issuer. This is required for the Loki service account to authenticate with Azure AD. If you have already created an AKS cluster, you can enable these features using the following command:

az aks update \
  --resource-group <MY_RESOURCE_GROUP_NAME> \
  --name <MY_AKS_CLUSTER_NAME> \
  --enable-workload-identity \
  --enable-oidc-issuer

The Azure CLI also lets you bind the AKS cluster to kubectl. You can do this by running the following command:

az aks get-credentials --resource-group <MY_RESOURCE_GROUP_NAME> --name <MY_AKS_CLUSTER_NAME>

Configuring Azure Blob Storage

Tip
Consider using unique bucket names rather than: chunk, ruler, and admin. Although Azure Blog Storage is not directly affected by this security update it is a best practice to use unique container names for buckets.

Before deploying Loki, you need to create two Azure storage containers; one to store logs (chunks), the second to store alert rules. You can create the containers using the Azure CLI. Containers must exist inside a storage account.

Note
GEL customers will require a third container to store the admin data. This container is not required for OSS users.

Create a storage account:

az storage account create \
--name <NAME> \
--location <REGION> \
--sku Standard_ZRS \
--encryption-services blob \
--resource-group <MY_RESOURCE_GROUP_NAME>

Replace the placeholders with your desired values.

Create the containers for chunks and ruler:

az storage container create --account-name <STORAGE-ACCOUNT-NAME> --name <CHUNK-BUCKET-NAME> --auth-mode login && \
az storage container create --account-name <STORAGE-ACCOUNT-NAME> --name <RULER-BUCKET-NAME> --auth-mode login

Make sure --account-name matches the account you just created

With the storage account and containers created, you can now proceed to creating the Azure AD role and federated credentials.

Creating the Azure AD role and federated credentials

The recommended way to authenticate Loki with Azure Blob Storage is to use federated credentials. This method is more secure than hard coding a connection string directly into the Loki configuration. In this next section, we will create an Azure AD role and federated credentials for Loki to allow it to read and write from Azure Blob Storage:

Locate the OpenID Connect (OIDC) issuer URL:
Bash
```
az aks show \
--resource-group <MY_RESOURCE_GROUP_NAME> \
--name <MY_AKS_CLUSTER_NAME> \
--query "oidcIssuerProfile.issuerUrl" \
-o tsv
```
This command will return the OIDC issuer URL. You will need this URL to create the federated credentials.

Generate a credentials.json file with the following content:

{
    "name": "LokiFederatedIdentity",
    "issuer": "<OIDC-ISSUER-URL>",
    "subject": "system:serviceaccount:loki:loki",
    "description": "Federated identity for Loki accessing Azure resources",
    "audiences": [
      "api://AzureADTokenExchange"
    ]
}

Replace <OIDC-ISSUER-URL> with the OIDC issuer URL you found in the previous step.

Make sure you to save the credentials.json file before continuing.
Next generate an Azure directory app. We will use this to assign our federated credentials to:
Bash
```
 az ad app create \
 --display-name loki \
 --query appId \
 -o tsv
```
This will return the app ID. Save this for later use. If you need to find the app ID later you can run the following command:
Bash
```
az ad app list --display-name loki --query "[].appId" -o tsv
```
The app requires a service principal to authenticate with Azure AD. Create a service principal for the app:
Bash
```
az ad sp create --id <APP-ID>
```
Replace <APP-ID> with the app ID you generated in the previous step.
Next assign the federated credentials to the app:
Bash
```
az ad app federated-credential create \
  --id <APP-ID> \
  --parameters credentials.json 
```
Replace <APP-ID> with the app ID you generated in the previous step.

Lastly add a role assignment to the app:

az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee <APP-ID> \
  --scope /subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE-ACCOUNT-NAME>

Replace the placeholders with your actual values.

Now that you have created the Azure AD role and federated credentials, you can proceed to deploying Loki using the Helm chart.

Deploying the Helm chart

The following steps require the use of helm and kubectl. Make sure you have run the az command to bind your AKS cluster to kubectl:

az aks get-credentials --resource-group <MY_RESOURCE_GROUP_NAME> --name <MY_AKS_CLUSTER_NAME>

Before we can deploy the Loki Helm chart, we need to add the Grafana Community chart repository to Helm. This repository contains the Loki Helm chart.

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```
Create a new namespace for Loki:
Bash
```
kubectl create namespace loki
```

Loki basic authentication

Loki by default does not come with any authentication. Since we will be deploying Loki to Azure and exposing the gateway to the internet, we recommend adding at least basic authentication. In this guide we will give Loki a username and password:

To start we will need create a .htpasswd file with the username and password. You can use the htpasswd command to create the file:

Tip
If you don’t have the htpasswd command installed, you can install it using brew or apt-get or yum depending on your OS.
Bash
```
htpasswd -c .htpasswd <username>
```
This will create a file called auth with the username loki. You will be prompted to enter a password.
Create a Kubernetes secret with the .htpasswd file:
Bash
```
kubectl create secret generic loki-basic-auth --from-file=.htpasswd -n loki
```
This will create a secret called loki-basic-auth in the loki namespace. We will reference this secret in the Loki Helm chart configuration.
Create a canary-basic-auth secret for the canary:
Bash
```
kubectl create secret generic canary-basic-auth \
  --from-literal=username=<USERNAME> \
  --from-literal=password=<PASSWORD> \
  -n loki
```
We create a literal secret with the username and password for Loki canary to authenticate with the Loki gateway. Make sure to replace the placeholders with your desired username and password.

Loki Helm chart configuration

Create a values.yaml file choosing the configuration options that best suit your requirements. Below there is an example of values.yaml files for the Loki Helm chart in microservices mode.

loki:
  podLabels:
    "azure.workload.identity/use": "true" # Add this label to the Loki pods to enable workload identity
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: azure
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage:
    type: azure
    bucketNames:
      chunks: "<CHUNK-CONTAINER-NAME>" # Your actual Azure Blob Storage container name (loki-azure-dev-chunks)
      ruler: "<RULER-CONTAINER-NAME>" # Your actual Azure Blob Storage container name (loki-azure-dev-ruler)
      # admin: "admin-loki-devrel" # Your actual Azure Blob Storage container name (loki-azure-dev-admin)
    azure:
      accountName: <INSERT-STORAGE-ACCOUNT-NAME>
      useFederatedToken: true # Use federated token for authentication
  ingester:
    chunk_encoding: snappy
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention
  compactor:
    retention_enabled: true
    delete_request_store: azure
  ruler:
    enable_api: true
    alertmanager_url: http://prom:9093 # The URL of the Alertmanager to send alerts (Prometheus, Mimir, etc.)

  querier:
    max_concurrent: 4

# Define the Azure workload identity
serviceAccount:
  name: loki
  annotations:
    "azure.workload.identity/client-id": "<APP-ID>" # The app ID of the Azure AD app

deploymentMode: Distributed

ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false

querier:
  replicas: 3
  maxUnavailable: 2

queryFrontend:
  replicas: 2
  maxUnavailable: 1

queryScheduler:
  replicas: 2

distributor:
  replicas: 3
  maxUnavailable: 2

compactor:
  replicas: 1

indexGateway:
  replicas: 2
  maxUnavailable: 1

ruler:
  replicas: 1
  maxUnavailable: 1


# This exposes the Loki gateway so it can be written to and queried externaly
gateway:
  service:
    type: LoadBalancer
  basicAuth: 
    enabled: true
    existingSecret: loki-basic-auth

# Since we are using basic auth, we need to pass the username and password to the canary
lokiCanary:
  extraArgs:
    - -pass=$(LOKI_PASS)
    - -user=$(LOKI_USER)
  extraEnv:
    - name: LOKI_PASS
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: password
    - name: LOKI_USER
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: username

# Enable minio for storage
minio:
  enabled: false

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

Caution
Make sure to replace the placeholders with your actual values.

Loki Config vs. Values Config:
- The values.yaml file contains a section called loki, which contains a direct representation of the Loki configuration file.
- This section defines the Loki configuration, including the schema, storage, and querier configuration.
- The key configuration to focus on for chunks is the storage section, where you define the Azure container name and storage account. This tells Loki where to store the chunks.
- The ruler section defines the configuration for the ruler, including the Azure container name and storage account. This tells Loki where to store the alert and recording rules.
- For the full Loki configuration, refer to the Loki Configuration documentation.
Storage:
- Defines where the Helm chart stores data.
- Set the type to azure since we are using Azure Blob Storage.
- Configure the container names for the chunks and ruler to match the containers created earlier.
- The azure section specifies the storage account name and also sets useFederatedToken to true. This tells Loki to use federated credentials for authentication.
Service Account:
- The serviceAccount section is used to define the federated workload identity Loki will use to authenticate with Azure AD.
- We set the azure.workload.identity/client-id annotation to the app ID of the Azure AD app.
Zone-Aware Replication:
- The Helm chart enables zone-aware ingester replication by default, which creates three ingester StatefulSets (zone-a, zone-b, zone-c) for faster rollouts.
- In this guide, zone-aware replication is explicitly disabled (ingester.zoneAwareReplication.enabled: false) for simplicity. For production deployments, consider enabling it to improve rollout resilience.
Gateway:
- Defines how the Loki gateway will be exposed.
- We are using a LoadBalancer service type in this configuration.

Deploy Loki

Now that you have created the values.yaml file, you can deploy Loki using the Helm chart.

Deploy using the newly created values.yaml file:
Bash
```
helm install --values values.yaml loki grafana-community/loki -n loki --create-namespace
```
It is important to create a namespace called loki as our federated credentials were generated with the value system:serviceaccount:loki:loki. This translates to the loki service account in the loki namespace. This is configurable but make sure to update the federated credentials file first.

Verify the deployment:

kubectl get pods -n loki

You should see the Loki pods running.

NAME                                    READY   STATUS    RESTARTS   AGE
loki-canary-crqpg                       1/1     Running   0          10m
loki-canary-hm26p                       1/1     Running   0          10m
loki-canary-v9wv9                       1/1     Running   0          10m
loki-chunks-cache-0                     2/2     Running   0          10m
loki-compactor-0                        1/1     Running   0          10m
loki-distributor-78ccdcc9b4-9wlhl       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-km6j2       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-ptwrb       1/1     Running   0          10m
loki-gateway-5f97f78755-hm6mx           1/1     Running   0          10m
loki-index-gateway-0                    1/1     Running   0          10m
loki-index-gateway-1                    1/1     Running   0          10m
loki-ingester-zone-a-0                  1/1     Running   0          10m
loki-ingester-zone-b-0                  1/1     Running   0          10m
loki-ingester-zone-c-0                  1/1     Running   0          10m
loki-querier-89d4ff448-4vr9b            1/1     Running   0          10m
loki-querier-89d4ff448-7nvrf            1/1     Running   0          10m
loki-querier-89d4ff448-q89kh            1/1     Running   0          10m
loki-query-frontend-678899db5-n5wc4     1/1     Running   0          10m
loki-query-frontend-678899db5-tf69b     1/1     Running   0          10m
loki-query-scheduler-7d666bf759-9xqb5   1/1     Running   0          10m
loki-query-scheduler-7d666bf759-kpb5q   1/1     Running   0          10m
loki-results-cache-0                    2/2     Running   0          10m
loki-ruler-0                            1/1     Running   0          10m

Find the Loki gateway service

The Loki gateway service is a load balancer service that exposes the Loki gateway to the internet. This is where you will write logs to and query logs from. By default NGINX is used as the gateway.

Caution
The Loki gateway service is exposed to the internet. We provide basic authentication using a username and password in this tutorial. Refer to the Authentication documentation for more information.

To find the Loki gateway service, run the following command:

kubectl get svc -n loki

You should see the Loki gateway service with an external IP address. This is the address you will use to write to and query Loki.

  NAME                             TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)              AGE
loki-gateway                     LoadBalancer   10.100.201.74     134.236.21.145  80:30707/TCP         46m

Congratulations! You have successfully deployed Loki on Azure using the Helm chart. Before we finish, let’s test the deployment.

Testing Your Loki Deployment

k6 is one of the fastest ways to test your Loki deployment. This will allow you to both write and query logs to Loki. To get started with k6, follow the steps below:

Install k6 with the Loki extension on your local machine. Refer to Installing k6 and the xk6-loki extension.

Create a azure-test.js file with the following content:

 import {sleep, check} from 'k6';
 import loki from 'k6/x/loki';

 /**
 * URL used for push and query requests
 * Path is automatically appended by the client
 * @constant {string}
 */

 const username = '<USERNAME>';
 const password = '<PASSWORD>';
 const external_ip = '<EXTERNAL-IP>';

 const credentials = `${username}:${password}`;

 const BASE_URL = `http://${credentials}@${external_ip}`;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const KB = 1024;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const MB = KB * KB;

 /**
 * Instantiate config and Loki client
 */

 const conf = new loki.Config(BASE_URL);
 const client = new loki.Client(conf);

 /**
 * Define test scenario
 */
 export const options = {
   vus: 10,
   iterations: 10,
 };

 export default () => {
   // Push request with 10 streams and uncompressed logs between 800KB and 2MB
   var res = client.pushParameterized(10, 800 * KB, 2 * MB);
   // Check for successful write
   check(res, { 'successful write': (res) => res.status == 204 });

   // Pick a random log format from label pool
   let format = randomChoice(conf.labels["format"]);

   // Execute instant query with limit 1
   res = client.instantQuery(`count_over_time({format="${format}"}[1m])`, 1)
   // Check for successful read
   check(res, { 'successful instant query': (res) => res.status == 200 });

   // Execute range query over last 5m and limit 1000
   res = client.rangeQuery(`{format="${format}"}`, "5m", 1000)
   // Check for successful read
   check(res, { 'successful range query': (res) => res.status == 200 });

   // Wait before next iteration
   sleep(1);
 }

 /**
 * Helper function to get random item from array
 */
 function randomChoice(items) {
   return items[Math.floor(Math.random() * items.length)];
 }

Replace <EXTERNAL-IP> with the external IP address of the Loki Gateway service.

This script will write logs to Loki and query logs from Loki. It will write logs in a random format between 800KB and 2MB and query logs in a random format over the last 5 minutes.

Run the test:
Bash
```
./k6 run azure-test.js
```
This will run the test and output the results. You should see the test writing logs to Loki and querying logs from Loki.

Now that you have successfully deployed Loki in microservices mode on Microsoft Azure, you may wish to explore the following:

Deploy the Loki Helm chart on GCP

Thu, 09 Apr 2026 02:28:18 +0000

Deploy the Loki Helm chart on GCP

This guide shows how to deploy a minimally viable Loki in microservices mode on Google Cloud Platform (GCP) using the Helm chart. To run through this guide, we expect you to have the necessary tools and permissions to deploy resources on GCP, such as:

Full access to Google Kubernetes Engine (GKE)
Full access to Google Cloud Storage (GCS)
Sufficient permissions to create Identity Access Management (IAM) roles and policies

There are two methods for authenticating and connecting Loki to GCP GCS. We will guide you through the recommended method of granting access via an IAM role: using Workload Identity Federation.

Considerations

Caution
This guide was accurate at the time it was last updated on 10th of June, 2025. As cloud providers frequently update their services and offerings, as a best practice, you should refer to the GCP GCS documentation before creating your buckets and assigning roles.

IAM Role: The IAM role created in this guide is a basic role that allows Loki to read and write to the GCS bucket. You may wish to add more granular permissions based on your requirements.
Authentication: Grafana Loki comes with a basic authentication layer. The Loki gateway (NGINX) is exposed to the internet using basic authentication in this example. NGINX can also be replaced with other open-source reverse proxies. Refer to Authentication for more information.
Retention: The retention period is set to 28 days in the values.yaml file. You may wish to adjust this based on your requirements.
Costs: Running Loki on GCP will incur costs. Make sure to monitor your usage and costs to avoid any unexpected bills. In this guide we have used a simple GKE cluster with 3 nodes (n2-standard-8 instances). You may wish to adjust the instance types and number of nodes based on your workload.

Prerequisites

Helm 3 or above. Refer to Installing Helm. This should be installed on your local machine.
A running Kubernetes cluster on GCP. Refer to Create a cluster and deploy a workload in the Google Cloud console.
Kubectl installed on your local machine. Refer to Install and Set Up kubectl.
gcloud CLI installed on your local machine. Refer to Install the Google Cloud CLI. In this guide, we use gcloud CLI to create the GKE cluster and modify the IAM roles and policies locally.

GKE Minimum Requirements

Caution
These GKE requirements are the minimum specification needed to deploy Loki using this guide. You may wish to adjust plugins and instance types based on your GCP environment and workload. If you choose to do so, we cannot guarantee that this sample configuration will still meet your needs.

In this guide, we deploy Loki using n2-standard-8 instances. This is a instance type that should work for most scenarios. However, you can modify the instance types and count based on your specific needs.

The minimum requirements for deploying Loki on GKE are:

Kubernetes version 1.30 or above.
3 nodes for the GKE cluster.
Instance type depends on your workload. A good starting point for a production cluster is n2-standard-8.

To allow kubectl to support GKE, install the gcloud kubectl auth plugin:

gcloud components install gke-gcloud-auth-plugin

This plugin is necessary to use kubectl to authenticate with GKE. Click here for more details on this plugin.

Warning
Regional clusters in GKE are designed for resilience, and thus by default span three zones within the region. In the command below, num-nodes=1. Note that if you set num_nodes=3, you would get 9 nodes in total for the region: 3 in each zone. Therefore, leave num_nodes=1 when you create your cluster.

Here is an example of a command you can run using gcloud CLI to create a new cluster:

gcloud container clusters create loki-gcp \
  --location=europe-west4 \
  --num-nodes=1 \
  --machine-type=n2-standard-8 \
  --release-channel=regular \
  --workload-pool=<PROJECT_ID>.svc.id.goog \
  --enable-ip-alias \
  --no-enable-basic-auth \
  --no-issue-client-certificate

Replace <PROJECT_ID> with the ID of the project you want to create the cluster in. This should be something like my-project-123456.

Create GCS buckets

Warning
DO NOT use the default bucket names; chunks, ruler and admin. Choose a unique name for each bucket. For more information see the following security update.

Before deploying Loki, you need to create two GCS buckets: one to store logs (chunks) and another to store alert rules (ruler). You can create the bucket using the GCP Management Console or the GCP CLI. The bucket name must be globally unique.

Note
GEL customers will require a third bucket to store the admin data. This bucket is not required for OSS users.

gcloud storage buckets create gs://<CHUNKS_BUCKET_NAME> gs://<RULER_BUCKET_NAME> \
  --location=<REGION> \
  --default-storage-class=STANDARD \
  --public-access-prevention \
  --uniform-bucket-level-access \
  --soft-delete-duration=7d

Make sure to replace the region and bucket name with your desired values. We will revisit the bucket policy later in this guide.

Here’s an example with all the variables filled in:

gcloud storage buckets create gs://loki-gcp-chunks gs://loki-gcp-ruler \
  --location=europe-west4 \
  --default-storage-class=STANDARD \
  --public-access-prevention \
  --uniform-bucket-level-access \
  --soft-delete-duration=7d

When you run this command, you should get something like this in response:

Creating gs://loki-gcp-chunks/...
Creating gs://loki-gcp-ruler/...

Defining IAM roles and policies

IAM determines who can access which resources on GCP and can be configured in several ways. The recommended method for allowing Loki to access GCS is to use Workload Identity Federation. This method is more secure than creating and distributing a service account key. The following steps show how to create the role and policy using the gcloud CLI.

Authenticating to the GKE cluster

You need to be able to run kubectl commands on the cluster, so make sure you have it installed (run gcloud components install kubectl if not) and then run this command:

gcloud container clusters get-credentials <CLUSTER_NAME> \
  --region=<REGION>

Here’s an example of that command with the variables filled in:

gcloud container clusters get-credentials loki-gcp \
  --region=europe-west4

This will authenticate you via your GCP IAM identity, write the cluster’s access info to your local kubeconfig (usually ~/.kube/config), and then allow kubectl commands to talk to the right cluster from now on.

Then check that you’re connected to the GKE cluster and that you’re accessing it via kubectl by running:

kubectl config current-context

You should get something like this in return:

gke_my-project-123456_europe-west4_loki-gcp

Create a Kubernetes Namespace

Create a Kubernetes namespace where you’ll install your Loki workloads:

kubectl create namespace <NAMESPACE>

Replace <NAMESPACE> with the namespace where your Loki workloads will be located.

Example:

kubectl create namespace loki

You should get the output:

namespace/loki created

Create Kubernetes Service Account (KSA)

A KSA is a cluster identity (service account, named default by default) assigned to pods that allows pods to interact with each other.

Create a KSA on your Kubernetes cluster:

kubectl create serviceaccount <KSA_NAME> \
  --namespace <NAMESPACE>

Replace <KSA_NAME> with the name of the KSA created above, and <NAMESPACE> with the namespace where your Loki workloads are located.

Example:

kubectl create serviceaccount loki-gcp-ksa \
  --namespace loki

You should get this in response:

serviceaccount/loki-gcp-ksa created

Add IAM Policy to Buckets

Note
The pre-defined roles/storage.objectUser role is sufficient for Loki to operate. See IAM permissions for Cloud Storage for details about each individual permission. You can use this predefined role or create your own with matching permissions.

Create an IAM policy binding on the buckets using the KSA created previously and the roles of your choice. Use a separate command for each bucket, one for chunks, and another for the ruler.

gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
 --role=roles/storage.objectUser \
  --member=principal://iam.googleapis.com/projects/<PROJECT_NUMBER>/locations/global/workloadIdentityPools/<PROJECT_ID>.svc.id.goog/subject/ns/<NAMESPACE>/sa/<KSA_NAME> \
  --condition=None

Replace <PROJECT_ID> with the GCP project ID (for example, project-name), <PROJECT_NUMBER> with the project number (for example, 1234567890), <NAMESPACE> with the namespace where Loki is installed, and <KSA_NAME> with the name of the KSA you created above.

Then do the same thing for the other bucket.

Examples:

gcloud storage buckets add-iam-policy-binding gs://loki-gcp-chunks \
  --role=roles/storage.objectUser \
  --member=principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa \
  --condition=None

and

gcloud storage buckets add-iam-policy-binding gs://loki-gcp-ruler \
  --role=roles/storage.objectUser \
  --member=principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa \
  --condition=None

You should get something like this in response:

bindings:
- members:
  - projectEditor:my-project-123456
  - projectOwner:my-project-123456
  role: roles/storage.legacyBucketOwner
- members:
  - projectViewer:my-project-123456
  role: roles/storage.legacyBucketReader
- members:
  - projectEditor:my-project-123456
  - projectOwner:my-project-123456
  role: roles/storage.legacyObjectOwner
- members:
  - projectViewer:my-project-123456
  role: roles/storage.legacyObjectReader
- members:
  - principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa
  role: roles/storage.objectUser
etag: CAI=
kind: storage#policy
resourceId: projects/_/buckets/loki-gcp-chunks
version: 1

Deploying the Helm chart

Before we can deploy the Loki Helm chart, we need to add the Grafana Community chart repository to Helm. This repository contains the Loki Helm chart.

Add the Grafana Community chart repository to Helm:

helm repo add grafana-community https://grafana-community.github.io/helm-charts

Update the chart repository:
Bash
```
helm repo update
```

Loki Basic Authentication

Loki by default does not come with any authentication. Since we will be deploying Loki to GCP and exposing the gateway to the internet, we recommend adding at least basic authentication. In this guide we will give Loki a username and password:

To start we will need create a .htpasswd file with the username and password. You can use the htpasswd command to create the file:

Tip
If you don’t have the htpasswd command installed, you can install it using brew or apt-get or yum depending on your OS.
Bash
```
htpasswd -c .htpasswd <username>
```
This will create a file called auth with the username loki. You will be prompted to enter a password.
Create a Kubernetes secret with the .htpasswd file:
Bash
```
kubectl create secret generic loki-basic-auth --from-file=.htpasswd -n loki
```
This will create a secret called loki-basic-auth in the loki namespace. We will reference this secret in the Loki Helm chart configuration.
Create a canary-basic-auth secret for the canary:
Bash
```
kubectl create secret generic canary-basic-auth \
  --from-literal=username=<USERNAME> \
  --from-literal=password=<PASSWORD> \
  -n loki
```
We create a literal secret with the username and password for Loki canary to authenticate with the Loki gateway. Make sure to replace the placeholders with your desired username and password.

Loki Helm chart configuration

Create a values.yaml file choosing the configuration options that best suit your requirements. Below there is an example of values.yaml files for the Loki Helm chart in microservices mode.

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: gcs
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    gcs:
      bucket_name: <CHUNK_BUCKET_NAME> # Your actual gcs bucket name, for example, loki-gcp-chunks
  ingester:
    chunk_encoding: snappy
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
    volume_enabled: true
    retention_period: 672h # 28 days retention
  compactor:
    retention_enabled: true
    delete_request_store: gcs
  ruler:
    enable_api: true
    storage_config:
      type: gcs
      gcs_storage_config:
        region: <REGION> # The GCS region, for example europe-west4
        bucketnames: <RULER_BUCKET_NAME> # Your actual gcs bucket name, for example, loki-gcp-ruler
      alertmanager_url: http://prom:9093 # The URL of the Alertmanager to send alerts (Prometheus, Mimir, etc.)

  querier:
    max_concurrent: 4

  storage:
    type: gcs
    bucketNames:
      chunks: <CHUNK_BUCKET_NAME> # Your actual gcs bucket name, for example, loki-gcp-chunks
      ruler: <RULER_BUCKET_NAME> # Your actual gcs bucket name, for example, loki-gcp-ruler
      
serviceAccount:
  create: false
  name: <KSA_NAME>

deploymentMode: Distributed

ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false

querier:
  replicas: 3
  maxUnavailable: 2

queryFrontend:
  replicas: 2
  maxUnavailable: 1

queryScheduler:
  replicas: 2

distributor:
  replicas: 3
  maxUnavailable: 2
 
compactor:
  replicas: 1

indexGateway:
  replicas: 2
  maxUnavailable: 1

ruler:
  replicas: 1
  maxUnavailable: 1


# This exposes the Loki gateway so it can be written to and queried externaly
gateway:
  service:
    type: LoadBalancer
  basicAuth:
    enabled: true
    existingSecret: loki-basic-auth

# Since we are using basic auth, we need to pass the username and password to the canary
lokiCanary:
  extraArgs:
    - -pass=$(LOKI_PASS)
    - -user=$(LOKI_USER)
  extraEnv:
    - name: LOKI_PASS
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: password
    - name: LOKI_USER
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: username

# Enable minio for storage
minio:
  enabled: false

backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0

singleBinary:
  replicas: 0

Caution
Make sure to replace the placeholders with your actual values.

Note
In values.yaml above, you may notice that serviceAccount is set to create: false. This is because you want to use the service account that you created earlier instead of creating a new one.

Loki Config vs. Values Config:
- The values.yaml file contains a section called loki, which contains a direct representation of the Loki configuration file.
- This section defines the Loki configuration, including the schema, storage, and querier configuration.
- The key configuration to focus on for chunks is the storage_config section, where you define the GCS bucket region and name. This tells Loki where to store the chunks.
- The ruler section defines the configuration for the ruler, including the GCS bucket region and name. This tells Loki where to store the alert and recording rules.
- For the full Loki configuration, refer to the Loki Configuration documentation.
Storage:
- Defines where the Helm chart stores data.
- Set the type to GCS since we are using Google Cloud Storage.
- Configure the bucket names for the chunks and ruler to match the buckets created earlier.
- The GCS section specifies the region of the bucket.
Service Account:
- The serviceAccount section is used to define the IAM role for the Loki service account.
- This is where the IAM role created earlier is linked.
Zone-Aware Replication:
- The Helm chart enables zone-aware ingester replication by default, which creates three ingester StatefulSets (zone-a, zone-b, zone-c) for faster rollouts.
- In this guide, zone-aware replication is explicitly disabled (ingester.zoneAwareReplication.enabled: false) for simplicity. For production deployments, consider enabling it to improve rollout resilience.
Gateway:
- Defines how the Loki gateway will be exposed.
- We are using a LoadBalancer service type in this configuration.

Deploy Loki

Now that you have created the values.yaml file, you can deploy Loki using the Helm chart.

Deploy using the newly created values.yaml file:
Bash
```
helm install --values values.yaml loki grafana-community/loki -n loki --create-namespace
```
It is important to create a namespace called loki as our trust policy is set to allow the IAM role to be used by the loki service account in the loki namespace. This is configurable but make sure to update your service account.

Verify the deployment:

kubectl get pods -n loki

You should see the Loki pods running.

NAME                                    READY   STATUS    RESTARTS   AGE
loki-canary-crqpg                       1/1     Running   0          10m
loki-canary-hm26p                       1/1     Running   0          10m
loki-canary-v9wv9                       1/1     Running   0          10m
loki-chunks-cache-0                     2/2     Running   0          10m
loki-compactor-0                        1/1     Running   0          10m
loki-distributor-78ccdcc9b4-9wlhl       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-km6j2       1/1     Running   0          10m
loki-distributor-78ccdcc9b4-ptwrb       1/1     Running   0          10m
loki-gateway-5f97f78755-hm6mx           1/1     Running   0          10m
loki-index-gateway-0                    1/1     Running   0          10m
loki-index-gateway-1                    1/1     Running   0          10m
loki-ingester-zone-a-0                  1/1     Running   0          10m
loki-ingester-zone-b-0                  1/1     Running   0          10m
loki-ingester-zone-c-0                  1/1     Running   0          10m
loki-querier-89d4ff448-4vr9b            1/1     Running   0          10m
loki-querier-89d4ff448-7nvrf            1/1     Running   0          10m
loki-querier-89d4ff448-q89kh            1/1     Running   0          10m
loki-query-frontend-678899db5-n5wc4     1/1     Running   0          10m
loki-query-frontend-678899db5-tf69b     1/1     Running   0          10m
loki-query-scheduler-7d666bf759-9xqb5   1/1     Running   0          10m
loki-query-scheduler-7d666bf759-kpb5q   1/1     Running   0          10m
loki-results-cache-0                    2/2     Running   0          10m
loki-ruler-0                            1/1     Running   0          10m

Find the Loki Gateway Service

The Loki Gateway service is a LoadBalancer service that exposes the Loki gateway to the internet. This is where you will write logs to and query logs from. By default NGINX is used as the gateway.

Caution
The Loki Gateway service is exposed to the internet. We provide basic authentication using a username and password in this tutorial. Refer to the Authentication documentation for more information.

To find the Loki Gateway service, run the following command:

kubectl get svc -n loki

You should see the Loki Gateway service with an external IP address. This is the address you will use to write to and query Loki.

NAME           TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)        AGE
loki-gateway   LoadBalancer   34.118.239.140   34.91.203.240   80:30566/TCP   25m

In this case, the external IP address is 34.91.203.240.

Congratulations! You have successfully deployed Loki on GCP using the Helm chart. Before we finish, let’s test the deployment.

Testing Your Loki Deployment

k6 is one of the fastest ways to test your Loki deployment. This will allow you to both write and query logs to Loki. To get started with k6, follow the steps below:

Install k6 with the Loki extension on your local machine. Refer to Installing k6 and the xk6-loki extension.

Create a gcp-test.js file with the following content:

 import {sleep, check} from 'k6';
 import loki from 'k6/x/loki';

 /**
 * URL used for push and query requests
 * Path is automatically appended by the client
 * @constant {string}
 */

 const username = '<USERNAME>';
 const password = '<PASSWORD>';
 const external_ip = '<EXTERNAL-IP>';

 const credentials = `${username}:${password}`;

 const BASE_URL = `http://${credentials}@${external_ip}`;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const KB = 1024;

 /**
 * Helper constant for byte values
 * @constant {number}
 */
 const MB = KB * KB;

 /**
 * Instantiate config and Loki client
 */

 const conf = new loki.Config(BASE_URL);
 const client = new loki.Client(conf);

 /**
 * Define test scenario
 */
 export const options = {
   vus: 10,
   iterations: 10,
 };

 export default () => {
   // Push request with 10 streams and uncompressed logs between 800KB and 2MB
   var res = client.pushParameterized(10, 800 * KB, 2 * MB);
   // Check for successful write
   check(res, { 'successful write': (res) => res.status == 204 });

   // Pick a random log format from label pool
   let format = randomChoice(conf.labels["format"]);

   // Execute instant query with limit 1
   res = client.instantQuery(`count_over_time({format="${format}"}[1m])`, 1)
   // Check for successful read
   check(res, { 'successful instant query': (res) => res.status == 200 });

   // Execute range query over last 5m and limit 1000
   res = client.rangeQuery(`{format="${format}"}`, "5m", 1000)
   // Check for successful read
   check(res, { 'successful range query': (res) => res.status == 200 });

   // Wait before next iteration
   sleep(1);
 }

 /**
 * Helper function to get random item from array
 */
 function randomChoice(items) {
   return items[Math.floor(Math.random() * items.length)];
 }

Replace <EXTERNAL-IP> with the external IP address of the Loki Gateway service.

This script will write logs to Loki and query logs from Loki. It will write logs in a random format between 800KB and 2MB and query logs in a random format over the last 5 minutes.

Run the test:
Bash
```
./k6 run gcp-test.js
```
This will run the test and output the results. You should see the test writing logs to Loki and querying logs from Loki.

Now that you have successfully deployed Loki in microservices mode on GCP, you may wish to explore the following: