Uygulama Loglarını Neden ELK Stack’e Taşıdık?

“Prod patlamış, log dosyası lazım?”, “Geliştirmeyi devreye almadan ayrıntılı log takibi lazım, dosya nerde?”, “Prod’a yetkim yok log dosyasını gönderin bana!”, “abi tail x.log neyinize yetmiyor?”, “Notepadd’den aç dosyayı takip et işte.”

Jira uygulaması ve entegrasyon servislerini barındıran uygulamamızın loglarını takip ederken, ekip olarak bu anları yaşıyorduk. Ekibin her üyesi için log takibinin daha basit olması gerekiyordu. Ne yapalım diye araştırırken hem öğreniriz hem de faydalı bir iş olur diye ELK Stack yapısına loglarımızı taşıdık. Bu yazımda araçların ayrıntısı ve nasıl yapılacağından çok yapıya geçerken hangi yolları izledik, ne tarz zorluklarla karşılaştık, bize nasıl faydası oldu gibi noktalara değineceğim.

ELK Stack nedir? Şu görsel çok güzel açıklıyor.

Nasıl bir yol izledik?

• Elasticsearch ve Kibana kurulumlarını ana sunucumuz içerisinde gerçekleştirdik.
• Elasticsearch’ü diğer sunuculardan erişilebilecek şekilde host ettik.
• Son olarak uygulamayı Nginx üzerinde ayağa kaldırdık.
• Artık elimizde http://xx.xx.xx.xx:9200 şeklinde erişebileceğimiz bir Elasticsearch uygulamamız oldu.

Log dosyalarını ana sunucuya nasıl gönderdik?

• Farklı sunucularda çalışan uygulamalarımız vardı.
• Uygulamanın loglarını barındıran dosyayı input olarak Logstash ile Elasticsearch url’ine gönderdik.

Logları nasıl görselleştirdik?

• Logstash ile beslediğimiz Elasticsearch içerisindeki her log’un indexlerini oluşturduk.
• Oluşan bu indexleri ise Kibana üzerinde görselleştirdik.

Hangi zorluklarla karşılaştık?

Bu kısımda ise karşılaştığımız sorun / hata ve bunlara getirdiğimiz çözümlerden bahsedeceğim. Bazı hataların çözümünü arayıp bulmak vakit aldı. Bulduğumuz çözümleri ise kendi senaryomuza uyarlamaya çalıştık.

Sunucu ortam farklılıkları

• Sunucular üzerindeki işletim sistemlerinin farklı olmasından dolayı o işletim sistemine özel kurulum yapmak zorunda kaldık. Örnek olarak Logstash’i servis olarak çalıştırmak istediğimizde https://www.elastic.co/guide/en/logstash/current/running-logstash.html içerisindeki farklı yöntemler ile ilerledik.
• İşletim sistemlerinin versiyon farklılıklarından dolayı o versiyona özel çözümler ürettiğimiz anlar da oldu.

Max number of threads of elasticsearch

• Elasticsearch’ü dışarıya host ederken aldığımız bir hataydı.
• etc/security/limits.conf içerisinde elasticsearch için thread tanımlamaları yapıp sorunu çözdük. ayrıntılı link

Bootstrap system call filter

• Tam host ettik rahatız dedik böyle bir hata ile karşılaştık.
• etc/elasticsearch/elasticsearch.yml içerisinde bootstrap.system_call_filter: false atamasını yapmamız gerekiyor. ayrıntılı link

Bize faydası ne oldu?

• Takımdaki kişiler log bakmak istedikleri zaman “her defasında” sunucuya erişip log dosyasını indirmek zorunda değiller.
• Tek bir url üzerinden bütün uygulamaların loglarını daha okunabilir bir formatta sunabildik.
• Elasticsearch, Logstash ve Kibana ile uğraşıp geliştirme yapabilmemiz için bir sebep oldu.
• Bundan sonra geliştireceğimiz her uygulama için “Acaba loglamayı nasıl görselleştirelim?” sorusuna bir cevabımız var.
• Prod sunucularına yetkileri olmayan kişiler ilgili log dosyasına erişemeyip takibini yapamıyordu. Bu soruna çözüm getirebildik.

Ana sorunlarımızı bu yapıyla çözmüş olduk. Şimdi ise ELK araçları üzerindeki yetkinliklerimiz arttıkça kendi senaryolarımızı iyileştirerek devam edeceğiz. Umarım log takibine yöntem arayanlara fikir oluşabilmesi açısından faydalı olmuştur.

Teşekkürler..💯