Azure Monitor sənədlərində Advanced Platform Metrics preview qeyd olundu və Azure Storage üçün enablement/usage sənədləri yeniləndi.
Bu yenilikdə vacib məqam budur ki, Azure Monitor artıq seçilmiş resurs provayderləri üçün daha granular “advanced platform metrics” qatını ayrıca ödənişli, opt-in preview kimi təqdim edir. Bu mərhələdə Azure Storage dəstəklənən əsas provayderlərdən biridir və storage account səviyyəsində container-level blob count və container-level capacity kimi daha dərin telemetriya verir. Bu, xüsusən böyük multi-tenant storage account-larda “hansı container şişir” sualına cavab tapmağı xeyli asanlaşdırır. Amma eyni zamanda latency və throttling diaqnostikası hələ də böyük ölçüdə klassik service metrics və resource logs üzərindən aparılır; advanced metrics bunu əvəz etmir, observability stack-i tamamlayır.
Əməliyyat təsiri iki istiqamətdə yüksəkdir. Birincisi capacity governance-dir: container-level capacity və object count hesablaması sayəsində chargeback/showback və hot-tenant detection daha dəqiq olur. İkincisi incident response-dur: latency spike və throttling hallarında artıq siz eyni observability modelində həm account-level və service-level latency metriklərini, həm ResponseType əsasında throttling təsnifatını, həm də resource logs-ları birləşdirə bilirsiniz. Azure Blob monitoring reference sənədi SuccessE2ELatency, SuccessServerLatency, Transactions kimi metriklərin bir dəqiqə intervalında çıxarıldığını, ApiName, GeoType, Authentication, lazım gəldikdə Tier və ResponseType kimi ölçülərlə bölünə bildiyini göstərir.
Arxitektura və Dəyişikliyin Mahiyyəti.
Burada arxitektura prinsipi belədir: Advanced Platform Metrics capacity-ə dair daha dərin görünürlük gətirir, Standard Platform Metrics isə transaction, availability, E2E latency, server latency və throttling correlation üçün əsas qalır, Resource Logs isə request-level forensic qatıdır. Storage advanced platform metrics rule modelində hazırda əsas rule type ContainerLevelCapacityMetrics-dir və bu rule ContainerUsedSize və ContainerBlobCount metriklərini emit edir. Rule-lar AllContainersFilter, ContainerPrefixFilter və ContainerSiyahıFilter ilə scope oluna bilər. Əgər siz storage account-da minlərlə container saxlayırsınızsa, prefix əsaslı seçim xərci və noise-u azaltmaq üçün praktik üsuldur.
Latency troubleshooting-də ən vacib interpretasiya qaydası SuccessE2ELatency ilə SuccessServerLatency fərqidir. Microsoft-un storage performance troubleshooting guidance-i bu fərqin böyük olması halında problemin çox vaxt şəbəkə və ya client tərəfində olduğunu, server latency-nin yüksək olduğu halda isə storage processing və ya backend saturation ehtimalının artdığını bildirir. ResponseType ölçüsü də mühümdür: ServerBusyError, ServerTimeoutError, ClientAccountBandwidthThrottlingError və ClientAccountRequestThrottlingError kimi dəyərlər sizə saturation-un hard throttling, backend busy və ya auth/network failure olduğunu ayırmağa kömək edir. Bu səviyyəli ayrım olmadan “storage yavaşdır” cümləsi əməliyyat baxımından faydasızdır.
Adım-adım Tətbiq və Konfiqurasiya.
İlk addım subscription-da Microsoft.Insights provider-inin qeydiyyatıdır; əks halda advanced metrics görünməyə bilər. Sonra storage account üçün advanced-platform-metric rule yaradılır. CLI preview komanda qrupu az storage advanced-platform-metric bu səviyyədə artıq create/list/show/update/delete əməliyyatlarını təqdim edir və AllContainersFilter, ContainerPrefixFilter, ContainerSiyahıFilter variantlarını dəstəkləyir.
az provider register -n Microsoft.Insights
# Enable advanced container-level capacity metrics for all containers
az storage advanced-platform-metric create \
-g rg-observability \
--account-name stappmetricsprod \
--enabled \
--rule-config-filter-type AllContainersFilter
# Or restrict collection to selected prefixes
az storage advanced-platform-metric create \
-g rg-observability \
--account-name stappmetricsprod \
--enabled \
--rule-config-filter-type ContainerPrefixFilter \
--rule-config-filter-values logs tenant-Real-time diaqnostika üçün metric query-ləri ApiName, GeoType və lazım gəldikdə ResponseType məntiqi ilə aparılmalıdır. Azure CLI-nin metric list nümunələri storage latency-ni ApiName üzrə bölməyi birbaşa göstərir.
RESOURCE_ID=$(az storage account show -g rg-observability -n stappmetricsprod --query id -o tsv)
# Query E2E latency by API name
az monitor metrics list \
--resource $RESOURCE_ID \
--metric SuccessE2ELatency \
--dimension ApiName
# Query server latency and transactions
az monitor metrics list \
--resource $RESOURCE_ID \
--metric SuccessServerLatency Transactions \
--filter "ApiName eq '*' and GeoType eq '*'"Logs qatını qoşmaq üçün diagnostic settings ayrıca qurulmalıdır; Microsoft-un sənədi resource logs-un default toplanmadığını, bunun üçün ayrıca diagnostic setting lazım olduğunu açıq bildirir. Blob service logs Log Analytics-ə axıdıldıqda StorageBlobLogs cədvəlində OperationName, MetricResponseType, AuthenticationType, Uri, StatusCode kimi sahələr üzərindən root-cause analizi etmək mümkündür.
StorageBlobLogs
| where TimeGenerated > ago(30m)
| summarize count(), p95Duration=percentile(DurationMs, 95)
by OperationName, MetricResponseType, AuthenticationType, StatusCode
| order by p95Duration descAlerting strategiyası bir metrikdən çox kombinə edilmiş signal üzərində qurulmalıdır. Azure Monitor metric alert documentation göstərir ki, bir storage account üçün eyni alert rule üzərində həm Transactions, həm də SuccessE2ELatency kimi çoxşərtli model qurmaq olar və dimension-lar fərqli metriklərdə eyni dəyərə uyğunlaşdırılmalıdır. Praktik dizayn belədir: GetBlob üçün latency alert, Transactions + throttling dimension trend alert və ayrıca capacity alert.
Mümkün Problemlər və Troubleshooting Ssenariləri.
Birinci edge case “advanced metrics enabled but nothing shows up” halıdır. Microsoft-un storage doc-u bunun ilk yoxlamasının Microsoft.Insights provider registration olduğunu deyir. İkinci yoxlama isə düzgün filter scope-dur; məsələn ContainerPrefixFilter-də prefix-lər səhvdirsə, siz faktiki olaraq heç bir data toplamırsınız. Üçüncü yoxlama isə resource-level selection-dir: bəzən komandalar blob service metrics əvəzinə storage account namespace-də yanlış qrafiki oxuyur.
İkinci edge case “latency yüksəkdir, amma səbəb storage deyil” ssenarisidir. Əgər SuccessE2ELatency yüksək, SuccessServerLatency isə aşağıdırsa, Microsoft-un troubleshooting guidance-inə görə problem çox vaxt şəbəkə və client layer-də axtarılmalıdır. Əksinə, SuccessServerLatency də yüksəlibsə və ResponseType ServerBusyError və ya ServerTimeoutError göstərirsə, bu daha çox service-side saturation, hot partition və ya backend contention siqnalıdır. ClientAccountRequestThrottlingError və ClientAccountBandwidthThrottlingError isə account scalability limitlərinə dəyməni göstərir.
Üçüncü edge case log freshness misunderstanding-dir. Əgər siz hələ klassik Storage Analytics log-larından istifadə edirsinizsə, Microsoft bildirir ki, log data-nın $logs container-ə görünməsi bir saata qədər gecikə bilər. Real-time troubleshooting üçün bu mənbə kifayət deyil; instant decision üçün Azure Monitor metrics, yaxın-real-time forensic üçün resource logs istifadə olunmalıdır.
Ən Yaxşı Təcrübələr.
Advanced metrics-i yalnız lazım olan container scope-da aktivləşdirin. Capacity analytics, latency analytics və request forensic-i ayrı panel və query-lərlə saxlayın. Alert rule-ları API name və response type üzrə dimension-aware qurun. Capacity growth üçün advanced metrics, performance üçün standard metrics, root cause üçün logs istifadə edin. Və Storage Analytics klassik log-larını yaxın-real-time monitorinq üçün deyil, tarixi analiz üçün saxlayın.