ECSRO Filter/Guard Performance, Runtime Logs ve Diagnostics Rehberi

Bu rehber, PvPSunucusu ECSRO Filter/Guard yazılımında Performance, Runtime Logs ve Diagnostics alanlarının nasıl kullanılacağını açıklamak için hazırlanmıştır. Bu bölüm; filter çalışma durumu, bağlantı olayları, SQL kayıtları, GameServer bridge mesajları, packet güvenlik logları, exploit guard uyarıları, firewall olayları, performans metrikleri, bellek kullanımı, log klasörü ve destek öncesi hata analizi için kullanılır.

1. Performance ve Runtime Logs Alanı Ne İşe Yarar?

ECSRO Filter/Guard yazılımı birçok sistemi aynı anda yönetir: Gateway bağlantısı, Agent yönlendirmesi, modül ayarları, SQL kayıtları, Packet Registry, Packet Exploit Guard, Firewall, Auto Notice, Auto Events, GameServer Bridge, Unique tracking, banned words ve runtime cache gibi birçok yapı aynı program içinde çalışır.

Bu kadar çok sistemin sağlıklı çalışıp çalışmadığını anlamanın en önemli yolu Runtime Logs ve Diagnostics ekranlarını doğru okumaktır. Log ekranı yalnızca hata olduğunda bakılacak bir alan değildir. Program başlatıldığında, filter açıldığında, SQL bağlantısı kurulduğunda, modül ayarları yüklendiğinde, packet güvenliği devreye girdiğinde veya GameServer bridge komutu işlendiğinde de log üretir.

Bu bölümün temel amacı şudur:

• Programın gerçekten çalışıp çalışmadığını görmek.
• Filter, Gateway, Agent ve GameServer bağlantı durumunu takip etmek.
• SQL bağlantı ve kayıt hatalarını tespit etmek.
• Oyuncu bağlantı, disconnect, rate limit ve firewall olaylarını incelemek.
• Packet Registry ve Packet Exploit Guard kurallarının ne zaman çalıştığını görmek.
• Banned Words ve Text Payload Security engellerini anlamak.
• GameServer Bridge komutlarının başarılı veya başarısız olduğunu görmek.
• Auto Event, Auto Notice ve reward sistemlerinin çalışmasını takip etmek.
• Performans, bellek, bağlantı ve runtime yükünü izlemek.
• Destek ekibine doğru log ve ekran görüntüsü göndermek.

2. Runtime Logs Ekranı

Runtime Logs ekranı, programın çalışma anında ürettiği kayıtları gösterir. Bu kayıtlar genellikle zaman sırasına göre listelenir. Her satırda sistemin hangi aşamada olduğu, hangi işlemi yaptığı veya hangi hatayla karşılaştığı anlaşılabilir.

Runtime log ekranında görülebilecek kayıt türleri şunlardır:

• Başlatma logları: Program açılışı, modül yükleme, ayar okuma, cache hazırlama kayıtları.
• SQL logları: MSSQL bağlantısı, Guard DB erişimi, tablo eksikliği, kayıt hatası veya SQL başarı mesajları.
• Filter logları: Gateway/Agent dinleme portları, client bağlantıları, proxy yönlendirme, filter başlatma/durdurma kayıtları.
• Firewall logları: IP/HWID block, rate limit, auto block, risk skoru ve bağlantı yoğunluğu kayıtları.
• Packet logları: Packet Registry, Packet Exploit Guard, opcode throttle, payload uyarısı ve güvenlik aksiyonları.
• Chat güvenlik logları: Banned Words, Text Payload Security, SQL/meta karakter ve max text length uyarıları.
• GameServer Bridge logları: Komut kuyruğu, callback, inject/connection, command result ve action response kayıtları.
• Auto Event logları: Event başlatma, event bitirme, reward verme, min online/min level kontrol kayıtları.
• Unique logları: Unique alive/dead durumu, killer bilgisi, geçmiş kayıtları ve callback sonuçları.
• Hata logları: Exception, timeout, SQL error, missing table, config parse error veya bridge bağlantı hatası.

3. Log Seviyeleri Nasıl Yorumlanır?

Her log satırı aynı önemde değildir. Bazı loglar sadece bilgi verirken bazıları müdahale gerektiren sorunları gösterir. Log seviyesini doğru yorumlamak, gereksiz panik ve yanlış müdahaleyi önler.

4. Runtime Log Ekranındaki Temel İşlemler

Logları Temizle

Logları Temizle işlemi, ekrandaki mevcut runtime log satırlarını temizlemek için kullanılır. Bu işlem disk üzerindeki eski log dosyalarını her zaman silmez; genellikle sadece ekrandaki görüntüyü temizler. Yeni test yapmadan önce ekranı sadeleştirmek için faydalıdır.

Örneğin bir ayar değiştirip sonucu test edecekseniz önce log ekranını temizleyebilir, sonra işlemi tekrar deneyebilir ve yalnızca yeni oluşan loglara bakabilirsiniz. Böylece eski kayıtlar ile yeni hatalar karışmaz.

Log Klasörünü Aç

Log Klasörünü Aç işlemi, programın dosyaya yazdığı logların bulunduğu klasörü açmak için kullanılır. Runtime ekranındaki loglar bazen uzun süreli geçmiş için yeterli olmayabilir. Diskteki log dosyaları daha eski kayıtları incelemek için önemlidir.

Destek talebi açarken yalnızca ekran görüntüsü değil, ilgili saat aralığını kapsayan log dosyası da gönderilmelidir. Özellikle crash, SQL hata, GameServer bridge command failure, packet block, firewall auto block veya filter kapanma gibi durumlarda dosya logları çok değerlidir.

Logları Kopyala

Bazı ekranlarda logları kopyalama veya seçili satırları alma imkanı bulunabilir. Bu işlem kısa destek bildirimlerinde faydalıdır. Ancak büyük sorunlarda yalnızca birkaç satır yerine olayın öncesi ve sonrası da paylaşılmalıdır.

Yanlış:
Sadece son hata satırını göndermek.

Doğru:
Hatanın oluştuğu saatten 1-2 dakika öncesi,
hatanın kendisi,
hata sonrası oluşan kayıtlar,
hangi işlem yapılırken oluştuğu bilgisi.

5. Performance / Metrics Alanı

Performance veya Metrics alanı, programın çalışma yükünü ve anlık durumunu görmek için kullanılır. Bu ekran, sistemin kasıp kasmadığını, bağlantı sayısının yükselip yükselmediğini, bellek kullanımının artıp artmadığını ve runtime tarafında olağan dışı bir yoğunluk olup olmadığını anlamaya yardımcı olur.

Performance ekranında takip edilebilecek metrikler şunlar olabilir:

• Uptime: Programın ne kadar süredir çalıştığını gösterir.
• Active Connections: O an aktif bağlantı sayısını gösterir.
• Gateway Connections: Gateway tarafında görülen bağlantıları gösterir.
• Agent Connections: Agent tarafındaki oyun dünyası bağlantılarını gösterir.
• Packet Count: İşlenen packet yoğunluğunu anlamaya yardımcı olur.
• Blocked Packets: Packet Registry veya Exploit Guard tarafından engellenen packet sayısını gösterir.
• Firewall Blocks: Firewall tarafından engellenen bağlantıları gösterir.
• SQL Errors: SQL tarafında son dönemde oluşan hata sayısını takip etmeye yardımcı olur.
• Memory Usage: Programın RAM kullanımını gösterir.
• GC / Managed Memory: .NET runtime belleği ve çöp toplama davranışı hakkında bilgi verir.
• Command Queue: GameServer command kuyruğundaki bekleyen veya işlenen komut durumunu gösterir.

Her metrik tek başına karar vermek için yeterli değildir. Örneğin bağlantı sayısının artması her zaman saldırı anlamına gelmez; event saati, restart sonrası yoğun login veya kampanya duyurusu sonrası giriş artışı olabilir. Bu yüzden metrikler runtime loglar ve firewall konsolu ile birlikte yorumlanmalıdır.

6. Metrics Yenileme

Metrics Yenile veya benzeri bir buton, performans değerlerini anlık olarak güncellemek için kullanılır. Bu işlem programın gerçek durumunu tekrar okuyarak ekrana yansıtır.

Özellikle şu durumlarda metrics yenileme faydalıdır:

• Filter yeni başlatıldıktan sonra.
• Oyuncu yoğunluğu aniden arttığında.
• Firewall veya packet block sayıları yükseldiğinde.
• SQL hata sayısı artıyor gibi göründüğünde.
• GameServer Bridge komutları beklemede kalıyorsa.
• Programın kasıp kasmadığı kontrol edilecekse.

Metrics değerleri yalnızca anlık fotoğraf verir. Sorun analizi için log geçmişiyle birlikte değerlendirilmelidir.

7. Diagnostics Alanı

Diagnostics, sistemin sağlık durumunu hızlı kontrol etmek için kullanılan yardımcı bölümdür. Bu bölüm, ayarların, SQL bağlantısının, modül durumlarının, bridge bağlantısının ve bazı runtime bileşenlerinin düzgün çalışıp çalışmadığını anlamaya yardımcı olabilir.

Diagnostics alanında kontrol edilebilecek başlıklar şunlardır:

• SQL bağlantısı: MSSQL erişimi var mı?
• Guard DB tabloları: Gerekli tablolar kurulu mu?
• Shard DB erişimi: GameServer command ve karakter işlemleri için Shard DB doğru mu?
• Module settings: Modül ayarları SQL veya JSON fallback üzerinden yüklenmiş mi?
• Firewall tables: Firewall ayar ve kural tabloları mevcut mu?
• Packet tables: Packet Registry ve Packet Exploit Guard tabloları mevcut mu?
• GameServer Bridge: Komut kuyruğu ve callback tabloları hazır mı?
• Runtime cache: Ayarlar ve ref data cache düzgün yüklenmiş mi?
• Log write access: Program log dosyası yazabiliyor mu?

8. GC Collect Ne İşe Yarar?

GC Collect, .NET runtime üzerinde çöp toplama işlemini manuel tetiklemek için kullanılan bakım aracıdır. Program uzun süre çalıştığında geçici nesneler, log bufferları, grid verileri veya runtime cache geçici olarak bellekte kalabilir. .NET normalde bunu otomatik yönetir. GC Collect butonu, ihtiyaç halinde bu temizleme sürecini manuel başlatır.

GC Collect doğru kullanıldığında geçici bellek baskısını azaltmaya yardımcı olabilir. Ancak bu işlem performans sihirli çözümü değildir. Sürekli artan bellek kullanımı varsa asıl neden araştırılmalıdır. Örneğin aşırı log birikimi, çok yüksek konsol satırı, yoğun firewall threat kaydı, temizlenmeyen runtime liste veya SQL retry kuyruğu gibi sebepler ayrıca incelenmelidir.

9. SQL Logları Nasıl Okunur?

SQL logları, programın Guard DB, Shard DB, Account DB veya Log DB ile iletişiminde sorun olup olmadığını gösterir. ECSRO Filter/Guard sistemi birçok ayarı SQL üzerinde tuttuğu için SQL hataları dikkate alınmalıdır.

SQL loglarında görülebilecek yaygın durumlar:

10. GameServer Bridge Logları

GameServer Bridge kullanılıyorsa runtime loglarda GameServer command ve callback kayıtları görülebilir. Bu kayıtlar, Project91 panelinden GameServer tarafına gönderilen komutların işlenip işlenmediğini anlamak için önemlidir.

GameServer Bridge loglarında şu olaylar takip edilebilir:

• GameServer bağlantısı veya inject durumu.
• PS_GameServerCommands kuyruğuna komut yazılması.
• Komutun GameServer tarafından claim edilmesi.
• Komutun başarılı veya başarısız tamamlanması.
• RetryCount artışı.
• Command timeout veya result bekleme durumu.
• PS_GameServerCallbacks üzerinden gelen event/unique/region/teleport callbackleri.

11. Packet ve Exploit Logları

Packet Registry ve Packet Exploit Guard sistemleri çalıştığında runtime loglarda opcode, action, payload, direction, character ve sebep bilgileri görülebilir. Bu loglar, oyuncu işleminin neden engellendiğini anlamak için kritiktir.

Örneğin bir oyuncu global atamıyor, item kullanamıyor, karakter seçtikten sonra oyuna giremiyor veya teleport kullanamıyorsa ilgili packet logları kontrol edilmelidir. Yanlış yazılmış bir packet kuralı normal oyuncu akışını kesebilir.

12. Firewall Logları

Firewall logları IP/HWID block, rate limit, allow, auto block ve risk skoru olaylarını gösterir. Bu loglar oyuncunun neden bağlanamadığını anlamak için çok önemlidir.

Oyuncu “servera giremiyorum” dediğinde sadece Gateway ayarlarına bakmak yeterli değildir. Firewall üzerinde IP veya HWID block olabilir. AutoBlock oyuncuyu geçici olarak engellemiş olabilir. Rate limit değeri çok düşük olduğu için oyuncu bağlantı limitine takılmış olabilir.

• Block policy: IP/HWID block listesinde olduğu için bağlantı engellenmiştir.
• Rate limit exceeded: IP/HWID dakika limitini aşmıştır.
• AutoBlock: Risk skoru eşiğe ulaştığı için geçici block oluşmuştur.
• Allow policy: IP/HWID allow listesinde olduğu için bağlantıya izin verilmiştir.
• Windows Firewall add failed: OS seviyesinde block kuralı eklenememiş olabilir.

13. Banned Words ve Text Payload Logları

Yasaklı kelime ve text payload logları, oyuncunun chat veya metin alanındaki işleminin neden engellendiğini gösterir. Bu loglar özellikle şu şikayetlerde kontrol edilmelidir:

• Chat mesajım gitmiyor.
• Global mesajım yıldızlı çıkıyor.
• Stall başlığı yazamıyorum.
• Party matching ilanı açamıyorum.
• Guild notice güncellenmiyor.

Loglarda yasaklı kelime, max text length, SQL/meta karakter veya control character sebebi görülebilir. Oyuncunun metni normal görünse bile bazı özel karakterler, çok uzun metin veya listeye eklenen kısa kelimeler sorun çıkarabilir.

14. Auto Events ve Reward Logları

Auto Events, Silk Per Hour, Unique Silk, Guide Event Silk ve Lucky Party gibi sistemler çalışırken runtime loglarda event ve reward kayıtları oluşabilir. Bu kayıtlar ödülün neden verilmediğini veya eventin neden başlamadığını anlamak için kullanılır.

15. Program Kasıyor veya Donuyor Gibi Görünüyorsa Ne Kontrol Edilmeli?

Programın kasması veya donması her zaman işlemci yetersizliği anlamına gelmez. Genellikle sebep; yoğun UI grid güncellemesi, çok büyük log listesi, SQL timeout, aşırı firewall event kaydı, packet spam, uzun süren database sorgusu veya bloklayan dış işlem olabilir.

Kontrol edilmesi gereken başlıklar:

• Runtime log ekranında aşırı hızlı log akışı var mı?
• Firewall konsol satır limiti çok yüksek mi?
• Packet Registry veya Exploit Guard çok fazla LogOnly kayıt üretiyor mu?
• SQL timeout veya yavaş sorgu hatası var mı?
• GameServer command queue çok fazla pending kayıt biriktiriyor mu?
• Auto Events tick süresi çok düşük mü?
• Log Rate Limit kapalı mı?
• Konsol / risk kaydı normal oyun port bağlantılarını çok yoğun gösteriyor mu?
• Program uzun süredir açık ve bellek kullanımı sürekli artıyor mu?
• GC Collect sonrası geçici rahatlama oluyor mu?

16. Destek Talebi Açmadan Önce Log Hazırlama

Destek talebi açmadan önce doğru log hazırlamak çözüm süresini ciddi şekilde kısaltır. Eksik log ile bildirilen sorunlarda geliştirici tarafında tahmin yapılması gerekir. Doğru log ile hangi modülün ne yaptığı net görülebilir.

Destek talebi için ideal bilgi seti şudur:

• Sorunun yaşandığı tarih ve saat.
• Sorunu yaşayan karakter adı.
• Varsa hesap adı, IP veya HWID bilgisi.
• Oyuncunun yaptığı işlem: login, global, stall, exchange, teleport, job, event, item kullanımı vb.
• Runtime log ekranındaki ilgili kayıtlar.
• Log klasöründen ilgili saat aralığını kapsayan log dosyası.
• İlgili modül ekranının ayar görüntüsü.
• Son yapılan ayar değişikliği veya patch bilgisi.
• Sorunun her oyuncuda mı yoksa belirli oyuncuda mı olduğu.
• Sorunun tekrar edilebilir olup olmadığı.

17. Sık Yapılan Hatalar

Sadece son hata satırını paylaşmak

Son hata satırı çoğu zaman yeterli değildir. Hatanın öncesinde hangi işlem başladı, hangi modül devreye girdi, SQL bağlantısı var mıydı, hangi kural çalıştı gibi bilgiler önceki loglarda bulunur.

Warning logunu kesin hata sanmak

Warning seviyesi her zaman sistemin bozulduğu anlamına gelmez. Bazı warningler sadece kullanıcıyı uyarmak veya fallback davranışı bildirmek için yazılır. Aynı warning sürekli tekrarlanıyorsa önem kazanır.

SQL hatalarını görmezden gelmek

Modül ayarları kaydolmuyor, firewall kuralları kayboluyor veya packet kuralları yeniden başlatma sonrası gelmiyorsa genellikle SQL kayıt problemi vardır. SQL logları mutlaka okunmalıdır.

Packet block loglarını oyuncu hatası sanmak

Oyuncu bir işlemi yapamıyorsa bunun sebebi gerçekten oyuncu olmayabilir. Yanlış Packet Registry veya Packet Exploit Guard kuralı normal packeti engelliyor olabilir.

Firewall auto block kaydını kontrol etmemek

Oyuncu servera bağlanamıyorsa IP veya HWID block dışında AutoBlock süresi de kontrol edilmelidir. Geçici block bazen sorun kaynağı olabilir.

GC Collect ile kalıcı performans sorunu çözdüğünü sanmak

GC Collect geçici bellek temizliği yapabilir. Ancak sürekli performans sorunu varsa asıl neden log yoğunluğu, SQL timeout, packet spam, firewall kayıt yoğunluğu veya uzun süren task olabilir.

18. Destek Talebi Açmadan Önce Kontrol Listesi

• Runtime log ekranında hata var mı?
• Hata saatinden önceki 1-2 dakikalık loglar incelendi mi?
• SQL connection veya missing table hatası var mı?
• Database / Installer üzerinden Eksik Tabloları Tamamla çalıştırıldı mı?
• Firewall block veya rate limit logu var mı?
• Oyuncunun IP/HWID değeri Firewall listesinde mi?
• Packet Registry veya Exploit Guard ilgili işlemi engelliyor olabilir mi?
• Banned Words veya Text Payload Security oyuncu metnini engelliyor olabilir mi?
• GameServer Bridge komutu kuyruğa yazılmış mı?
• GameServer komutu result dönmüş mü?
• Callback bekleyen işlem callback almış mı?
• Auto Event için min online, min level, cooldown ve reward ayarları doğru mu?
• Metrics ekranında bellek, bağlantı veya queue değerleri olağan dışı mı?
• Log klasöründeki dosyalar incelendi mi?
• Son yapılan ayar değişikliğinden sonra mı sorun başladı?
• Log Rate Limit kapalı olduğu için aşırı log üretiliyor olabilir mi?
• Konsol satır limiti çok yüksek olduğu için UI ağırlaşıyor olabilir mi?

19. Performans ve Güvenlik Önerileri

• Runtime logları düzenli takip edin. Sorun büyümeden önce uyarılar loglarda görünür.
• Log Rate Limit açık kalmalıdır. Packet spam veya saldırı sırasında log şişmesini azaltır.
• Firewall konsol satır limitini makul tutun. Çok yüksek limit UI tarafını gereksiz yorabilir.
• Packet kurallarını LogOnly ile test edin. Yanlış block normal oyuncuları etkileyebilir.
• SQL tablolarını güncel tutun. Yeni sürüm sonrası eksik tablo/kolon performans ve kayıt sorunlarına neden olur.
• GameServer Bridge queue birikimini kontrol edin. Pending komutlar artıyorsa bridge veya GameServer tarafı incelenmelidir.
• Auto Event tick değerlerini çok düşük yapmayın. Gereksiz sık kontrol SQL ve runtime yükünü artırabilir.
• Log dosyalarını periyodik arşivleyin. Çok büyük log klasörleri bakım ve analiz sürecini zorlaştırır.
• GC Collect'i bakım aracı olarak görün. Kalıcı performans sorununda asıl sebep bulunmalıdır.

20. Sık Sorulan Sorular

Runtime log ekranında warning gördüm, sistem bozuk mu?

Her warning kritik hata değildir. Warning, dikkat edilmesi gereken bir durumu bildirir. Aynı warning sürekli tekrar ediyorsa veya oyuncu sorunuyla aynı anda oluşuyorsa incelenmelidir.

Oyuncu oyuna giremiyor, ilk nereye bakmalıyım?

Önce Runtime Logs, ardından Firewall Konsol, Engellenenler listesi, SQL bağlantısı ve Gateway/Agent port logları kontrol edilmelidir. IP/HWID block, AutoBlock veya rate limit olup olmadığına bakılmalıdır.

Ayarları kaydediyorum ama geri dönüyor, sebep ne olabilir?

SQL kayıt hatası olabilir. Guard DB bağlantısı, PS_Settings tablosu ve ilgili modül tabloları kontrol edilmelidir. Database / Installer üzerinden Eksik Tabloları Tamamla ve SQL JSON Eşitle işlemleri yapılmalıdır.

Program kasıyor, GC Collect yeterli mi?

Hayır, tek başına yeterli kabul edilmemelidir. GC Collect geçici bellek temizliği sağlayabilir; fakat kasma sebebi SQL timeout, fazla log, yoğun firewall konsolu, packet spam veya command queue birikimi olabilir.

GameServer komutu çalışmadığında hangi loga bakmalıyım?

GameServer Bridge logları, PS_GameServerCommands kuyruğu, command result, retry count ve PS_GameServerCallbacks kayıtları kontrol edilmelidir. Ayrıca Shard DB üzerinde ilgili tabloların kurulu olduğundan emin olunmalıdır.

Packet loglarında Block görürsem ne yapmalıyım?

Önce hangi kuralın block verdiği bulunmalıdır. Kural yeni eklendiyse geçici olarak LogOnly yapılmalı ve oyuncu işlemi tekrar denenmelidir. Normal oyuncular etkileniyorsa kural yanlış veya fazla geniş olabilir.

Destek ekibine hangi logları göndermeliyim?

Sorunun yaşandığı saat aralığındaki runtime log dosyası, ekran görüntüsü, ilgili modül ayarları ve oyuncu/karakter bilgisi gönderilmelidir. Sadece son hata satırı genellikle yeterli değildir.

Sonuç

ECSRO Filter/Guard yazılımındaki Performance, Runtime Logs ve Diagnostics alanları, sistemin sağlıklı çalışıp çalışmadığını anlamanın en önemli yollarından biridir. Filter bağlantıları, SQL kayıtları, firewall olayları, packet güvenliği, banned words, GameServer bridge, auto events ve runtime performans metrikleri bu ekranlar üzerinden takip edilir.

Bir sorun yaşandığında tahminle işlem yapmak yerine önce loglar okunmalı, ilgili saat aralığı incelenmeli, hangi modülün devreye girdiği belirlenmeli ve Database / Installer, Firewall, Packet, GameServer veya Module Settings ekranlarıyla birlikte değerlendirme yapılmalıdır.

Sağlıklı kullanım için log rate limit açık tutulmalı, konsol satır limitleri makul seçilmeli, SQL tabloları güncel tutulmalı, GameServer bridge queue birikimi takip edilmeli ve destek talebi açmadan önce ilgili log dosyaları hazırlanmalıdır. Doğru log analizi, hem server stabilitesini artırır hem de destek çözüm süresini ciddi şekilde azaltır.

Bu makale PvPSunucusu için özel olarak hazırlanmıştır.