Merhaba,
Bu makalede Huawei OceanStor storage cihazı Pool Havuzları içinde oluşturulan File System objelerinin monitör edilmesini anlatıyor olacağım.
Öncelikle File System alanlarının neler olduğunu teknik olarak kısaca anlamaya çalışalım. Storage cihazları en temelinde üzerine fiziksel ve adet olarak yüksek kapasitede disklerin bulunduğu depolama cihazlarıdır.
İzleme yapacağımız cihaz üzerindeki mimariyi de 2 yönden ele alarak tanıyabiliriz.
- Fiziksel Katman (Raid + Blok Sanallaştırma)
Bu katman teknik olarak Disk Domaini, CK(Chunk), CKG(ChunkGroup), Extent, Grain gibi bileşenlerden oluşmaktadır. Bizim izlemeye çalışacağımız File System yapısına bu katmandan bakarsak aşağıdaki gibi görebiliriz.
Bu bakışı fiziksel katmandan mantıksal katmana doğru bir yaklaşım olarak düşünebilirsiniz.
Disk Domain
└──> CK (Chunk)
└──> CKG (Chunk Group)
└──> Extent
└──> Grain
└──>> File System
- NAS (File System Servis Objeleri) Katmanı
Bu katmanda Pool Havuzu, File System, Dtree(Directory Tree), Quota, Share(NFS,CIFS), Snapshot gibi mantıksal dosya sistemi objelerini görebilirsiniz.
Pool Havuzu; Bir önceki maddede açıkladığımız Disk Domain objeleri üzerinde oluşturulan mantıksal alanlarken, File System ise; Pool içinde oluşturulabilen depolama alanlarıdır.
Yine burada izlemek istediğimiz File System yapısına bu katmandan bakarsak aşağıdaki gibi hiyerarşi görebiliriz.
Disk Domain
└──> Storage Pool
└──>> File System
└──> Dtree
├──> Quota
├──> Share
└──> Snapshot
Özetle izleyeceğimiz File System objeleri storage üzerindeki Pool Havuzu içinde oluşturulabilen ve kapasiteleri belli olan mantıksal depolama alanlarıdır.
Bu izlemeyi teknik olarak Pull Metodu + Rest API + Zabbix Discovery kullanarak dinamik bir şekilde gerçekleştireceğiz. Yeni bir File System objesi oluşturulduğunda tasarladığımız izleme kurgusu bunu otomatik olarak keşfederek izlemeye dahil edecek.
Makake İçeriği
1-REST API Doküman Analizi
Storage üreticisinden temin ettiğimiz OceanStor REST Interface Reference dokümanını analiz ederek başlıyoruz. İzleyeceğimiz storage cihazının marka, model ve yazılım + API versiyonu bu doküman ile tam uyumlu olmalıdır ve üreticiden official olarak temin edilmesi önemlidir.
Bu doküman oldukça uzun ve detaylı (3.504 sayfa) olduğundan analizimizde zaman kazanmak için Prompt Engineering yöntemini kullanıyoruz. Siz de kullandığınız bir AI Tool’undan destek alabilirsiniz ben makale boyunca Anthropic / Claude kullanıyor olacağım. Dokümanı analiz etmesi için AI Tool’a upload ediyorum.
Buradaki en önemli kısım AI ile konuşurken izlemeye çalıştığınız hedef cihaza ve yönettiğiniz monitoring tool’una ne kadar hakim olursanız sonuca çok daha kısa yoldan ve optimize şekilde ulaşmış olursunuz.
- İzleme Ürünü : Zabbix (Versiyon 7 LTS)
- İzleme Yöntemi: Rest API (User, Password, Token+SessionID)
- İzlenecek Storage Cihazı: Huawei OceanStor 5XXX Serisi
Bağlantı yöntemi olarak Huawei Storage cihazı dataları doğrudan (Basic User + Password) erişimine açık değildir. Bu nedenle Rest API ile doğrudan HTTP item ile data çekip kullanamıyoruz.
Her sorguda Raw Data’ya erişebilmek için User ve Şifre kullanarak elde ettiğimiz SessionID ve Token’ı kullanacak bir Script item’a ihtiyacımız olduğunu API dokümanından anlıyoruz.
Buna benzer item örneklerini Zabbix Official Template ve dokümanlar içerisinde sıkça görebilirsiniz ve inceleyebilirsiniz.
2-File System Raw Data Script Item
Rest API dokümanı analiz ettirdiğimiz AI ajanından bize File System objelerine ait dataları JSON formatında döndüren bir Script item hazırlamasını istiyorum.
Bu item’ı ekleyebilmek için de Zabbix’e Huawei Storage’i bir host olarak ekliyorum.

Host eklerken interface olarak doğrudan Storage IP adresini yazıp ICMP Template ile ekleyebilirsiniz ancak ben sadece API Call adımlarına odaklanmak için Zabbix Local Host’u interface olarak kabul ediyorum.
Host Macros alanına API içerisinde kullanacağım credential bilgilerini Zabbix’in Macro formatında yazıyorum ve yanlarına da kısa açıklamalarını ekliyorum.

Ardından bu Host içine Scritp tipinde bir item tanımı yapıyorum. Bu item içindeki alanların tanımları aşağıdaki gibidir.

- Name : Huawei FS Inventory Raw
- Type : Script
- Key : huawei.fs.inventory.raw
- Type of information : Text
- Script : AI Tarafından oluşturulan Script item
- Update interval : 15m
* Doğru Script AI ile birkaç konuşma ve deneme sonrası mümkün olmaktadır.
Bu item bizim File System data objelerini JSON formatında 15 dakika aralıklar ile çekeceğimiz ana item objemizdir. Şimdi Test ve ardından Get value butonuna basarak sonucuna bakalım.

Value alanında gelen Raw datayı JSON görüntüleme alanına alıp kontrol ediyorum. 59 adet veri içeren bir data seti elde etmiş olduk. Şimdi bunların içeriğini anlamaya çalışalım.

Bu data içeriklerinin ne anlama geldiğini dokümanı okuyan AI Agent’a sorup yanıtlarını yanına yazmasını istiyorum. Dokümana göre tüm detayları bana aşağıdaki gibi bir tabloda sunuyor.
| Alan | Değer | Açıklama |
|---|---|---|
| ID | 1 | Filesystem benzersiz ID |
| NAME | test | Filesystem adı |
| HEALTHSTATUS | 1 | Sağlık: 1=Normal, 2=Faulty |
| RUNNINGSTATUS | 27 | Durum: 27=Online, 28=Offline |
| SUBTYPE | 0 | FS alt tipi |
| ALLOCTYPE | 1 | Tahsis tipi: 1=Thick |
| CAPACITYTHRESHOLD | 90 | Uyarı eşiği (%) |
| PARENTNAME | StoragePool001 | Bağlı Storage Pool |
| CAPACITY_SECTORS | 20971520 | Toplam kapasite (sektör) |
| CAPACITY_BYTES | 10737418240 | Toplam kapasite (byte) ≈ 10 GB |
| ALLOCCAPACITY_SECTORS | 0 | Kullanılan (sektör) |
| ALLOCCAPACITY_BYTES | 0 | Kullanılan (byte) |
| AVAILABLECAPCITY_SECTORS | 16776896 | Boş alan (sektör) *typo |
| AVAILABLECAPCITY_BYTES | 8589770752 | Boş alan (byte) ≈ 8 GB |
| UTILIZATION_PERCENT | 0 | Kullanım oranı (%) |
Ancak bu dataları Storage üzerinden de kontrol ederek emin olmakta fayda var ve buradaki “test” isimli File System objesinin kapasitesini JSON ile dönen datalarını Storage üzerindeki veriler ile de karşılaştırıyorum. Ardından kullanacağım alanları netleştiriyorum.
Aşağıdaki 4 alan benim izlemek istediğim durum için yeterli olacak.
“CAPACITY_BYTES” => Toplam Kapasite Alanını (B) gösteriyor, Storage üzerinden teyit edildi ✔
“AVAILABLECAPCITY_BYTES” => Free Kapasite Alanını (B) gösteriyor, Storage üzerinden teyit edildi ✔
“PARENTNAME” => File System objesinin bağlı olduğu Pool Havuz adı
“NAME” => File System Objesinin Adı
“ID” => File System Objesinin benzersiz ID’si (item create ederken kullanacağız)
3-Dependent Discovery Rule Tanımlama
Şimdi Huawei FS Inventory Raw item’ından bir Dependent Discovery kuralı oluşturalım ve bu data seti her geldiğinde otomatik olarak keşif yöntemi ile dataları ayrıştırarak zahmetsizce alalım.
Raw data item’ın solundaki 3 noktaya tıklıyorum ve Create dependent discovery rule diyerek tanımlamaya başlıyorum.

Açılan ekranda Master item Huawei FS Inventory Raw master item’a bağlı olduğundan otomatik olarak geliyor. (Yanındaki … nokta kısmından create ettiğimiz için)

LLD macros alanına JSON içinde kullanmaya karar verdiğim 2 kapasite parametresi için Macro’ları tanımlıyorum. Bu tanımlar bizim JSON içindeki verileri çekmemizi kolaylaştırmış olacak ve item prototype oluştururken kullanabilmemizi sağlayacak parametre ve JSON eşleşmeleri alanıdır.
Aslında Raw olarak gelen data setindeki bir data’yı Zabbix içinde kullanabileceğim formada map’liyorum veya convert ediyorum gibi düşünebilirsiniz.

Ardından Add diyerek tanımladığım Discovery kuralını ekliyorum.

4-Item Prototype (Total Capacity)
Şimdi Item Prototype kısmına geçelim ve bu Discovery Rule’a bir prototype item ekleyelim.

Ekranın sağ üst kısmından Create item prototype kısmından ekleyelim.

Oluşturacağımız Item; Dependent tipinde olup Huawei FS Inventory Raw olan ana item’a bağlı olacak. Key alanı ise her File System objesi’nin benzersiz ID’si ile unique bir şekilde oluşacak. Zabbix’de kural gereği item key’lerin benzersiz olması gereklidir.
Bizde bu benzersizliği Key alanına yazdığımız String tanımlama ve içindeki [{#ID}] dinamik parametresi ile sağlıyoruz.

Tags kısmına Latest Data ekranında File System objelerini kolay bulabilmek için bir Tag ekliyorum.

Preprocessing adımında ID ile CAPACITY_BYTES alanını JSON Path üzerinde eşleştiriyorum ve $[0] ile bu eşleşmenin ilk elemanının datasını alıyorum.
$.data[?(@.ID == ‘{#ID}’)].CAPACITY_BYTES
Preprocessing alanında JSON Path veya Java Script kodu ile esnek bir şekilde gelen datayı item’a ait ID ile eşleştirebilirsiniz. JS kodu için AI zaten öneride bulunacaktır ben burada JSONPath ile ilerliyorum.

Item prototype eklendi.

Şimdi Discovery Rule Execute edelim ve dataların gelip gelmediğini kontrol edelim.

Latest Data ekranına geçip kontrol ettiğimde Storage üzerindeki File System objelerini doğru bir şekilde geldiğini görüyorum. Oluşturduğum Tag ve Item isimlendirmesi de olması gerektiği gibi.
Örnek olması için Test isimli File System verilerini görebilirsiniz. Bu Storage üzerinde oluşturulmuş 3 adet Test isimli File System objesi mevcut ve Total Capacity bilgileri de Storage üzerinden teyit edilerek doğrulandı.

5-Item Prototype (Free Available Capacity)
Şimdi aynı şekilde Available Capacity File System item’ını da ekleyelim. İlk item’dan bir Clone alarak hızlıca yapabilirsiniz sadece Key alanının adını ve preprocessing içindeki JSONPath‘i güncellemeyi unutmayın.

JSON işleme alanını da güncelliyoruz.
$.data[?(@.ID == ‘{#ID}’)].AVAILABLECAPCITY_BYTES

Toplamda 2 tane item prototype ekledik. Key alanlarının benzersiz olduğunu görebilirsiniz kontrol etmeyi unutmayın.

Latest data ekranından kontrol ettiğimde Available kapasite bilgisinin de Bytes cinsinden geldiğini görüntülüyorum.

6-Calculated Item Prototype (Used Capacity)
Şimdi elimizdeki Total ve Free kapasite data’ları ile Calculated Used kapasite item oluşturalım. Elimizdeki iki datayı matematiksel işleme dahil ederek yeni bir item oluşturacağız.
Used = Total – Free

7-Calculated Item Prototype (Utilization %)
Yine elimizdeki Total ve Free kapasite bilgileri ile Calculated Utilization % olacak bir item oluşturalım. Elimizdeki iki datayı matematiksel işlem (formula alanındaki gibi) ile kullanarak yeni bir item oluşturmaya devam ediyoruz.
Used Utilizasyon % = Used / Total * 100

Latest data ekranından hem normal hem de calculated tipindeki tüm item’ları görüntülüyorum. Calculated olanların Tag alanına Type=Calculated olarak ayrıca bir Tag de ekledim.

Item detaylarına da aşağıdaki gibi göz atabilirsiniz.

Artık Utilization item prototype’ına solundaki (…) nokta alanından Create Trigger Prototype diyerek bir Trigger tanımlayıp File System objelerinin Utilizasyon alarmlarını tanımlayabilirsiniz. Bloğumda bununla ilgili çok fazla örnek olduğu için Trigger tanımlamasını detaylarına inerek uzun uzadıya anlatmadan bu makalenin ana konusunu burada tamamlıyorum.

8-Sonuç
Aşağıdaki hiyeraşik yapıda nasıl bir kurgulama ile izleme yaptığımızı analiz edebilirsiniz. Raw Data, Discovery Rule, Item Prototype ve Calculated item gibi kavramlar Zabbix üzerinde birbirine doğrudan bağlı ve mantığı oldukça basit bir kurgudur. Bunları olması gerektiği kadar kullanarak hem izlediğimiz cihaza minimum API Call yapmış oluyoruz hem de daha az karmaşık tanımlamaları olan bir izleme kurgusu tasarlamış oluyoruz.
Huawei FS Inventory Raw Item (huawei.fs.inventory.raw)
│ Type: Script
│ Output: {"data":[...]}
│
└── Discovery Rule (huawei.fs.discovery)
│ Type: Dependent item
│ Master: huawei.fs.inventory.raw
│
├── {#PARENTNAME} / File System : [{#NAME}] - Available Capacity (Bytes)
│ Key: huawei.fs.available.gb[{#ID}]
│ Type: Dependent item
│ Master: huawei.fs.inventory.raw
│
├── {#PARENTNAME} / File System : [{#NAME}] - Total Capacity (Bytes)
│ Key: huawei.fs.capacity.gb[{#ID}]
│ Type: Dependent item
│ Master: huawei.fs.inventory.raw
│
├── {#PARENTNAME} / File System : [{#NAME}] - Used Capacity (Bytes)
│ Key: huawei.fs.used.gb[{#ID}]
│ Type: Calculated
│ Formula: last(capacity) - last(available)
│
└── {#PARENTNAME} / File System : [{#NAME}] - Used Utilization %
Key: huawei.fs.util.pct[{#ID}]
Type: Calculated
Formula: last(used) / last(capacity) * 100
Yeni yazılarda görüşmek dileği ile hoşça kalın.