Günlük kaydı kontrolü, swarm.yaml dosyası aracılığıyla sağlanır . Bu dosya, günlük kaydı kaynaklarını (alıcılarını) veya günlük kaydı işleyicilerini devre dışı bırakma seçeneği sunar.
Sinks, Swarm günlük kaydı kaynaklarıdır – seviyeler veya alt sistemler :
uygulama – genel olarak uygulama
disk – keşif alt sistemi
mesg – Eşler arası TCP/IP mesajlaşması
grpc – DCC (SketchUp, Rhino, vb.) ile yerel Swarm servisi arasında gRPC iletişimi.
web – Swarm hizmetinin web arayüzü veya ön yüzü
denetim – denetim alt sistemi
dl – indirme alt sistemi (V-Ray dağıtımlarını indirme ve yükleme)
bln – DCC bilgisayarları ve oturumları arasında eşleri dağıtan dengeleyici alt sistem
tel – telemetri alt sistemi
instScript – kurulum komut dosyalarını çalıştıran alt sistem
vray – V-Ray’i kontrol eden (çalışan) alt sistem
st – Sürü’nün iç durumunun anlık görüntüsü
Buna göre, günlük kayıtları şu bilgileri içerir:
[2025-06-26T10:28:44.849859+0300 – INFO – mesg ] V-Ray AppSDK 7.00.06 6043c2d9… sürümünün doğrulanmasını sağlamak için istek
Günlük kaydını devre dışı bırak #
Herhangi bir lavabo, aşağıdaki değişiklik yapılarak devre dışı bırakılabilir (sessize alınabilir):
ile
swarm.yaml dosya örneği:
Tüm sink’ler seviyesinde (genellikle günlük kaydı bölümünün sonunda) benzer bir bayrak bulunur. Bunu disabled: true olarak değiştirirseniz, tüm günlük kaydı devre dışı bırakılır.
Lavabo Günlüğü Kayıt Şiddeti #
Her lavabonun, en düşük öncelikten en yüksek önceliğe doğru sıralanan, izin verilen ciddiyet seviyeleri (seviyeleri) vardır. Seviyeler şu şekildedir:
Bir veri havuzunun seviyesi INFO ise, DEBUG seviyesinde log kaydı yazmaz. Sadece INFO, WARN, ERROR ve FATAL seviyelerinde log kaydı yazar. Seviyesi ERROR ise, yalnızca ERROR ve FATAL kayıtlarını yazabilir.
DEBUG günlük kayıtları, sistemin nasıl çalıştığına dair ayrıntılı adımları gösterir ve bu da olası sorunların tespit edilmesine yardımcı olabilir.
Örnekler: Günlük Kayıt Havuzlarını Devre Dışı Bırakma #
Günlük dosyaları tarafından kullanılan disk alanının boyutu sınırlıdır ve bu da süresiz olarak büyümesini engeller. Ancak, önemsiz günlük kayıtları önemli günlük kayıtlarına baskın gelirse, hayati bilgileri kaybetme riskiyle karşı karşıya kalırız. Çok zaman alan karmaşık sorunların hata ayıklamasında, belirli günlük havuzlarını sınırlamak faydalı olabilir. Örneğin, keşif süreci genellikle çok sayıda günlük mesajı üretir, bu nedenle bu gibi durumlarda “disk” havuzunu devre dışı bırakmayı düşünebilirsiniz.
“Mesaj” havuzu birçok mesaj üretir, ancak bu bilgiler sorunların araştırılması için hayati önem taşır. Bu nedenle, devre dışı bırakılması kesinlikle önerilmez.
Yukarıda da belirtildiği gibi, bir diğer kullanım örneği, bazı veri havuzlarının önem derecesini değiştirmek olabilir; örneğin, DEBUG’dan INFO’ya veya INFO’dan WARN’a.
Chaos/Swarm Destek Ekibi ile iletişime geçerken, kapsamlı ve ayrıntılı günlükler sağlamanız gerekmektedir. Bu, tüm sink’ler için önem derecesinin DEBUG olarak ayarlanması ve sessize alınmaması gerektiği anlamına gelir. Tek istisna, herhangi bir sorun yoksa veya ağınızda keşif ile ilgili herhangi bir sorunun farkındaysanız sessize alınabilen “disc” sink’idir. Günlük dosyasını destek ekibine gönderirken, sorunun oluştuğu süre boyunca kaydedilen ayrıntılı bilgileri içerdiğinden emin olun.
Günlük Dosyalarının Döndürülmesi #
Her lavabonun bir veya daha fazla sorumlusu vardır. Bu kişiler kayıtların düzenlenmesinden sorumludur.
Şu anda 5 hadler bulunmaktadır:
konsol – Swarm konsolda çalışıyorsa mevcut konsola, Linux durumunda ise systemd günlüğü tarafından toplanan stdout’a yazar.
Döndürme – Bir disk dosyası – bkz. “dosya: …” ayarı – ve aşağıdaki döndürme politikası.
instScriptRotate – “rotate” ile aynı işlevi görür, ancak ayrı bir dosyada çalışır.
vrayfile – “rotate” ile aynı işlevi görür, ancak ayrı bir dosyada.
vraymem – Swarm işlemi içindeki bir bellek bloğuna yazar (dahili kullanım için).
Swarm günlük dosyalarının kullandığı disk boyutu sınırlıdır. Bu sınıra ulaşıldığında, günlük dosyaları döndürülür:
-
Öncelikle, döndürme işleyicileri günlük dosyasına yazarlar.
-
<NAME>.log adlı günlük dosyasının sınırlı bir boyutu vardır (bkz. “maxBytes: …” ayarı). Sınır aşıldıktan sonra, dolu günlük dosyası <NAME>.log’dan <NAME>.1.log’a yeniden adlandırılır.
-
İşleyici, <NAME>.log dosyasını baştan yazmaya başlar. Önceki günlük kayıtları <NAME>.1.log dosyasındadır.
-
İşleyici tekrar sınıra ulaştığında, tüm bu günlük dosyalarını yeniden adlandırarak kaydırır: <NAME>.2.log, <NAME>.3.log olur, <NAME>.1.log, <NAME>.2.log olur – hiçbir şey kaybolmaz. Sınıra her ulaşıldığında <NAME>.log dosyasını kaydırır (yeniden adlandırır, yığına iter gibi) ve yeniden başlatır.
-
Aşağıdaki şekilde N ile gösterilen taşınan dosya sayısı da sınırlıdır; ayarı “backupCount: …” şeklindedir, bu nedenle diskteki sayıları N’den fazla olamaz. Eğer hepsi doluysa, en eski dosya kaldırılır (unutulur), kayıtlar kaybolur. Dolayısıyla, tüm günlük kayıtlarının geçmişine sahip olursunuz, ancak en eski N dosyaya kadar. Zaman sırası şu şekildedir:
|
<NAME>.log |
Her zaman güncel, bir yönetici buraya yazıyor! |
|
<NAME>.1.log |
<NAME>.log dosyasından daha eski |
|
<NAME>.2.log |
<NAME>.1.log dosyasından daha eski |
|
<AD>.N.log |
en yaşlısı |
Bu şema ne kadar disk alanı kullanıyor? Tek bir işleyici: backupCount * maxBytes. Eğer 3 işleyiciniz varsa, her biri kendi alanını tüketir (farklı, ayrı dosyalara yazarlar!). instScriptRotate ve vrayfile gibi bazı işleyiciler çok nadiren yazma işlemi gerçekleştirir .
maxBytes ve backupCount ayarları her işleyici için ayrı ayrıdır. Ayarlar dosyasından bir bölüm:
RotatingFileHandler, işleyicileri döndürür. Konsol işleyicisi StreamHalder türündedir ve herhangi bir döndürme işlemi yapmadan doğrudan yazar.
Bazı işleyici özellikleri, hedef özellikleri tekrarlar. Bu, kullanılan yazılım kütüphanesinin tasarımına özgüdür ve bunların yapılandırılması için ek bir merkezi yer sağlar.
Örnekler: Değişiklik Rotasyonu Politikası #
Eğer incelenecek yeterli veri yoksa, maxBytes ve backupCount ayarlarını artırabilirsiniz. Bunun tersi de mümkündür; eğer çok fazla yer kaplıyorlarsa, bu ayarları azaltabilirsiniz (ancak bu durumda önemli performans kayıtlarını kaybedebilirsiniz).
Alan sınırına ulaşıldıktan sonraki mevcut maksimum tüketimi tahmin etmek için:
Konsol Günlüğü #
Sink’ler, farklı işleyicilere paralel olarak kayıt tutabilir. İşleyici, kayıt verilerini tüketen (kaydeden, toplayan, birleştiren) bir dosya mekanizmasıdır. Eski Swarm sürümlerinde bazı sink’ler, kayıtları 2 işleyiciye paralel olarak tutuyordu: bir dosya ve konsol; ayarları şu şekilde bir kod parçası içeriyordu:
Konsol işleyici , swarm.yaml ayar dosyasında yapılandırılır. Bu kod parçası, uygulama havuzunun günlük kayıtlarını konsola ve döndürülen işleyiciye göndermesi gerektiğini belirtir. Bu durumda, Swarm yürütülebilir dosyasını konsolda çalıştırırsanız, uygulama havuzu günlük kayıtlarını yalnızca bir günlük dosyasına değil, aynı zamanda çalıştırdığınız konsola da yazar. Bu, işlemin standart çıktı akışıdır.
Swarm’ı Linux systemd servisi olarak çalıştırırsanız, standart çıktısı toplanır ve systemd günlüğüne kaydedilir ve bu çıktı çok fazla yer kaplayabilir. Bu, systemd günlüğünde disk alanı tüketir (Swarm günlük dosyalarında değil – boyutları her zaman sınırlıdır!).
Eğer böyle bir etki istenmiyorsa, tüm çıktılardan “-” konsol dizesini kaldırmanız yeterlidir. Yeni Swarm sürümlerinde bu kaldırılmıştır.
Günlük Sıkıştırma #
Günlük dosyaları düz metin dosyaları olarak kaydedilir. Hakkında > Sorun Giderme > Tanılama verilerini topla seçeneğine tıklarsanız , tüm Swarm günlük dosyalarının arşivini indirebilirsiniz (bunu Chaos destek ekibiyle iletişime geçerken kullanabilirsiniz).
Ağaç Kesim Yapısı #
İşte yöneticiler için gelişmiş bir günlük kaydı yapısı.
