Günlükler sistemin önemli bir parçasıdır ve sistemin beklendiği gibi çalıştığını (veya çalışmadığını) anlamanıza olanak tanır. Mikro hizmet mimarisinde, günlüklerle çalışmak özel bir Olimpiyat için ayrı bir disiplin haline gelir. Bir sürü sorunun aynı anda çözülmesi gerekiyor:
- bir uygulamadan günlüklerin nasıl yazılacağı;
- günlüklerin nereye yazılacağı;
- günlüklerin depolama ve işleme için nasıl teslim edileceği;
- Günlüklerin nasıl işleneceği ve saklanacağı.
Şu anda popüler olan konteynırlaştırma teknolojilerinin kullanılması, sorunu çözme seçenekleri alanına tırmığın üstüne kumu da ekliyor.
Yuri Bushmelev’in “Kütük toplama ve teslim alanındaki tırmık haritası” başlıklı raporunun metni tam olarak bununla ilgilidir.
Kimin umurunda, lütfen kedinin altına.
Benim adım Yuri Bushmelev. Lazada'da çalışıyorum. Bugün loglarımızı nasıl oluşturduğumuzdan, bunları nasıl topladığımızdan ve oraya neler yazdığımızdan bahsedeceğim.
Nereliyiz? Biz Kimiz? Lazada, Güneydoğu Asya'daki altı ülkede 1 numaralı çevrimiçi perakendecidir. Tüm bu ülkeler veri merkezlerimiz arasında dağıtılmaktadır. Şu anda toplamda 4 veri merkezi var. Bu neden önemli? Çünkü bazı kararlar merkezler arasındaki bağın çok zayıf olmasından kaynaklanıyordu. Mikro hizmet mimarimiz var. Halihazırda 80 mikro hizmetimiz olduğunu öğrendiğimde şaşırdım. Günlüklerle işe başladığımda, yalnızca 20 tane vardı. Ayrıca, benim de birlikte yaşamam ve katlanmam gereken oldukça büyük bir PHP mirası var. Bütün bunlar şu anda sistemin tamamı için dakikada 6 milyondan fazla mesaj üretiyor. Daha sonra bununla nasıl yaşamaya çalıştığımızı ve bunun neden böyle olduğunu göstereceğim.
Bu 6 milyon mesajla bir şekilde yaşamak zorundasınız. Onlarla ne yapmalıyız? İhtiyacınız olan 6 milyon mesaj:
- uygulamadan gönder
- teslimat için kabul et
- Analiz ve depolama için teslim edin.
- analiz etmek
- bir şekilde saklayın.
Üç milyon mesaj göründüğünde, hemen hemen aynı görünüyordum. Çünkü sadece birkaç kuruşla başladık. Uygulama günlüklerinin orada yazıldığı açıktır. Mesela veritabanına bağlanamadım, veritabanına bağlanabildim ama hiçbir şey okuyamadım. Ancak bunun yanında mikro hizmetlerimizin her biri de bir erişim günlüğü yazar. Mikro hizmete gelen her istek günlüğe kaydedilir. Bunu neden yapıyoruz? Geliştiriciler takip edebilmek istiyor. Her erişim günlüğü, özel bir arayüzün yardımıyla tüm zinciri çözen ve izi güzel bir şekilde görüntüleyen bir izleme kimliği alanı içerir. İzleme, isteğin nasıl gittiğini gösterir ve bu, geliştiricilerimizin tanımlanamayan çöplerle hızlı bir şekilde başa çıkmasına yardımcı olur.
Bununla nasıl yaşanır? Şimdi seçenekler alanını kısaca anlatacağım - bu sorunun genel olarak nasıl çözüldüğünü. Günlüklerin toplanması, iletilmesi ve saklanması sorunu nasıl çözülür?
Bir uygulamadan nasıl yazılır? Farklı yolların olduğu açıktır. Özellikle moda yoldaşlarımızın bize söylediği gibi en iyi uygulamalar var. Büyükbabalarımızın bize söylediği gibi iki tür eski tarz vardır. Başka yollar da var.
Günlüklerin toplanmasında durum yaklaşık olarak aynıdır. Bu özel kısmı çözmek için pek fazla seçenek yok. Zaten onlardan daha fazlası var, ama henüz çok fazla değil.
Ancak teslimat ve sonraki analizlerle birlikte varyasyonların sayısı patlamaya başlar. Şimdi her seçeneği açıklamayacağım. Ana seçeneklerin konuyla ilgilenen herkes tarafından iyi bilindiğini düşünüyorum.
Size bunu Lazada'da nasıl yaptığımızı ve aslında her şeyin nasıl başladığını göstereceğim.
Bir yıl önce Lazada'ya geldim ve kütüklerle ilgili bir projeye gönderildim. Bunun gibi bir şeydi. Uygulama günlüğü stdout ve stderr'e yazıldı. Her şey modaya uygun bir şekilde yapıldı. Ancak daha sonra geliştiriciler bunu standart akışların dışına attı ve sonra bir şekilde altyapı uzmanları bunu çözecek. Altyapı uzmanları ve geliştiriciler arasında, "ah... tamam, hadi bunları bir kabukla bir dosyaya saralım, hepsi bu." diyen yayınlayıcılar da var. Ve bunların hepsi bir kapta olduğu için, onu doğrudan kabın içine sardılar, içindeki kataloğu haritalandırıp oraya koydular. Sanırım bunun ne olduğu herkes için oldukça açık.
Şimdilik biraz daha ileriye bakalım. Bu günlükleri nasıl teslim ettik? Birisi aslında akıcı olan ancak pek akıcı olmayan td-agent'ı seçti. Bu iki proje arasındaki ilişkiyi hâlâ anlayamıyorum ama aynı şeymiş gibi görünüyorlar. Ve Ruby'de yazılan bu fluentd, günlük dosyalarını okuyor, bir tür düzenlilik kullanarak onları JSON'a ayrıştırıyor. Daha sonra bunları Kafka'ya gönderdim. Üstelik Kafka'da her API için 4 ayrı konu başlığımız vardı. Neden 4? Çünkü canlı var, sahneleme var ve çünkü stdout ve stderr var. Geliştiriciler bunları oluşturur ve altyapı geliştiricilerinin bunları Kafka'da oluşturması gerekir. Üstelik Kafka başka bir departman tarafından kontrol ediliyordu. Bu nedenle her api için 4 konu oluşturacak şekilde ticket oluşturmak gerekiyordu. Herkes bunu unuttu. Genel olarak çöp ve yaygara vardı.
Bundan sonra ne yaptık? Kafka'ya gönderdik. Sonra Kafka'dan gelen kütüklerin yarısı Logstash'a uçtu. Kütüklerin diğer yarısı bölündü. Bazıları bir Graylog'a, bazıları başka bir Graylog'a uçtu. Sonuç olarak tüm bunlar tek bir Elasticsearch kümesinde toplandı. Yani tüm bu karışıklık orada sona erdi. Bunu yapma!
Yukarıdan bakıldığında böyle görünüyor. Bunu yapma! Burada sorunlu alanlar hemen sayılarla işaretlenmiştir. Aslında bunlardan daha fazlası var, ancak 6'sı gerçekten sorunlu ve hakkında bir şeyler yapılması gerekenler. Şimdi size bunları ayrı ayrı anlatacağım.
Buraya (1,2,3) dosyaları yazıyoruz ve buna göre burada aynı anda üç tırmık var.
Birincisi (1) bunları bir yere yazmamız gerekiyor. API'ye doğrudan bir dosyaya yazma yeteneğinin verilmesi her zaman arzu edilen bir durum değildir. API'nin bir kapta izole edilmesi veya daha da iyisi salt okunur olması arzu edilir. Ben bir sistem yöneticisiyim, dolayısıyla bu konulara biraz alternatif bir bakış açım var.
İkinci nokta (2,3), API'ye çok fazla istek gelmesidir. API bir dosyaya çok fazla veri yazar. Dosyalar büyüyor. Onları döndürmemiz gerekiyor. Çünkü aksi takdirde oradaki herhangi bir diski stoklayamazsınız. Bunları döndürmek kötüdür çünkü kabuktan dizine yönlendirilerek yapılırlar. Bunu revize etmemizin imkanı yok. Uygulamaya tanıtıcıları yeniden açmasını söyleyemezsiniz. Çünkü geliştiriciler size aptalmışsınız gibi bakacaklar: "Hangi tanımlayıcılar? Genellikle stdout'a yazıyoruz. Altyapı geliştiricileri, dosyanın bir kopyasını oluşturan ve orijinali yazıya döken logrotate için copytruncate'i yaptılar. Buna göre, bu kopyalama işlemleri arasında genellikle disk alanı tükenir.
(4) Farklı API'lerde farklı formatlarımız vardı. Biraz farklıydılar ama regexp'in farklı yazılması gerekiyordu. Bütün bunlar Puppet tarafından kontrol edildiğinden, kendi hamamböceklerinin olduğu çok sayıda sınıf vardı. Ayrıca, çoğu zaman td-agent hafızayı yiyebilir, aptal olabilir, çalışıyormuş gibi davranabilir ve hiçbir şey yapmaz. Dışarıdan hiçbir şey yapmadığını anlamak mümkün değildi. En iyi ihtimalle düşecek ve daha sonra birisi onu kaldıracak. Daha doğrusu bir uyarı gelecek ve birisi gidip onu elleriyle kaldıracak.
(6) Ve en fazla çöp ve atık elastik aramaydı. Çünkü eski bir versiyondu. Çünkü o zamanlar bu konuda uzman ustalarımız yoktu. Alanları örtüşebilecek heterojen günlüklerimiz vardı. Farklı uygulamalara ait farklı günlükler aynı alan adlarıyla yazılabilir ancak içinde farklı veriler bulunabilir. Yani, bir günlük, alanda Tamsayı ile birlikte gelir, örneğin seviye. Başka bir günlük, seviye alanında String ile birlikte gelir. Statik haritalamanın yokluğunda bu harika bir şey. Elasticsearch'te dizini döndürdükten sonra önce dize içeren bir mesaj gelirse, o zaman normal yaşarız. Ancak ilk mesaj Integer'dan geldiyse, String'den gelen sonraki tüm mesajlar basitçe atılır. Çünkü alan türü eşleşmiyor.
Bu soruları sormaya başladık. Suçlayacak kişileri aramamaya karar verdik.
Ama bir şeyler yapılması gerekiyor! Açık olan şey, standartlar oluşturmamız gerektiğidir. Zaten bazı standartlarımız vardı. Biraz sonra başladık. Neyse ki o dönemde tüm API'ler için tek bir günlük formatı zaten onaylanmıştı. Hizmetler arasındaki etkileşim standartlarına doğrudan yazılmıştır. Buna göre log almak isteyenlerin bu formatta yazması gerekmektedir. Birisi günlükleri bu formatta yazmazsa, hiçbir şeyi garanti etmiyoruz.
Daha sonra, günlüklerin kaydedilmesi, iletilmesi ve toplanması yöntemleri için birleşik bir standart oluşturmak istiyorum. Aslında bunları nereye yazacağız, nasıl teslim edeceğiz. İdeal durum projelerin aynı kütüphaneyi kullanmasıdır. Go için ayrı bir günlük kitaplığı ve PHP için ayrı bir kitaplık vardır. Elimizdeki herkes bunları kullanmalı. Şu anda bu konuda yüzde 80 oranında başarılı olduğumuzu söyleyebilirim. Ancak bazı insanlar kaktüsleri yemeye devam ediyor.
Ve orada (slaytta) "Günlüklerin teslimi için SLA" zar zor görünmeye başlıyor. Henüz mevcut değil ama üzerinde çalışıyoruz. Çünkü altyapı diyor ki, falan formatta falan yere yazarsanız ve saniyede N mesajdan fazla yazmazsanız, biz bunu büyük ihtimalle falan yere ulaştırırız diyor. Bu birçok baş ağrısını hafifletir. Bir SLA varsa, bu kesinlikle harika!
Sorunu çözmeye nasıl başladık? Asıl sorun td-agent ile ilgiliydi. Kayıtlarımızın nereye gittiği belli değildi. Teslim edildiler mi? Onlar gidiyorlar mı? Bu arada neredeler? Bu nedenle ilk noktada td-agent'ın değiştirilmesine karar verildi. Burada neyle değiştirileceğine ilişkin seçenekleri kısaca özetledim.
Akıcı. Öncelikle onunla daha önceki bir işte karşılaştım ve o da periyodik olarak oraya düşüyordu. İkincisi, bu aynı şeydir, yalnızca profilde.
Dosya ritmi. Bizim için ne kadar uygun oldu? Çünkü Go'da var ve Go konusunda çok fazla uzmanlığımız var. Buna göre, eğer bir şey olursa, bir şekilde kendimiz için buna ekleme yapabiliriz. Bu yüzden almadık. Böylece kendiniz için yeniden yazmaya başlamanın cazibesine bile kapılmayın.
Sistem yöneticisi için bariz çözüm bu miktardaki her türlü sistem günlüğüdür (syslog-ng/rsyslog/nxlog).
Veya kendinize ait bir şeyler yazın, ancak dosya atımının yanı sıra bunu da attık. Bir şey yazarsanız, iş için yararlı bir şey yazmak daha iyidir. Günlükleri teslim etmek için hazır bir şey almak daha iyidir.
Bu nedenle seçim aslında sistem günlüğü ve rsyslog arasındaki seçime bağlıydı. Puppet'ta zaten rsyslog için sınıflarımız olduğu için rsyslog'a yöneldim ve aralarında bariz bir fark bulamadım. Sistem günlüğü nedir, sistem günlüğü nedir? Evet, bazılarının belgeleri daha kötü, bazılarının ise daha iyi. Bu bunu bu şekilde yapabilir, diğeri ise farklı şekilde yapabilir.
Ve rsyslog hakkında biraz. Her şeyden önce harika çünkü çok sayıda modülü var. İnsan tarafından okunabilen RainerScript'e (modern bir yapılandırma dili) sahiptir. Standart araçları kullanarak td-agent'ın davranışını taklit edebilmemiz ve uygulamalarda hiçbir şeyin değişmemesi harika bir avantaj. Yani td-agent'ı rsyslog olarak değiştiriyoruz ve geri kalan her şeyi şimdilik kendi haline bırakıyoruz. Ve anında çalışma teslimatı alıyoruz. Sonra, mmnormalize rsyslog'da harika bir şeydir. Günlükleri ayrıştırmanıza olanak tanır, ancak Grok ve regexp'i kullanmaz. Soyut bir sözdizimi ağacı oluşturur. Günlükleri, bir derleyicinin kaynakları ayrıştırmasıyla hemen hemen aynı şekilde ayrıştırır. Bu, çok hızlı çalışmanıza, az CPU tüketmenize olanak tanır ve genel olarak bu gerçekten harika bir şeydir. Daha bir sürü bonus var. Bunlar üzerinde durmayacağım.
rsyslog'un başka birçok dezavantajı vardır. Bunlar bonuslarla hemen hemen aynıdır. Temel sorunlar, onu nasıl pişireceğinizi bilmeniz ve versiyonu seçmeniz gerektiğidir.
Günlükleri bir unix soketine yazmaya karar verdik. Ve /dev/log'da değil, çünkü orada bir sürü sistem günlüğümüz var, Journald bu hattın içinde. Öyleyse özel bir sokete yazalım. Bunu ayrı bir kural kümesine ekleyeceğiz. Hiçbir şeye karışmayalım. Her şey şeffaf ve anlaşılır olacak. Biz de tam olarak bunu yaptık. Bu soketlerin bulunduğu dizin standartlaştırılır ve tüm konteynerlere iletilir. Konteynerler ihtiyaç duydukları soketi görebilir, açabilir ve ona yazabilir.
Neden bir dosya değil? Çünkü herkes okudu docker'a bir dosya iletmeye çalışan rsyslog yeniden başlatıldıktan sonra dosya tanımlayıcısının değiştiği ve docker'ın bu dosyayı kaybettiği keşfedildi. Başka bir şeyi açık tutuyor ama yazdıkları soketi değil. Bu sorunu çözmeye karar verdik ve aynı zamanda engelleme sorununu da çözmeye karar verdik.
Rsyslog, slaytta belirtilen eylemleri gerçekleştirir ve günlükleri aktarıcıya veya Kafka'ya gönderir. Kafka eski yolu izliyor. Aktarma - Günlükleri iletmek için saf rsyslog'u kullanmaya çalıştım. İleti Kuyruğu olmadan, standart rsyslog araçlarını kullanma. Temel olarak işe yarıyor.
Ancak bunların bu kısma (Logstash/Graylog/ES) nasıl aktarılacağına ilişkin nüanslar vardır. Bu kısım (rsyslog-rsyslog) veri merkezleri arasında kullanılır. İşte bant genişliğinden tasarruf etmemize ve buna bağlı olarak kanal tıkandığında başka bir veri merkezinden bazı günlükler alma olasılığımızı bir şekilde artırmamıza olanak tanıyan sıkıştırılmış bir tcp bağlantısı. Çünkü her şeyin kötü olduğu Endonezya'mız var. Sürekli sorunun yattığı yer burasıdır.
Uygulamadan kaydettiğimiz logların sonuca ulaşma ihtimalini gerçekte nasıl takip edebiliriz diye düşündük. Metrikler oluşturmaya karar verdik. rsyslog'un bir tür sayaç içeren kendi istatistik toplama modülü vardır. Örneğin sıranın büyüklüğünü, falanca eylemde kaç mesaj geldiğini gösterebilir. Zaten onlardan bir şeyler alabilirsiniz. Ayrıca, yapılandırılabilen özel sayaçları vardır ve size örneğin bazı API'lerin kaydettiği mesaj sayısını gösterir. Daha sonra Python'da rsyslog_exporter yazdım ve hepsini Prometheus'a gönderip grafikler oluşturduk. Graylog metriklerini gerçekten istiyorduk ancak bunları ayarlamak için henüz zamanımız olmadı.
Sorunlar nelerdi? Live API'lerimizin saniyede 50 bin mesaj yazdığını (ANINDA!) keşfettiğimizde sorunlar ortaya çıktı. Bu yalnızca hazırlama özelliği olmayan bir Canlı API'dir. Ve Graylog bize saniyede yalnızca 12 bin mesaj gösteriyor. Ve makul bir soru ortaya çıktı: Kalıntılar nerede? Buradan Graylog'un başa çıkamayacağı sonucuna vardık. Baktık ve gerçekten de Graylog ve Elasticsearch bu akışı kaldıramadı.
Daha sonra, yol boyunca yaptığımız diğer keşifler.
Sokete yazma işlemleri engellendi. Nasıl oldu? Teslimat için rsyslog'u kullanırken bir noktada veri merkezleri arasındaki kanal bozuldu. Bir yerde teslimat durduruldu, başka bir yerde teslimat durduruldu. Bütün bunlar rsyslog soketine yazan API'ler ile makineye ulaştı. Orada kuyruk vardı. Daha sonra varsayılan olarak 128 paketten oluşan unix soketine yazma kuyruğu doldu. Ve uygulamadaki bir sonraki write() engellenir. Go uygulamalarında kullandığımız kütüphaneye baktığımızda sokete yazmanın engellemesiz modda gerçekleştiği yazıyordu. Hiçbir şeyin engellenmediğinden emindik. Çünkü okuyoruz bunun hakkında kim yazdı? Ama bir an var. Ayrıca bu çağrının etrafında, sokete sürekli bir mesaj gönderme girişiminin olduğu sonsuz bir döngü vardı. Onu fark etmedik. Kütüphaneyi yeniden yazmak zorunda kaldım. O zamandan beri bu birkaç kez değişti ama artık tüm alt sistemlerdeki engellemelerden kurtulduk. Bu nedenle rsyslog'u durdurabilirsiniz ve hiçbir şey çökmez.
Bu tırmığa basmaktan kaçınmaya yardımcı olan kuyrukların boyutunu izlemek gerekir. Öncelikle mesajları kaybetmeye başladığımız zamanı takip edebiliriz. İkinci olarak teslimatta sorun yaşadığımızı takip edebiliyoruz.
Ve başka bir hoş olmayan an - mikro hizmet mimarisinde 10 kat büyütme çok kolaydır. Çok fazla gelen talebimiz yok, ancak bu mesajların daha uzağa gittiği grafik nedeniyle, erişim günlükleri nedeniyle günlük yükünü aslında yaklaşık on kat artırıyoruz. Ne yazık ki kesin rakamları hesaplayacak vaktim olmadı ama mikro hizmetler böyledir. Bu akılda tutulmalıdır. Şu anda Lazada'da en çok yüklü olanın günlük toplama alt sistemi olduğu ortaya çıktı.
Elasticsearch problemini nasıl çözebilirim? Tüm makinelere koşup onları orada toplamamak için günlükleri hızlı bir şekilde tek bir yere almanız gerekiyorsa, dosya depolamayı kullanın. Bunun çalışması garantilidir. Herhangi bir sunucudan yapılabilir. Diskleri oraya yapıştırmanız ve sistem günlüğünü yüklemeniz yeterlidir. Bundan sonra tüm günlüklerin tek bir yerde olması garanti edilir. Daha sonra elasticsearch'ü, greylog'u ve başka bir şeyi yavaş yavaş yapılandırabilirsiniz. Ancak tüm günlüklere zaten sahip olacaksınız ve ayrıca yeterli disk dizisi olduğu sürece bunları saklayabilirsiniz.
Raporumu yazdığım sırada plan şu şekilde görünmeye başladı. Dosyaya yazmayı neredeyse bıraktık. Şimdi büyük olasılıkla geri kalanını kapatacağız. API'yi çalıştıran yerel makinelerde dosyalara yazmayı bırakacağız. İlk olarak, çok iyi çalışan dosya depolama alanı var. İkincisi, bu makinelerin sürekli olarak alanı tükeniyor; sürekli izlenmesi gerekiyor.
Logstash ve Graylog'un olduğu bu kısım gerçekten başarılı. Bu nedenle bundan kurtulmamız gerekiyor. Bir şeyi seçmelisiniz.
Logstash ve Kibana'yı atmaya karar verdik. Çünkü güvenlik departmanımız var. Hangi bağlantı? Bağlantı, X-Pack'siz ve Shield'sız Kibana'nın, günlüklere erişim haklarını ayırt etmenize izin vermemesidir. Bu yüzden Graylog'u aldık. Hepsi var. Hoşuma gitmedi ama işe yarıyor. Yeni donanım aldık, oraya yeni Graylog kurduk ve tüm logları katı formatlarda ayrı bir Graylog'a aktardık. Sorunu farklı türdeki aynı alanlarla organizasyonel olarak çözdük.
Yeni Graylog'da tam olarak neler yer alıyor? Her şeyi docker'a yazdık. Bir sürü sunucu aldık, üç Kafka örneğini, 7 Graylog sunucusu sürüm 2.3'ü kullanıma sunduk (çünkü Elasticsearch sürüm 5'i istiyorduk). Bütün bunlar HDD'den yapılan baskınlar sırasında yakalandı. Saniyede 100 bin mesaja kadar indekslenme oranı gördük. Haftada 140 terabayt veri rakamını gördük.
Ve yine tırmık! Önümüzde iki satış var. 6 milyon mesajın ötesine geçtik. Graylog'un çiğnemeye vakti yok. Bir şekilde yeniden hayatta kalmak zorundayız.
Bu şekilde hayatta kaldık. Birkaç sunucu ve SSD daha ekledik. Şu anda bu şekilde yaşıyoruz. Şimdi zaten saniyede 160 bin mesajı çiğniyoruz. Henüz sınıra ulaşmadık, dolayısıyla bundan gerçekte ne kadar yararlanabileceğimiz belli değil.
Bunlar geleceğe dair planlarımız. Bunlardan en önemlisi muhtemelen yüksek kullanılabilirliktir. Henüz elimizde değil. Birkaç araba aynı şekilde yapılandırılmıştır, ancak şu ana kadar her şey tek bir arabadan geçiyor. Aralarında yük devretmeyi ayarlamak zaman alır.
Graylog'dan ölçümleri toplayın.
Bant genişliğimizi ve diğer her şeyi kesmeyen çılgın bir API'ye sahip olmak için bir hız sınırı yapın.
Ve son olarak geliştiricilerle bir tür SLA imzalayın ki bu kadar hizmet verebilelim. Daha fazla yazarsan özür dilerim.
Ve belgeleri yazın.
Kısaca yaşadığımız her şeyin sonuçları. İlk olarak standartlar. İkincisi, sistem günlüğü pastadır. Üçüncüsü, rsyslog tam olarak slaytta yazıldığı gibi çalışır. Ve sorulara geçelim.
sorular.
Soru: Neden almamaya karar verdin... (filebeat?)
Cevap: Bir dosyaya yazmamız gerekiyor. Gerçekten istemedim. API'niz saniyede binlerce mesaj yazdığında, onu saatte bir döndürseniz bile bu hala bir seçenek değildir. Pipe'a yazabilirsiniz. Geliştiriciler bana şunu sordu: "Yazdığımız süreç çökerse ne olur?" Onlara ne cevap vereceğimi bulamadım ve şöyle dedim: "Tamam, bunu yapmayalım."
Soru: Neden günlükleri HDFS'ye yazmıyorsunuz?
Cevap: Bu bir sonraki aşamadır. Bunu en başında düşündük ama şu anda bunu yapacak kaynak olmadığından uzun vadeli çözümümüz askıda kalıyor.
Soru: Sütun formatı daha uygun olacaktır.
Cevap: Anladım. Bunun için iki elimiz var.
Soru: RSyslog'a yazıyorsunuz. Orada hem TCP hem de UDP'yi kullanabilirsiniz. Ancak UDP ise teslimatı nasıl garanti edersiniz?
Cevap: İki nokta var. Öncelikle herkese logların teslimini garanti etmediğimizi hemen söylüyorum. Çünkü geliştiriciler gelip “Finansal verileri oraya yazmaya başlayalım, sen de bir şey olursa bizim için bir yere koyacaksın” dediğinde onlara “Harika! Sokete yazma konusunda engellemeye başlayalım ve bunu işlemlerde yapalım ki, bizim için onu sokete koymanız ve karşı taraftan almamızı garanti altına alın.” Ve şu anda herkesin artık buna ihtiyacı yok. Gerekli değilse hangi soruları sormalıyız? Eğer bir sokete yazmayı garanti etmek istemiyorsanız neden teslimatı garanti etmemiz gerekiyor? Elimizden gelen çabayı gösteriyoruz. Gerçekten mümkün olduğu kadar ve en iyi şekilde teslim etmeye çalışıyoruz ancak %100 garanti vermiyoruz. Dolayısıyla oraya finansal veri yazmaya gerek yok. Bunun için işlemlerin olduğu veritabanları var.
Soru: API günlükte bir mesaj oluşturduğunda ve kontrolü mikro hizmetlere aktardığında, farklı mikro hizmetlerden gelen mesajların yanlış sırada gelmesi sorunuyla karşılaştınız mı? Bu karışıklığa neden olur.
Cevap: Farklı sıralarda gelmeleri normaldir. Bunun için hazırlıklı olmanız gerekir. Çünkü herhangi bir ağ teslimatı düzeni garanti etmez veya bunun için özel kaynaklar harcamanız gerekir. Dosya depolarını alırsak, her API günlükleri kendi dosyasına kaydeder. Daha doğrusu, rsyslog onları dizinlere ayırıyor. Her API'nin gidip bakabileceğiniz kendi günlükleri vardır ve ardından bu günlükteki zaman damgasını kullanarak bunları karşılaştırabilirsiniz. Graylog'a bakarlarsa orada zaman damgasına göre sıralanırlar. Orada her şey güzel olacak.
Soru: Zaman damgası milisaniyeye göre değişebilir.
Cevap: Zaman damgası API'nin kendisi tarafından oluşturulur. Aslında bütün mesele bu. NTP'miz var. API, mesajın kendisinde bir zaman damgası oluşturur. rsyslog bunu eklemiyor.
Soru: Veri merkezleri arasındaki etkileşim çok net değil. Veri merkezi içerisinde logların nasıl toplandığı ve işlendiği açıktır. Veri merkezleri arasındaki etkileşim nasıl gerçekleşiyor? Yoksa her veri merkezi kendi hayatını mı yaşıyor?
Cevap: Neredeyse. Ülkemizde her ülke bir veri merkezinde bulunmaktadır. Şu anda bir ülkenin farklı veri merkezlerinde yer alması şeklinde bir yayılımımız yok. Bu nedenle bunları birleştirmeye gerek yoktur. Her merkezin içinde bir Log Rölesi bulunur. Bu bir RSyslog sunucusudur. Aslında iki yönetim makinesi. Aynı tutuma sahipler. Ancak şimdilik trafik bunlardan birinden geçiyor. Tüm günlükleri bir araya getirir. Her ihtimale karşı bir disk kuyruğu var. Günlükleri indirir ve merkezi veri merkezine (Singapur) gönderir, burada da Graylog'a gönderilir. Ve her veri merkezinin kendi dosya deposu vardır. Bağlantımızın kopması durumunda tüm günlükler orada bulunur. Orada kalacaklar. Orada saklanacaklar.
Soru: Anormal durumlarda logları oradan alıyor musunuz?
Cevap: Oraya (dosya deposuna) gidip bakabilirsiniz.
Soru: Günlükleri kaybetmediğinizi nasıl izliyorsunuz?
Cevap: Aslında onları kaybediyoruz ve bunu takip ediyoruz. İzleme bir ay önce başlatıldı. Go API'lerinin kullandığı kitaplığın metrikleri vardır. Bir sokete kaç kez yazı yazamadığının sayısını sayabilir. Şu anda orada akıllı bir buluşsal yöntem var. Orada bir tampon var. Ondan sokete bir mesaj yazmaya çalışır. Arabellek taşarsa, onları düşürmeye başlar. Ve kaç tanesini düşürdüğünü sayıyor. Orada sayaçlar taşmaya başlarsa haberimiz olacak. Artık onlar da Prometheus'a geliyorlar ve grafikleri Grafana'da görebilirsiniz. Uyarıları ayarlayabilirsiniz. Ancak kime gönderileceği henüz belli değil.
Soru: Elasticsearch'te günlükleri yedekli olarak saklarsınız. Kaç kopyanız var?
Cevap: Tek çizgi.
Soru: Bu sadece bir satır mı?
Cevap: Bu ana kopya ve kopyadır. Veriler iki kopya halinde saklanır.
Soru: Bir şekilde rsyslog arabellek boyutunu ayarladınız mı?
Cevap: Datagramları özel bir unix soketine yazıyoruz. Bu bize anında 128 kilobaytlık bir sınır getiriyor. Daha fazlasını yazamayız. Bunu standarda yazdık. Depolamaya girmek isteyenler 128 kilobyte yazıyor. Üstelik kütüphanelerin yolları kesiliyor, mesajın kesildiğine dair bayrak asılıyor. Mesajın kendisine yönelik standartımızda, kayıt sırasında kesilip kesilmediğini gösteren özel bir alan bulunmaktadır. Dolayısıyla bu anı da takip etme imkanımız var.
Soru: Bozuk JSON yazıyor musunuz?
Cevap: Bozuk JSON, paket çok büyük olduğundan geçiş sırasında atılacaktır. Veya Graylog, JSON'u ayrıştıramadığından atılacaktır. Ancak düzeltilmesi gereken nüanslar var ve bunlar çoğunlukla rsyslog'a bağlı. Orada zaten üzerinde çalışılması gereken birkaç konuyu doldurdum.
Soru: Neden Kafka? RabbitMQ'yu denediniz mi? Graylog bu tür yükler altında başarısız olur mu?
Cevap: Graylog ile işler bizim için yürümüyor. Ve Graylog bizim için şekilleniyor. Gerçekten sorunlu biri. O tuhaf bir şey. Ve aslında buna gerek yok. Doğrudan rsyslog'dan elasticsearch'e yazmayı ve ardından Kibana'ya bakmayı tercih ederim. Ama sorunu güvenlik görevlileriyle çözmemiz gerekiyor. Graylog'u atıp Kibana'yı kullandığımızda bu, geliştirmemiz için olası bir seçenektir. Logstash'ı kullanmanın bir anlamı yok. Çünkü aynı şeyi rsyslog ile de yapabilirim. Ve elasticsearch'e yazmak için bir modülü var. Graylog'la bir şekilde yaşamaya çalışıyoruz. Hatta biraz ayarladık. Ancak hala iyileştirme için yer var.
Kafka'ya dair. Tarihsel olarak bu böyle oldu. Ben geldiğimde zaten oradaydı ve kayıtlar zaten ona yazılıyordu. Kümemizi yükselttik ve günlükleri ona taşıdık. Biz onun yönetimiyiz, nasıl hissettiğini biliyoruz. RabbitMQ'ya gelince... RabbitMQ bizim için işe yaramıyor. Ve RabbitMQ bizim için şekilleniyor. Üretimde var ve sorunlar vardı. Şimdi satıştan önce onu büyüleyecekler ve normal şekilde çalışmaya başlayacaktı. Ancak ondan önce onu üretime sokmaya hazır değildim. Bir nokta daha var. Graylog, AMQP sürüm 0.9'u okuyabilir ve rsyslog, AMQP 1.0 sürümünü yazabilir. Ve ortada ikisini birden yapabilecek tek bir çözüm yok. Ya biri ya da diğeri. Bu nedenle şu anda sadece Kafka. Ama aynı zamanda kendi nüansları da var. Çünkü kullandığımız rsyslog sürümünün omkafka'sı, rsyslog'dan aldığı mesaj arabelleğinin tamamını kaybedebilir. Yeter ki biz buna katlanalım.
Soru: Kafka'yı zaten sahip olduğunuz için mi kullanıyorsunuz? Artık herhangi bir amaç için kullanılmıyor mu?
Cevap: Veri Bilimi ekibi tarafından kullanılan Kafka. Bu tamamen ayrı bir proje ve ne yazık ki hakkında hiçbir şey söyleyemem. Bilmiyorum. Veri Bilimi ekibi tarafından yürütüldü. Günlükler oluşturulduğunda, kendimizinkini yüklememek için onu kullanmaya karar verdik. Şimdi Graylog'u güncelledik ve Kafka'nın eski bir sürümüne sahip olduğu için uyumluluğu kaybettik. Kendi işimizi başlatmamız gerekiyordu. Aynı zamanda her API için bu dört başlıktan da kurtulduk. Tüm canlı yayınlar için geniş bir konu, tüm sahnelemeler için geniş bir konu oluşturduk ve her şeyi oraya koyduk. Graylog tüm bunları paralel olarak sıyırıyor.
Soru: Bu prizli şamanizme neden ihtiyacımız var? Kapsayıcılar için sistem günlüğü günlük sürücüsünü kullanmayı denediniz mi?
Cevap: Bu soruyu sorduğumuz dönemde liman işçisiyle ilişkimiz gergindi. Docker 1.0 veya 0.9'du. Docker'ın kendisi tuhaftı. İkincisi, içine günlükleri de iterseniz... Tüm günlükleri kendi içinden, docker arka plan programı aracılığıyla geçirdiğine dair doğrulanmamış bir şüphem var. Bir API çıldırırsa, geri kalan API'ler stdout ve stderr gönderemedikleri gerçeğine takılıp kalır. Bunun nereye varacağını bilmiyorum. Burada Docker syslog sürücüsünü kullanmaya gerek olmadığı hissini verecek düzeyde bir şüphem var. Fonksiyonel test departmanımızın günlükleri içeren kendi Graylog kümesi vardır. Docker günlük sürücülerini kullanıyorlar ve orada her şey yolunda görünüyor. Ama hemen Graylog'a GELF yazıyorlar. Bütün bunlara başladığımızda, sadece işe yaramasına ihtiyacımız vardı. Belki daha sonra birisi gelip yüz yıldır gayet iyi çalıştığını söylediğinde deneyeceğiz.
Soru: Veri merkezleri arası teslimatı rsyslog kullanarak yaparsınız. Neden Kafka değil?
Cevap: Aslında ikisini de yapıyoruz. İki nedenden dolayı. Kanal tamamen ölüyse, sıkıştırılmış biçimde bile tüm günlüklerimiz kanalda gezinmeyecektir. Ve Kafka bu süreçte onları kolayca kaybetmenize izin veriyor. Bu şekilde sıkışan loglardan kurtuluyoruz. Bu durumda sadece doğrudan Kafka'yı kullanıyoruz. Eğer iyi bir kanalımız varsa ve onu serbest bırakmak istiyorsak onların rsyslog'unu kullanırız. Ama aslında, onu, uymayan şeyi kendisi bırakacak şekilde yapılandırabilirsiniz. Şu anda sadece rsyslog dağıtımını doğrudan bir yerde, Kafka'yı da bir yerde kullanıyoruz.
Kaynak: habr.com