Libreoffice Çalışmalarım-2

 Herkese merhaba,
 
 Üçüncü sınıftayken Libreoffice katkı vermeye başlamış, 13 kişilik bir ekiple birlikte çalışmıştım. Çok güzel işler yaptık ve daha önceki blog yazılarımda bu işlerden bahsetmiştim. Dördüncü sınıfta da Libreoffice katkı vermeye devam ediyorum.

 Hakkında blog yazdığım Libreoffice Math aracı ile ilgili çalışmamdan sonra Libreoffice'ın bir çok farklı işleriyle ilgili katkı verdim. Bunlar hakkında özel blog yazıları yazmamıştım. Bu yıl ilk kabul edilen yamamla birlikte şimdi neler yaptığımla ilgili kısaca yazmış olmak istedim.

Bu yılın kabul edilen ilk yamasında arka planda kod iyileştirmesi yaptım. Daha önce uğraşmadığım bir iş olan makro fonksiyonlarla çalıştım. Yeni bir makro fonksiyon tanımlaması ve kullanımıyla ilgili bir iş yaptım. Bir süre daha makrolarla ilgili çalışmaya devam edeceğim.

 Söylemeden geçemeyeceğim bir şey var ki; yazın stajda ELK, elastalert ve docker üzerine yaptığım çalışmalardan sonra tekrar "It has been merged to LibreOffice." yazan mailin sevincini yaşamak güzel bir duyguydu :)

 Bu senede +Necdet hocamın yön göstermesi ile daha güzel işler yapacağım ve size de güzel haberler vereceğim :)

On İki Faktör Uygulaması

 12 Faktör uygulamasının hizmet olarak yazılım uygulamalarını oluşturmak için metodolojisi vardır:

• Ayar otomasyonu için  bildirim formatları kullanır, projeye katılan yeni geliştiriciler için zaman ve maliyeti aza indirmek için.
• Yürütme ortamları arasında maksimum taşınabilirlik sunan temel işletim sistemi ile clean contract vardır.
• Modern bulut platformları üzerindeki dağıtım için uygun, sunucu ve sistem yönetimi ihtiyacını ortadan kaldırır.
• Maksimum çeviklik için sürekli dağıtım sağlayan geliştirme ve üretim arasındaki ayrışmayı en aza indirir,
• Ve önemli değişiklikler dışında, mimari ve geliştirici uygulamaları düzeyinde ölçeklendirilebilir.

On iki faktör uygulaması herhangi bir programlama dili ile yazılmış uygulamalara uygulanabilir ve istediğiniz yardım servislerinden herhangi birini kullanabilirsiniz.

Bu belgeye katkı veren kişiler doğrudan ilgili geliştiriciler, yüzlerce uygulama geliştirmiş, tanıklık etmiş ve heroku platformun da çalışmalarda geliştirme yapmıştır. Bu döküman, katkıcıların deneyim ve gözlemlerini sentezler. Katkıcıların amacı modern yazılım geliştirmede gördükleri sorunların bilincini arttırmak, sorunları tartışıp ortak ve kavramsal bir çözüm sağlamaktır.

Herhangi bir çalışan uygulama geliştiren mühendisler okumalıdır.

                                    12 FAKTÖR

1) Codebase(Kod Tabanı)

   Bir codebase bir çok uygulamanın sürüm kontrolünü incelemektedir. 12 faktör uygulaması  her zaman sürüm kontrol sisteminde izlenir, Git , Mermcurial, Subversion gibi. Sürüm takip, kod tabanının bir kopyası, kod deposu olarak bilinir. Bir codebase herhangi tek bir depo(Subverison) ya da kökü paylaşan bir dizi depodur(Git).

Codebase ile uygulama arasında bire bir ilişki her zaman vardır:

   Birden fazla codebase varsa bu bir  uygulama değil dağıtık sistemdir. Dağıtık sistemin her birleşeni bir uygulama olup on iki faktöre uygun olmalıdır.
   Aynı kodu paylaşan birden fazla uygulama on iki faktörü ihlal eder. Çözüm paylaşılan kodları kütüphane ile dahil etmek olabilir.

 Uygulamanın sadece bir codebase vardır fakat birden fazla dağıtımı olacaktır. Bir dağıtım uygulamanın çalışan bir örneğidir. Ayrıca her geliştiricinin kendi yerel geliştirme ortamında çalışan bir kopyası vardır, her biri aynı zamanda dağıtım olarak nitelendirilirler.

Sürümler her bir dağıtımda etkin olabilir fakat kod temeli tüm dağıtımlrda aynıdır. Örneğin geliştiricilerin henüz uygulamaya eklenmemiş commitleri olabilir. Bu nedenle hepsi ayrı dağıtım olarak tanımlanır ama kod temeli aynıdır.

2)  Dependencies(Bağımlılıklar)

   Çoğu programlama dili yardım kütüphaneleri dağıtımı için paketleme sistemi sunuyor. Paketleme sistemi sayesinde yüklenen kütüphaneler  sistem geneline yüklenir ya da uygulamayı içeren dizinlerdir. Tüm bağımlılılar açıkça bağımlılık bildirimi yoluyla, apacık ve kesin olarak bildirilirler. Ayrıca  çevreleyen sistemden itibaren açık bağımlılıkları için uygulama sırasında bir bağımlılık aracı kullanılır. Tam ve açık şartname uygulama ve geliştirmede eşit uygulanır.

   Ne olursa olsun araç zinciri, bağımlılık beyanı ve izolasyon her zaman birlikte kullanılmalıdır. Sadece biri on iki faktörü karşılamak için yeterli değildir.

Açık bağımlılık bildiriminin yararlarından biri de yeni geliştiriciler için kurulumu kolaylaştırmasıdır. Yeni geliştiriciler onların geliştirme makineleri üzerinde, uygulama codebase çıktısını kontrol eder, bağımlılık yöneticisi ön koşulları yükler ve sadece çalışma zamanını zorunlu tutar.


3) Config (Yapılandırma)

     Bir uygulama yapılandırması çeşitli dağıtımlar arasındaki farklılıkların muhtemel hepsidir. Bunları içerir:

• Kaynak veritabanı, Memcached ve diğer destek hizmetleri kolları
• Dış hizmetlerin(twitter, amazon gibi) kimlik bilgileri
• Dağıtım için dağıtıma göre standart hostname

Uygulamaların bazen koddaki depo yapılandırmaları sabittir. Bu on iki faktöru ihlal eder, bu yapılandırma koddan ayrılmalıdır. Bir turnusol testi için uygulamanın faktor çıktılarının doğru yapılandırılıp yapılandırılmaması, kodun codebasenin herhangi bir zamanda kimlikten ödün vermeden açık kaynak kodlu olup olmadığıdır.

Bu bildirim yapılandırması uygulama içindeki yapılandırmaya dahil edilmez. Yapılandırma dağıtımlar arasında değişmez ve en iyi kod yazılır. Başka bir yaklaşım ise yapılandırma dosyaları kullanılmasıdır örneğin Rails de "config/database.yml" . Bu depo sabitleri kullanarak üzerinde büyük bir değişiklik olduğunda kontrol edilir, ancak yine de zayıflıklar vardır. Yapılandırmayı yönetmek için yapılandırma dosyalarının farklı yerlerde ve farklı biçimlerde olması için bir eğilim vardır. Bundan başka dile veya yapıya özel olma eğilimi vardır.

On iki faktör uygulaması depoları çevre değişkenleri olarak yapılandırılır. Kod değiştirmeden dağıtım arasında geçiş yapmak yapılandırma dosyalarının aksine kolaydır.

  Yapılandırma yönetiminin bir diğer yönü gruplandırmadır. Ortamlar olarak gruplandırılır fakat bağımsız olarak her dağıtım için yönetilir. Bu yöntem sorunsuz olarak doğal ömrü boyunca daha fazla dağıtımla genişler.

4) Backing Service(Destek Hizmeti)

Bir destek uygulaması herhangi bir uygulama ağ bölümlerinde, normal işlem üzerinden daha fazla tüketilir. Örneğin, stmp hizmetleri, ön belleğe alma sistemleri, kuyruk sistemleri. Veri tabanı gibi yardım sistemleri bazı sistem yöneticileriyle geleneksel olarak yönetilmeli, uygulama gerçek zamanlı dağıtılmlıdır. Bu yerel yönetim hizmetlerine ek olarak, uygulama aynı zamanda üçüncü şahıslar tarafından sağlanan ve yönetilen servisler olabilir. Örneğin Api, stmp hizmetleri, google maps...

On iki faktör uygulaması için kod yerel ve üçüncü taraf hizmetleri arasında bir ayrım yapmamaktadır. Uygulama da yapılandırma içinde her ikisi de  kaynaklara bağlı, url bağlama yolu ya da kimlik saklama ile olmalıdır. On iki faktör uygulamasında bir dağıtım, uygulamanın kodunda herhangi bir değişiklik olmadan üçüncü bir uygulama tarafından yönetilen tek bir yerel MySql veritabanı takası gerektirir. Aynı şekilde bir yerel  Stmp sunucusu kod değişikliği olmadan bir üçüncü uygulama Stmp hizmeti ile takas olabilir. Her iki durumda da yapılandırma da sadece kaynak tanıtıcı değiştirilmelidir. Her ayrı destek hizmeti bir kaynaktr. Kaynaklar eklenir ve istediği zaman ayrılabilir.

5) Build,Release,Run(Derle, Sürüm ,Çalıştır)

  Bir  kod tabanında değişim üç aşamadan oluşur:

• Build aşaması: yapı olarak bilinen bir yürütülebilir paket içini bir kod deposuna dönüştürür.
• Release aşaması: Build aşamasında oluşturulan yapıyı alır ve dağıtmak için mevcut yapılandırma ile birleştirir. Ortaya çıkan yapı yürütme ortamında çalıştırılmak için hazırdır.
• Çalışma aşaması: Uygulama süreçlerini başlatarak yürütme ortamında uygulamayı çalıştırır.

12 faktör uygulaması bu aşamalar arasında katı bir ayrım kullanır. Örneğin zamanında kod değişikliği yapmak mümkün değildir çünkü build aşamasındaki değişiklikleri yaymak için bir yol yoktur. Dağıtım araçları, genellikle sürüm yönetim araçları, bir önceki sürüme almak için olanak sağlar.

Örneğin Capistrano dağıtım aracı sürümleri releases dizini altında tutar, şimdiki sürümü current release dizininde tutar. Geri dönüşü de rollback komutu ile hızlıca sağlar.
Her sürüm her zaman eşsiz bir sürüm id'sine sahip olmalıdır. Herhangi bir değişiklikte yeni bir sürüm oluşturmanız gerekir.

   Yeni kod dağıtıldığında her uygulamanın geliştiricileri tarafından build başlatılır. Çalışma zamanlı uygulamalar karşılaştırılmalara göre  reboot hizmeti durumunu otomatik yapabilir ya da davetsiz bir süreç, süreç yöneticisi tarafından başlatılabilir. Bu nedenle çalışma aşamasında mümkün olduğunca az hareketli parça tutulmalı, geliştirici elle yapmadığında gece olan kırılmalar uygulama çalışırken önlenir. Dağıtıma sürülen hatalar geliştiriciler için daha önemli olduğundan build aşaması karmaşık olabiliyor.

6) Processes(Süreçler)

  Uygulama bir veya daha fazla işlem olarak yürütme ortamında yürütülür. En basit durumda kod bir stand-alone script ile yürütme ortamı bir geliştirici yerel dil çalıştırma ile ve süreç komut satırı ile başlatılabilir.

On iki faktör süreçleri durum bilgisi olmayan, paylaşımdan başka bir şey değildir. Süreklilik gerektiren bir veri bir durum bilgisi olan destek hizmeti, tipik bir veritabanında saklanmalıdır.
Sürecin bellek alanı veya bir dosya sistemi özeti tek aktarımlı önbellek olarak kullanılır. Örneğin büyük bir dosya indirirken üzerinde faaliyet gösteren işlemleri ve veritabanındaki işlemin sonuçlarını saklamak. On iki faktör uygulaması bellek veya disk üzerinden önbelleğe aldıklarını bir iş gelecek veya zaten var olduğunu varsayar. Tek bir süreç çalışırken yeniden başlatma genellikle tüm yereli silecektir.
Varlık paketleyici derlenmiş varlıklar için önbellek olarak dosya sistemi kullanır.

7) Port Binding(Port Bağlamı)

Web uygulamaları bazen bir web sunucusu container'ı içinde yürütülür. Örneğin php uygulamaları apache içinde bir modül olarak çalışabilir veya java uygulamaları Tomcat içinde çalışabilir.

On iki faktör uygulaması tamamen kendi kendine yeter. Bir web uygulaması port bağlayıcısı tarafından servis olarak http ile dışa aktarır ve port üzerinden gelen istekleri dinler.

Bir yerel geliştirme ortamında, geliştiriciler dışa aktarılan servislere erişmek için Url gibi örneğin "http://localhost:5000/" ziyaret ederler. Dağıtımda bir yönlendirme katmanı, port-bound web işlemlerine göre, public-facing ana makineden itibaren yönlendirme isteklerini işler.

   Bu tipik uygulama kullanılan bağımlılık bildirimleri tarafından web-server kütüphanelerine eklenir. Bu durum kullanıcı alanında uygulama kodunun içindedir. Yürütme ortamı ile sözleşme istekleri hizmet için bir bağlantı noktasıdır.

     Http yalnızca servis değil, port bağlayıcıları tarafından dışa aktarılır. Neredeyse her tür yazılım servisleri için porta göre süreç bağlayıcıları üzerinde çalışır ve gelen istekleri bekler.

    Port bağlama yaklaşımının anlamı; tüketen uygulamalar için yapılandırmada cevap olarak işlenen destek uygulamaları ile birlikte, Url sağlayıcıları tarafından bir uygulama, diğer uygulamalar için servis bağlayıcısı olmalıdır.

8) Concurrency(Eş zamanlılık)

   Bir bilgisayar programı çalıştırıldığında bir veya bir çok süreç ile temsil edilir. Web uygulamaları süreç yürütme biçimlerinde çeşitlidir. Örneğin Php süreçleri apache için çocuk süreçler çalıştırılır, istek değerleri tarafından gerektiğinde başlatma talep eder. Java süreçleri ters yaklaşım kabul etmektedir. Her iki durumda da çalışan süreçler uygulamalar için geliştiricilere göre minimal görünür.

  On iki faktör uygulamasında süreçler birinci sınıf vatandaşlardır. On iki faktör uygulaması süreç servislerini çalıştırmak için unix süreç modellerinden güçlü ipuçları alır.  Kullanılan bu model de çalışan süreç tipleri için belirtilen her bir tip tarafından çeşitli iş yükü kullanımına göre diğer uygulamaları planlar. Bu tür bireysel süreçler kendi iç dışlama kullanılarak dışa aktarılmaz, thread üzerinde bulunan çalışma zamanlı VM kullanılır ama bireysel VM çok büyüyebilir, bu nedenle çoklu fiziksel makine üzerindeki bir çok süreci kapsamalıdır. On iki faktör uygulamalarının daha eşzamanlı basit ve güvenirlir bir işlem olduğu anlamına gelir. Bu dizi süreç tipleri için ve her tip süreç numarası için tip formatı olarak biliniyor.

  On iki faktör uygulaması süreçleri bekletmez ve PID dosyasına yazmaz. Bunun yerine, çıktı akışlarını yönetmek için işletim sisteminin süreç yöneticisine güvenir, çöken süreçlere cevap verir, kullanıcı üyeliği kabul edilmiş kullanıcı tarafından yeniden başlatılır ve kapatılabilir.

9) Disposability(Kullanıma Hazır Olma Durumu)

  Hızlı başlatma ve zarif kapama ile sağlamlık seviyesini en üst düzeye çıkarmak. On iki faktör uygulaması süreçleri kullanıma hazır olmalı, amaç bir anlık bildirimle başlatmak ya da bitirmek. Bu hızlı ölçekleme kod için geliştirimi ve yapılandırma değişikliğini kolaylaştırır ve üretim dağıtımı için sağlamlığı kolaylaştırır. Süreçlerin başlatma süresini en aza indirmek için çaba gerekir. İdeal olarak, süreçlerin bir süre için, sürecin yükselmesine kadar, komut başlatması gerekir ve işlemleri karşılamak için hazırlık zaman almaktadır. Süreci bırakmak, yükseltmek ve yardım sağlamak için kısa başlama süresi atiklik sağlayacak. Çünkü süreç yöneticisi izin verdiğinde yeni fiziksel makineler için süreç hareketi kolaylaşacak. Süreç işlem yöneticisinden SIGNTERM sinyali aldığında duracaktır.

Web süreçlerinde zarif kapatma, port servisleri üzerinde dinleme kesilmesiyle elde edilir, herhangi bir geçerli istek, bitirmek için izin verir ve kapatır.

Çalışan süreç için zarif kapatma, çalışma sırasına göre şimdiki işi dönderme ile elde eder.

Süreçler donanımda bir arıza olması durumunda ani kesilmelere karşı güçlü olmalıdır. Bu SIGTERM ile zarif kapatmada çok daha az sık rastlanan bir durum olmasına rağmen olabilir. Sağlam bir kuyruk olan arka uç kullanılmalıdır. Her iki durumda da, on iki faktör uygulaması beklenmedik işlemleri, zarif olmayan kapanışları planlar. Crash-only tasarım mantıksal sonucuna göre bu kavramı ele alır.

10) Dev/prod parity

Tarihle ilgili ürün ve geliştirme arasında önemli boşluklar oluşmuştur. Bu boşluklar üç alanda gerçekleşir:

• Time gap: Bir geliştiricini üretime geçmek için kod çalışması günler haftalar aylar sürebilir.
• Personel gap: Geliştiriciler kod yazıyor, ops mühendisleri dağıtır.
• Tools gap: Geliştiriciler ürün dağıtımında Apache,MySQL ve linux kullandığında, nginx, SQlite ve OSx gibi bir yığın kullanıyor olabilirler.

On iki faktör uygulaması üretim ile dağıtım arasındaki boşluğu tutarak sürekli dağıtım için tasarlanmıştır. Bu üç boşluğa baktığımız da:

• Time gap küçültmek: Bir geliştirici kod yazdığı zaman saatler hatta dakikalar sonra bile dağıtmak mümkün.
• Personel gap küçültmek: Kod yazan geliştiriciler dağıtımı yakından izlerler.
• Tools gap küçültmek:  Üretim ve dağıtım mümkün olduğunca benzer sürdürürler.

Tabloyla özetlemek gerekirse:
                                       
                                                         Geleneksel uygulama                    12 Faktör uygulaması

Dağıtım arasındaki zaman                Hafta                                              Saat

Kod yazarları ve kod dağıtıcıları      Farklı kisiler                                   Aynı kişiler

Üretim ve geliştirme ortamı               Farklı                                             Mümkün olduğunca benzer


Yedekleme hizmeti, veritabanı, kuyruk sistemi ya da önbellek /dev/prod da önemli bir alandır. Bir çok dil yardım hizmetlerine erişimi kolaylaştırmak için kütüphaneler sunar. Bazı geliştiriciler üretimde daha güçlü ve ciddi yardım hizmetlerini kullanmak için  yereldeki hafif destek hizmetlerine başvuruyorlar.

12 faktör uygulamaları geliştirme ve dağıtım arasındaki farklı yardım hizmetlerine karşıdır. Destek hizmetleri arasındaki farklılıklar geliştirilirken  kod çalıştırma ve test etme bağlantıları kesebilir ya da üretimde fail verebilir. Bu uygulamanın ömrü boyunca düşünüldüğünde maliyeti oldukça artırır.

Hafif yerel destek hizmetleri daha az zorlayıcıdır. Modern yardım hizmetlerinin yüklemesi ve çalıştırması modern paketleme sistemleri sayesinde zor değildir, apt gibi. Bu sistemlerin kurulması ve kullanılmasının maliyeti "dev/prod" bölümü ve sürekli dağıtım yararına oranla düşüktür.

Yeni destek hizmetlerine geçiş yapmak için hala farklı yardım hizmetlerinin uyarlayıcıları kullanılıyor. Fakat tüm dağıtım uygulamalarının kullandıkları tip ve versiyon her bir yardım sistemi için aynı olmalı.


11)Logs (Kayıtlar)

Olay akışlarının işlenmesidir.

Loglar çalışan bir uygulamanın davranışlarında görünürlük sağlar. Sunucu tabanlı ortamlarda genellikle diskteki bir dosyaya yazılır fakat bu sadece bir çıkış yöntemidir. Loglar çalışan süreçlerin ve yardım hizmetlerinin zamanla bağlantılı olay akışlarının toplamıdır. Logların sabit başlangıcı ve sonu yoktur, uygulama çalışırken sürekli akış olur.

12 faktör uygulaması asla çıktı akışını yönelendirme ve depolamayla ilgilenmez. Yazmamalı veya log dosyası yönetmeye kalkışmamalısınız. Bunun yerine, her çalışan süreç olay akışını stduo ile yazıyor. Yerel geliştirme sırasında, uygulama davranışlarını kendi terminalinde gözlemlemek için akışları ön plan da izler. Her işlem akışı ele alınır çevre ortamları tarafından, diğer uygulama akışlarıyla birlikte karşılaştırılır ve arşivlerde görüntülemek üzere nakledilir. Bu hedef arşiv uygulama tarafından görünür veya yapılandırılabilir değildir. Onun yerine uygulama ortamı tarafından tamamen işlenir. Açık kaynak yönlendiricileri bu amaçla kullanılır(Logplex).

Bir uygulama için olay akışı bir dosyaya yönlendirilebilir veya bir terminalde zamanlı kuyruk üzerinden izlenebilmektedir. En önemlisi, akış bir günlük indeksleme ve analiz sistemine gönderilebilir. Bu sistemler uygulamanın zamana bağlı davranışlarını ölçmek için büyük güç ve esneklik sağlar:

• Geçmişte belirli olayları bulmak.
• Eğilimlerin büyük ölçekli grafikleri.(Örneğin dakika başına istekler)
• Kullanıcı tanımına uygun olarak uyarı verir.( Örneğin hata miktarı belli bir eşiği aştığında uyarı gönderir. )

12) Admin Proccess( Yönetici süreci )

Bir defaya mahsus admin yönetici görevlerini çalıştırmak.

   Süreç oluşumu uygulamanın düzenli iş yapması için kullanılan süreç dizisidir. Ayrı olarak, geliştiriciler yönetimi ve bakımını bir defaya mahsus yapmak isterler:

•    Veritabanı göçleri çalıştırmak
•    Çalıştırılan konsol rasgele kodları çalıştırır veya canlı veritabanına karşı uygulamanın modellerini inceler. Çoğu dil bir Repl'i çalışan yorumlayıcı tarafından sağlar , herhangi bir argüman olmadan veya bazı durumlarda ayrı komutlara sahip olarak. 
•     Uygulamanın depo içine işlenen tek seferlik komut dosyalarını çalıştırır.

   Bir kerelik yönetici işlemleri, uygulamanın düzenli uzun soluklu süreçleri olarak özdeş bir ortamda çalıştırılmalıdır. Çalışan bir sürüme karşı herhangi bir işlem, sürüme dayalı olarak yapılandırılmalı ve benzer kod tabanı kullanılmalıdır. Yönetici Kod senkronizasyon sorunlarını önlemek için uygulama kodu ile göndermeniz gerekir.

Aynı bağımlılık izolasyon teknikleri tüm süreç türlerinde kullanılmalıdır. Örneğin eğer ruby web servisleri  bundle exec thin start komutunu kullanıyorsa, veritabanı göçü içinde bundle exec rake db:migrate kullanmalıdır.

12 faktör  bir Repl kabuk çıktısında kutular için güçlü dil desteği sağlar bir defaya mahsus. Yerel dağıtımlarda, geliştiriciler uygulamanın çıkış dizini içinde doğrudan kabuk komutu ile tek seferlik yönetici işlemleri başlatırlar. Bir ürün dağıtımında geliştiriciler ssh veya diğer uzak komut erişim mekanizmalarını böyle bir işlemi başlatmak için kullanırlar.

Kurallar için Filtre Yazımı

query_string: Bölümler için kullanılır veya çoklu alanlarda tam eşleşme sağlar. Lucene sorgu formatını takip eder.

filter:
- query:
    query_string:
      query: "username: bob"
- query:
    query_string:
      query: "_type: login_logs"
- query:
    query_string:
      query: "field: value OR otherfield: othervalue"
- query:
    query_string:
      query: "this: that AND these: those"

term: Kesin alanlarla eşleşir.

filter:
- term:
    message: "foo"


Şeklinde filtreleme yaptığımız zaman, logların mesaj alanlarında foo geçen tüm loglarla eşleşir.  Aşağıdaki örneğe baktığımız da 5 tane log message alanında   foo olan log gelmiş ve hepsi ile eşleşme sağlanmış.

 















terms: Birden fazla değerle eşleşmesi için basit bir kombinasyonu vardır:

filter:
- terms:
    message: ["foo", "infoowl"]

Log message foo ve infoowl olan loglarla eşleşir.

wildcard: ‘?’( Tek harf değerinde ), ’*’(  Kullanış göre içindeki tüm karkterleri temsil eder.  ) gibi özel karakter kullanmak için.

filter:
- query:
    wildcard:
      field: "foo*bar"

not, and, or :

filter:
- or:
    - term:
        field: "value"
    - wildcard:
        field: "foo*bar"
    - and:
        - not:
            term:
              field: "value"
        - not:
            term:
              _type: "something"

ElastAlert Kural Tipleri

*Kural örnek yapılandırma dosyasında ilgili yerlerde değişiklik yapıp, eklenmesi gerekenler eklenmiştir. 

Any ( Verilen herhangi bir filtreleme ile eşleştiğinde alert oluşur. )
…
name: log_any
type: any
..
filter:
  - query:
      query_string:
          query: "version:1"

version alanı 1 olan tüm sorgular için alert oluşturur.

Frequency( Belli bir zaman diliminde olayların en az belli bir sayıda eşleşme olduğunda alert oluşur.)

name: log_error
type: frequency
num_events: 1
timeframe:
  minutes: 1
filter:
  - query:
      query_string:
          query: "level:ERROR"

Eğer bir dakikada log seviyesi Error olan bir log varsa alert oluşturur. 

Flatline ( Belli bir zamanda eşleşen sorgu sayısının verilen eşik değerinden az olmasıyla alert oluşturur. )

  name: log_flatline
  type: flatline
  threshold: 5 // ‘den fazla olunca eşleşmiyor. 
  timeframe: 
        minute: 1
 filter:
    - query:
      query_string:
                query: "version:1"

version değeri 1 olan sorgular 1 dakikadan  5 den az ise alert oluşturur.

Blaclist ( liste’de var ise alert oluşturur. )

name: log_blacklist
type: blacklist //içerirse eşleşir.
blacklist:
“message” //aranacak kelime
compare_key: message //aranacak yer


Eğer message kelimesi logların message alanında geçiyorsa alert oluşturur.

Whitelist ( Verilen değer listedeki alanla eşleşmiyorsa alert oluşturur.  )

name: log_whitelist 
type: whitelist 
whitelist:
“infoowl” //liste bunu içermiyorsa eşleşir
compare_key: message
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor

Eğer infoowl kelimesi logların message alanında geçmiyorsa alert oluşturur.

Cardinality ( Belli bir zamanda belirli alandaki benzersiz değerlerin sayısı verilen eşik değerinden düşükse alert oluşturur. )

name: log_cardinality
type: cardinality 
cardinality_field: “host”
min_cardinality: 5 

timeframe:
      minutes: 1


loglardaki host alanında oluşan benzersiz değerler bir dakikada 5’den düşükse alert oluşturur.

Change ( Bir alan bir süre içerisinde iki farklı değere sahip olduğunda alert oluşturulur. )

name: log_change
type: change 
compare_key: message    //değişikliğin kontrol edileceği alan
ignore_null: True olduğunda compare_key olanı olmadan eşleşme yapmıyor
query_key: host  (kontrol edilmiş olayların hepsinde bu alan olmalı)

timeframe:
  minutes: 1

1 dakika da Host alanı olan ve message alanında değişiklik olduğunda alert oluşturuyor.

Örnekler

Örnek 1
Alerti thread_name alanında değişiklik olursa

name: log_error
type: change
index: logstash-*
compare_key: thread_name
ignore_null: True
query_key: host

Çıktıda hem yeni hem eski değerini çıktı olarak vermektedir:

level: ERROR
level_value: 40000
logger_name: com.example.DemoApplication$$EnhancerBySpringCGLIB$$2bec2634
message: New Error
new_value: http-nio-8080-exec-6
old_value: http-nio-8080-exec-5
thread_name: http-nio-8080-exec-6
type: syslog

Örnek 2
Mesaj kısmında Yıldız geçip ay geçmeyen loglar

type: blacklist
blacklist:  
   - "Yıldız"
compare_key: message

filter:
  - not:
      term:
         message: "ay"

Örnek 3
Mesajda a ve b olup c ve d olmaması. Eğer terms: message: [“a”,”b”] yazarsak sadece a ya da b olduğunda da eşleşme oluyor.

type: frequency
filter:
   - term:
       message: "a"
   - and:
      - term:
          message: "b"
   - and:
     - not:
        terms:
          message: ["c","d"]

Elastalert Kural Yapılandırma Dosyası

Elasticsearch, Logstash ve Kibana giderek artan log ve verileri yönetmek için kullanılıyor. Kibana görselleştirme için iyi fakat biz verilerdeki değişikliklerde, tutarsızlıklarda uyarıcı bir araca ihtiyac duyuyoruz.

Elasticsearch’deki verilerin belli desenlerle eşleştiğinde uyarılmasını istiyorsak, Elastalert bu işi yapmak için kullanılan bir araçtır.

İki türlü birleşeni birleştirerek çalıştırılır; kural tipleri ve alertler. Elasticsearch belirlenen kural tipine göre periyodik olarak sorgulanır. Eşleşme olduğunda uyarı gönderilir.

Elastalert de çok sayıda kural türü bulunur:

• Belli bir zamanda olayların eşleşmesi ( frequency )
• Eşleşme hacminin artması veya azalması ( spike )
• Belli zaman da eşleşmeler daha az olduğunda ( flatline )
• Belli bir alan liste ile eşleştiğinde( whitelist ya da blacklist )
• Verilmiş herhangi bir filtre ile eşleştiğinde ( any )
• Bir alan bir süre içinde iki farklı değerlere sahip olduğunda ( change )

Alert türler şimdilik bunlara destek vermektedir:

• Command
• Email
• JIRA
• OpsGenie
• SNS
• HipChat
• Slack
• Telegram
• Debug ( Konsola eşleşen loglarla ilgili bilgileri dönderir. )

Kural Yapılandırması

Varsayılan olarak çalışma prensibi her dosya sonu .yaml ile bitmeli, rule dizininin içinde olmalıdır.

Gerekli Alanlar

es_host: Kuralın sorgulanacağı makine adı(Elasticserch makine adı).

es_port:  es_host a ulaşmak için kullanılan port.

index: Arama yapılacak dizin adıdır. Özel karakterleri burada kullanabiliriz. Örneğin index: my-index-* , my-index-2014-10-5 ile eşleşir. Format string içeriği %Y yıl, %m ay, %d gün içerir. Bunu kullanmak için use_strftime_index true olmalıdır.

name: Kural adı, eşsiz olmalıdır.

type: Kullanmak için seçtiğimiz kural adını yazıyoruz.

alert: Kullanmak istediğimiz alert tiplerini yazıyoruz.

Şeçenek Olan Alanlar

es_username , es_password Elasticsearch makinesi ile otomatik bağlantı sağlamak için kullanılır.

es_send_get_body_as : Elasticsearch sorgusu için kullanılan metod. Varsayılan olarak GET’dir.

use_strftime_index: Eğer True ise ElastAlert index için tarih zaman kullanılır.

aggregation: Çoklu eşleşmelerde bir alert göndermek için kullanılır. Eşleşmeyi bulduğunda aggregation periyodunu tamamlamayı bekler. Cron sözdizimini kullanır, hakkında. ( hours, minute, days )

buffer_time: config.yaml da genel ayarlanmış tanımlamaların üzerine yazmak için kullanılır. (Formatı zamandır.)

max_query_size: Tek sorguda Elasticsearch de indirilebilecek maksimum dosya sayısı. (int) Varsayılan olarak genel max_query_size’dır(10.000) )

use_kibana4_dashboard: Kibana4 dashboard’a bağlamak için kullanılır. Örneğin “ https://kibana.example.com/#/dashboard/My-Dashboard” gibi.

timeframe: Belli kural türlerinde minimum süre geçmesi gerektirir onu belirler.

filter: Sorguları filtrelemek için kullanılan alan.

Örnek rule.yaml

es_host: elk-elasticsearch

es_port: 9200

name: log_error

type: frequency

index: logstash-*

# link to a kibana dashboard with correct time settings

use_kibana4_dashboard:"http://elk-elasticsearch:5601/app/kibana#/dashboard/monitoring dashboard"

num_events: 1

max_query_size: 10000

run_every:

 minutes: 1

buffer_time:

 minutes: 15

timeframe:

 minutes: 1

filter:

 - query:

     query_string:

         query: "level:ERROR"

alert:

 - "debug"

 - "email"

email:

 - "error@example.net"

Jhipster-console ile Elastalert Yapılandırması

Elastalert genel bir yapılandırma dosyasına sahiptir(config.yaml). Elastalert yapılandırma dosyaları YAML dosyasıdır.

*Kurallar içinde yapılandırma dosyası oluşturacağımızdan hepsini bir dizinde toplamak kolaylık olabilir.

Örnek config.yaml 

# The unit can be anything from weeks to seconds
run_every:
  minutes: 1

# ElastAlert will buffer results from the most recent
# period of time, in case some log sources are not in real time
buffer_time:
  minutes: 5

# The elasticsearch hostname for metadata writeback
# Note that every rule can have it's own elasticsearch host
es_host: elk-elasticsearch

# The elasticsearch port
es_port: 9200

# Optional URL prefix for elasticsearch
#es_url_prefix: elasticsearch

# Connect with SSL to elasticsearch
use_ssl: False

# Option basic-auth username and password for elasticsearch
#es_username: someusername
#es_password: somepassword

# The index on es_host which is used for metadata storage
# This can be a unmapped index, but it is recommended that you run
# elastalert-create-index to set a mapping
writeback_index: elastalert_status

# If an alert fails for some reason, ElastAlert will retry
# sending the alert until this time period has elapsed
alert_time_limit:
  days: 1

Örnek Yapılandırma dosyasında var olan seçenek dışında kullanacağınız yapılandırma alanları da vardır:

rules_folder: ElastAlertden gelen kural yapılandırma dosyalarının yolu yazılır.

run_every: Elastalertin Elasticserch sorgu sıklığıdır. Verilen kural çalıştığında zamanı tutar ve şimdiki zamandan itibaren periyodik olarak sorgular. Bu alanın biçimi "minute"

buffer_time: Her sorgu çalıştırıldığında geriye doğru uzanan sorgu penceresi boyutu vardır. Bu değer  use_count_query veya  use_terms_query true olarak ayarlandığında göz ardı edilir.

es_host: Elastalert'in aramalarıyla ilgili metadataları kaydeden Elasticserch'un makine adıdır.

es_port: es_host makinesine erişmek için kullanılan porttur.

use_ssl: es_host bağlanırken SSL kullanmak isteyip istemediğimizi değerine 'True',  'False' vererek ayarlayabiliriz.

es_hostname: es_host a bağlanırken otomatik bağlanmak için kullanıcı adı

es_password: es_host a bağlanırken otomatik bağlanmak için parola

es_url_prefix: Elasticserch endpoint için url alan kodu.

es_send_get_body_as: Elasticsearh sorgulaması için metot. GET, POST  ve source olabilir. Varsayılan Get dir.

es_counn_timeout: Bağlanma ve es_host'u okumak için zaman aşımı ayrlar. Varsayılan olarak 10 dur.

scan_subdirectories: Ayar yapılmadığında veya elastalert kural dizinini yeniden indirmeyeceginde. True veya False Varsayılan olarak True.

 writeback_index: Elasticsearch de kaydedilen verileri indekslemek için kullanılır. 3 farklı tipi vardır.
1)elastalert_status
2)elastalert
3)elastalert_error

max_query_size: Tekli sorgular için elasticserch de indirilen maksimum dosya sayısı. Varsayılan olarak 10,000

scroll_keepalive :Maksimum sürede akan bağlantılar anlık yakalanmalı. Fakat sonuçların bitirilmesini sağlamak için dikkatli değer vermeliyiz. Yüksek değer verdiğimiz zaman elasticserch kaynaklarını kötüye kullanır.(Format time units)

max_aggregation: Toplu yakalama için maksimum sayı. Bir kural da aggregation ayarlanmış ise belli zaman diliminde meydana gelen tüm alertlerin hepsi birlikte gönderilir. Varsayılan olarak 10.000

old_query_limit: Elastalert için sorgular arasındaki maksimum sürede en son çalıştırılan sorguyu başlatır. Varsayılan olarak one week

disable_rules_on_error: Eğer True ise, Elastalert yakalanmayan exception kurallarını yok sayar. Varsayılan olarak True.

notify_email: email bildirimi göndermek için. Varsayılan olarak True dur.

notify_email: Bildirim göndermek istediği email ya da email listesi. Varsayılan olark email göndermez.

     options:
          from_addr: Adres email bildirimlerinde  başlık kullanır. Varsayılan değer  'Elastalert' dir.
          stmp_host: Email bildirimi göndermek için kullanılan stmp ana makie adı.
          email_replay_to: Varsayılan olarak alıcı adresidir.

Konteynırdan elastalerti çalıştırmak için elastalert.py dosyasını çalıştırmanız gerekir. Çalıştırırken sizden config dosyasını isteyecektir. config.yaml dosyasının yolunu --config parametresiyle belirtmek gerekir.

# python /opt/elastalert/elastalert/elastalert.py  --config   opt/elastalert/config.yaml

JHipster Konsol

Bir önceki yazılarımda ELK'dan ve Kibanadan bahsetmiştim. Bu yazımda kısaca Jhipster neymiş diye bahsedeyim istedim.

 Jhipster ile kolay bir şekilde databasedeki tabloları ve bu tablolar arasındaki ilişkileri belirliyebiliyoruz. Aynı zamanda Jhipster güncelleme yönetmek ve uygulama paketlemek için gerekli araçları sağlar. Jhipster logları izlemek için kolaylık sağlar. ".yml" dosyasında ilgili özellikleri basitçe ayarlanabilir ve bir izleme platformu kullanılarak gerçek zamanlı analiz edilebilir. Jhipster kurulumu için bilgisayarınız da maven, npm ve java bulunmalıdır.

Jhipster izleme platformu olarak Jhipster-console kullanır. Jhipster-console ELK'nın üstüne özellikler ekleyen docker tabanlı bir projedir.


JHipster Konsolu logları iletme

Jhipster-console günlüklerini iletmek için logstash yapılandırmasını yapmak gerekir, application-dev.yml ya da application-prod.yml dosyasını

jhipster:
    logging:
        logstash:
            enabled: true
            host: localhost
            port: 5000
            queueSize: 512

Etkin metric loglarını Jhipster uygulamasına bildirmek için metrics monitoring yapılandırması yapıyoruz:

jhipster:
    metrics:
        logs:
            enabled: true
         reportFrequency: 60 # seconds

Jhipster-Console Yüklemek:

Zaten var olan bir docker image var ise o kullanılır. Aşağıdaki komut ile jhipster konsolunun docker-compose dosyasını alabiliriz:

curl -O https://raw.githubusercontent.com/jhipster/jhipster-console/master/bootstrap/docker-compose.yml

 Konteynır kurup başlatmak için:

docker-compose up -d

Her seferde Elasticsearch, Logstash, Kibana ve ElastAlert başlayacaktır. Daha sonra  JHipster Konsolu erişmek mümkün olacak http:// localhost: 5601.

Her şeyi durdurmak için:

docker-compose stop

Jhipster-Console kullanımı Kibana kullamına benzemektedir.

Kibana Dashboards Kullanımı ve Görselleştirme

Kibana Arayüz

Kibana arayüzü dört ana bölüme ayrılır:

• Discover
• Visualize
• Dashboard
• Settings

 Kibana Discover

  İlk Kibana bağlandığınızda, Discover sayfası alınacaktır. Varsayılan olarak, bu sayfa ELK Stack'nın en son alınan logların tümünü gösterecektir. Burada, filtreleme ve belirli log iletileri bulunur.

 Search Bar:  Doğrudan ana navigasyon menüsü altında uzmanlık alanları veya tüm mesajları aramak için bu kullabılır.

 Time Filter:  Üst-Sağ (saat simgesi). Çeşitli mutlak zaman aralıkları dayalı logları filtrelemek için kullanılır. En son ne zamandan başlayarak logların gösterilmesini ayarlayabiliriz.

 Field Selector: Solda, Search bar altında. Seçilmiş alan değişikliklerinin log görünüm menüsü görüntüler.

 Date Histogram: Arama çubuğunun altındaki grafik bar.  Varsayılan olarak, bu arama ve zaman filtre tarafından eşleşen tüm logların sayımı, zamana karşı (x-ekseni), göstermektedir. Zaman filtresini daraltmak için cubukları tıklayın ya da tıklayıp sürükleyin.

 Log View: Sağ altta. Bireysel log iletileri bakmak ve alanlarına göre filtrelenmiş log verilerini görüntülemek için kullanılır.

 Search Bar da yaptığınız aramaların sonuçlarının varsayılan olarak "Son 15 dakika" ile sınırlı olduğunu unutmayın. Eğer herhangi bir sonuç almıyorsanız, belirtilen süre içinde oluşturulan arama sorgusu neticesinde log var mı emin olun.

  
Arama Sözdizimi Kuralları 


  Arama log iletileri belirli bir alt kümesini seçmek için kolay ve güçlü bir yol sağlar. Arama sözdizimi oldukça kendini açıklayıcı ve bağlaçlar, joker, ve saha filtreleme sağlar. Örneğin, Google Chrome kullanıcıları tarafından oluşturulan Nginx erişim logları bulmak istiyorsanız, type: "nginx-erişim" AND agent: "crome" yazarak arama yapabilirsiniz.
  Arama yaptıktan sonra Save düğmesine basıp kaydedebilirsiniz. Kaydedilen aramalar Load Saved Search simgesini tıklayarak istediğiniz zaman açabilir ve görselleştirme oluştururken onlar kullanılabilir.



 
Kibana Visualize

 Kibana Visualize sayfası kendi özel görselleştirmelerinizi görebilceğiniz, oluşturabilceğiniz, değiştirebilceğiniz sayfadır. Dikey bar ve ve Veri tabloları (bir harita üzerinde veri görüntülemek için) Çini haritalara Pie çizelgeleri arasında değişen görsel birkaç farklı türleri vardır. Görsel öğeler de Kibana örneğine erişimi olan diğer kullanıcılarla paylaşılabilir. Bu Kibana görselleştirme ilk kez kullanacak iseniz, ilerlemeden önce alan listesini yeniden yüklemeniz gerekir. Bunu yapmak için Kibana Settings bölümünde, Reload Field Data alt bölümünde kaplıdır.

Dikey Bar Grafik Oluşturma

 Öncelikle bir görselleştirme oluşturmak için  Visualize menu öğesini tıklayın. İstediğiniz görselleştirme hangi tip karar verin ve onu seçin. Bir dikey çubuk grafik yaratacaktır, bu iyi bir başlangıç noktasıdır. Şimdi bir arama kaynağını seçmeniz gerekir ya da yeni bir arama oluşturmak veya kaydedilmiş bir aramayı kullanabilirsiniz.
  
 İlk başta, önizleme grafiği, sağ tarafta, (arama loglarının bulunduğunu varsayarsak) bir katı bar olacaktır çünkü "Count" için sadece bir Y-ekseni oluşur. Yani, sadece belirtilen arama sorgusu ile bulunan logların sayısını gösteriyor. 

 Görselleştirmeyi daha kullanışlı hale getirmek için buckets ekleyin. İlk olarak, bir X ekseni bucket ekleyin, sonra Add Sub Aggregation menüsünü tıklayın ve "Date Histogram" seçeneğini seçin. Eğer Apply düğmesini tıklarsanız, tek çubuk X ekseni boyunca çeşitli barlar bölünür. Şimdi Count zaman aralıklarında bölünmüş çoklu bar olarak görüntülenir. 

 Grafik biraz daha ilginç hale getirmek için isterseniz, Add Sub Aggregation  düğmesine tıklayabilirsiniz.  Split Bars bucket türünü seçin. Daha sonra Sub Aggregation drop-down menu  tıklayın ve "Significant Terms" seçeneğini seçin. Sonra Field drop-down menu seçip yapıp boyutunu girdikten sonra Apply düğmesine basın ve yeni grafik oluşsun. Görselleştirmeyi kaydetmek için hazır olduğunuzda üste Save Visualize düğmesini tıklıyoruz, isim girip Save düğmesine basıyoruz.

 Biz bir dashboard nasıl oluşturulacağını bölüme devam etmeden önce, en az bir tane daha görselleştirme oluşturmanız gerekir. Deneyin ve çeşitli görselleştirme türlerini keşfedin. 

Kibana Dashboard 

Kibana Dashboard sayfası kendi özel panoları görebileceğiniz, oluşturabileceğiniz, değiştirebileceğiniz sayfadır. Bir pano ile, bir arama sorgusu sağlayarak veya görselleştirme elemanları tıklayarak filtreleri seçerek, tek bir sayfa üzerine birden fazla görselleştirme birleştirebilirsiniz. Loglarda bir bakış elde etmek istediğinizde, çeşitli loglar arasında bağlantı kurmak istediğinizde panolar yararlıdır.

Dashboard Oluşturma

 Öncelikle bir pano oluşturmak için  Dashboard menu öğesini tıklayın.
Daha önce bir pano oluşturmadıysanız, çoğunlukla boş bir sayfa göreceksiniz. "Başlamak için hazır mısınız?" diyor. Eğer bu ekranı görmezseniz, oraya (arama çubuğunun sağında) New Dashboard simgesine basın. Ekrana çıkan visualize filtrelerinden seçim yapabilirsiniz.

Dashboard Kullanımı

Dashboard arama sorgusu girildiğinde daha fazla filtreleme yapar, zaman filtresini değiştirir ya da görselleştirme içindeki unsurları tıklayarak daha fazla filtre edilir. Histograma belirli bir renk segmenti tıklarsanız filtreleme sağlayacaktır.

Kibana Settings

Kibana Ayarları sayfası varsayılan değerler veya dizin desen gibi çeşitli şeyleri değiştirmenizi sağlar.

Reload Field Data 

 Yeni bir logstash verisi ekleme istediğinizde, eğer filtrelemeye yeni bir log türü ekleyecekseniz, yeni reload field listesine ihtiyacınız vardır. 

Edit Save Objects

Nesneler bölümü, düzenlemek, görüntülemek ve kaydedilmiş panoları, aramalar ve görselerden herhangi birini silmenize olanak verir.