...11011010110010...

Kontrol 1, 2, 3

Merhaba sevgi pıtırcıkları. Angaryos ‘du (TODO: buraya “angaryos yayında” yazısı tamamlanınca linki gelecek), kurumun işleriydi, ingilizceydi derken (pratik yapacak kadar boş vakti olanlar yeşillendirebilir)… uzun süredir yazamadım farkındayım. Daha önce uygulamaya karar vermiş olduğum “Ne kadar kısa yazı, o kadar yüksek reklam” kararım gereği; şuuraltı boşalmalarımı kişisel word yazılarıma saklayarak hemen mevzuya giriyorum!

Bu yazı donanım ve yazılım sistemlerin izlenmesi ve/veya kontrolü hakkında olacak.

Daha önce çeşitli vesilelerle bahsettim; ağınızı yapılandırdınız, sanallaştırma ortamınızı, depolama alanlarını kurdunuz, sanal makineler, servisler, yazılımlar hepsini ayağa kaldırdınız… Süper! Eğer tek node ‘dan (yazar, araya ingilizce terimler sokuşturarak “ben bu işten anlıyorum biraz. eheh*” mesajı vermek istemektedir) oluşan bir sanallaştırma altyapınız yoksa, yada servisler dediğiniz şey sadece ağ paylaşımları değilse, sistem size çok sevgili Ali Atay ‘ın da bahsettiği şeyi hemen hatırlatacaktır(!) Eksik bişey var.

Bazı makinelerin ram ‘i bitiyor, bazı containerler çalışmasına rağmen, anlamsız bir şekilde sorgulara cevap vermiyor, bazı görevler zamanında çalışmıyor, elastic search denen ram canavarı bazen loglarınızı tutmuyor, bazı karaktersiz müşteriler paranızı ödemiyor! Pardon. Evet. Herneyse. İşte tam burada moğolların da dediği gibi bişey yapmalı. Ki o bişey, sistemi devamlı izleyip problem daha farkedilmeden sorunları gidermeli. En kötü ihtimalle sorunun ilgilisini bilgilendirmeli.

Hatta görüyorum ve artırıyorum! Örneğin; sistem toner stoklarını ve yazıcıları aynı anda izlemeli, bir yazıcının toneri azalmaya başladığında eğer stokta yok ise stok görevlisi personele mobil bildirim göndermeli, stok 3 gün içinde temin edilmez ise müdürüne şikayet etmeli.

Bu ihtiyaç bana şunu düşündürüyor; ürün/üretim aslında bir kültür. Yazılımı sadece yazıp canlıya atmakla bitmiyor. Dökümanları, eğitimi, reklamı, desteği, hata giderme mekanizmaları… Hepsi küçümsenmeyecek kadar önemli bileşenler. Evet 1 milyonuncu işi de batırdıktan sonra artık böyle düşünüyorum.

Peki nasıl?
Bir kaç yaklaşım var. Benim şahsi fikrim burada revize bir “çevik” uygulamak. Zira koskoca nike bile “just do it” demiş yanılıyor olamazlar. Hemen başla, bişeyler yap sonra iyileştirirsin.

Özellikle bizim gibi sıfırdan bir geliştirme yapıyorsanız ve ilk paragrafta bahsettiğim gibi çok fazla bileşen varsa geliştiriciler başını log ‘dan, destekten kaldıramıyor. Önce bir merkezi izleme sistemi kurmak şart. Bırakın loglar akmaya devam etsin, sorunlar çıksın. Hepsini bir anda çözemezsiniz. Hiç bişey sizden önemli değil* İlk öncelik sistemi kurmak.

Burada çok alternatif var lisans bedeli öderim diyorsanız PRTG, biraz emek vermeyi göze alırsanız Zabbix, Daha derin bir izleme yapmak istiyorum diyorsanız Docker grafana stack, bla bla bla. Ama şunu bilerek başlamak gerek hiç bir ürün yüzde yüz bir kapsama sağlayamıyor. Siz onu ileriki iterasyonlarda kendi eklentilerinizle tamamlamaya çalışacaksınız.

Her seviye için farklı izleme methodları var. En temel seviye ssh, snmp yada wmi(yalnızca windows) diyebiliriz. Ssh için (genellikle) işletim sisteminizin kullanıcı adı ve şifre bilgilerini paylaşmak zorundasınız. Bu açıdan biz çok tercih etmedik. Snmp fiziksel makineleriniz, sanal makineleriniz, switchleriniz hatta yazıcılarınız için bile yeterli bence. WMI ‘a hiç ihtiyaç duymadım detayını bilmiyorum.

En temelden başladık, önce snmp ile fw ve switchlerimizi izledik. Ağ tıkanmaları bağlantı kopmaları vs tüm sorunlarımızı çözdü. Çok değil; 20 tane bile switchiniz olsa arada kopan switch i bulmak çok kolay olmayacakken sistem size daha kopma gerçekleştiği anda mail atıyor. Bu da ekibinize en az 1 saat kazandırıyor.

Baktık bu iş iyi; sonra fiziksel ve sanal sunucularımızı dahil ettik. Genel olarak ping, işlemci, ram, disk ve bağlantı hızını izlememiz yetti. Bazı eski servislerimizin çalışmaya başlaması için masaüstünün açılması gerekiyordu; onun için küçük bir script yazdık. Masaüstü açılması ile birlikte otomatik çalışıyor. Bu script belirli bir porttan http yayını yaparak sadece “OK” cevabı dönüyor. Makine açık olsa bile sistem o makinenin http servisinden “OK” cevabını alamazsa ilgili personele mail atarak masaüstünü açmalısınız diye bilgilendiriyor. Ayrıca ftp, db, ldap, radius gibi servislerimiz için de birer takipçi ayarladık.

Ardından ip kameralarımızı izlemeye başladık onlarca kamerayı teker teker takip etmek zor. Kamera kayıp zamanlarımız toplamda aylık bir kaç dakikaya kadar düştü.

Son olarak da mesai takip cihazları, UPS ‘ler, keos cihazları gibi ip sahibi herşeyi dahil ettik. Ha bide ta milattan önce arduino ile sıcaklık/nem sensörü yapmıştık onu da sunucu odamızı izlemek için ekledik. Sıcaklık yükselmeye başladığı anda teknik ekibe sms atıyor.

İlk aşamayı tamamladık. Bu bile bize bayağı bir mesai kazandırdı. Hem teknik ekibe hem yazılım tarafına. Çünkü merkezi bilgi sistemimiz tamamen docker üzerinde koşuyor. Yani sistem docker’ın bir getirisi olarak makine kapanması gibi durumlara zaten tahammüllü. Bunun yanında izleme monitörü sayesinde kayıplarda minimuma inince servis erişilememe gibi durumlara çok nadiren düştüğünü gördük. Eğer herşeyi kurum içinden kendiniz host etmeniz zorunluysa ram bitti, disk bitti, servis durdu gibi sorunlarla çok daha fazla kaşılaşıyorsunuz. Bulutcular bilmez (!)*

Sonra bilgi sistemimizin bileşenlerini irdelemeye başladık. İçerdeki servislerin hepsi için birer genel izleme ekledik. Backend, frontend, geoserver, radius, ldap hatta varnish için bile izleme eklentileri var. Tüm servislerimizin çalıştığı dışarıdan teyit ediliyor.

Bazı görevlerimiz var. Mesela personele mesai oluşturulması gibi, mesela araç atanmamış taleplerin gün sonunda iptal edilmesi gibi. Bu görevlerin en son problemsiz gerçekleşme zamanını tutmaya başladık. İzleme sistemine de bunu kontrol etmesini söyledik. Şuan herhangi bir sebepten görevler aksamaya başlarsa hemen yazılım ekibine mail atılıyor.

Sonra farkettik ki elasticsearch bazen logları yakalayamıyor. Ram kaynaklı olabileceğini düşünüyoruz çünkü her gece container yeniden başlatılınca hata ortadan kalktı. Bunun için de bir yeniden başlatma görevi oluşturup bunun kontrolünü de yine izleme merkezine bıraktık.

Ağ depolamalarımız için kurum içinde ve dışında bir kaç replike sunucumuz var. Rutin olarak belirli zamanlarda her sunucu bir alt sunucusunu replike ediyor. Bunun bazen koptuğunu gördük. Hemen mini bir python script yazdık. Bu script kendi üzerindeki replikasyonu kontrol ederek bir http servisinden “OK” cevabını dönüyor. İzleme merkezimiz her sunucuyu ziyaret ederek zincirin nerede koptuğunu hemen tespit edebiliyor.

Velhasıl izleme monitörü bir sistemin olmazsa olmazı. Yemyeşil bir sayfanın içinde kırmızı bir nokta hemen göze çarpıyor. Yoksa onlarca bileşeni bir kaç göz ile manuel kontrol etmek hem sürdürülebilir değil hem de problem ayyuka çıktığında yada işler daha kötü olduğunda çok daha fazla mesai harcamak zorunda kalıyorsunuz.

Sağlıcakla.

« »