Log adalah bagian penting dari sistem, memungkinkan Anda memahami bahwa sistem berfungsi (atau tidak berfungsi) seperti yang diharapkan. Dalam kondisi arsitektur layanan mikro, bekerja dengan log menjadi disiplin tersendiri dari Olimpiade Khusus. Ada banyak masalah yang perlu ditangani:
- cara menulis log dari aplikasi;
- tempat menulis log;
- cara mengirim log untuk disimpan dan diproses;
- cara memproses dan menyimpan log.
Penggunaan teknologi kontainerisasi yang populer saat ini menambah pasir di atas penggaruk di bidang opsi pemecahan masalah.
Tentang ini adalah transkrip laporan oleh Yuri Bushmelev "Peta penggaruk di bidang pengumpulan dan pengiriman kayu gelondongan"
Siapa yang peduli, tolong di bawah kucing.
Nama saya Yuri Bushmelev. Saya bekerja untuk Lazada. Hari ini saya akan berbicara tentang bagaimana kami membuat log kami, bagaimana kami mengumpulkannya, dan apa yang kami tulis di sana.
Dari mana kita berasal? Siapa kita? Lazada adalah peritel online #1 di enam negara di Asia Tenggara. Semua negara ini didistribusikan di antara pusat data. Sekarang total ada 4 pusat data, mengapa ini penting? Karena beberapa keputusan disebabkan oleh fakta bahwa ada hubungan yang sangat lemah antara pusat-pusat tersebut. Kami memiliki arsitektur layanan mikro. Saya terkejut saat mengetahui bahwa kami sudah memiliki 80 layanan mikro. Ketika saya memulai tugas dengan log, hanya ada 20. Plus, ada bagian warisan PHP yang agak besar, yang juga harus saya jalani dan tahan. Semua ini menghasilkan bagi kami saat ini lebih dari 6 juta pesan per menit untuk sistem secara keseluruhan. Selanjutnya saya akan menunjukkan bagaimana kami mencoba untuk hidup dengan ini, dan mengapa demikian.
Anda harus hidup dengan 6 juta pesan ini. Apa yang harus kita lakukan dengan mereka? 6 juta pesan diperlukan:
- kirim dari aplikasi
- menerima untuk pengiriman
- dikirim untuk analisis dan penyimpanan.
- menganalisa
- menyimpan entah bagaimana.
Ketika ada tiga juta pesan, saya memiliki tampilan yang hampir sama. Karena kami mulai dengan beberapa sen. Jelas bahwa log aplikasi tertulis di sana. Misalnya, tidak bisa terhubung ke database, bisa terhubung ke database, tapi tidak bisa membaca sesuatu. Namun selain itu, setiap layanan mikro kami juga menulis log akses. Setiap permintaan yang tiba di layanan mikro masuk ke dalam log. Mengapa kita melakukan ini? Pengembang ingin dapat melacak. Setiap log akses berisi bidang traceid, yang menurutnya antarmuka khusus kemudian melepaskan seluruh rantai dan menampilkan jejak dengan indah. Jejak menunjukkan bagaimana permintaan berjalan, dan ini membantu pengembang kami menangani sampah yang tidak diketahui dengan lebih cepat.
Bagaimana cara hidup dengannya? Sekarang saya akan menjelaskan secara singkat bidang opsi - bagaimana masalah ini diselesaikan secara umum. Bagaimana mengatasi masalah mengumpulkan, mentransfer, dan menyimpan log.
Bagaimana cara menulis dari aplikasi? Jelas bahwa ada berbagai cara. Secara khusus, ada praktik terbaik, seperti yang dikatakan oleh rekan-rekan modis kepada kami. Ada dua jenis sekolah tua, seperti kata kakek. Ada cara lain.
Dengan pengumpulan log, situasinya kurang lebih sama. Tidak banyak pilihan untuk menyelesaikan bagian khusus ini. Ada lebih banyak dari mereka, tetapi belum begitu banyak.
Namun dengan penyampaian dan analisis selanjutnya, jumlah variasi mulai meledak. Saya tidak akan menjelaskan setiap opsi sekarang. Saya pikir opsi utama sudah diketahui oleh semua orang yang tertarik dengan topik tersebut.
Saya akan menunjukkan kepada Anda bagaimana kami melakukannya di Lazada dan bagaimana semuanya dimulai.
Setahun yang lalu, saya datang ke Lazada dan dikirim ke proyek log. Itu seperti ini di sana. Log dari aplikasi ditulis ke stdout dan stderr. Semuanya dilakukan dengan cara yang modis. Tapi kemudian pengembang membuangnya dari aliran standar, dan kemudian spesialis infrastruktur akan mengetahuinya. Antara spesialis infrastruktur dan pengembang, ada juga rilis yang berkata: "eh ... baiklah, mari kita bungkus saja dalam file dengan shell, dan hanya itu." Dan karena semua ini ada di dalam wadah, mereka membungkusnya tepat di dalam wadah itu sendiri, memetakan direktori di dalamnya dan meletakkannya di sana. Saya pikir cukup jelas bagi semua orang apa yang terjadi.
Mari kita lihat lebih jauh. Bagaimana kami mengirimkan log ini. Seseorang memilih td-agent, yang sebenarnya lancar tetapi tidak terlalu lancar. Saya masih tidak mengerti hubungan kedua proyek ini, tetapi tampaknya tentang hal yang sama. Dan fasih ini, ditulis dalam Ruby, membaca file log, menguraikannya menjadi JSON menggunakan beberapa ekspresi reguler. Kemudian mereka dikirim ke Kafka. Selain itu, di Kafka, kami memiliki 4 topik terpisah untuk setiap API. Mengapa 4? Karena ada live, ada staging, dan karena ada stdout dan stderr. Pengembang memproduksinya, dan pekerja infrastruktur harus membuatnya di Kafka. Apalagi Kafka dikendalikan oleh departemen lain. Oleh karena itu, perlu dibuat tiket agar mereka membuat 4 topik di sana untuk setiap api. Semua orang melupakannya. Secara umum, itu adalah sampah dan limbah.
Apa yang kita lakukan selanjutnya dengan itu? Kami mengirimkannya ke kafka. Lebih jauh dari Kafka, setengah dari batang kayu terbang ke Logstash. Separuh log lainnya dibagikan. Beberapa terbang ke satu Graylog, beberapa ke Graylog lainnya. Akibatnya, semua ini terbang ke dalam satu cluster Elasticsearch. Artinya, semua kekacauan ini berakhir di sana. Anda tidak perlu melakukan itu!
Seperti ini jika dilihat dari atas. Anda tidak perlu melakukan itu! Di sini, area masalah langsung ditandai dengan angka. Sebenarnya ada lebih banyak dari mereka, tetapi 6 benar-benar bermasalah, yang perlu dilakukan sesuatu. Saya akan menceritakan tentang mereka secara terpisah sekarang.
Di sini (1,2,3) kami menulis file dan, karenanya, ada tiga penggaruk di sini sekaligus.
Yang pertama (1) adalah kita perlu menuliskannya di suatu tempat. Itu tidak selalu diinginkan untuk memberikan API kemampuan untuk menulis langsung ke file. Sebaiknya API diisolasi dalam wadah, dan bahkan lebih baik lagi, hanya bisa dibaca. Saya seorang administrator sistem, jadi saya memiliki sedikit pandangan alternatif tentang hal-hal ini.
Poin kedua (2,3) adalah kami memiliki banyak permintaan yang datang ke API. API menulis banyak data ke file. File-file itu berkembang. Kita perlu memutarnya. Karena jika tidak, Anda tidak akan dapat menyimpan disk apa pun di sana. Memutarnya buruk karena dialihkan melalui shell ke direktori. Tidak mungkin kita bisa memutarnya. Anda tidak dapat memberi tahu aplikasi untuk membuka kembali pegangannya. Karena pengembang akan memandang Anda seperti orang bodoh: “Deskriptor apa? Kami biasanya menulis ke stdout. Kerangka kerja membuat copytruncate menjadi logrotate, yang hanya membuat salinan file dan membuat trunk yang asli. Karenanya, di antara proses penyalinan ini, ruang disk biasanya habis.
(4) Kami memiliki format yang berbeda di API yang berbeda. Mereka sedikit berbeda, tetapi regexp harus ditulis secara berbeda. Karena semuanya dikelola oleh Wayang, ada banyak kelas dengan kecoak mereka sendiri. Plus, td-agent sebagian besar waktu bisa memakan memori, menjadi bodoh, dia hanya bisa berpura-pura bekerja dan tidak melakukan apa-apa. Secara lahiriah, mustahil untuk memahami bahwa dia tidak melakukan apa-apa. Paling banter, dia akan jatuh, dan seseorang akan menjemputnya nanti. Lebih tepatnya, sebuah peringatan akan terbang masuk, dan seseorang akan pergi dan mengangkatnya dengan tangan mereka.
(6) Dan yang paling banyak sampah dan limbah - itu adalah pencarian elastis. Karena itu adalah versi lama. Karena kami tidak memiliki guru yang berdedikasi pada saat itu. Kami memiliki log heterogen yang bidangnya dapat tumpang tindih. Log yang berbeda dari aplikasi yang berbeda dapat ditulis dengan nama bidang yang sama, tetapi pada saat yang sama mungkin terdapat data yang berbeda di dalamnya. Artinya, satu log dilengkapi dengan bilangan bulat di bidang, misalnya, level. Log lain dilengkapi dengan String di bidang level. Dengan tidak adanya pemetaan statis, hal yang luar biasa terjadi. Jika, setelah rotasi indeks, pesan dengan string tiba lebih dulu di elasticsearch, maka kita hidup normal. Dan jika yang pertama datang dengan Integer, maka semua pesan berikutnya yang datang dengan String akan dibuang begitu saja. Karena jenis bidang tidak cocok.
Kami mulai mengajukan pertanyaan-pertanyaan ini. Kami memutuskan untuk tidak mencari yang bersalah.
Tetapi sesuatu perlu dilakukan! Hal yang jelas adalah kita perlu menetapkan standar. Kami sudah memiliki beberapa standar. Beberapa kami bawa nanti. Untungnya, satu format log untuk semua API sudah disetujui saat itu. Itu ditulis langsung ke dalam standar interaksi layanan. Karenanya, mereka yang ingin menerima log harus menulisnya dalam format ini. Jika seseorang tidak menulis log dalam format ini, maka kami tidak menjamin apapun.
Selanjutnya, saya ingin memiliki satu standar untuk metode pencatatan, pengiriman dan pengumpulan log. Sebenarnya, di mana menulisnya, dan bagaimana cara menyampaikannya. Situasi yang ideal adalah ketika proyek menggunakan pustaka yang sama. Ada pustaka logging terpisah untuk Go, ada pustaka terpisah untuk PHP. Setiap orang yang kita miliki, setiap orang harus menggunakannya. Saat ini, saya akan mengatakan bahwa kami berhasil 80 persen. Tetapi beberapa terus makan kaktus.
Dan di sana (di slide) "SLA untuk pengiriman log" baru saja mulai muncul. Itu belum ada di sana, tapi kami sedang mengusahakannya. Karena sangat nyaman ketika infra mengatakan bahwa jika Anda menulis dalam format ini dan itu ke tempat ini dan itu dan tidak lebih dari N pesan per detik, kemungkinan besar kami akan mengirimkannya ke sana. Ini menghilangkan banyak sakit kepala. Jika ada SLA, maka itu bagus!
Bagaimana kita mulai memecahkan masalah? Rake utama adalah dengan td-agent. Tidak jelas ke mana log kami pergi. Apakah mereka dikirim? Apakah mereka akan pergi? Di mana mereka sih? Oleh karena itu, diputuskan untuk mengganti td-agent dengan item pertama. Opsi untuk menggantinya dengan apa, saya uraikan secara singkat di sini.
Lancar Pertama, saya bertemu dengannya di pekerjaan sebelumnya, dan dia juga secara berkala jatuh ke sana. Kedua, ini sama, hanya di profil.
filebeat. Bagaimana itu baik bagi kita? Fakta bahwa dia ada di Go, dan kami memiliki keahlian hebat di Go. Karenanya, jika ada, entah bagaimana kita bisa menambahkannya ke diri kita sendiri. Itu sebabnya kami tidak mengambilnya. Sehingga tidak ada godaan untuk mulai menulis ulang sendiri.
Solusi yang jelas untuk sysadmin adalah semua jenis syslog dalam jumlah ini (syslog-ng/rsyslog/nxlog).
Atau tulis sesuatu milik Anda sendiri, tetapi kami membuangnya, serta filebeat. Jika Anda menulis sesuatu, lebih baik menulis sesuatu yang berguna untuk bisnis. Untuk mengirimkan log, lebih baik mengambil sesuatu yang sudah jadi.
Oleh karena itu, pilihan sebenarnya adalah pilihan antara syslog-ng dan rsyslog. Saya condong ke rsyslog hanya karena kami sudah memiliki kelas untuk rsyslog di Wayang, dan saya tidak menemukan perbedaan yang jelas di antara mereka. Apa itu syslog, apa itu syslog. Ya, beberapa dokumentasi lebih buruk, beberapa lebih baik. Dia tahu cara ini, dan dia melakukannya secara berbeda.
Dan sedikit tentang rsyslog. Pertama, keren karena modulnya banyak. Ini memiliki RainerScript yang dapat dibaca manusia (bahasa konfigurasi modern). Bonus yang luar biasa adalah kami dapat meniru perilaku td-agent dengan alat standarnya, dan tidak ada yang berubah untuk aplikasi. Yaitu, kami mengubah td-agent menjadi rsyslog, dan belum menyentuh yang lainnya. Dan segera kami mendapatkan pengiriman yang berfungsi. Selanjutnya, mmnormalize adalah hal keren tentang rsyslog. Ini memungkinkan Anda untuk mengurai log, tetapi tidak dengan Grok dan regexp. Itu membuat pohon sintaks abstrak. Ini mem-parsing log dengan cara yang sama seperti kompiler mem-parsing kode sumber. Ini memungkinkan Anda untuk bekerja sangat cepat, makan sedikit CPU, dan, secara umum, itu hal yang sangat keren. Masih banyak bonus lainnya. Saya tidak akan memikirkannya.
rsyslog memiliki lebih banyak kelemahan. Mereka hampir sama dengan bonus. Masalah utamanya adalah Anda harus bisa memasaknya, dan Anda harus memilih versinya.
Kami memutuskan bahwa kami akan menulis log di soket unix. Dan tidak di /dev/log, karena di sana kami memiliki log sistem yang berantakan, ada jurnal di dalam pipa ini. Jadi mari menulis ke soket khusus. Kami akan melampirkannya ke kumpulan aturan terpisah. Mari kita tidak mengganggu apa pun. Semuanya akan transparan dan dapat dimengerti. Jadi kami benar-benar melakukannya. Direktori dengan soket ini distandarisasi dan diteruskan ke semua wadah. Kontainer dapat melihat soket yang mereka butuhkan, membuka dan menulisnya.
Kenapa bukan file? Karena semua orang pernah membaca , yang mencoba meneruskan file ke docker, dan menemukan bahwa setelah memulai ulang rsyslog, deskriptor file berubah, dan docker kehilangan file ini. Dia terus membuka sesuatu yang lain, tetapi bukan soket yang sama di mana mereka menulis. Kami memutuskan bahwa kami akan melewati masalah ini, dan, pada saat yang sama, melewati masalah pemblokiran.
Rsyslog melakukan tindakan yang ditunjukkan pada slide dan mengirimkan log ke relai atau Kafka. Kafka mengikuti cara lama. Rayleigh - Saya mencoba menggunakan rsyslog murni untuk mengirimkan log. Tanpa Antrian Pesan, menggunakan alat rsyslog standar. Pada dasarnya, ini berhasil.
Tapi ada nuansa dengan cara memasukkannya nanti ke bagian ini (Logstash/Graylog/ES). Bagian ini (rsyslog-rsyslog) digunakan antara pusat data. Ini adalah tautan tcp terkompresi, yang memungkinkan Anda menghemat bandwidth dan, karenanya, meningkatkan kemungkinan kami menerima beberapa log dari pusat data lain saat saluran penuh. Karena kita punya Indonesia yang semuanya buruk. Di situlah letak masalah yang terus-menerus.
Kami berpikir tentang bagaimana kami benar-benar memantau, dengan kemungkinan apa log yang kami rekam dari aplikasi mencapai tujuan itu? Kami memutuskan untuk memulai metrik. Rsyslog memiliki modul pengumpulan statistiknya sendiri, yang memiliki semacam penghitung. Misalnya, ini dapat menunjukkan ukuran antrean, atau berapa banyak pesan yang masuk untuk tindakan ini dan itu. Anda sudah dapat mengambil sesuatu dari mereka. Plus, ini memiliki penghitung khusus yang dapat Anda konfigurasikan, dan ini akan menunjukkan kepada Anda, misalnya, jumlah pesan yang telah direkam oleh beberapa API. Selanjutnya, saya menulis rsyslog_exporter dengan Python, dan kami mengirimkan semuanya ke Prometheus dan diplot. Kami sangat menginginkan metrik Graylog, tetapi sejauh ini kami belum punya waktu untuk menyiapkannya.
Apa masalahnya? Masalah muncul dengan fakta bahwa kami menemukan (Tiba-tiba!) bahwa Live API kami menulis 50 ribu pesan per detik. Ini hanya API Langsung tanpa pementasan. Dan Graylog hanya menampilkan 12 ribu pesan per detik. Dan muncul pertanyaan yang masuk akal, di mana sisa-sisanya? Dari situ kami menyimpulkan bahwa Graylog tidak bisa mengatasinya. Kami melihat, dan, memang, Graylog dengan Elasticsearch tidak menguasai aliran ini.
Selanjutnya, penemuan lain yang kami buat di sepanjang jalan.
Menulis ke soket diblokir. Bagaimana hal itu terjadi? Saat saya menggunakan rsyslog untuk pengiriman, di beberapa titik kami memutus saluran antara pusat data. Pengiriman bangkit di satu tempat, pengiriman bangkit di tempat lain. Semua ini bermuara pada mesin dengan API yang menulis ke soket rsyslog. Ada antrian. Kemudian antrian untuk menulis ke soket unix terisi, yang secara default adalah 128 paket. Dan write() berikutnya di blok aplikasi. Saat kami melihat pustaka yang kami gunakan di aplikasi Go, tertulis di sana bahwa penulisan ke soket terjadi dalam mode non-pemblokiran. Kami yakin tidak ada yang diblokir. Karena kita telah membaca yang menulis tentang itu. Tapi ada saatnya. Ada juga loop tak terbatas di sekitar panggilan ini, di mana ada upaya terus-menerus untuk memasukkan pesan ke dalam soket. Kami tidak memperhatikannya. Saya harus menulis ulang perpustakaan. Sejak itu, ini telah berubah beberapa kali, tetapi sekarang kami telah menghilangkan kunci di semua subsistem. Oleh karena itu, Anda dapat menghentikan rsyslog dan tidak ada yang jatuh.
Penting untuk memantau ukuran antrian, yang membantu untuk tidak menginjak penggaruk ini. Pertama, kita bisa memantau kapan kita mulai kehilangan pesan. Kedua, kami dapat memantau bahwa pada dasarnya kami memiliki masalah dengan pengiriman.
Dan momen tidak menyenangkan lainnya - amplifikasi 10 kali lipat dalam arsitektur layanan mikro sangat mudah. Kami tidak memiliki begitu banyak permintaan masuk, tetapi karena grafik di mana pesan-pesan ini berjalan lebih jauh, karena log akses, kami benar-benar meningkatkan beban pada log sekitar sepuluh kali lipat. Sayangnya, saya tidak punya waktu untuk menghitung angka pastinya, tetapi layanan mikro memang seperti itu. Ini harus diingat. Ternyata saat ini subsistem pengumpulan log paling banyak dimuat di Lazada.
Bagaimana cara mengatasi masalah pencarian elastis? Jika Anda perlu mendapatkan log dengan cepat di satu tempat, agar tidak berjalan di semua mesin dan mengumpulkannya di sana, gunakan penyimpanan file. Ini dijamin berhasil. Itu dilakukan dari server mana pun. Anda hanya perlu menempelkan disk di sana dan meletakkan syslog. Setelah itu, Anda dijamin memiliki semua log di satu tempat. Kemudian dimungkinkan untuk mengonfigurasi elasticsearch, graylog, atau yang lainnya secara perlahan. Tetapi Anda sudah memiliki semua log, dan terlebih lagi, Anda dapat menyimpannya, selama array disk cukup.
Pada saat laporan saya, skema mulai terlihat seperti ini. Kami praktis berhenti menulis ke file. Sekarang, kemungkinan besar, kami akan mematikan sisa-sisanya. Pada mesin lokal yang menjalankan API, kami akan berhenti menulis ke file. Pertama, ada penyimpanan file, yang bekerja dengan sangat baik. Kedua, mesin ini terus-menerus kehabisan ruang, Anda harus terus memantaunya.
Bagian ini dengan Logstash dan Graylog, benar-benar melonjak. Karena itu, Anda perlu menyingkirkannya. Anda harus memilih salah satu.
Kami memutuskan untuk menjatuhkan Logstash dan Kibana. Karena kami memiliki departemen keamanan. Apa hubungannya? Koneksinya adalah Kibana tanpa X-Pack dan tanpa Shield tidak memungkinkan Anda untuk membedakan hak akses ke log. Oleh karena itu, mereka mengambil Graylog. Ia memiliki semuanya. Saya tidak menyukainya, tetapi berhasil. Kami membeli perangkat keras baru, memasang Graylog baru di sana, dan memindahkan semua log dengan format ketat ke Graylog terpisah. Kami telah memecahkan masalah dengan berbagai jenis bidang yang sama secara organisasi.
Apa sebenarnya yang termasuk dalam Graylog baru. Kami baru saja menulis semuanya di buruh pelabuhan. Kami mengambil banyak server, meluncurkan tiga instans Kafka, 7 server Graylog versi 2.3 (karena saya menginginkan Elasticsearch versi 5). Semua ini dibesarkan pada penggerebekan dari HDD. Kami melihat tingkat pengindeksan hingga 100 ribu pesan per detik. Kami melihat angka 140 terabyte data per minggu.
Dan lagi penggaruk! Kami memiliki dua penjualan yang akan datang. Kami telah melampaui 6 juta postingan. Kami Graylog tidak punya waktu untuk mengunyah. Entah bagaimana Anda harus bertahan hidup lagi.
Beginilah cara kami bertahan. Menambahkan beberapa server dan SSD lagi. Saat ini kami hidup seperti ini. Sekarang kami sudah mengunyah 160 ribu pesan per detik. Kami belum mencapai batasnya, jadi tidak jelas seberapa banyak yang bisa kami keluarkan secara realistis.
Ini adalah rencana kami untuk masa depan. Dari jumlah tersebut, sungguh, yang paling penting mungkin adalah ketersediaan yang tinggi. Kami belum memilikinya. Beberapa mobil dipasang dengan cara yang sama, tetapi sejauh ini semuanya melewati satu mobil. Diperlukan waktu untuk menyiapkan failover di antara mereka.
Kumpulkan metrik dari Graylog.
Buat batas tarif sehingga kami memiliki satu API gila yang tidak membunuh kami bandwidth dan yang lainnya.
Dan terakhir, tandatangani semacam SLA dengan pengembang sehingga kami bisa melayani sebanyak itu. Jika Anda menulis lebih banyak, maka maaf.
Dan menulis dokumentasi.
Singkatnya, hasil dari semua yang kami alami. Pertama, standar. Kedua, syslog adalah kue. Ketiga, rsyslog berfungsi persis seperti yang tertulis di slide. Dan mari kita ke pertanyaan.
pertanyaan.
Pertanyaan: Mengapa mereka memutuskan untuk tidak mengambil ... (filebeat?)
Menjawab: Perlu menulis ke file. Saya benar-benar tidak mau. Saat API Anda menulis ribuan pesan per detik, bahkan jika Anda menggilir sekali dalam satu jam, ini tetap bukan pilihan. Anda dapat menulis ke pipa. Di mana pengembang bertanya kepada saya: "Apa yang akan terjadi jika proses yang kami tulis gagal"? Saya hanya tidak menemukan apa untuk menjawabnya, dan berkata: "Baiklah, jangan lakukan itu."
Pertanyaan: Mengapa Anda tidak menulis log ke HDFS saja?
MenjawabA: Ini adalah tahap selanjutnya. Kami memikirkannya sejak awal, tetapi karena tidak ada sumber daya untuk menanganinya saat ini, solusi jangka panjang kami menggantung.
Pertanyaan: Format kolom akan lebih cocok.
Menjawab: Saya mengerti. Kami "untuk" dengan kedua tangan.
Pertanyaan: Anda menulis ke rsyslog. Baik TCP dan UDP tersedia di sana. Tetapi jika UDP, lalu bagaimana Anda menjamin pengiriman?
MenjawabJ: Ada dua poin. Pertama, saya segera memberi tahu semua orang bahwa kami tidak menjamin pengiriman log. Karena ketika pengembang datang dan berkata: "Mari mulai menulis data keuangan di sana, dan Anda akan meletakkannya di suatu tempat untuk kami jika terjadi sesuatu", kami menjawab mereka, "Bagus! Mari kita mulai memblokir menulis ke soket, dan melakukannya dalam transaksi, sehingga Anda dijamin memasukkannya ke dalam soket untuk kami dan memastikan bahwa kami menerimanya dari sisi lain. Dan pada saat ini, semua orang segera menjadi tidak diperlukan. Dan jika tidak, lalu pertanyaan apa yang kita miliki? Jika Anda tidak ingin menjamin penulisan ke soket, lalu mengapa kami menjamin pengiriman? Kami melakukan upaya terbaik. Kami benar-benar berusaha memberikan sebanyak mungkin dan sebaik mungkin, namun kami tidak memberikan jaminan 100%. Karena itu, Anda tidak perlu menulis data keuangan di sana. Ada database transaksional untuk ini.
Pertanyaan: Ketika API menghasilkan beberapa pesan ke log dan mentransfer kontrol ke layanan mikro, apakah Anda mengalami masalah bahwa pesan dari layanan mikro yang berbeda tiba dengan urutan yang salah? Karena itu, kebingungan muncul.
MenjawabA: Itu normal bahwa mereka datang dalam urutan yang berbeda. Anda harus siap untuk ini. Karena pengiriman jaringan apa pun tidak menjamin pesanan untuk Anda, atau Anda perlu mengeluarkan sumber daya khusus untuk ini. Jika kami mengambil penyimpanan file, maka setiap API menyimpan log ke filenya sendiri. Sebaliknya, rsyslog menguraikannya menjadi direktori di sana. Setiap API memiliki lognya sendiri di sana, di mana Anda dapat pergi dan melihat, lalu Anda dapat membandingkannya menggunakan stempel waktu di log ini. Jika mereka mencari di Graylog, maka di sana mereka akan diurutkan berdasarkan stempel waktu. Semuanya akan baik-baik saja di sana.
Pertanyaan: Stempel waktu dapat bervariasi dalam milidetik.
Menjawab: Stempel waktu dihasilkan oleh API itu sendiri. Faktanya, inilah intinya. Kami memiliki NTP. API sudah menghasilkan stempel waktu dalam pesan itu sendiri. Itu tidak ditambahkan oleh rsyslog.
Pertanyaan: Interaksi antara pusat data tidak terlalu jelas. Dalam kerangka pusat data, jelas bagaimana log dikumpulkan dan diproses. Bagaimana interaksi antar pusat data? Atau apakah setiap pusat data menjalani kehidupannya sendiri?
Menjawab: Hampir. Kami memiliki setiap negara yang terletak di satu pusat data. Kami saat ini tidak memiliki penyebaran, sehingga satu negara ditempatkan di pusat data yang berbeda. Karena itu, tidak perlu menggabungkannya. Di dalam setiap pusat terdapat Log Relay. Ini adalah server Rsyslog. Bahkan, dua mesin manajemen. Mereka diatur dengan cara yang sama. Namun untuk saat ini, lalu lintas hanya melewati salah satunya. Dia mencatat semua agregat. Ini memiliki antrian disk untuk berjaga-jaga. Dia menekan log dan mengirimkannya ke pusat data pusat (Singapura), di mana mereka sudah diracuni di Graylog. Dan setiap pusat data memiliki penyimpanan file sendiri. Jika kami kehilangan koneksi, kami memiliki semua log di sana. Mereka akan tinggal di sana. Mereka akan disimpan di sana.
Pertanyaan: Apakah Anda mendapatkan log dari sana selama situasi abnormal?
Menjawab: Anda dapat pergi ke sana (ke penyimpanan file) dan melihat.
Pertanyaan: Bagaimana Anda memantau bahwa Anda tidak kehilangan log?
Menjawab: Kami benar-benar kehilangan mereka, dan kami memantaunya. Pemantauan dimulai sebulan yang lalu. Pustaka yang digunakan Go API memiliki metrik. Dia dapat menghitung berapa kali dia gagal menulis ke soket. Di sana saat ini ada heuristik yang rumit. Ada penyangga di sana. Ia mencoba menulis pesan darinya ke soket. Jika buffer meluap, itu mulai menjatuhkannya. Dan dia menghitung berapa banyak dia menjatuhkannya. Jika penghitung mulai meluap di sana, kami akan mengetahuinya. Mereka sekarang juga datang ke prometheus, dan Anda dapat melihat grafiknya di Grafana. Anda dapat mengatur peringatan. Namun belum jelas kepada siapa harus mengirimkannya.
Pertanyaan: Di elasticsearch, Anda menyimpan log dengan redundansi. Berapa banyak replika yang Anda miliki?
Menjawab: Satu replika.
Pertanyaan: Apakah hanya satu baris?
Menjawab: Ini adalah master dan replika. Data disimpan dalam rangkap dua.
Pertanyaan: Apakah Anda mengubah ukuran buffer rsyslog?
Menjawab: Kami menulis datagram ke soket unix khusus. Ini segera memberlakukan batasan 128 kilobyte pada kami. Kami tidak bisa menulis lebih banyak tentang itu. Kami telah menulis ini ke dalam standar. Siapa yang ingin masuk ke penyimpanan, mereka menulis 128 kilobyte. Perpustakaan, terlebih lagi, memotong, dan memberi bendera bahwa pesan tersebut terputus. Kami memiliki bidang khusus dalam standar pesan itu sendiri, yang menunjukkan apakah pesan itu terpotong selama perekaman atau tidak. Jadi kami memiliki kesempatan untuk melacak momen ini.
Pertanyaan: Apakah Anda menulis JSON yang rusak?
Menjawab: JSON yang rusak akan dibuang selama relai karena paket terlalu besar. Atau Graylog akan dihapus, karena tidak dapat mengurai JSON. Tapi ada nuansa di sini yang perlu diperbaiki, dan sebagian besar terkait dengan rsyslog. Saya sudah mengisi beberapa masalah di sana, yang masih perlu dikerjakan.
Pertanyaan: Kenapa Kafka? Sudahkah Anda mencoba RabbitMQ? Graylog tidak bertambah di bawah beban seperti itu?
Menjawab: Tidak bekerja dengan Graylog. Dan Graylog mulai terbentuk. Ini benar-benar bermasalah baginya. Dia semacam hal. Dan nyatanya, itu tidak dibutuhkan. Saya lebih suka menulis dari rsyslog langsung ke elasticsearch dan kemudian menonton Kibana. Tapi kita perlu menyelesaikan masalah dengan penjaga keamanan. Ini adalah varian yang mungkin dari pengembangan kami saat kami membuang Graylog dan menggunakan Kibana. Logstash tidak masuk akal. Karena saya bisa melakukan hal yang sama dengan rsyslog. Dan ia memiliki modul untuk menulis ke elasticsearch. Dengan Graylog kami mencoba untuk hidup entah bagaimana. Kami bahkan mengubahnya sedikit. Tapi masih ada ruang untuk perbaikan.
Tentang Kafka. Begitulah yang terjadi secara historis. Ketika saya tiba, itu sudah ada di sana, dan log sudah ditulis untuk itu. Kami baru saja mengangkat klaster kami dan memindahkan log ke dalamnya. Kami mengaturnya, kami tahu bagaimana perasaannya. Untuk RabbitMQ... kami mengalami masalah dengan RabbitMQ. Dan RabbitMQ sedang berkembang untuk kami. Kami memilikinya dalam produksi, dan ada masalah dengannya. Sekarang, sebelum dijual, dia akan disiksa, dan dia akan mulai bekerja secara normal. Tapi sebelumnya, saya belum siap merilisnya ke produksi. Ada satu poin lagi. Graylog dapat membaca versi AMQP 0.9 dan rsyslog dapat menulis versi AMQP 1.0. Dan tidak ada satu solusi pun yang dapat melakukan keduanya di tengah. Ada salah satu atau yang lain. Jadi untuk saat ini hanya Kafka. Tapi ada juga nuansa. Karena omkafka versi rsyslog yang kita gunakan bisa kehilangan seluruh buffer pesan yang diambilnya dari rsyslog. Selama kita menahannya.
Pertanyaan: Apakah Anda menggunakan Kafka karena Anda memilikinya? Tidak digunakan untuk tujuan lain?
Menjawab: Kafka, yang digunakan oleh tim Data Science. Ini adalah proyek yang sepenuhnya terpisah, yang sayangnya, saya tidak bisa mengatakan apa-apa. Saya tidak tahu. Dia dijalankan oleh tim Ilmu Data. Ketika log dimulai, mereka memutuskan untuk menggunakannya, agar tidak menempatkannya sendiri. Sekarang kami telah memperbarui Graylog, dan kami kehilangan kompatibilitas, karena ada Kafka versi lama. Kami harus membuatnya sendiri. Pada saat yang sama, kami menyingkirkan keempat topik ini untuk setiap API. Kami membuat satu atasan lebar untuk semua siaran langsung, satu atasan lebar lebar untuk semua pementasan dan kami hanya merekam semuanya di sana. Graylog menggali semua ini secara paralel.
Pertanyaan: Mengapa kita membutuhkan perdukunan ini dengan soket? Sudahkah Anda mencoba menggunakan driver log syslog untuk wadah.
Menjawab: Pada saat kami menanyakan pertanyaan ini, kami memiliki hubungan yang tegang dengan buruh pelabuhan. Itu buruh pelabuhan 1.0 atau 0.9. Docker sendiri aneh. Kedua, jika Anda juga memasukkan log ke dalamnya ... Saya memiliki kecurigaan yang tidak dapat diverifikasi bahwa ia melewati semua log melalui dirinya sendiri, melalui daemon buruh pelabuhan. Jika kita memiliki satu API yang gila, maka API lainnya akan mengalami fakta bahwa mereka tidak dapat mengirim stdout dan stderr. Saya tidak tahu kemana ini akan mengarah. Saya memiliki kecurigaan pada tingkat perasaan bahwa tidak perlu menggunakan driver docker syslog di tempat ini. Departemen pengujian fungsional kami memiliki kluster Graylog sendiri dengan log. Mereka menggunakan driver log buruh pelabuhan dan semuanya tampak baik-baik saja di sana. Tapi mereka segera menulis GELF ke Graylog. Pada saat kami memulai semua ini, kami membutuhkannya untuk bekerja. Mungkin nanti, ketika seseorang datang dan mengatakan bahwa itu telah berfungsi normal selama seratus tahun, kami akan mencobanya.
Pertanyaan: Anda mengirim antar pusat data menggunakan rsyslog. Kenapa tidak di Kafka?
Menjawab: Kami melakukan ini, dan begitulah adanya. Karena dua alasan. Jika saluran benar-benar mati, maka semua log kami, bahkan dalam bentuk terkompresi, tidak akan melewatinya. Dan kafka memungkinkan mereka kalah begitu saja dalam prosesnya. Dengan cara ini, kami menghilangkan penempelan batang kayu ini. Kami hanya menggunakan Kafka dalam hal ini secara langsung. Jika kami memiliki saluran yang bagus dan ingin membebaskannya, kami menggunakan rsyslog mereka. Namun nyatanya, Anda dapat mengaturnya sehingga menjatuhkan apa yang tidak dapat dilewatinya. Saat ini kami hanya menggunakan pengiriman rsyslog langsung di suatu tempat, di suatu tempat Kafka.
Sumber: www.habr.com