n8n Sunucuda İzleme Sistemi Nasıl Kurulur?

n8n iş akışları üretim ortamında çalışıyorsa yalnızca uygulamanın açık olup olmadığını kontrol etmek yeterli değildir. Kuyrukta bekleyen işler, başarısız workflow çalıştırmaları, bellek tüketimi, disk doluluğu ve webhook yanıt süreleri düzenli izlenmelidir. Bu nedenle n8n izleme sistemi, kesintileri erken fark etmek ve otomasyon süreçlerini güvenle yönetmek için kritik bir operasyon katmanı oluşturur.

İzleme için temel gereksinimleri belirleme

Kuruluma başlamadan önce hangi metriklerin iş açısından önemli olduğunu netleştirmek gerekir. Küçük bir n8n kurulumu için erişilebilirlik, CPU, RAM, disk kullanımı ve hata logları yeterli olabilir. Daha yoğun yapılarda ise execution sayısı, başarısız görev oranı, queue durumu, veritabanı bağlantıları ve webhook gecikmeleri de izlenmelidir.

n8n Docker üzerinde çalışıyorsa container sağlığı, restart sayısı ve volume kullanımı ayrıca takip edilmelidir. PostgreSQL, Redis veya reverse proxy gibi bileşenler ayrı servisler olduğundan izleme kapsamına dahil edilmelidir.

n8n metriklerini aktif hale getirme

n8n, uygun yapılandırma ile Prometheus uyumlu metrikler sunabilir. Bunun için ortam değişkenlerinde metrik desteği etkinleştirilir ve metriklerin hangi endpoint üzerinden okunacağı belirlenir. Bu ayarı yaparken endpoint erişiminin herkese açık olmamasına dikkat edilmelidir.

En sık yapılan hata, metrik endpoint’ini doğrudan internete açmaktır. Bunun yerine yalnızca izleme sunucusunun erişebileceği özel ağ, firewall kuralı veya reverse proxy kısıtlaması kullanılmalıdır. Kurumsal yapılarda temel kimlik doğrulama veya IP bazlı erişim kuralı tercih edilebilir.

Prometheus ile veri toplama

Prometheus, n8n ve sunucu metriklerini belirli aralıklarla okuyarak zaman serisi veri tabanında saklar. Yapılandırmada scrape interval değeri çok düşük seçilirse gereksiz yük oluşabilir; çok yüksek seçilirse sorunlar geç fark edilir. Genellikle 15-30 saniye aralığı dengeli bir başlangıçtır.

Prometheus yapılandırmasında n8n servis adresi, node exporter ve varsa PostgreSQL exporter ayrı hedefler olarak tanımlanmalıdır. Böylece uygulama, işletim sistemi ve veritabanı aynı panelden karşılaştırılabilir. Örneğin workflow hataları artarken aynı anda bellek kullanımı yükseliyorsa sorun yalnızca n8n tarafında değil, sunucu kapasitesinde de olabilir.

Grafana paneli oluşturma

Grafana, Prometheus’tan gelen verileri okunabilir panellere dönüştürür. İlk panelde genel sistem sağlığı, CPU, RAM, disk ve ağ trafiği yer almalıdır. İkinci panelde n8n’e özel metrikler, çalışma sayıları, hata oranları ve yanıt süreleri takip edilebilir.

Dashboard tasarlarken yalnızca teknik ekibin anlayacağı karmaşık grafikler yerine karar vermeyi kolaylaştıran göstergeler kullanılmalıdır. Kritik workflow hata oranı, son 24 saatte başarısız execution sayısı ve disk doluluğu gibi metrikler operasyonel açıdan daha hızlı aksiyon alınmasını sağlar.

Uyarı kuralları ve bildirim kanalları

İzleme sisteminin değer üretmesi için uyarı mekanizması doğru kurgulanmalıdır. Sunucu tamamen kapandığında bildirim almak önemlidir; ancak asıl fayda, sorun büyümeden önce uyarı üretmektir. Disk kullanımı yüzde 80’i geçtiğinde, RAM uzun süre yüksek kaldığında veya n8n belirli süre yanıt vermediğinde alarm çalışmalıdır.

Bildirimler e-posta, Slack, Microsoft Teams veya kurumsal olay yönetim sistemi üzerinden gönderilebilir. Yanlış pozitif uyarıları azaltmak için her kuralda kısa bir bekleme süresi tanımlanmalıdır. Örneğin CPU kullanımının birkaç saniye yükselmesi alarm üretmemeli, belirlenen eşik birkaç dakika boyunca aşılırsa bildirim gönderilmelidir.

Log takibi ve hata analizi

Metrikler ne olduğunu gösterir, loglar ise neden olduğunu anlamaya yardımcı olur. n8n logları, container logları ve reverse proxy kayıtları merkezi bir log yönetim sistemine aktarılabilir. Basit kurulumlarda Docker logları düzenli kontrol edilebilir; daha büyük ortamlarda Loki, Elasticsearch veya benzeri çözümler tercih edilebilir.

Log saklama süresi planlanırken disk kapasitesi göz önünde bulundurulmalıdır. Gereğinden uzun saklanan ayrıntılı loglar maliyet ve performans sorunu yaratabilir. Hassas verilerin loglara düşmemesi için workflow tasarımında kimlik bilgileri, token ve müşteri verileri dikkatli yönetilmelidir.

Bakım ve kapasite planlaması

n8n izleme sistemi kurulduktan sonra panellerin düzenli gözden geçirilmesi gerekir. Yeni workflow eklendikçe yük profili değişebilir; eski alarm eşikleri yetersiz veya fazla hassas hale gelebilir. Aylık kontrol rutini oluşturarak disk büyümesi, execution trendleri ve hata kaynakları incelenmelidir.

Canlı ortamda değişiklik yapmadan önce test sunucusunda metrik endpoint’i, Prometheus hedefleri ve Grafana panelleri doğrulanmalıdır. İzleme kapsamı önce temel servislerle başlatılıp ardından veritabanı, kuyruk sistemi ve kritik workflow bazlı uyarılarla genişletildiğinde daha yönetilebilir bir yapı kurulur.