Azure에서 Loki Helm 차트 배포
이 가이드는 Helm 차트를 사용하여 Azure에 최소한의 실행 가능한 Loki를 마이크로서비스 모드로 배포하는 방법을 보여줍니다. 이 가이드를 성공적으로 완료하려면 다음과 같이 Azure에 리소스를 배포하는 데 필요한 도구와 권한이 있어야 합니다:
- AKS(Azure Kubernetes Service)에 대한 전체 액세스
- Azure Blob Storage에 대한 전체 액세스
- Azure AD(Active Directory)에서 페더레이션된 자격 증명과 역할을 생성할 수 있는 충분한 권한
Loki를 Azure로 인증하는 세 가지 주요 방법이 있습니다:
- 연결 문자열 하드코딩 - 가장 간단한 방법이지만 프로덕션 환경에는 권장되지 않습니다.
- 관리 ID
- 페더레이션 토큰
이 가이드에서는 페더레이션 토큰 방법을 사용하여 Azure에 Loki를 배포합니다. 이 방법은 연결 문자열을 하드코딩하는 것보다 안전하며 프로덕션 환경에 더 적합합니다.
고려 사항
이 가이드는 마지막으로 업데이트된 2025년 1월 8일을 기준으로 정확합니다. 클라우드 제공업체는 서비스를 자주 업데이트하므로, 스토리지 계정을 만들고 역할을 할당하기 전에 Azure 문서 (opens in a new tab)를 참조하는 것이 가장 좋습니다.
- AD 역할: 이 튜토리얼에서는 Loki가 Azure Blob Storage에서 읽고 쓸 수 있도록 Azure Active Directory(Azure AD)에 역할을 생성합니다. 이 역할은 Loki 서비스 계정에 할당됩니다. 요구 사항에 따라 권한을 조정할 수 있습니다.
- 인증: Grafana Loki는 기본 인증 계층을 제공합니다. 이 예제에서는 Loki 게이트웨이(NGINX)가 기본 인증을 사용하여 인터넷에 노출됩니다. NGINX는 다른 오픈 소스 리버스 프록시로 대체될 수도 있습니다. 자세한 내용은 인증을 참조하십시오.
- 보존 기간: 보존 기간은
values.yaml
파일에서 28일로 설정되어 있습니다. 요구 사항에 따라 이를 조정할 수 있습니다. - 비용: Azure에서 Loki를 실행하면 비용이 발생합니다. 예기치 않은 청구를 피하기 위해 사용량과 비용을 모니터링하십시오. 이 가이드에서는 3개의 노드와
Standard_E2ds_v5
인스턴스가 있는 간단한 AKS 클러스터를 사용했습니다. 워크로드에 따라 인스턴스 유형과 노드 수를 조정할 수 있습니다.
사전 준비 사항
- Helm 3 이상. Helm 설치하기 (opens in a new tab)를 참조하십시오. 로컬 머신에 설치해야 합니다.
- 로컬 머신에 Kubectl 설치. kubectl 설치 및 설정 (opens in a new tab)을 참조하십시오.
- 로컬 머신에 Azure CLI 설치. Azure CLI 설치하기 (opens in a new tab)를 참조하십시오. 모든 리소스가 Azure CLI를 사용하여 생성되므로 이 가이드를 따르기 위한 필수 요건입니다.
AKS 최소 요구 사항
Azure에서 AKS 클러스터를 생성하기 전에 리소스 그룹을 만들어야 합니다. Azure CLI를 사용하여 리소스 그룹을 생성할 수 있습니다:
az group create --name <INSERT-NAME> -location <INSERT-AZURE-REGION>
이러한 AKS 요구 사항은 이 가이드를 사용하여 Loki를 배포하는 데 필요한 최소 사양입니다. Azure 환경 및 워크로드에 따라 인스턴스 유형을 조정할 수 있습니다. 그렇게 할 경우, 이 샘플 구성이 여전히 요구 사항을 충족한다고 보장할 수 없습니다.
이 가이드에서는 Standard_E2ds_v5
인스턴스를 사용하여 Loki를 배포합니다. 이는 Azure의 무료 등급 한도 내에 머무르도록 하기 위함입니다. 이를 통해 한 지역 내에서 최대 10개의 vCPU를 배포할 수 있습니다. 대규모 프로덕션 워크로드의 경우 이러한 노드를 Standard_D4_v5
로 확장하는 것을 권장합니다.
AKS에 Loki를 배포하기 위한 최소 요구 사항은 다음과 같습니다:
- Kubernetes 버전
1.30
이상. - AKS 클러스터용
3
개 노드. - 인스턴스 유형은 워크로드에 따라 다릅니다. 무료 등급의 프로덕션 클러스터를 위한 좋은 시작점은
Standard_E2ds_v5
인스턴스이고, 대규모 프로덕션 워크로드의 경우Standard_D4_v5
인스턴스입니다.
다음은 최소 요구 사항으로 AKS 클러스터를 생성하는 방법입니다:
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
위의 명령에서 워크로드 아이덴티티와 OIDC 발급자를 활성화했습니다. 이는 Loki 서비스 계정이 Azure AD로 인증하는 데 필요합니다. 이미 AKS 클러스터를 생성했다면 다음 명령을 사용하여 이러한 기능을 활성화할 수 있습니다:
az aks update \
--resource-group <MY_RESOURCE_GROUP_NAME> \
--name <MY_AKS_CLUSTER_NAME> \
--enable-workload-identity \
--enable-oidc-issuer
Azure CLI를 사용하면 AKS 클러스터를 kubectl에 바인딩할 수도 있습니다. 다음 명령을 실행하여 이 작업을 수행할 수 있습니다:
az aks get-credentials --resource-group <MY_RESOURCE_GROUP_NAME> --name <MY_AKS_CLUSTER_NAME>
Azure Blob Storage 구성
chunk
, ruler
, admin
대신 고유한 버킷 이름을 사용하는 것을 고려하십시오. Azure Blog Storage는 이 보안 업데이트 (opens in a new tab)의 직접적인 영향을 받지 않지만 버킷에 고유한 컨테이너 이름을 사용하는 것이 가장 좋습니다.
Loki를 배포하기 전에 두 개의 Azure 스토리지 컨테이너를 만들어야 합니다. 하나는 로그(청크)를 저장하고 다른 하나는 경고 규칙을 저장합니다. Azure CLI를 사용하여 컨테이너를 만들 수 있습니다. 컨테이너는 스토리지 계정 내에 있어야 합니다.
GEL 고객은 관리자 데이터를 저장하기 위해 세 번째 컨테이너가 필요합니다. 이 컨테이너는 OSS 사용자에게는 필요하지 않습니다.
-
스토리지 계정 만들기:
az storage account create \ --name <NAME> \ --location <REGION> \ --sku Standard_ZRS \ --encryption-services blob \ --resource-group <MY_RESOURCE_GROUP_NAME>
자리 표시자를 원하는 값으로 바꾸십시오.
-
청크 및 룰러용 컨테이너 만들기:
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
--account-name
이 방금 만든 계정과 일치하는지 확인하십시오.
스토리지 계정과 컨테이너를 만들었으므로 이제 Azure AD 역할 및 페더레이션된 자격 증명을 만들 수 있습니다.
Azure AD 역할 및 페더레이션된 자격 증명 만들기
Loki를 Azure Blob Storage로 인증하는 권장 방법은 페더레이션된 자격 증명을 사용하는 것입니다. 이 방법은 연결 문자열을 Loki 구성에 직접 하드코딩하는 것보다 안전합니다. 다음 섹션에서는 Loki가 Azure Blob Storage에서 읽고 쓸 수 있도록 Azure AD 역할과 페더레이션된 자격 증명을 만듭니다.
-
OpenID Connect(OIDC) 발급자 URL 찾기:
az aks show \ --resource-group <MY_RESOURCE_GROUP_NAME> \ --name <MY_AKS_CLUSTER_NAME> \ --query "oidcIssuerProfile.issuerUrl" \ -o tsv
이 명령은 OIDC 발급자 URL을 반환합니다. 페더레이션된 자격 증명을 만드는 데 이 URL이 필요합니다.
-
다음 내용으로
credentials.json
파일 생성:{ "name": "LokiFederatedIdentity", "issuer": "<OIDC-ISSUER-URL>", "subject": "system:serviceaccount:loki:loki", "description": "Federated identity for Loki accessing Azure resources", "audiences": [ "api://AzureADTokenExchange" ] }
<OIDC-ISSUER-URL>
을 이전 단계에서 찾은 OIDC 발급자 URL로 바꾸십시오. -
계속하기 전에
credentials.json
파일을 저장했는지 확인하십시오. -
다음으로 Azure 디렉터리
app
을 생성합니다. 이를 사용하여 페더레이션된 자격 증명을 할당합니다:az ad app create \ --display-name loki \ --query appId \ -o tsv
그러면 앱 ID가 반환됩니다. 나중에 사용할 수 있도록 저장하십시오. 나중에 앱 ID를 찾아야 하는 경우 다음 명령을 실행할 수 있습니다:
az ad app list --display-name loki --query "[].appId" -o tsv
-
앱이 Azure AD로 인증하려면 서비스 주체가 필요합니다. 앱에 대한 서비스 주체 만들기:
az ad sp create --id <APP-ID>
<APP-ID>
를 이전 단계에서 생성한 앱 ID로 바꾸십시오. -
다음으로 페더레이션된 자격 증명을 앱에 할당합니다:
az ad app federated-credential create \ --id <APP-ID> \ --parameters credentials.json
<APP-ID>
를 이전 단계에서 생성한 앱 ID로 바꾸십시오. -
마지막으로 앱에 역할 할당을 추가합니다:
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>
자리 표시자를 실제 값으로 바꾸십시오.
이제 Azure AD 역할 및 페더레이션된 자격 증명을 만들었으므로 Helm 차트를 사용하여 Loki를 배포할 수 있습니다.
Helm 차트 배포
다음 단계에서는 helm
및 kubectl
을 사용해야 합니다. az
명령을 실행하여 AKS 클러스터를 kubectl
에 바인딩했는지 확인하십시오.
az aks get-credentials --resource-group <MY_RESOURCE_GROUP_NAME> --name <MY_AKS_CLUSTER_NAME>
Loki Helm 차트를 배포하기 전에 Grafana 차트 저장소를 Helm에 추가해야 합니다. 이 저장소에는 Loki Helm 차트가 포함되어 있습니다.
-
Grafana 차트 저장소를 Helm에 추가합니다:
helm repo add grafana https://grafana.github.io/helm-charts
-
차트 저장소를 업데이트합니다:
helm repo update
-
Loki를 위한 새 네임스페이스를 만듭니다:
kubectl create namespace loki
Loki 기본 인증
Loki는 기본적으로 어떠한 인증도 제공하지 않습니다. Loki를 Azure에 배포하고 게이트웨이를 인터넷에 노출할 것이므로 최소한 기본 인증을 추가하는 것이 좋습니다. 이 가이드에서는 Loki에 사용자 이름과 암호를 부여합니다.
-
시작하려면 사용자 이름과 암호가 포함된
.htpasswd
파일을 만들어야 합니다.htpasswd
명령을 사용하여 파일을 만들 수 있습니다:htpasswd
명령이 설치되어 있지 않은 경우 OS에 따라brew
,apt-get
또는yum
을 사용하여 설치할 수 있습니다.htpasswd -c .htpasswd <username>
그러면
loki
라는 사용자 이름으로auth
라는 파일이 생성됩니다. 암호를 입력하라는 메시지가 표시됩니다. -
.htpasswd
파일로 Kubernetes 시크릿을 만듭니다:kubectl create secret generic loki-basic-auth --from-file=.htpasswd -n loki
이렇게 하면
loki
네임스페이스에loki-basic-auth
라는 시크릿이 생성됩니다. Loki Helm 차트 구성에서 이 시크릿을 참조할 것입니다. -
카나리(canary)용
canary-basic-auth
시크릿을 만듭니다:kubectl create secret generic canary-basic-auth \ --from-literal=username=<USERNAME> \ --from-literal=password=<PASSWORD> \ -n loki
Loki 카나리가 Loki 게이트웨이로 인증할 수 있도록 사용자 이름과 암호가 포함된 리터럴 시크릿을 만듭니다. 자리 표시자를 원하는 사용자 이름과 암호로 바꾸십시오.
Loki Helm 차트 구성
요구 사항에 가장 적합한 구성 옵션을 선택하여 values.yaml
파일을 만듭니다. 아래는 마이크로서비스 모드에서 Loki Helm 차트에 대한 values.yaml
파일의 예입니다.
loki:
podLabels:
"azure.workload.identity/use": "true" # 워크로드 아이덴티티를 활성화하려면 이 레이블을 Loki 파드에 추가하세요
schemaConfig:
configs:
- from: "2024-04-01"
store: tsdb
object_store: azure
schema: v13
index:
prefix: loki_index_
period: 24h
storage_config:
azure:
account_name: "<INSERT-STORAGE-ACCOUNT-NAME>"
container_name: "<CHUNK-CONTAINER-NAME>" # 실제 Azure Blob Storage 컨테이너 이름 (loki-azure-dev-chunks)
use_federated_token: true # 인증에 페더레이션 토큰 사용
ingester:
chunk_encoding: snappy
pattern_ingester:
enabled: true
limits_config:
allow_structured_metadata: true
volume_enabled: true
retention_period: 672h # 28일 보존
compactor:
retention_enabled: true
delete_request_store: azure
ruler:
enable_api: true
storage:
type: azure
azure:
account_name: <INSERT-STORAGE-ACCOUNT-NAME>
container_name: <RULER-CONTAINER-NAME> # 실제 Azure Blob Storage 컨테이너 이름 (loki-azure-dev-ruler)
use_federated_token: true # 인증에 페더레이션 토큰 사용
alertmanager_url: http://prom:9093 # 경고를 보낼 Alertmanager의 URL (Prometheus, Mimir 등)
querier:
max_concurrent: 4
storage:
type: azure
bucketNames:
chunks: "<CHUNK-CONTAINER-NAME>" # 실제 Azure Blob Storage 컨테이너 이름 (loki-azure-dev-chunks)
ruler: "<RULER-CONTAINER-NAME>" # 실제 Azure Blob Storage 컨테이너 이름 (loki-azure-dev-ruler)
# admin: "admin-loki-devrel" # 실제 Azure Blob Storage 컨테이너 이름 (loki-azure-dev-admin)
azure:
accountName: <INSERT-STORAGE-ACCOUNT-NAME>
useFederatedToken: true # 인증에 페더레이션 토큰 사용
# Azure 워크로드 아이덴티티 정의
serviceAccount:
name: loki
annotations:
"azure.workload.identity/client-id": "<APP-ID>" # Azure AD 앱의 앱 ID
labels:
"azure.workload.identity/use": "true"
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
# 외부에서 쓰기 및 쿼리할 수 있도록 Loki 게이트웨이를 노출합니다
gateway:
service:
type: LoadBalancer
basicAuth:
enabled: true
existingSecret: loki-basic-auth
# 기본 인증을 사용하므로 카나리에 사용자 이름과 암호를 전달해야 합니다
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
# 스토리지에 minio 비활성화
minio:
enabled: false
backend:
replicas: 0
read:
replicas: 0
write:
replicas: 0
singleBinary:
replicas: 0
자리 표시자를 실제 값으로 바꾸십시오.
Loki 배포에 유효한 values.yaml
파일을 정의하는 것이 중요합니다. 잘못된 구성의 위험을 제거하기 위해 Azure에 배포할 때 염두에 두어야 할 구성 옵션을 자세히 살펴보겠습니다.
-
Loki 구성 대 Values 구성:
values.yaml
파일에는 Loki 구성 파일을 직접적으로 나타내는loki
라는 섹션이 포함되어 있습니다.- 이 섹션은 스키마, 스토리지 및 쿼리어 구성을 포함한 Loki 구성을 정의합니다.
- 청크에 대해 집중해야 할 주요 구성은 Azure 컨테이너 이름과 스토리지 계정을 정의하는
storage_config
섹션입니다. 이는 Loki에게 청크를 어디에 저장할지 알려줍니다. ruler
섹션은 Azure 컨테이너 이름과 스토리지 계정을 포함하여 룰러의 구성을 정의합니다. 이는 Loki에게 경고 및 기록 규칙을 어디에 저장할지 알려줍니다.- 전체 Loki 구성에 대한 자세한 내용은 Loki 구성 문서를 참조하십시오.
-
스토리지:
- Helm 차트가 데이터를 저장하는 위치를 정의합니다.
- Azure Blob Storage를 사용하므로 유형을
azure
로 설정합니다. - 청크 및 룰러에 대한 컨테이너 이름을 이전에 만든 컨테이너와 일치하도록 구성합니다.
azure
섹션은 스토리지 계정 이름을 지정하고useFederatedToken
을true
로 설정합니다. 이는 Loki에게 인증을 위해 페더레이션된 자격 증명을 사용하도록 지시합니다.
-
서비스 계정:
serviceAccount
섹션은 Loki가 Azure AD로 인증하는 데 사용할 페더레이션된 워크로드 아이덴티티를 정의하는 데 사용됩니다.azure.workload.identity/client-id
주석을 Azure AD 앱의 앱 ID로 설정합니다.
-
게이트웨이:
- Loki 게이트웨이가 노출되는 방식을 정의합니다.
- 이 구성에서는
LoadBalancer
서비스 유형을 사용하고 있습니다.
Loki 배포
values.yaml
파일을 만들었으므로 이제 Helm 차트를 사용하여 Loki를 배포할 수 있습니다.
-
새로 만든
values.yaml
파일을 사용하여 배포합니다:helm install --values values.yaml loki grafana/loki -n loki --create-namespace
페더레이션된 자격 증명이
system:serviceaccount:loki:loki
값으로 생성되었으므로loki
라는 네임스페이스를 만드는 것이 중요합니다. 이는loki
네임스페이스의loki
서비스 계정으로 변환됩니다. 이것은 구성 가능하지만 먼저 페더레이션된 자격 증명 파일을 업데이트해야 합니다. -
배포를 확인합니다:
kubectl get pods -n loki
Loki 파드가 실행 중인 것을 볼 수 있습니다.
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
Loki 게이트웨이 서비스 찾기
Loki 게이트웨이 서비스는 Loki 게이트웨이를 인터넷에 노출하는 로드 밸런서 서비스입니다. 여기에서 로그를 쓰고 쿼리하게 됩니다. 기본적으로 NGINX가 게이트웨이로 사용됩니다.
Loki 게이트웨이 서비스는 인터넷에 노출됩니다. 이 튜토리얼에서는 사용자 이름과 암호를 사용하여 기본 인증을 제공합니다. 자세한 내용은 인증 문서를 참조하십시오.
Loki 게이트웨이 서비스를 찾으려면 다음 명령을 실행하십시오:
kubectl get svc -n loki
외부 IP 주소를 가진 Loki 게이트웨이 서비스가 표시되어야 합니다. 이 주소를 사용하여 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
축하합니다! Helm 차트를 사용하여 Azure에 Loki를 성공적으로 배포했습니다. 마치기 전에 배포를 테스트해 보겠습니다.
Loki 배포 테스트
k6는 Loki 배포를 테스트하는 가장 빠른 방법 중 하나입니다. 이를 통해 Loki에 로그를 쓰고 쿼리할 수 있습니다. k6를 시작하려면 아래 단계를 따르십시오.
-
Loki 확장 기능이 있는 k6를 로컬 머신에 설치합니다. k6 및 xk6-loki 확장 기능 설치를 참조하십시오.
-
다음 내용으로
azure-test.js
파일을 만듭니다:import { sleep, check } from 'k6'; import loki from 'k6/x/loki'; /** * 푸시 및 쿼리 요청에 사용되는 URL * 경로는 클라이언트에 의해 자동으로 추가됩니다 * @constant {string} */ const username = '<USERNAME>'; const password = '<PASSWORD>'; const external_ip = '<EXTERNAL-IP>'; const credentials = `${username}:${password}`; const BASE_URL = `http://${credentials}@${external_ip}`; /** * 바이트 값에 대한 헬퍼 상수 * @constant {number} */ const KB = 1024; /** * 바이트 값에 대한 헬퍼 상수 * @constant {number} */ const MB = KB * KB; /** * 구성 및 Loki 클라이언트 인스턴스화 */ const conf = new loki.Config(BASE_URL); const client = new loki.Client(conf); /** * 테스트 시나리오 정의 */ export const options = { vus: 10, iterations: 10, }; export default () => { // 10개의 스트림과 800KB에서 2MB 사이의 압축되지 않은 로그로 푸시 요청 var res = client.pushParameterized(10, 800 * KB, 2 * MB); // 성공적인 쓰기 확인 check(res, { 'successful write': (res) => res.status == 204, }); // 레이블 풀에서 임의의 로그 형식 선택 let format = randomChoice(conf.labels["format"]); // 제한이 1인 즉시 쿼리 실행 res = client.instantQuery(`count_over_time({format="${format}"}[1m])`, 1) // 성공적인 읽기 확인 check(res, { 'successful instant query': (res) => res.status == 200, }); // 지난 5분 동안의 범위 쿼리 실행 및 1000개로 제한 res = client.rangeQuery(`{format="${format}"}`, "5m", 1000) // 성공적인 읽기 확인 check(res, { 'successful range query': (res) => res.status == 200, }); // 다음 반복 전에 대기 sleep(1); }; /** * 배열에서 임의의 항목을 가져오는 헬퍼 함수 */ function randomChoice(items) { return items[Math.floor(Math.random() * items.length)]; }
<EXTERNAL-IP>
를 Loki 게이트웨이 서비스의 외부 IP 주소로 바꾸십시오.이 스크립트는 Loki에 로그를 쓰고 Loki에서 로그를 쿼리합니다. 800KB에서 2MB 사이의 임의 형식으로 로그를 쓰고 지난 5분 동안 임의 형식으로 로그를 쿼리합니다.
-
테스트를 실행합니다:
./k6 run azure-test.js
그러면 테스트가 실행되고 결과가 출력됩니다. 테스트가 Loki에 로그를 쓰고 Loki에서 로그를 쿼리하는 것을 볼 수 있습니다.
이제 Microsoft Azure에서 마이크로서비스 모드로 Loki를 성공적으로 배포했으므로 다음을 탐색할 수 있습니다.