Azure Log Analytics Workspace Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

Bulut altyapısı yönetiminde en can sıkıcı konulardan biri izleme ve log yönetimidir. Onlarca sanal makine, yüzlerce servis ve bunların ürettiği gigabaytlarca log verisi… Azure Log Analytics Workspace tam da bu kaosun ortasında bir düzen noktası oluşturmanı sağlıyor. Bu yazıda sıfırdan kurulum yaparak, gerçek dünya senaryolarında nasıl kullanacağını adım adım anlatacağım.

Log Analytics Workspace Nedir ve Neden Önemlidir?

Azure Log Analytics Workspace, Azure Monitor’ün temel bileşenlerinden biridir. Farklı kaynaklardan gelen log verilerini merkezi bir noktada toplar, saklar ve sorgulamanı sağlar. Bunu basit bir log deposu olarak düşünme; aynı zamanda güçlü bir sorgu motoru olan KQL (Kusto Query Language) ile bu verileri analiz edebilirsin.

Bir workspace’in toplayabileceği veriler şunlardır:

  • Azure sanal makinelerinden gelen sistem ve uygulama logları
  • Azure Kubernetes Service (AKS) pod logları
  • Azure Activity Log verileri
  • Güvenlik olayları (Security Events)
  • Network akış logları
  • Özel uygulama logları (custom logs)
  • Linux syslog verileri

Gerçek hayattan bir örnek vereyim: Bir e-ticaret şirketinin 50 sanal makinesi var ve her biri farklı loglar üretiyor. Bir güvenlik ihlali şüphesi oluştuğunda bu makinelere tek tek bağlanıp log incelemek yerine, tek bir sorgu ile tüm makinelerin authentication loglarını saniyeler içinde analiz edebilirsin. İşte Log Analytics Workspace’in pratik değeri tam olarak buradan geliyor.

Ön Gereksinimler

Kuruluma geçmeden önce şunların hazır olması gerekiyor:

  • Aktif bir Azure aboneliği
  • Subscription üzerinde Contributor veya Owner rolü
  • Azure CLI (tercihen 2.40.0 ve üzeri) veya Azure PowerShell modülü
  • Hangi region’da çalışacağını ve veri saklama gereksinimlerini bilmek

Azure CLI versiyonunu kontrol etmek için:

az --version
az login
az account show

Eğer birden fazla subscription’ın varsa, doğru olanı seç:

az account list --output table
az account set --subscription "Subscription-ID-veya-Adi"

Resource Group Oluşturma

Log Analytics Workspace için ayrı bir resource group oluşturmak iyi bir pratik. Monitoring kaynaklarını diğer iş yüklerinden ayırman, yönetimi kolaylaştırır ve maliyet takibini basitleştirir.

# Resource group oluştur
az group create 
  --name rg-monitoring-prod 
  --location westeurope 
  --tags Environment=Production Purpose=Monitoring Owner=SysAdminTeam

# Oluşturulduğunu doğrula
az group show --name rg-monitoring-prod --output table

Etiketleri (tags) atlamayı alışkanlık haline getirme. Aylık fatura geldiğinde “bu kaynaklar ne işe yarıyordu?” sorusunu sormak istemezsin.

Log Analytics Workspace Kurulumu

Azure CLI ile Kurulum

En hızlı ve tekrarlanabilir yöntem CLI üzerinden kurulumdur. Production ortamında her zaman infrastructure as code yaklaşımını tercih etmeni tavsiye ederim.

# Log Analytics Workspace oluştur
az monitor log-analytics workspace create 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --location westeurope 
  --sku PerGB2018 
  --retention-time 90 
  --tags Environment=Production Purpose=Monitoring

# Workspace ID ve key bilgilerini al (ileride lazım olacak)
WORKSPACE_ID=$(az monitor log-analytics workspace show 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --query customerId 
  --output tsv)

WORKSPACE_KEY=$(az monitor log-analytics workspace get-shared-keys 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --query primarySharedKey 
  --output tsv)

echo "Workspace ID: $WORKSPACE_ID"
echo "Workspace Key: $WORKSPACE_KEY"

Burada birkaç önemli parametreyi açıklayayım:

  • –sku PerGB2018: Günümüzde en yaygın kullanılan fiyatlandırma modeli. GB başına ücretlendirme yapılır.
  • –retention-time 90: Logları 90 gün sakla. Varsayılan 30 gündür, compliance gereksinimlerine göre 730 güne kadar artırabilirsin.
  • –workspace-name: İsimlendirme konventionı belirle ve buna sadık kal. Ben law-{purpose}-{env}-{number} formatını kullanıyorum.

Azure PowerShell ile Kurulum

Windows ortamında çalışıyorsan veya PowerShell tabanlı otomasyon script’lerin varsa bu yöntemi kullanabilirsin:

# Az modülünün güncel olduğunu kontrol et
Import-Module Az.OperationalInsights

# Login
Connect-AzAccount

# Workspace oluştur
$WorkspaceParams = @{
    ResourceGroupName = "rg-monitoring-prod"
    Name              = "law-monitoring-prod-001"
    Location          = "westeurope"
    Sku               = "PerGB2018"
    RetentionInDays   = 90
    Tag               = @{
        Environment = "Production"
        Purpose     = "Monitoring"
        Owner       = "SysAdminTeam"
    }
}

New-AzOperationalInsightsWorkspace @WorkspaceParams

# Workspace bilgilerini al
$Workspace = Get-AzOperationalInsightsWorkspace `
    -ResourceGroupName "rg-monitoring-prod" `
    -Name "law-monitoring-prod-001"

$WorkspaceKeys = Get-AzOperationalInsightsWorkspaceSharedKeys `
    -ResourceGroupName "rg-monitoring-prod" `
    -Name "law-monitoring-prod-001"

Write-Output "Workspace ID: $($Workspace.CustomerId)"
Write-Output "Primary Key: $($WorkspaceKeys.PrimarySharedKey)"

Sanal Makineleri Workspace’e Bağlama

Workspace hazır, şimdi asıl iş başlıyor. Azure VM’lerden log toplamak için Log Analytics Agent (MMA/OMS Agent) veya daha modern yaklaşım olan Azure Monitor Agent (AMA) kullanabilirsin. Microsoft, Log Analytics Agent’ı 2024 sonu itibarıyla deprecated etti, bu yüzden yeni kurulumlar için AMA kullanmanı öneriyorum.

Linux VM’ye Azure Monitor Agent Kurulumu

# VM'nin resource ID'sini al
VM_RESOURCE_ID=$(az vm show 
  --resource-group rg-production 
  --name vm-web-01 
  --query id 
  --output tsv)

# Azure Monitor Agent extension'ını yükle
az vm extension set 
  --resource-group rg-production 
  --vm-name vm-web-01 
  --name AzureMonitorLinuxAgent 
  --publisher Microsoft.Azure.Monitor 
  --version 1.0 
  --enable-auto-upgrade true

# Extension durumunu kontrol et
az vm extension show 
  --resource-group rg-production 
  --vm-name vm-web-01 
  --name AzureMonitorLinuxAgent 
  --query "provisioningState" 
  --output tsv

Data Collection Rule (DCR) Oluşturma

AMA kullanırken logların nereden toplanacağını ve nereye gönderileceğini Data Collection Rule ile tanımlarsın. Bu yaklaşım çok daha granüler bir kontrol sağlıyor.

# DCR JSON tanımını oluştur
cat > dcr-linux-syslog.json << 'EOF'
{
  "location": "westeurope",
  "properties": {
    "dataSources": {
      "syslog": [
        {
          "streams": ["Microsoft-Syslog"],
          "facilityNames": [
            "auth",
            "authpriv",
            "cron",
            "daemon",
            "kern",
            "syslog"
          ],
          "logLevels": [
            "Warning",
            "Error",
            "Critical",
            "Alert",
            "Emergency"
          ],
          "name": "syslogBase"
        }
      ]
    },
    "destinations": {
      "logAnalytics": [
        {
          "workspaceResourceId": "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/rg-monitoring-prod/providers/Microsoft.OperationalInsights/workspaces/law-monitoring-prod-001",
          "name": "lawDestination"
        }
      ]
    },
    "dataFlows": [
      {
        "streams": ["Microsoft-Syslog"],
        "destinations": ["lawDestination"]
      }
    ]
  }
}
EOF

# DCR oluştur
az monitor data-collection rule create 
  --resource-group rg-monitoring-prod 
  --name dcr-linux-syslog-prod 
  --rule-file dcr-linux-syslog.json

# DCR'yi VM'ye associate et
az monitor data-collection rule association create 
  --name dcr-assoc-vm-web-01 
  --resource $VM_RESOURCE_ID 
  --rule-id $(az monitor data-collection rule show 
    --resource-group rg-monitoring-prod 
    --name dcr-linux-syslog-prod 
    --query id --output tsv)

KQL ile Log Sorgulama

Log Analytics’in en güçlü özelliği KQL sorgu dilidir. Birkaç pratik örnek verelim.

Temel Sorgular

Azure portalındaki Log Analytics workspace sayfasında “Logs” bölümüne gidip şu sorguları çalıştırabilirsin:

// Son 1 saatteki tüm Syslog kayıtları
Syslog
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc
| take 100

// Sadece error ve üzeri seviye loglar
Syslog
| where TimeGenerated > ago(24h)
| where SeverityLevel in ("err", "crit", "alert", "emerg")
| summarize Count = count() by Computer, Facility, SeverityLevel
| order by Count desc

// Başarısız SSH login denemeleri
Syslog
| where TimeGenerated > ago(24h)
| where Facility == "auth"
| where SyslogMessage contains "Failed password"
| extend IPAddress = extract(@"from (d+.d+.d+.d+)", 1, SyslogMessage)
| summarize AttemptCount = count() by IPAddress, Computer
| where AttemptCount > 10
| order by AttemptCount desc

Bu son sorgu, brute force saldırı tespiti için gerçek hayatta kullanabileceğin bir örnek. 10’dan fazla başarısız giriş denemesi yapan IP adreslerini listeliyor.

Alerts Yapılandırması

Log toplayıp sorgulayabilmek güzel ama asıl değer, kritik durumlar oluştuğunda otomatik uyarı almaktır.

# Alert action group oluştur (email bildirimi için)
az monitor action-group create 
  --resource-group rg-monitoring-prod 
  --name ag-sysadmin-oncall 
  --short-name sysadmin 
  --action email 
    oncall-engineer 
    [email protected]

# Scheduled query alert oluştur
az monitor scheduled-query create 
  --resource-group rg-monitoring-prod 
  --name alert-brute-force-ssh 
  --scopes "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/rg-monitoring-prod/providers/Microsoft.OperationalInsights/workspaces/law-monitoring-prod-001" 
  --condition "count 'Syslog | where Facility == "auth" | where SyslogMessage contains "Failed password" | summarize count()' greater than 50" 
  --condition-query "Syslog | where Facility == 'auth' | where SyslogMessage contains 'Failed password'" 
  --evaluation-frequency 5m 
  --window-size 15m 
  --severity 2 
  --action-groups "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/rg-monitoring-prod/providers/microsoft.insights/actionGroups/ag-sysadmin-oncall" 
  --description "15 dakika icinde 50'den fazla basarisiz SSH login denemesi tespit edildi"

Workspace Erişim Kontrolü

Birden fazla ekibin aynı workspace’i kullandığı senaryolarda erişim kontrolü kritik önem taşır. Log Analytics iki farklı erişim modunu destekler.

RBAC ile Erişim Yönetimi

# Bir kullanıcıya sadece okuma yetkisi ver
az role assignment create 
  --role "Log Analytics Reader" 
  --assignee "[email protected]" 
  --scope "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/rg-monitoring-prod/providers/Microsoft.OperationalInsights/workspaces/law-monitoring-prod-001"

# Bir service principal'a katkıcı yetkisi ver (CI/CD pipeline için)
az role assignment create 
  --role "Log Analytics Contributor" 
  --assignee-object-id {SERVICE_PRINCIPAL_OBJECT_ID} 
  --assignee-principal-type ServicePrincipal 
  --scope "/subscriptions/{SUBSCRIPTION_ID}/resourceGroups/rg-monitoring-prod/providers/Microsoft.OperationalInsights/workspaces/law-monitoring-prod-001"

Rolleri açıklayayım:

  • Log Analytics Reader: Workspace’i ve logları okuyabilir, sorgu çalıştırabilir, alert görebilir. Yazma yetkisi yoktur.
  • Log Analytics Contributor: Workspace yapılandırmasını değiştirebilir, yeni data source ekleyebilir, solution yönetebilir.
  • Monitoring Reader: Azure Monitor genelinde okuma yetkisi verir.
  • Monitoring Contributor: Alert, action group ve diğer monitor kaynaklarını yönetebilir.

Maliyet Yönetimi

Log Analytics’in maliyeti öngörülemeyen bir şekilde artabilir. Bunu kontrol altında tutmak için birkaç strateji var.

Günlük Cap (Data Volume Cap) Ayarlama

# Günlük veri alımını 10 GB ile sınırla
az monitor log-analytics workspace update 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --quota 10

# Mevcut kullanımı kontrol et (KQL sorgusu)
# Bu sorguyu portal üzerinde çalıştır:
# Usage
# | where TimeGenerated > ago(7d)
# | where IsBillable == true
# | summarize TotalGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d)
# | order by TimeGenerated desc

Günlük cap’i dikkatli ayarla. Limit aşıldığında o güne ait logların alınması durabilir ve bu güvenlik olaylarının gözden kaçmasına yol açabilir. Uyarı tabanlı bir limit için Azure Monitor Alerts kullanmak daha güvenlidir.

Veri Saklama Optimizasyonu

Tüm tabloları aynı süre saklamak zorunda değilsin. Kritik güvenlik loglarını uzun, debug loglarını kısa tutabilirsin:

# Belirli bir tablo için saklama süresini değiştir
az monitor log-analytics workspace table update 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --name SecurityEvent 
  --retention-time 365

# Syslog tablosunu 30 gün tut
az monitor log-analytics workspace table update 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --name Syslog 
  --retention-time 30

Gerçek Dünya Senaryosu: Multi-Environment Monitoring

Büyük bir organizasyonda genellikle Development, Staging ve Production ortamları ayrı workspace’lerde yönetilir. Ancak merkezi güvenlik izlemesi için tüm ortamların loglarını tek bir workspace’e göndermek isteyebilirsin.

#!/bin/bash
# Tüm ortamlar için workspace oluşturan script

ENVIRONMENTS=("dev" "staging" "prod")
LOCATION="westeurope"
RESOURCE_GROUP="rg-monitoring-central"

az group create --name $RESOURCE_GROUP --location $LOCATION

for ENV in "${ENVIRONMENTS[@]}"; do
  WORKSPACE_NAME="law-monitoring-${ENV}-001"
  
  # Retention sürelerini ortama göre ayarla
  if [ "$ENV" == "prod" ]; then
    RETENTION=365
  elif [ "$ENV" == "staging" ]; then
    RETENTION=90
  else
    RETENTION=30
  fi
  
  echo "Olusturuluyor: $WORKSPACE_NAME (Retention: ${RETENTION} gun)"
  
  az monitor log-analytics workspace create 
    --resource-group $RESOURCE_GROUP 
    --workspace-name $WORKSPACE_NAME 
    --location $LOCATION 
    --sku PerGB2018 
    --retention-time $RETENTION 
    --tags Environment=$ENV Purpose=Monitoring
    
  echo "$WORKSPACE_NAME basariyla olusturuldu."
done

Bu yaklaşımda her ortam kendi workspace’ine logları yollarken, güvenlik ekibi yalnızca production workspace’ini yakından takip eder. Cross-workspace sorgular için KQL’de workspace() fonksiyonunu kullanabilirsin:

// Birden fazla workspace'te sorgu çalıştır
union
  workspace("law-monitoring-prod-001").SecurityEvent,
  workspace("law-monitoring-staging-001").SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize FailedLogins = count() by Computer, WorkspaceName = TenantId

Diagnostic Settings ile Azure Servislerini Bağlama

Azure’un kendi servisleri de (Key Vault, App Service, SQL Database vb.) Log Analytics’e log gönderebilir. Bu yapılandırmayı Diagnostic Settings üzerinden yaparsın:

# Azure Key Vault için diagnostic settings aktif et
KEY_VAULT_ID=$(az keyvault show 
  --name kv-uretim-secrets 
  --resource-group rg-production 
  --query id 
  --output tsv)

WORKSPACE_ID=$(az monitor log-analytics workspace show 
  --resource-group rg-monitoring-prod 
  --workspace-name law-monitoring-prod-001 
  --query id 
  --output tsv)

az monitor diagnostic-settings create 
  --name diag-keyvault-to-law 
  --resource $KEY_VAULT_ID 
  --workspace $WORKSPACE_ID 
  --logs '[{"category": "AuditEvent", "enabled": true}]' 
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

Artık Key Vault’a yapılan tüm erişimler (kim hangi secret’a erişti, hangi key kullanıldı) Log Analytics’te görünür hale gelir. Compliance açısından bu son derece değerli bir yapılandırmadır.

Workspace’in Sağlığını İzleme

Workspace’in kendisinin de izlenmesi gerekiyor. Veri alımı durdu mu, agent’lar heartbeat gönderiyor mu gibi soruları yanıtlamak için:

// Son 5 dakikada heartbeat gondermeyen makineler
Heartbeat
| where TimeGenerated > ago(5m)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(5m)
| order by LastHeartbeat asc

// Son 24 saatte veri alim ozeti
Usage
| where TimeGenerated > ago(24h)
| where IsBillable == true
| summarize TotalGB = round(sum(Quantity) / 1024, 2) by DataType
| order by TotalGB desc

Bu sorguları scheduled alert olarak yapılandırırsan, herhangi bir makine 5 dakikadan fazla heartbeat göndermediğinde hemen haberdar olursun.

Sonuç

Azure Log Analytics Workspace, dağınık bir Azure altyapısını merkezi olarak izlemek için güçlü ve esnek bir çözüm. Bu yazıda ele aldığımız konuları özetlersek:

  • Resource group ve workspace oluşturmayı hem CLI hem de PowerShell üzerinden gördük
  • Azure Monitor Agent kurulumu ve Data Collection Rule yapılandırması ile modern log toplama yaklaşımını uyguladık
  • KQL ile anlamlı sorgular yazarak ham log verilerini eyleme dönüştürülebilir bilgiye çevirdik
  • Alert yapılandırması ile proaktif izleme kurguladık
  • RBAC ile erişim kontrolünü doğru şekilde ayarladık
  • Maliyet optimizasyonu için günlük cap ve tablo bazlı retention stratejisi geliştirdik

Başlangıç için aklında şunu tut: Workspace kurmak kolay, doğru yapılandırmak beceri ister. Önce hangi verileri toplamak istediğini net tanımla, sonra buna göre DCR ve alert yapılarını kur. Her şeyi varsayılan ayarlarla toplamaya başlarsan hem maliyetin patlar hem de önemli logları gürültü içinde kaybedersin.

Bir sonraki adım olarak Azure Sentinel (Microsoft Sentinel) ile bu workspace’i güvenlik bilgi ve olay yönetimi (SIEM) platformuna dönüştürmeyi inceleyebilirsin. Log Analytics temeli sağlam kurulduktan sonra Sentinel entegrasyonu oldukça pürüzsüz ilerliyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir