Yazar: @atilayberber
Pipeline gece 02:00’de patladı. Sabah 08:30’da satış müdürü “rapordaki rakamlar dünkü” diye mesaj attı. Siz de o an fark ettiniz. Tanıdık mı?
Fabric’te bir projeyi çalışır hale getirmek işin yarısı. Diğer yarısı, bir sorunu kullanıcıdan önce fark etmek ve nedenini hızlıca bulmak. Son aylarda Fabric’in izleme tarafı ciddi şekilde değişti: Workspace monitoring yeni bir “monitoring item” yapısına geçti, Activator ile alarm kurmak kolaylaştı, operations agent ise hataları sizin yerinize incelemeye başladı.
Bu rehberde workspace monitoring’in ne olduğunu, nasıl kurulduğunu, hangi verileri topladığını, KQL ile nasıl sorgulanacağını ve bu verilerden nasıl alarm üretileceğini uçtan uca anlatıyorum.
Kısaca: Bu yazıda neler var?
- Fabric’te izlemenin katmanları: Monitor hub, Capacity Metrics, workspace monitoring
- Monitoring item: Eventhouse, Eventstream, Activator ve operations agent
- Hangi öğeler hangi logları gönderiyor?
- Adım adım kurulum ve ön koşullar
- Hazır KQL sorguları: refresh hataları, yavaş DAX sorguları, iş geçmişi
- Alarm kurmak: KQL queryset’ten Activator’a
- Maliyet, saklama süresi, sınırlamalar ve eski sürümden geçiş
Fabric’te izlemenin üç katmanı
“İzleme” kelimesi Fabric’te birkaç farklı aracı kapsıyor. Hangisinin hangi soruyu cevapladığını bilmek, doğru aracı seçmenin ilk adımı:
| Araç | Cevapladığı soru | Kimin için? |
|---|---|---|
| Monitor hub | Şu an ne çalışıyor, ne başarısız oldu? | Geliştirici, veri mühendisi |
| Capacity Metrics app | Kapasitemi kim, ne kadar tüketiyor? Throttling var mı? | Kapasite yöneticisi |
| Workspace monitoring | Bu workspace’teki öğeler ne yaptı, ne kadar sürdü, neden hata verdi? Geçmişe dönük ve sorgulanabilir. | Ekip lideri, platform ekibi |
Monitor hub da yenileniyor: Önizlemedeki yeni sürüm iş yükleri, işler, uygulamalar, ajanlar, alarmlar ve kapasiteler için ölçekli sağlık görünümleri getiriyor. Dataflow refresh’lerinin sorgu düzeyindeki detayları da artık hub’dan çıkmadan görülebiliyor (önizleme). Ama Monitor hub “an”ı gösterir. Bir sorunun deseni, tekrarı ve kök nedeni için workspace monitoring gerekiyor.
Workspace monitoring nedir?
Workspace monitoring (önizleme), desteklenen Fabric öğelerinden log ve metrikleri toplayıp düzenleyen, isteğe bağlı bir gözlemlenebilirlik katmanı. Yeni sürümde her şey bir monitoring item üzerinden yönetiliyor. Bir monitoring item oluşturduğunuzda workspace’inize şunlar gelir:
- Eventhouse ve salt okunur bir KQL veritabanı: Logların tutulduğu yer.
- Eventstream: Telemetrinin akışını taşır; isterseniz özel bir uç noktaya (custom endpoint) da yönlendirebilirsiniz.
- Activator: Log verisinden alarm üretmek için.
- Operations agent (isteğe bağlı): Hataları sizin yerinize inceleyen yapay zekâ ajanı.
Power BI için Azure Log Analytics kullananlar için tanıdık bir deneyim; fark şu ki her şey Fabric’in içinde, KQL ile sorgulanabilir ve Real-Time Intelligence’ın tüm araçlarıyla (dashboard, alarm, ajan) doğrudan bağlantılı.
Hangi öğeler hangi verileri gönderiyor?
Kapsam her ay genişliyor. Microsoft Learn’deki güncel listeye göre:
| İş yükü | Öğe | Gönderilen veri |
|---|---|---|
| Power BI | Semantic model | Semantic model operasyon logları (sorgular, refresh’ler, hatalar) |
| Data Factory | Pipeline | Pipeline activity run logları |
| Data Factory | Copy job | Copy job çalışma detayları |
| Data Warehouse | Warehouse, SQL analytics endpoint | Sorgu çalışma logları |
| Real-Time Intelligence | Eventhouse | Metrik, komut, sorgu, ingestion, throttling ve scale-out olayları |
| Real-Time Intelligence | Eventstream | Node durumu, metrikler, hata metrikleri |
| Real-Time Intelligence | Activator | Kural bildirimleri |
| Data Engineering | GraphQL API | Metrikler ve operasyon logları |
| Mirroring | Mirrored database | Çalışma logları |
| Real-Time hub | Job events | İş olay logları |
Bir tablo, ilgili öğe ilk telemetrisini üretene kadar veritabanında görünmeyebilir. Kurulumdan hemen sonra tablo yoksa panik yapmayın; bir refresh ya da pipeline çalıştırın.
Adım adım kurulum
Ön koşullar
- Workspace bir Fabric ya da Power BI Premium kapasitesine atanmış olmalı.
- Fabric yöneticisi “Workspace admins can turn on monitoring for their workspaces” tenant ayarını açmış olmalı.
- Sizin için “Users can create Fabric items” ayarı açık olmalı. Kapalıysa Monitoring seçeneği hata vermeden pasif görünür; bu en sık karşılaşılan “neden açılmıyor?” sebebi.
- Workspace’te Admin rolünüz olmalı.
Kurulum
- Workspace’i açın ve Workspace settings > Monitoring‘e gidin.
- Hedefi seçin: Bu monitoring item’daki Eventhouse (her şey bu workspace’te kurulur) ya da başka bir monitoring item’daki Eventhouse (birden çok workspace’in telemetrisini tek yerde toplamak için; iki workspace aynı Azure bölgesinde olmalı).
- İsterseniz Eventstream’de özel bir uç nokta (custom endpoint) açın. Önizlemede bu sadece oluşturma anında yapılabiliyor.
- İsterseniz “agentic investigation” seçeneğiyle operations agent ekleyin. Bu sonradan kapatılamıyor.
- Yapılandırmayı tamamlayın ve veri toplamayı açın. Monitoring item oluşturulduğunda veri toplama kapalı gelir; bu adımı atlamak çok yaygın bir hata.
İki kararı baştan doğru verin, çünkü sonradan değiştirilemiyor: Verinin hangi Eventhouse’a gideceği ve operations agent’ın eklenip eklenmeyeceği. Ayrıca workspace monitoring geçmişe dönük veri toplamaz; sadece açtığınız andan sonraki aktiviteyi görürsünüz.
Merkezi mi, workspace bazlı mı?
Birkaç workspace’iniz varsa (örneğin geliştirme, test, üretim ya da her departman için ayrı), tek bir merkezi monitoring item’a veri göndermek genellikle daha iyi. Tek bir yerden sorgu yazar, tek bir dashboard kurarsınız. Dikkat: Veri gönderen her workspace, hedef workspace’te kendi KQL veritabanını oluşturur ve bu veritabanları hedef workspace’in 1.000 öğe sınırına sayılır.
KQL ile sorgulamak: hazır sorgular
Monitoring veritabanını sorgulamak için workspace’te en az Contributor rolü yeterli. Aşağıdaki sorguları bir KQL queryset’e kaydedip ekipçe kullanabilirsiniz. Kolon değerleri kiracınıza ve öğe türüne göre farklılık gösterebilir; ilk çalıştırmada bir take 10 ile veriye göz atıp filtreleri buna göre ayarlayın.
1. Son işlerin genel görünümü
ItemJobEventLogs
| top 100 by Timestamp desc2. Son 24 saatteki semantic model hataları
SemanticModelLogs
| where Timestamp > ago(1d)
| where Level =~ "Error"
| project Timestamp, WorkspaceName, ItemName, OperationName, ExecutingUser, EventText
| order by Timestamp desc3. En yavaş 20 DAX sorgusu
SemanticModelLogs
| where Timestamp > ago(7d)
| where OperationName == "QueryEnd"
| project Timestamp, ItemName, ExecutingUser, DurationMs, CpuTimeMs, EventText
| top 20 by DurationMs descEventText kolonu çalışan DAX sorgusunun kendisini içerir. En yavaş sorgunun hangi rapor görselinden geldiğini ApplicationContext kolonundaki rapor kimliğiyle bulabilirsiniz.
4. Saatlik sorgu yükü ve ortalama süre
SemanticModelLogs
| where Timestamp > ago(3d)
| where OperationName == "QueryEnd"
| summarize Sorgu = count(), OrtSureMs = avg(DurationMs) by bin(Timestamp, 1h), ItemName
| render timechartBu grafik, “raporlar sabah 09:00’da neden yavaş?” sorusunun cevabını genellikle tek bakışta verir: Ya sorgu sayısı o saatte zirve yapıyordur ya da aynı saatte bir refresh çalışıyordur.
Sıfırdan başlamak istemiyorsanız, Microsoft’un fabric-toolbox GitHub deposunda workspace monitoring için hazır Real-Time Dashboard ve Power BI rapor şablonları var; Fabric samples deposunda da örnek KQL sorguları bulunuyor.
İzlemeden aksiyona: alarm kurmak
Log toplamak tek başına bir şey çözmez; asıl değer, birinin doğru anda haberdar olmasında. Akış basit:
- Sorunu tespit eden KQL sorgusunu yazın ve queryset’e kaydedin (örneğin yukarıdaki hata sorgusu).
- Sorgu sonucundan bir alarm oluşturun; alarm, monitoring item’daki Activator’a bağlanır.
- Koşulu ve kanalı belirleyin: Sonuç sayısı sıfırdan büyükse e-posta ya da Teams mesajı gönder.
Başlangıç için alarm listesi
| Alarm | Kaynak | Kime? |
|---|---|---|
| Semantic model refresh hatası | SemanticModelLogs | Model sahibi |
| 10 saniyeyi aşan DAX sorgusu (saatte 5’ten fazla) | SemanticModelLogs | BI geliştirici |
| Pipeline hatası veya beklenenden uzun çalışma | Pipeline logları, ItemJobEventLogs | Veri mühendisi |
| Kapasitenin throttling’e girmesi | Kapasite olayları | Kapasite yöneticisi |
Kapasite tarafında iki yenilik daha var: Real-Time Hub’daki Capacity Operation Events (önizleme) kapasite tüketimini, süreyi ve throttling’i operasyon düzeyinde veriyor. Monitor hub’daki hata bildirimlerini yönetme özelliği (önizleme) ise hata bildirimi tanımlı tüm zamanlanmış öğeleri tek listede gösterip alıcıları tek yerden düzenlemenizi sağlıyor. Kapasite ve Copilot maliyetini bir önceki yazıda anlatmıştım; throttling alarmı o yazının doğal devamı.
Operations agent: hatayı sizin yerinize incelesin
Yeni nesil izlemenin en ilginç parçası bu. Operations agent, tanımladığınız koşulları sürekli izleyen, desen yakalayan ve insanların belirlediği sınırlar içinde aksiyon alan bir yapay zekâ ajanı. Önizlemedeki birkaç özelliği öne çıkıyor:
- Operations Agent for Pipelines: Pipeline çalışmalarını izler, hata ya da anormallik olduğunda Teams’ten haber verir.
- Investigator insights: Bir alarm sonrası ilgili veriyi analiz eder ve sonraki adımları önerir.
- Fabric Observability Insights: Pipeline hatalarını Fabric bağlamını kullanarak inceler; kök neden araştırmasının ilk turunu sizin yerinize yapar.
Benim önerim: Ajanı bir “ilk müdahale ekibi” gibi düşünün. Gece 02:00’de patlayan pipeline için sabah size “şu kaynak tablo boş geldi, bir önceki adımdaki copy job zaman aşımına uğradı” diyen bir özet hazırlaması, işin en zaman alan kısmını ortadan kaldırıyor. Kararı ve düzeltmeyi yine siz verirsiniz.
Maliyet, saklama süresi ve throttling davranışı
- Maliyet: Workspace monitoring kapasitenizden tüketir (Eventhouse ve Eventstream tüketimi). Ayrı bir fatura yok, ama bedava da değil. Kapasite planlamanıza dahil edin.
- Saklama: Varsayılan saklama süresi 30 gün. Monitoring KQL veritabanında Manage > Data policies üzerinden değiştirebilirsiniz. Önbellek (caching) süresi saklama süresinden uzun olamaz.
- Throttling: Kapasite throttling’e girdiğinde Eventstream ingestion, Eventhouse izleme, monitoring Eventhouse üzerindeki sorgular ve Real-Time Dashboard’lar çalışmaya devam eder. Ama monitoring verisini kullanan Power BI raporları ve Activator alarmları kapasite durumuna tabidir ve onlar da kısıtlanabilir. Kritik alarmlarınızı bu bilgiyle tasarlayın.
Sınırlamalar ve dikkat edilecekler
- Bir workspace için aynı anda yalnızca bir monitoring item telemetri toplayabilir.
- Monitoring veritabanı salt okunur; kendi tablolarınızı ekleyemezsiniz.
- Private Link destekleniyor. Sorun yaşarsanız Private Link’i geçici kapatıp monitoring’i açın, sonra tekrar açın.
- Kuruluşunuzda Power BI için Azure Log Analytics entegrasyonu kullanılıyorsa, iki yapıyı birlikte nasıl kullanacağınızı önceden planlayın; aynı veriyi iki yere göndermek hem maliyet hem kafa karışıklığı demek.
Eski (legacy) workspace monitoring’den geçiş
Workspace monitoring’i bir süredir kullanıyorsanız muhtemelen eski sürümdesiniz (workspace’te doğrudan bir Eventhouse veritabanı oluşturan yapı). Geçiş otomatik değil: Önce Workspace settings > Monitoring’de Log workspace activity ayarını kapatın, ardından çıkan geçiş bandından monitoring item’ı yapılandırın. Eski veri eski Eventhouse’ta kalır; yeni telemetrinin görünmesi bir saati bulabilir. Eski sürümde log türüne göre filtreleme ve Private Link desteği yoktu; yeni sürüm bu açıdan da daha iyi.
Ekip için izleme kuralları
- Her alarmın bir sahibi olsun. Kimsenin okumadığı bir kanala düşen alarm, alarm değildir.
- Az ama anlamlı alarm. Günde 50 bildirim gelen bir kanalı bir hafta sonra kimse açmaz. Eşikleri gerçek veriyle ayarlayın.
- Sorguları dokümante edin. KQL sorgularını queryset’te saklayın, her birinin ne zaman ve neden alarm ürettiğini yazın.
- Kısa bir runbook yazın. “Refresh hatası gelirse önce şuna bak” diyen yarım sayfalık bir not, gece yarısı paniğini ciddi şekilde azaltır.
- Haftalık gözden geçirme. Saatlik sorgu yükü grafiğine haftada bir bakmak, sorunları alarm üretmeden önce yakalamanızı sağlar.
Sonuç
Fabric’te izleme artık ayrı bir proje değil, platformun parçası: Monitor hub anı gösterir, workspace monitoring geçmişi ve deseni, Activator haber verir, operations agent ilk incelemeyi yapar. Kurulum birkaç dakika sürüyor; asıl iş, hangi sinyalin kimi uyandıracağına karar vermek. Bu kararı ekipçe verin, gerisini platform hallediyor.
Sizin ekibinizde bir hatayı genellikle kim ilk fark ediyor: sistem mi, kullanıcı mı? Yorumlarda ya da LinkedIn’de yazın.
Kaynaklar
- What is workspace monitoring? (Microsoft Learn)
- Enable monitoring in your workspace (Microsoft Learn)
- Semantic model operation logs (Microsoft Learn)
- What’s new in Microsoft Fabric (Microsoft Learn)
- fabric-toolbox: workspace monitoring dashboards (GitHub)
- Sending alerts from Fabric Workspace Monitoring (Chris Webb’s BI Blog)
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.