Kurumsal ADC ve WAAP platformları tek bir monolitik süreçten ibaret değildir. Trafik istatistiği toplayan worker'lar, network işlemleri, firewall yönetimi, CLI servisleri, routing console süreçleri, log ve RRD toplayıcıları birlikte çalışır. Bu süreçlerden biri sessizce durursa veya yanlış kaynak profiliyle çalışırsa, sorun trafik düzleminden önce yönetim ve görünürlük düzleminde başlar.
Klasik yaklaşımda süreç izleme harici ajanlara veya genel amaçlı process manager araçlarına bırakılır. Bu araçlar sürecin çalışıp çalışmadığını görebilir; ancak sürecin TR7 içindeki rolünü, hangi kaynak profiliyle çalışması gerektiğini veya hangi hata durumunda reload mı restart mı yapılacağını bilmez. Sonuçta izleme genel kalır, aksiyon manuel hale gelir.
Çok süreçli Node.js tabanlı sistemlerde kaynak ayarları da kritiktir. Her sürece aynı heap limiti ve aynı thread pool değeri vermek doğru değildir. Hafif CLI süreci ile yoğun RRD collector aynı profille çalıştırılırsa ya kaynak israfı oluşur ya da yoğun süreç yetersiz limitlerle baskılanır.
Restart davranışı da dikkatli tasarlanmalıdır. Çok sık restart kök nedeni gizler; çok geç restart ise arızalı sürecin uzun süre etkili olmasına yol açar. Trafik taşıyan ADC container'larında ise önce soft reload denenmeli, başarısız durumda hard restart fallback yapılmalıdır.
TR7 Süreç İzleme, süreç tipi bazlı performans profilleri, ForkManager tabanlı alt süreç yönetimi, RRD tabanlı istatistik toplama ve soft-to-hard restart akışıyla iç platform süreçlerini operasyonel olarak kontrol altında tutar.
TR7, süreç izlemeyi yalnızca "process ayakta mı?" kontrolü olarak değil, süreç tipi, kaynak profili ve restart davranışıyla birlikte ele alır.
Her süreç tipi kendi iş yüküne göre default, light, heavy, worker veya ioIntensive profillerinden biriyle çalıştırılır. Heap, semi-space ve UV thread pool ayarları bu profile göre üretilir.
RRD collector süreçleri CPU, bellek, disk ve network olaylarını zaman serisi mantığında toplar. Bu veriler izleme ekranları, alarm mantığı ve operasyon analizi için temel sağlar.
TR7 iç süreçleri child process olarak başlatılır ve ForkManager registry altında takip edilir. Süreç çökerse manager yeniden başlatma akışını yönetebilir ve süreç ağacı operasyonel olarak ayrıştırılır.
ADC istatistik hataları belirli eşiğe ulaştığında önce soft reload denenir. Soft reload başarısız olursa hard restart fallback ile container kontrollü biçimde yeniden başlatılır.
Süreç İzleme, TR7 iç bileşenlerini profil tabanlı kaynak yönetimi, otomatik restart ve merkezi süreç takibiyle işletir.
TR7 default, light, heavy, worker ve ioIntensive olmak üzere beş performans profili kullanır. Her profil farklı max-old-space-size, max-semi-space-size ve UV thread pool ayarlarına sahiptir. Hafif süreçler daha düşük heap ile çalışırken yoğun collector süreçleri daha geniş kaynakla başlatılır. Bu model, tüm süreçlere tek tip limit verme hatasını azaltır.
UV_THREADPOOL_SIZE değeri sistem CPU sayısına göre hesaplanır. Değer minimum 4, maksimum 32 olacak şekilde CPU çekirdek sayısının iki katı mantığıyla belirlenir. Bu, yoğun I/O yapan süreçlerde thread pool'un çok küçük kalmasını engeller. Aynı zamanda kontrolsüz yüksek değerlerle gereksiz kaynak tüketimi oluşmasını sınırlar.
Node.js süreçleri başlatılırken max-old-space-size değeri profil üzerinden verilir. Default profil 1024 MB, light ve worker profilleri 512 MB, heavy profil 2048 MB, ioIntensive profil 1024 MB heap değeriyle çalışabilir. Bu ayar, süreçlerin bellek kullanımını görevine göre sınırlandırır. Büyük collector süreçleri ile küçük yönetim süreçleri aynı bellek profiline zorlanmaz.
Semi-space değeri garbage collection davranışını etkileyen önemli bir çalışma parametresidir. Light profilde 8 MB, default profilde 16 MB, heavy profilde 32 MB gibi değerler kullanılabilir. Bu ayrım yoğun veri işleyen süreçlerin daha rahat çalışmasını, hafif süreçlerin ise küçük footprint ile kalmasını sağlar. Kaynak ayarları süreç tipine göre daha öngörülebilir hale gelir.
rrd-collector ve rrd-websocket gibi veri yoğun süreçler heavy profile bağlanabilir. pool-stats-worker worker profiliyle, network-fork ioIntensive profiliyle, frr-console ve cli-server light profiliyle çalıştırılabilir. Bu mapping operasyon standardı sağlar ve yanlış profil seçimi riskini azaltır. Yeni süreç eklendiğinde hangi profile bağlanacağı açıkça tanımlanır.
buildExecArgv akışı, süreç başlatılırken gerekli Node.js çalışma argümanlarını profil değerlerinden üretir. max-old-space-size ve max-semi-space-size gibi parametreler manuel komut satırı düzenlemesine bırakılmaz. Bu, deployment tutarlılığını artırır. Farklı ortamlar aynı profil tanımlarını kullanarak benzer davranış üretir.
buildEnvVars akışı, UV_THREADPOOL_SIZE gibi çevresel ayarları süreç profiline göre üretir. Özellikle I/O yoğun süreçlerde doğru thread pool değeri performans ve stabilite için önemlidir. Bu yaklaşım sistem yöneticisinin her süreç için ayrı environment dosyası yönetme ihtiyacını azaltır. Kaynak davranışı merkezi profil modeline bağlanır.
network_fork, firewall_fork ve stat_fork gibi süreç aileleri ForkManager altyapısı altında takip edilir. Her alt süreç bağımsız child process olarak çalışır. Çökme veya beklenmeyen çıkış durumlarında manager yeniden başlatma ve durum güncelleme akışını yürütebilir. Bu yapı, iç servislerin tek bir ana süreç içinde görünmez kalmasını engeller.
Process yönetimi olayları ayrı log kanalı üzerinden izlenebilir. Başlatma, durma, hata, restart ve internal exception olayları operasyon ekibinin inceleyebileceği şekilde kayda alınır. Bu kayıtlar tekrar eden süreç problemlerinde kök neden analizini kolaylaştırır. İzleme yalnızca anlık durumdan ibaret kalmaz, geçmiş davranış da incelenebilir.
ADC stat hata sayaçları belirli eşiğe ulaştığında sistem otomatik iyileştirme akışı başlatabilir. İlk adım soft reload olur; başarısızlıkta hard restart fallback uygulanır. Bu davranış, geçici runtime arızalarının manuel müdahale beklemeden toparlanmasına yardımcı olur. Sürekli tekrar eden durumlar ise ayrıca operasyonel inceleme gerektirir.
Süreç izleme; profil değerleri, süreç tipi mapping'i, UV thread pool sınırları, fork yönetimi ve restart davranışıyla birlikte işletilir.
Default profil genel amaçlı süreçler için 1024 MB heap ve 16 MB semi-space değeriyle kullanılabilir. UV thread pool değeri CPU sayısına göre hesaplanan varsayılan değeri takip eder. Özel ihtiyaç tanımlanmayan süreçler için dengeli bir başlangıç noktası sağlar.
Light profil 512 MB heap ve 8 MB semi-space gibi daha düşük kaynak değerleriyle çalışır. FRR console ve CLI server gibi hafif süreçler için uygundur. Bu profil gereksiz bellek tüketimini azaltır.
Heavy profil 2048 MB heap ve 32 MB semi-space değeriyle yoğun collector süreçleri için ayrılır. rrd-collector ve rrd-websocket gibi daha fazla veri işleyen süreçlerde kullanılabilir. UV thread pool üst sınırı 32'ye kadar çıkabilir.
Worker profil 512 MB heap ile daha dar, iş odaklı süreçler için kullanılır. UV thread pool değeri minimum 8 ve CPU sayısına bağlı şekilde ayarlanabilir, üst sınır daha kontrollü tutulur. pool-stats-worker gibi süreçlerde tercih edilebilir.
ioIntensive profil 1024 MB heap ile I/O ağırlıklı süreçler için kullanılır. UV thread pool CPU çekirdek sayısına göre büyütülür ve 32 üst sınırına kadar çıkabilir. network-fork gibi ağ ve I/O ağırlıklı işler için uygundur.
PROCESS_TYPE_PROFILES yapısı süreç tiplerini ilgili performans profiline bağlar. rrd-collector heavy, pool-stats-worker worker, network-fork ioIntensive, frr-console light ve cli-server light olarak eşlenebilir. Bu mapping operasyon standardı sağlar.
Yeni bir özellik sonrası pool-stats-worker kaynak baskısı yaşıyorsa süreç profili worker'dan daha uygun bir profile taşınabilir. Heap ve UV thread pool değerleri merkezi profil modeliyle güncellenir. Operasyon ekibi tek tek runtime argümanı düzenlemek zorunda kalmaz.
ADC istatistik hataları belirli eşiği aşarsa TR7 otomatik soft reload deneyebilir. Soft reload başarılı olursa trafik etkisi azaltılarak süreç toparlanır. Başarısızlık durumunda hard restart fallback uygulanır.
Ağ operasyon ekibi process durumu, sistem komutları ve izleme çıktılarıyla ilgili sürecin sağlığını tek operasyon akışında değerlendirebilir. Network fork, firewall fork veya collector süreçlerinin durumu olay incelemesini hızlandırır.
Failover veya bakım sonrası hangi süreçlerin ne zaman yeniden başladığı operasyon kayıtlarından incelenebilir. Bu kayıtlar kesinti analizi ve change management süreçleri için kullanılır. Tekil process restart'ları genel sistem davranışıyla ilişkilendirilebilir.
Profil tabanlı kaynak sınırları, otomatik restart akışı ve merkezi süreç görünürlüğü. Kendi ortamınızda canlı bir kurulumda gezdirelim.