[[GORSEL_KAPAK]]
Borsa işlemlerini otomatize ederken kullandığım sistemlerin kararlı çalışması benim için hayati önem taşıyor. Özellikle trading agent yapılarını Linux üzerinde canlı tutmak, hata anında müdahale etmek ve güncellemeleri hızlıca yaymak için farklı Python kütüphaneleri denedim. Bu süreçte karşılaştığım problemleri çözmek için kullandığım araçları ve yaşadığım tecrübeleri aşağıda sıraladım. Bu paketleri gerçek işlerde kullandım, sırasıyla anlatıyorum.
1. systemd-python (Sürüm 235)
Bu kütüphane sistemdeki servislerle Python üzerinden konuşmanı sağlar. BIST trading agentlarının systemd servis durumlarını Python içinden sorgulamak ve kontrol etmek için kullanıyorum. Servis durmuş mu yoksa çalışıyor mu diye terminale bakmak yerine kodun içinde bunu kontrol edebiliyorum.
Tuzak ise şudur. Bu kütüphane D-Bus arayüzüne bağımlı çalışır. Bu yüzden root yetkisi gerektiren işlemlerde izin hatalarıyla çok uğraştırır. Eğer yetki yönetimi konusunda dikkatli değilsen scriptlerin sürekli hata verir ve çalışmayı durdurur.
2. psutil (Sürüm 7.2.2)
Sistem izleme denince akla gelen ilk araçtır. Trading botlarının CPU ve RAM tüketimini anlık izleyip, limit aşımında servisi yeniden başlatmak için kullanıyorum. Özellikle bellek sızıntısı yapan bir agent varsa psutil sayesinde bunu erkenden fark edip sistemi kurtarabiliyorum.
Buradaki tuzak performansla ilgili. Sistem kaynaklarını okurken çok sık sorgu atmak, veri analizi scriptlerinizin performansını düşürür. Sürekli sistemi yoklamak yerine belirli aralıklarla kontrol yapmak daha sağlıklıdır.
3. fabric (Sürüm 3.2.3)
Birden fazla sunucuda çalışan finansal agentları tek merkezden güncellemek ve servisleri restart etmek için fabric kullanıyorum. SSH üzerinden komut çalıştırmak için harika bir kütüphanedir.
Tuzak noktası ise ağ bağlantılarıdır. SSH bağlantı zaman aşımları ve ağ kesintileri otomasyon sürecini yarıda bırakabilir. Eğer internetin dalgalıysa komutun yarısı çalışıp yarısı havada kalabilir.
4. python-crontab (Sürüm 3.4.0)
Piyasa açılış ve kapanış saatlerine göre çalışan zamanlanmış görevleri Python ile yönetmek için kullanıyorum. Crontab dosyasını manuel düzenlemek yerine bu API ile kod içinden yönetmek çok daha temiz.
Tuzak ise crontab dosyasının üzerine yazarken mevcut görevleri yanlışlıkla silme riskidir. Bu yüzden her zaman mevcut listeyi çekip üzerine ekleme yaparak ilerlemek gerekiyor.
5. watchdog (Sürüm 7.1.0)
Dosya sistemi olaylarını izleyip strateji dosyalarındaki değişiklikleri takip etmek için kullanıyorum. Kod güncellendiğinde ilgili servisleri otomatik reload etmek için çok işe yarar.
Tuzak ise dosya sistemi olaylarını izlerken çok hızlı tetiklenmesi durumunda gereksiz servis restartlarına yol açmasıdır. Tek bir dosyayı kaydederken bazen sistem bunu birkaç olay olarak algılayıp servisi üst üste yeniden başlatmaya çalışabilir.
6. circus (Sürüm 0.19.0)
Circus bir process yöneticisidir. Python tabanlı olduğu için birden fazla BIST veri çekme servisinin yaşam döngüsünü yönetmek için kullanıyorum.
Tuzak ise konfigürasyon karmaşıklığıdır. Servis sayısı arttıkça ve bağımlılıklar çoğaldıkça circus yapılandırmasını yönetmek systemd dosyalarına göre daha zor olabilir.
7. sh (Sürüm 2.4.0)
Linux terminal komutlarını Python fonksiyonu gibi çağırmak için harika bir araçtır. Hızlı servis yönetimi otomasyonları yazarken terminale gitmek yerine sh kullanıyorum.
import sh
sh.systemctl("restart", "trading-agent.service")
Yukarıdaki kod bloğu systemctl komutunu bir Python fonksiyonu gibi çalıştırır. Servis adını parametre olarak gönderir ve arka planda terminal komutunu tetikler. Hata çıkarsa Python içinde bunu yakalayabiliriz.
Tuzak ise komut çıktılarının yönetimi ve hata yakalama süreçleridir. Standart kütüphanelere göre daha karmaşık davranabilir, bu yüzden çıktıyı doğru okumak için biraz vakit harcaman gerekir.
8. supervisor (Sürüm 4.3.0)
Trading agentlarının her zaman ayakta kalmasını sağlamak ve hata durumunda loglarını incelemek için kullanıyorum. UNIX tabanlı sistemlerde süreç kontrolü için oldukça sağlam bir sistemdir.
Tuzak ise servis başlatma süreçlerinin uzun sürmesidir. Eğer agent ayağa kalkarken veri yükleme gibi uzun işlemler yapıyorsa supervisor bunu başarısız durumuna düşürüp gereksiz alarm üretebilir.
Gerçek Hayat Senaryosu ve Çözüm Adımları
Bu araçları neden kullandığımı bir örnekle açayım. BIST veri çekme agentlarım bazen bellek sızıntısı yüzünden RAM tüketimini %90 seviyesine çıkarıyor. Bu durumda sistem kilitlenmeden önce psutil ile CPU ve RAM verilerini her 30 saniyede bir kontrol eden bir script çalıştırıyorum. Eğer RAM kullanımı kritik eşiği geçerse, sh kütüphanesi ile servisi durdurup tekrar başlatıyorum. Bu süreç tamamen otomatik işliyor.
Adım adım çözümüm şu şekilde:
Önce psutil ile sistem kaynaklarını okuyorum. Ardından bir if bloğu ile bellek kullanımını kontrol ediyorum. Eğer limit aşılmışsa sh.systemctl komutu ile servisi yeniden başlatıyorum. Eğer hata devam ederse fabric ile uzak sunucudaki log dosyalarını çekip hatanın sebebini inceliyorum.
Yolda Çıkan Hatalar ve Giderilme Yöntemleri
En büyük sorunum her zaman SSH zaman aşımları oldu. Fabric kullanırken bağlantı koptuğunda scriptim yarım kalıyordu. Bunu çözmek için bağlantı denemelerini bir döngü içine aldım ve her başarısız denemede 5 saniye bekleyip tekrar bağlanmasını sağladım.
Bir diğer hata ise systemd-python kullanırken yaşadığım yetki sorunuydu. Servisleri root olmadan yönetemediğim için scripti sudo yetkisiyle çalıştırmak yerine, ilgili servis dosyasında gerekli izinleri tanımlayarak güvenlik riskini azalttım. Bu sayede scriptlerim artık daha güvenli ve stabil çalışıyor.
Karşılaştırma: Neden Bu Araçlar?
Alternatif olarak Bash scriptleri yazabilirdim ama Python ile hata yakalama ve loglama yapmak çok daha kolay. Bash içerisinde bir hata oluştuğunda bunu takip etmek zorlaşırken, Python ile try-except blokları kullanarak her türlü hatayı anında yakalayıp e-posta veya mesaj yoluyla bildirim alabiliyorum. Circus ve Supervisor arasında seçim yaparken, daha basit yapılar için systemd tercih ettim ancak çoklu process yönetimi gereken karmaşık sistemlerde Supervisor'ın sunduğu arayüz ve log yönetimi benim için daha pratik oldu.
Toparlarsak
Arac seçimi zeka değil tekrar meselesidir. Hangi aracın nerede hata verdiğini bir kez yaşayınca bir daha aynı tuzağa düşmüyorsun. Aynı işe aynı aracı kullanmak zaman kazandırıyor.
Bundan sonra yapman gereken şey şu. Kendi trading agentların için yukarıdaki araçlardan birini seç ve sadece bir servis üzerinde deneme yap. Önce psutil ile kaynak tüketimini izle, sonra fabric ile uzak sunucuda bir komut çalıştırmayı dene. Hata aldığında hemen pes etme, çünkü bu araçların hepsi gerçek üretim ortamlarında test edilmiş ve olgunlaşmış yapılar. Kendi sistemini kurarken bu yapıların tuzaklarını bilerek ilerlemek sana saatler kazandıracak. Küçük bir script ile başla ve sistemi yavaş yavaş otomatize et. İlk adım olarak mevcut servislerini bir Python scripti üzerinden sorgulayarak işe başlayabilirsin.
Top comments (0)