Kendi trading botlarımı ve veri toplama agent sistemlerimi kurarken sürekli aynı sorunlarla boğuşuyordum. Sunucu bir noktada tıkanıyor, veriler eksik geliyor ya da sistem bir şekilde sessiz sedasız çöküyordu. Bu süreçte deneme yanılma yoluyla öğrendiğim ve artık standart hale getirdiğim bazı kütüphaneler var. Gerçek işlerde, yani BIST tarafında veri çekerken kullandığım bu paketleri neden tercih ettiğimi ve nerelerde hata yapıp başımı yaktığımı burada anlatıyorum. Bu araçlar benim sistemimin bel kemiği oldu.
1. psutil
Bu kütüphane sistem kaynaklarını izlemek için kullanılan standart bir araç. Sunucunun CPU ve RAM kullanımını anlık olarak takip etmemi sağlıyor. BIST veri çekme scriptlerimi çalıştırdığım sunucuda darboğazları tespit etmek için bunu kullanıyorum. Eğer işlemci kullanımı aniden fırlarsa scriptin hata verip vermediğini buradan anlıyorum.
Bunun en büyük tuzağı ise kullanım sıklığı. Eğer bu aracı çok sık aralıklarla çağırırsanız sistem kaynaklarını gereksiz yere tüketmeye başlar. Yani sistemi izleyeyim derken ana işlem performansını düşürürsünüz. Ben bunu her saniye değil, belli aralıklarla kontrol edecek şekilde ayarladım. Örneğin 60 saniyelik periyotlarla kontrol etmek, sistemin üzerindeki yükü yüzde 5 seviyesinde tutmamı sağladı. Daha sık sorgulama yaptığımda ise Python süreçlerinin CPU kullanımında yüzde 15 civarında bir artış gözlemledim, bu da trading botunun tepki süresini yavaşlattı. Sistem kaynaklarını izlerken özellikle disk okuma yazma hızlarını da psutil ile takip etmek, veritabanı şişmelerini önceden fark etmemi sağlıyor. Bir keresinde disk doluluğu nedeniyle botum kilitlenmişti, psutil üzerinden gelen uyarı sayesinde artık disk yüzde 80 doluluğa ulaştığında otomatik temizlik yapan bir scriptim devreye giriyor.
2. schedule
Zamanlama işlerini yapmak için kullanıyorum. Borsa kapanış verilerini veya günlük raporları belirli saatlerde otomatik tetiklemek için basit bir zamanlayıcı görevi görüyor. İnsanların kolayca anlayabileceği bir yapısı var.
Ancak burada dikkatli olmak gerekiyor. Eğer çalıştırdığınız görev uzun sürüyorsa, bir sonraki görevi bloklayabilir. Asenkron yapılarla dikkatli çalışmazsanız sistemin kilitlendiğini görebilirsiniz. Ben bu sorunu aşmak için zamanlayıcıyı ana döngüden ayırıp ayrı bir thread üzerinde çalıştırıyorum. Örneğin BIST açılış seansında veri çekme işlemi bazen 40 saniye sürebiliyor. Eğer schedule kütüphanesini tek başına kullanırsam, o 40 saniye boyunca sistem başka hiçbir görevi yerine getiremiyor. Bu yüzden her görevi kendi içinde küçük bir zamanlayıcı ile yönetmek yerine, ana bir kontrol mekanizması kurarak uzun süren işlemleri arka plana atıyorum. Böylece sistemin donması engelleniyor ve veri akışı kesintisiz bir şekilde devam edebiliyor.
3. loguru
Python tarafında hata kayıtlarını tutmak bazen tam bir çileye dönüşebiliyor. Loguru bu işi çok basit hale getiriyor. Özellikle trading botlarının veya veri toplama agent sistemlerinin hata kayıtlarını dosya rotasyonu ile düzenli tutmak için kullandığım temel araç oldu. Hata nerede oluştu, neden oluştu, hepsini dosyaya yazdırıyorum.
Buradaki en büyük tuzak hata ayıklama seviyesini üretim ortamında açık bırakmak. Eğer debug seviyesini açık bırakırsanız, log dosyaları diski çok hızlı bir şekilde doldurabilir ve sunucunun durmasına neden olabilir.
from loguru import logger
logger.add("borsa_takip.log", rotation="500 MB")
logger.info("Veri cekme islemi basladi")
Yukarıdaki kod bloğunda loguru kütüphanesini projeye dahil ediyorum. İlk satırda log dosyasının yolunu ve boyutunu belirliyorum. 500 MB dolduğunda dosya otomatik olarak rotasyona giriyor. İkinci satırda ise basit bir bilgi mesajını log dosyasına ekliyorum. Bu sayede işlem geçmişini temiz bir şekilde takip edebiliyorum.
4. requests
Sunucu sağlığını kontrol ettikten sonra Slack veya Telegram üzerinden anlık bildirim göndermek için bunu kullanıyorum. Bir sorun olduğunda telefonuma bildirim düşmesi benim için çok kritik.
Buradaki en büyük tuzak ise zaman aşımı parametresi. Eğer timeout süresi tanımlamazsanız, hedef servis yanıt vermediğinde scriptiniz sonsuz döngüye girip kitlenebilir. Bu da tüm veri akışının durması demek.
5. watchdog
Sunucudaki veri dosyalarının veya konfigürasyonların değişip değişmediğini izlemek için watchdog kullanıyorum. Bir dosya güncellendiğinde anında tepki vermem gerekiyor.
Ancak çok fazla dosya değişikliği olan dizinlerde izleme yaparken dikkatli olmalısınız. Sistemin giriş çıkış performansını ciddi oranda yavaşlatabilir. Hangi klasörleri izlediğinizi kısıtlamanız gerekiyor.
6. paramiko
Dağıtık sistemlerde çalışıyorsanız diğer Linux sunuculara bağlanmanız gerekir. Paramiko ile SSH üzerinden bağlanıp uzaktan komut çalıştırıyorum veya veri çekiyorum.
SSH anahtar yönetimini düzgün yapmazsanız güvenlik açığı oluşturabilirsiniz. Ayrıca bağlantı kopmalarında scriptiniz askıda kalabilir. Bu yüzden bağlantı yönetimini çok iyi kurgulamak şart.
7. diskcache
Bellek kısıtlı sunucularda çalışırken veri analizi sırasında geçici verileri hızlıca diske yazıp okumam gerekiyor. Diskcache bu konuda çok yardımcı oluyor.
Ancak disk üzerinde çok fazla yazma işlemi yapmak SSD ömrünü azaltabilir. Yoğun işlem anında gecikmelere yol açtığı da oluyor. Bu yüzden sadece gerçekten gerekli olan veriler için kullanıyorum.
8. pydantic
Sunucudan gelen sistem metriklerini veya borsa verilerini doğrulamak için kullanıyorum. Hatalı veri girişini engellemek için veri modelleri oluşturuyorum.
Karmaşık veri modellerinde doğrulama süreci, yüksek frekanslı trading verisi işlerken gecikme yaratabilir. Bu yüzden modelleri mümkün olduğunca basit tutmaya çalışıyorum.
Toparlarsak
Bu araçları seçmemin nedeni zekice bir hamle yapmam değil, sadece aynı işi tekrar tekrar yaparken en verimli olanları bulmuş olmam. Başlarda her şeyi kendi başıma yazmaya çalıştım ama bu sadece zaman kaybına neden oldu. Standart kütüphaneleri kullanmak bana ciddi bir zaman kazandırdı. Bundan sonra yapman gereken şey, kendi sistemindeki darboğazları belirleyip bu araçlardan sana uygun olanı projene dahil etmek. İlk adım olarak loguru ile hata kayıtlarını düzenli tutmaya başla, bu bile sistemindeki belirsizliği büyük oranda azaltacaktır. Sonra diğer araçları ihtiyacına göre tek tek devreye alabilirsin. Hepsini aynı anda değiştirmeye kalkma, sistemin kararlılığını bozabilirsin. Her aşamada sistemi test et ve performans verilerini izle. Arac seçimi aslında bir zeka meselesi değil, tamamen tekrar meselesidir. Ne kadar çok tekrar edersen, hangi aracın nerede hata vereceğini o kadar iyi anlarsın. Kendi sistemini kurarken her bir modülü izole etmeye çalış ve hata aldığında hangi kütüphanenin nerede takıldığını log kayıtlarından analiz et. Bu disiplin, sisteminin ayakta kalmasını sağlar.
Sistemin kurulumunu tamamladıktan sonra mutlaka bir izleme paneli oluşturmalısın. Sadece kodun hata vermesini bekleme, sistemin genel sağlığını periyodik olarak kontrol eden bir ana script yaz. Eğer BIST verisi gelmediğinde watchdog ile tetiklenen bir uyarı mekanizması kurarsan, veri kaybını dakikalar içinde fark edebilirsin. Ayrıca diskcache kullanımında verileri temizleme stratejisini mutlaka belirle, aksi takdirde sunucun bir hafta içinde dolabilir. Her bir kütüphaneyi projenin farklı katmanlarına yayarak modüler bir yapı kurmak, ileride yaşanacak sorunların kaynağını bulmanı inanılmaz kolaylaştıracaktır. Küçük adımlarla ilerle, her kütüphaneyi eklediğinde sistemin yükünü ölç ve bir sonraki aşamaya öyle geç. Bu yöntemle kendi otomasyon sistemini inşa etmek, uzun vadede sana büyük bir zaman kazancı sağlayacaktır. Unutma, en sağlam sistem en karmaşık olan değil, en iyi izlenebilen ve hata anında sana ne olduğunu en net söyleyebilen sistemdir.
Top comments (0)