Log ialah bahagian penting dalam sistem, membolehkan anda memahami bahawa ia berfungsi (atau tidak berfungsi) seperti yang diharapkan. Di bawah syarat seni bina perkhidmatan mikro, bekerja dengan kayu balak menjadi satu disiplin tersendiri bagi Olimpik Khas. Terdapat banyak isu yang perlu ditangani:
- cara menulis log daripada aplikasi;
- di mana untuk menulis log;
- cara menghantar log untuk penyimpanan dan pemprosesan;
- cara memproses dan menyimpan log.
Penggunaan teknologi kontena yang popular pada masa ini menambah pasir di atas garu dalam bidang pilihan penyelesaian masalah.
Kira-kira ini adalah transkrip laporan oleh Yuri Bushmelev "Peta garu dalam bidang mengumpul dan menghantar balak"
Siapa peduli, sila di bawah kucing.
Nama saya Yuri Bushmelev. Saya bekerja untuk Lazada. Hari ini saya akan bercakap tentang cara kami membuat log kami, cara kami mengumpulnya, dan apa yang kami tulis di sana.
kita dari mana? Siapakah kita? Lazada ialah peruncit dalam talian #1 di enam negara di Asia Tenggara. Semua negara ini diedarkan di antara pusat data. Kini terdapat 4 pusat data secara keseluruhan. Mengapa ini penting? Kerana beberapa keputusan adalah disebabkan oleh fakta bahawa terdapat hubungan yang sangat lemah antara pusat. Kami mempunyai seni bina perkhidmatan mikro. Saya terkejut apabila mendapati kami sudah mempunyai 80 perkhidmatan mikro. Apabila saya memulakan tugas dengan log, hanya terdapat 20 daripadanya. Tambahan pula, terdapat sekeping legasi PHP yang agak besar, yang juga saya perlu hadapi dan hadapi. Semua ini menjana untuk kami pada masa ini lebih daripada 6 juta mesej seminit untuk sistem secara keseluruhan. Selanjutnya saya akan menunjukkan bagaimana kita cuba untuk hidup dengan ini, dan mengapa ini berlaku.
Anda perlu hidup dengan 6 juta mesej ini entah bagaimana. Apa yang perlu kita lakukan dengan mereka? 6 juta mesej diperlukan:
- hantar dari aplikasi
- terima untuk penghantaran
- hantar untuk analisis dan penyimpanan.
- untuk menganalisis
- simpan entah bagaimana.
Apabila terdapat tiga juta mesej, saya mempunyai rupa yang sama. Kerana kami bermula dengan beberapa sen. Adalah jelas bahawa log permohonan ditulis di sana. Sebagai contoh, tidak dapat menyambung ke pangkalan data, boleh menyambung ke pangkalan data, tetapi tidak dapat membaca sesuatu. Tetapi selain ini, setiap perkhidmatan mikro kami juga menulis log akses. Setiap permintaan yang tiba di perkhidmatan mikro dimasukkan ke dalam log. Mengapa kita melakukan ini? Pemaju mahu dapat mengesan. Setiap log akses mengandungi medan traceid, yang mengikutnya antara muka khas kemudiannya membuka keseluruhan rantai dan memaparkan jejak dengan cantik. Surih menunjukkan bagaimana permintaan itu berlaku, dan ini membantu pembangun kami menangani sebarang sampah yang tidak diketahui dengan lebih cepat.
Bagaimana untuk hidup dengannya? Sekarang saya akan menerangkan secara ringkas bidang pilihan - bagaimana masalah ini secara amnya diselesaikan. Bagaimana untuk menyelesaikan masalah mengumpul, memindahkan dan menyimpan balak.
Bagaimana untuk menulis dari aplikasi? Jelas bahawa terdapat cara yang berbeza. Khususnya, terdapat amalan terbaik, seperti yang diberitahu oleh rakan-rakan yang bergaya. Ada dua jenis sekolah lama, seperti kata datuk. Ada cara lain.
Dengan pengumpulan log, keadaannya lebih kurang sama. Tidak banyak pilihan untuk menyelesaikan bahagian tertentu ini. Terdapat lebih daripada mereka, tetapi tidak begitu banyak lagi.
Tetapi dengan penghantaran dan analisis seterusnya, bilangan variasi mula meletup. Saya tidak akan menerangkan setiap pilihan sekarang. Saya fikir pilihan utama diketahui oleh semua orang yang berminat dengan topik itu.
Saya akan menunjukkan kepada anda bagaimana kami melakukannya di Lazada dan bagaimana ia bermula.
Setahun yang lalu, saya datang ke Lazada dan dihantar ke projek log. Ia adalah seperti ini di sana. Log daripada aplikasi telah ditulis kepada stdout dan stderr. Semuanya dilakukan dengan cara yang bergaya. Tetapi kemudian pemaju membuangnya daripada aliran standard, dan kemudian pakar infrastruktur akan memikirkannya entah bagaimana. Antara pakar infrastruktur dan pemaju, terdapat juga pelepas yang berkata: "eh ... baiklah, mari bungkus mereka dalam fail dengan cangkerang, dan itu sahaja." Dan kerana semua ini ada dalam bekas, mereka membungkusnya betul-betul dalam bekas itu sendiri, memetakan direktori di dalam dan meletakkannya di sana. Saya fikir ia agak jelas kepada semua orang apa yang berlaku.
Mari lihat lebih jauh. Cara kami menghantar log ini. Seseorang memilih td-agent, yang sebenarnya fasih tetapi tidak begitu fasih. Saya masih tidak memahami hubungan kedua-dua projek ini, tetapi ia seolah-olah mengenai perkara yang sama. Dan fasih ini, yang ditulis dalam Ruby, membaca fail log, menghuraikannya ke dalam JSON menggunakan beberapa ungkapan biasa. Kemudian mereka dihantar ke Kafka. Selain itu, di Kafka, kami mempunyai 4 topik berasingan untuk setiap API. Kenapa 4? Kerana ada live, ada pementasan, dan kerana ada stdout dan stderr. Pemaju menghasilkannya, dan pekerja infrastruktur mesti menciptanya di Kafka. Lebih-lebih lagi, Kafka dikawal oleh jabatan lain. Oleh itu, adalah perlu untuk mencipta tiket supaya mereka mencipta 4 topik di sana untuk setiap api. Semua orang melupakannya. Secara umum, ia adalah sampah dan sisa.
Apa yang kita lakukan seterusnya dengannya? Kami menghantarnya kepada kafka. Lebih jauh dari Kafka, separuh daripada kayu balak terbang ke Logstash. Separuh lagi daripada kayu balak itu dikongsi. Ada yang terbang ke satu Graylog, beberapa ke Graylog yang lain. Akibatnya, semua ini terbang ke dalam satu kelompok Elasticsearch. Iaitu, semua kekacauan ini berakhir di sana. Anda tidak perlu berbuat demikian!
Beginilah rupanya apabila dilihat dari atas. Anda tidak perlu berbuat demikian! Di sini, kawasan masalah segera ditandakan dengan nombor. Sebenarnya terdapat lebih banyak daripada mereka, tetapi 6 adalah yang benar-benar bermasalah, yang mana sesuatu perlu dilakukan. Saya akan memberitahu tentang mereka secara berasingan sekarang.
Di sini (1,2,3) kami menulis fail dan, oleh itu, terdapat tiga rake di sini sekaligus.
Yang pertama (1) ialah kita perlu menulisnya di suatu tempat. Ia tidak semestinya wajar untuk memberikan API keupayaan untuk menulis terus ke fail. Adalah wajar bahawa API diasingkan dalam bekas, dan lebih baik lagi, ia boleh dibaca sahaja. Saya seorang pentadbir sistem, jadi saya mempunyai pandangan alternatif sedikit tentang perkara ini.
Perkara kedua (2,3) ialah kami mempunyai banyak permintaan yang datang ke API. API menulis banyak data ke fail. Fail semakin berkembang. Kita perlu menggilirkan mereka. Kerana jika tidak, anda tidak akan dapat menyimpan sebarang cakera di sana. Memutarnya adalah tidak baik kerana ia diubah hala melalui shell ke direktori. Tidak mungkin kita boleh memutarkannya. Anda tidak boleh memberitahu aplikasi untuk membuka semula pemegangnya. Kerana pembangun akan melihat anda seperti orang bodoh: “Penerangan apa? Kami biasanya menulis kepada stdout. Rangka kerja membuat copytruncate menjadi logrotate, yang hanya membuat salinan fail dan batang asal. Sehubungan itu, antara proses penyalinan ini, ruang cakera biasanya kehabisan.
(4) Kami mempunyai format yang berbeza dalam API yang berbeza. Mereka berbeza sedikit, tetapi regexp perlu ditulis secara berbeza. Oleh kerana semuanya diuruskan oleh Puppet, terdapat sekumpulan besar kelas dengan lipas mereka sendiri. Tambahan pula, ejen td selalunya boleh makan ingatan, menjadi bodoh, dia hanya boleh berpura-pura bahawa dia bekerja dan tidak melakukan apa-apa. Secara luaran, adalah mustahil untuk memahami bahawa dia tidak melakukan apa-apa. Paling best, dia akan jatuh, dan seseorang akan mengangkatnya nanti. Lebih tepat lagi, amaran akan masuk, dan seseorang akan pergi dan mengangkatnya dengan tangan mereka.
(6) Dan yang paling banyak sampah dan sisa - ia adalah elasticsearch. Kerana ia adalah versi lama. Kerana kami tidak mempunyai tuan yang berdedikasi pada masa itu. Kami mempunyai log heterogen yang bidangnya boleh bertindih. Log yang berbeza bagi aplikasi yang berbeza boleh ditulis dengan nama medan yang sama, tetapi pada masa yang sama mungkin terdapat data yang berbeza di dalamnya. Iaitu, satu log datang dengan Integer dalam medan, sebagai contoh, tahap. Log lain datang dengan String dalam medan tahap. Dengan ketiadaan pemetaan statik, perkara yang begitu indah ternyata. Jika, selepas putaran indeks, mesej dengan rentetan tiba dahulu dalam elasticsearch, maka kita hidup secara normal. Dan jika yang pertama tiba dengan Integer, maka semua mesej berikutnya yang tiba dengan String akan dibuang begitu sahaja. Kerana jenis medan tidak sepadan.
Kami mula bertanya soalan ini. Kami memutuskan untuk tidak mencari yang bersalah.
Tetapi sesuatu perlu dilakukan! Perkara yang jelas ialah kita perlu mewujudkan piawaian. Kami sudah mempunyai beberapa piawaian. Ada yang kami bawa sedikit kemudian. Nasib baik, satu format log untuk semua API telah pun diluluskan pada masa itu. Ia ditulis terus ke dalam piawaian interaksi perkhidmatan. Sehubungan itu, mereka yang ingin menerima log hendaklah menulisnya dalam format ini. Jika seseorang tidak menulis log dalam format ini, maka kami tidak menjamin apa-apa.
Selanjutnya, saya ingin mempunyai satu piawaian untuk kaedah merekod, menghantar dan mengumpul log. Sebenarnya, di mana untuk menulisnya, dan bagaimana untuk menyampaikannya. Situasi yang ideal ialah apabila projek menggunakan perpustakaan yang sama. Terdapat perpustakaan pengelogan berasingan untuk Go, terdapat perpustakaan berasingan untuk PHP. Setiap orang yang kita ada, semua orang harus menggunakannya. Pada masa ini, saya akan mengatakan bahawa kita berjaya sebanyak 80 peratus. Tetapi ada yang terus makan kaktus.
Dan di sana (pada slaid) "SLA untuk penghantaran log" hampir tidak mula muncul. Ia belum ada, tetapi kami sedang mengusahakannya. Kerana ia adalah sangat mudah apabila infra mengatakan bahawa jika anda menulis dalam format begini dan begitu ke tempat itu dan ini dan tidak lebih daripada N mesej sesaat, maka kemungkinan besar kami akan menghantarnya ke sana. Ia menghilangkan banyak sakit kepala. Jika ada SLA, maka ia sangat bagus!
Bagaimanakah kita mula menyelesaikan masalah itu? Pengaut utama adalah dengan td-agent. Tidak jelas ke mana perginya balak kami. Adakah mereka dihantar? Adakah mereka akan pergi? Di mana pula mereka? Oleh itu, ia telah memutuskan untuk menggantikan td-agent dengan item pertama. Pilihan untuk menggantikannya, saya gariskan secara ringkas di sini.
Fasihd. Pertama, saya terserempak dengannya di tempat kerja sebelumnya, dan dia juga secara berkala jatuh di sana. Kedua, ini adalah sama, hanya dalam profil.
filebeat. Bagaimanakah ia baik untuk kita? Hakikat bahawa dia berada dalam Go, dan kami mempunyai kepakaran yang hebat dalam Go. Oleh itu, jika ada, kita boleh menambahnya kepada diri kita sendiri. Itulah sebabnya kami tidak mengambilnya. Supaya tidak ada sebarang godaan untuk mula menulis semula untuk diri sendiri.
Penyelesaian yang jelas untuk sysadmin ialah semua jenis syslog dalam kuantiti ini (syslog-ng/rsyslog/nxlog).
Atau tulis sesuatu sendiri, tetapi kami membuangnya, serta filebeat. Jika anda menulis sesuatu, maka lebih baik menulis sesuatu yang berguna untuk perniagaan. Untuk menghantar log, lebih baik mengambil sesuatu yang sudah siap.
Oleh itu, pilihan sebenarnya datang kepada pilihan antara syslog-ng dan rsyslog. Saya condong ke arah rsyslog semata-mata kerana kami sudah mempunyai kelas untuk rsyslog dalam Puppet, dan saya tidak menemui perbezaan yang jelas antara mereka. Apa itu syslog, apa itu syslog. Ya, beberapa dokumentasi lebih buruk, ada yang lebih baik. Dia tahu cara ini, dan dia melakukannya secara berbeza.
Dan sedikit tentang rsyslog. Pertama, ia sejuk kerana ia mempunyai banyak modul. Ia mempunyai RainerScript yang boleh dibaca manusia (bahasa konfigurasi moden). Bonus yang hebat ialah kita boleh meniru gelagat td-agent dengan alat standardnya, dan tiada apa yang berubah untuk aplikasi. Iaitu, kami menukar td-agent kepada rsyslog, dan tidak menyentuh semua yang lain lagi. Dan segera kami mendapat penghantaran yang berfungsi. Seterusnya, mmnormalize adalah perkara yang menarik tentang rsyslog. Ia membolehkan anda menghuraikan log, tetapi tidak dengan Grok dan regexp. Ia menjadikan pokok sintaks abstrak. Ia menghuraikan log dengan cara yang sama seperti pengkompil menghuraikan kod sumber. Ini membolehkan anda bekerja dengan sangat pantas, makan sedikit CPU, dan, secara umum, ia hanya satu perkara yang sangat keren. Terdapat banyak bonus lain. Saya tidak akan memikirkan mereka.
rsyslog mempunyai lebih banyak kelemahan. Mereka hampir sama dengan bonus. Masalah utama ialah anda perlu boleh memasaknya, dan anda perlu memilih versi.
Kami memutuskan bahawa kami akan menulis log dalam soket unix. Dan bukan dalam /dev/log, kerana di sana kita mempunyai kekacauan log sistem, terdapat jurnal dalam saluran paip ini. Jadi mari kita tulis ke soket tersuai. Kami akan melampirkannya pada set peraturan yang berasingan. Jangan kita campur apa-apa. Semuanya akan telus dan boleh difahami. Jadi kami sebenarnya melakukannya. Direktori dengan soket ini diseragamkan dan dimajukan kepada semua bekas. Bekas boleh melihat soket yang mereka perlukan, membuka dan menulis kepadanya.
Kenapa bukan fail? Sebab semua orang dah baca , yang cuba memajukan fail ke docker, dan mendapati bahawa selepas memulakan semula rsyslog, deskriptor fail berubah, dan docker kehilangan fail ini. Dia terus membuka sesuatu yang lain, tetapi bukan soket yang sama tempat mereka menulis. Kami memutuskan bahawa kami akan memintas masalah ini, dan, pada masa yang sama, memintas masalah menyekat.
Rsyslog melakukan tindakan yang ditunjukkan pada slaid dan menghantar log ke sama ada geganti atau Kafka. Kafka mengikut cara lama. Rayleigh - Saya cuba menggunakan rsyslog tulen untuk menghantar log. Tanpa Baris Gilir Mesej, menggunakan alat rsyslog standard. Pada asasnya, ia berfungsi.
Tetapi terdapat nuansa dengan cara memasukkannya kemudian ke bahagian ini (Logstash/Graylog/ES). Bahagian ini (rsyslog-rsyslog) digunakan antara pusat data. Berikut ialah pautan tcp termampat, yang membolehkan anda menjimatkan lebar jalur dan, dengan itu, meningkatkan kemungkinan kami akan menerima beberapa log daripada pusat data lain apabila saluran penuh. Kerana kita ada Indonesia, di mana segala-galanya buruk. Di situlah letak masalah yang berterusan.
Kami memikirkan bagaimana kami sebenarnya boleh memantau dengan apakah kebarangkalian log yang kami rakamkan daripada aplikasi mencapai hujung itu? Kami memutuskan untuk memulakan metrik. Rsyslog mempunyai modul pengumpulan statistiknya sendiri, yang mempunyai beberapa jenis pembilang. Contohnya, ia boleh menunjukkan kepada anda saiz baris gilir, atau berapa banyak mesej yang masuk untuk tindakan sedemikian dan sedemikian. Anda sudah boleh mengambil sesuatu daripada mereka. Selain itu, ia mempunyai kaunter tersuai yang boleh anda konfigurasikan, dan ia akan menunjukkan kepada anda, sebagai contoh, bilangan mesej yang telah direkodkan oleh sesetengah API. Seterusnya, saya menulis rsyslog_exporter dalam Python, dan kami menghantar semuanya kepada Prometheus dan merancang. Kami benar-benar mahukan metrik Graylog, tetapi setakat ini kami tidak mempunyai masa untuk menyediakannya.
Apakah masalahnya? Masalah timbul dengan fakta bahawa kami mendapati (TIBA-TIBA!) bahawa API Langsung kami menulis 50k mesej sesaat. Ini hanya API Langsung tanpa pementasan. Dan Graylog hanya menunjukkan kepada kami 12 ribu mesej sesaat. Dan timbul persoalan yang munasabah, di manakah saki-bakinya? Dari mana kami membuat kesimpulan bahawa Graylog tidak dapat mengatasinya. Kami melihat, dan, sememangnya, Graylog dengan Elasticsearch tidak menguasai aliran ini.
Seterusnya, penemuan lain yang telah kami buat sepanjang perjalanan.
Tulisan ke soket disekat. Bagaimana ia berlaku? Apabila saya menggunakan rsyslog untuk penghantaran, pada satu ketika kami memecahkan saluran antara pusat data. Hantaran naik di satu tempat, penghantaran naik di tempat lain. Semua ini telah diturunkan kepada mesin dengan API yang menulis ke soket rsyslog. Terjadi beratur. Kemudian baris gilir untuk menulis ke soket unix diisi, yang secara lalai ialah 128 paket. Dan write() seterusnya dalam blok aplikasi. Apabila kami melihat perpustakaan yang kami gunakan dalam aplikasi Go, ada tertulis di sana bahawa menulis ke soket berlaku dalam mod tidak menyekat. Kami pasti tiada apa-apa yang disekat. Sebab kita dah baca yang menulis mengenainya. Tetapi ada seketika. Terdapat juga gelung tak terhingga di sekeliling panggilan ini, di mana terdapat percubaan berterusan untuk menolak mesej ke dalam soket. Kami tidak perasan dia. Saya terpaksa menulis semula perpustakaan. Sejak itu, ia telah berubah beberapa kali, tetapi kini kami telah menyingkirkan kunci dalam semua subsistem. Oleh itu, anda boleh menghentikan rsyslog dan tiada apa yang akan jatuh.
Ia adalah perlu untuk memantau saiz barisan, yang membantu untuk tidak memijak rake ini. Pertama, kita boleh memantau apabila kita mula kehilangan mesej. Kedua, kita boleh memantau bahawa kita pada dasarnya mempunyai masalah dengan penghantaran.
Dan satu lagi detik yang tidak menyenangkan - penguatan sebanyak 10 kali dalam seni bina perkhidmatan mikro adalah sangat mudah. Kami tidak mempunyai begitu banyak permintaan masuk, tetapi disebabkan graf di mana mesej ini berjalan lebih jauh, kerana log akses, kami sebenarnya meningkatkan beban pada log sebanyak kira-kira sepuluh kali ganda. Malangnya, saya tidak mempunyai masa untuk mengira nombor yang tepat, tetapi perkhidmatan mikro adalah apa itu. Ini mesti diingat. Ternyata pada masa ini subsistem pengumpulan log adalah yang paling banyak dimuatkan di Lazada.
Bagaimana untuk menyelesaikan masalah elasticsearch? Jika anda perlu mendapatkan log dengan cepat di satu tempat, agar tidak merentasi semua mesin dan mengumpulnya di sana, gunakan storan fail. Ini dijamin berkesan. Ia dilakukan dari mana-mana pelayan. Anda hanya perlu melekatkan cakera di sana dan meletakkan syslog. Selepas itu, anda dijamin mempunyai semua log di satu tempat. Kemudian anda boleh mengkonfigurasi elasticsearch, greylog atau sesuatu yang lain secara perlahan-lahan. Tetapi anda sudah mempunyai semua log, dan, lebih-lebih lagi, anda boleh menyimpannya, selagi terdapat susunan cakera yang mencukupi.
Pada masa laporan saya, skema mula kelihatan seperti ini. Kami hampir berhenti menulis ke fail. Sekarang, kemungkinan besar, kita akan mematikan sisa. Pada mesin tempatan yang menjalankan API, kami akan berhenti menulis ke fail. Pertama, terdapat storan fail, yang berfungsi dengan baik. Kedua, mesin ini sentiasa kehabisan ruang, anda perlu sentiasa memantaunya.
Bahagian ini dengan Logstash dan Graylog, ia benar-benar melonjak. Oleh itu, anda perlu menyingkirkannya. Anda perlu memilih satu.
Kami memutuskan untuk menggugurkan Logstash dan Kibana. Kerana kita mempunyai jabatan keselamatan. Apa kaitannya? Sambungannya ialah Kibana tanpa X-Pack dan tanpa Shield tidak membenarkan anda membezakan hak akses kepada log. Oleh itu, mereka mengambil Graylog. Ia mempunyai semuanya. Saya tidak suka, tetapi ia berkesan. Kami membeli perkakasan baharu, memasang Graylog baharu di sana dan mengalihkan semua log dengan format ketat ke Graylog yang berasingan. Kami telah menyelesaikan masalah dengan pelbagai jenis bidang yang sama secara organisasi.
Apa sebenarnya yang disertakan dalam Graylog baharu. Kami hanya menulis segala-galanya dalam docker. Kami mengambil sekumpulan pelayan, melancarkan tiga contoh Kafka, 7 pelayan Graylog versi 2.3 (kerana saya mahukan Elasticsearch versi 5). Semua ini dibangkitkan pada serbuan dari HDD. Kami melihat kadar pengindeksan sehingga 100 ribu mesej sesaat. Kami melihat angka bahawa 140 terabait data setiap minggu.
Dan sekali lagi garu! Kami mempunyai dua jualan yang akan datang. Kami telah melepasi 6 juta jawatan. Kami Graylog tidak mempunyai masa untuk mengunyah. Entah bagaimana anda perlu bertahan semula.
Beginilah cara kami bertahan. Menambah beberapa lagi pelayan dan SSD. Pada masa ini kita hidup seperti ini. Kini kami sudah mengunyah 160k mesej sesaat. Kami belum mencapai had, jadi tidak jelas berapa banyak yang boleh kami keluarkan secara realistik.
Ini adalah rancangan kami untuk masa depan. Daripada jumlah ini, yang paling penting mungkin ketersediaan yang tinggi. Kami belum memilikinya. Beberapa kereta disediakan dengan cara yang sama, tetapi setakat ini semuanya melalui satu kereta. Ia adalah perlu untuk meluangkan masa untuk menubuhkan failover antara mereka.
Kumpul metrik daripada Graylog.
Buat had kadar supaya kami mempunyai satu API gila yang tidak membunuh lebar jalur kami dan segala-galanya.
Dan akhirnya, tandatangani beberapa jenis SLA dengan pembangun supaya kami boleh berkhidmat sebanyak itu. Jika anda menulis lebih banyak, maka maaf.
Dan tulis dokumentasi.
Secara ringkasnya, hasil segala yang telah kita alami. Pertama, piawaian. Kedua, syslog ialah kek. Ketiga, rsyslog berfungsi sama seperti yang ditulis pada slaid. Dan mari kita ke soalan.
soalan.
Soalan: Mengapa mereka memutuskan untuk tidak mengambil ... (filebeat?)
Jawab: Perlu menulis ke fail. Saya benar-benar tidak mahu. Apabila API anda menulis beribu-ribu mesej sesaat, walaupun anda berputar sekali sejam, ini masih bukan pilihan. Anda boleh menulis ke paip. Yang mana pembangun bertanya kepada saya: "Apa yang akan berlaku jika proses yang kita tulis jatuh"? Saya hanya tidak menemui apa yang perlu dijawab kepada mereka, dan berkata: "Baiklah, ok, jangan buat begitu."
Soalan: Mengapa anda tidak menulis log sahaja ke HDFS?
JawabA: Ini adalah langkah seterusnya. Kami memikirkannya pada awalnya, tetapi oleh kerana tiada sumber untuk menanganinya pada masa ini, ia bergantung pada penyelesaian jangka panjang kami.
Soalan: Format lajur adalah lebih sesuai.
Jawab: Saya faham. Kami "untuk" dengan kedua-dua tangan.
Soalan: Anda menulis kepada rsyslog. Kedua-dua TCP dan UDP tersedia di sana. Tetapi jika UDP, maka bagaimana anda menjamin penghantaran?
JawabA: Terdapat dua perkara. Pertama, saya segera memberitahu semua orang bahawa kami tidak menjamin penghantaran log. Kerana apabila pembangun datang dan berkata: "Mari mula menulis data kewangan di sana, dan anda akan meletakkannya di suatu tempat untuk kami sekiranya sesuatu berlaku," kami menjawab mereka, "Bagus! Mari kita mula menyekat pada menulis ke soket, dan melakukannya dalam urus niaga, supaya anda dijamin untuk meletakkannya dalam soket untuk kami dan pastikan kami menerimanya dari pihak lain. Dan pada masa ini, semua orang segera menjadi tidak perlu. Dan jika tidak, maka apakah soalan yang kita ada? Jika anda tidak mahu menjamin penulisan pada soket, maka mengapa kami menjamin penghantaran? Kami melakukan usaha yang terbaik. Kami benar-benar cuba untuk menyampaikan sebanyak mungkin dan sebaik mungkin, tetapi kami tidak memberi jaminan 100%. Oleh itu, anda tidak perlu menulis data kewangan di sana. Terdapat pangkalan data transaksi untuk ini.
Soalan: Apabila API menjana beberapa mesej ke log dan memindahkan kawalan kepada perkhidmatan mikro, adakah anda menghadapi masalah bahawa mesej daripada perkhidmatan mikro yang berbeza tiba dalam susunan yang salah? Kerana ini, timbul kekeliruan.
JawabA: Ia adalah perkara biasa bahawa mereka datang dalam susunan yang berbeza. Anda perlu bersedia untuk ini. Kerana sebarang penghantaran rangkaian tidak menjamin pesanan kepada anda, atau anda perlu membelanjakan sumber khas untuk perkara ini. Jika kami mengambil storan fail, maka setiap API menyimpan log ke failnya sendiri. Sebaliknya, rsyslog menguraikannya ke dalam direktori di sana. Setiap API mempunyai log sendiri di sana, di mana anda boleh pergi dan melihat, dan kemudian anda boleh membandingkannya menggunakan cap masa dalam log ini. Jika mereka pergi untuk melihat dalam Graylog, maka di sana mereka akan diisih mengikut cap masa. Semuanya akan baik-baik saja di sana.
Soalan: Cap masa mungkin berbeza mengikut milisaat.
Jawab: Cap masa dijana oleh API itu sendiri. Ini, sebenarnya, adalah keseluruhannya. Kami mempunyai NTP. API menjana cap masa yang sudah ada dalam mesej itu sendiri. Ia tidak ditambah oleh rsyslog.
Soalan: Interaksi antara pusat data tidak begitu jelas. Dalam rangka kerja pusat data, jelas bagaimana log dikumpulkan dan diproses. Bagaimanakah interaksi antara pusat data? Atau adakah setiap pusat data menjalani kehidupannya sendiri?
Jawab: Hampir. Kami mempunyai setiap negara yang terletak dalam satu pusat data. Pada masa ini kami tidak mempunyai penyebaran, supaya satu negara diletakkan di pusat data yang berbeza. Oleh itu, tidak perlu menggabungkannya. Di dalam setiap pusat terdapat Log Relay. Ini adalah pelayan Rsyslog. Malah, dua mesin pengurusan. Mereka disediakan dengan cara yang sama. Tetapi buat masa ini, lalu lintas hanya melalui salah satu daripadanya. Dia log semua agregat. Ia mempunyai baris gilir cakera untuk berjaga-jaga. Dia menekan log dan menghantarnya ke pusat data pusat (Singapura), di mana lebih jauh mereka sudah diracuni dalam Graylog. Dan setiap pusat data mempunyai storan fail sendiri. Sekiranya kami terputus sambungan, kami mempunyai semua log di sana. Mereka akan tinggal di sana. Mereka akan disimpan di sana.
Soalan: Adakah anda mendapat log dari sana semasa situasi tidak normal?
Jawab: Anda boleh pergi ke sana (ke storan fail) dan lihat.
Soalan: Bagaimanakah anda memantau bahawa anda tidak kehilangan log?
Jawab: Kami sebenarnya kehilangan mereka, dan kami memantaunya. Pemantauan bermula sebulan yang lalu. Pustaka yang digunakan oleh API Go mempunyai metrik. Dia boleh mengira berapa kali dia gagal menulis ke soket. Pada masa ini terdapat heuristik yang rumit. Terdapat penampan di sana. Ia cuba menulis mesej daripadanya ke soket. Jika penimbal melimpah, ia mula menjatuhkannya. Dan dia mengira berapa banyak dia menjatuhkan mereka. Jika kaunter mula melimpah di sana, kita akan tahu mengenainya. Mereka kini juga akan datang ke prometheus, dan anda boleh melihat graf dalam Grafana. Anda boleh menyediakan makluman. Tetapi masih belum jelas kepada siapa untuk menghantar mereka.
Soalan: Dalam elasticsearch, anda menyimpan log dengan redundansi. Berapa banyak replika yang anda ada?
Jawab: Satu replika.
Soalan: Adakah ia hanya satu baris?
Jawab: Ini adalah tuan dan replika. Data disimpan dalam pendua.
Soalan: Adakah anda mengubah saiz penimbal rsyslog entah bagaimana?
Jawab: Kami menulis datagram pada soket unix tersuai. Ini serta-merta mengenakan had 128 kilobait kepada kami. Kami tidak boleh menulis lebih lanjut mengenainya. Kami telah menulis ini ke dalam piawaian. Siapa yang mahu masuk ke dalam storan, mereka menulis 128 kilobait. Perpustakaan, lebih-lebih lagi, potong, dan letakkan bendera bahawa mesej itu dipotong. Kami mempunyai medan khas dalam standard mesej itu sendiri, yang menunjukkan sama ada ia dipotong semasa rakaman atau tidak. Jadi kita mempunyai peluang untuk menjejaki detik ini.
soalan: Adakah anda menulis JSON yang rosak?
Jawab: JSON yang rosak akan dibuang sama ada semasa relay kerana paket terlalu besar. Atau Graylog akan digugurkan, kerana ia tidak akan dapat menghuraikan JSON. Tetapi terdapat nuansa di sini yang perlu diperbaiki, dan kebanyakannya terikat pada rsyslog. Saya telah pun mengisi beberapa isu di sana, yang masih perlu diusahakan.
soalan: Kenapa Kafka? Pernahkah anda mencuba RabbitMQ? Graylog tidak menambah di bawah beban sedemikian?
Jawab: Ia tidak berfungsi dengan Graylog. Dan Graylog semakin terbentuk. Memang menyusahkan dia. Dia adalah sejenis perkara. Dan, sebenarnya, ia tidak diperlukan. Saya lebih suka menulis dari rsyslog terus ke elasticsearch dan kemudian menonton Kibana. Tetapi kita perlu menyelesaikan masalah dengan pengawal keselamatan. Ini adalah kemungkinan varian pembangunan kami, apabila kami membuang Graylog dan menggunakan Kibana. Logstash tidak akan masuk akal. Kerana saya boleh melakukan perkara yang sama dengan rsyslog. Dan ia mempunyai modul untuk menulis kepada elasticsearch. Dengan Graylog kami cuba untuk hidup entah bagaimana. Kami juga mengubahnya sedikit. Tetapi masih ada ruang untuk penambahbaikan.
Soal Kafka. Begitulah ia berlaku dalam sejarah. Apabila saya tiba, ia sudah ada, dan log telah ditulis kepadanya. Kami baru sahaja menaikkan kluster kami dan mengalihkan log ke dalamnya. Kita uruskan dia, kita tahu perasaan dia. Bagi RabbitMQ... kami menghadapi masalah dengan RabbitMQ. Dan RabbitMQ sedang membangun untuk kami. Kami mempunyainya dalam pengeluaran, dan terdapat masalah dengannya. Sekarang, sebelum jualan, dia akan dibodohkan, dan dia akan mula bekerja seperti biasa. Tetapi sebelum itu, saya belum bersedia untuk mengeluarkannya ke dalam produksi. Ada satu perkara lagi. Graylog boleh membaca versi AMQP 0.9 dan rsyslog boleh menulis versi AMQP 1.0. Dan tidak ada penyelesaian tunggal yang boleh melakukan kedua-duanya di tengah. Terdapat sama ada satu atau yang lain. Jadi buat masa ini hanya Kafka. Tetapi terdapat juga nuansa. Kerana omkafka versi rsyslog yang kami gunakan boleh kehilangan keseluruhan penimbal mesej yang diperoleh daripada rsyslog. Asalkan kita bersabar.
soalan: Adakah anda menggunakan Kafka kerana anda memilikinya? Tidak digunakan untuk tujuan lain?
Jawab: Kafka, yang digunakan oleh pasukan Sains Data. Ini adalah projek yang sama sekali berasingan, yang saya, malangnya, tidak dapat mengatakan apa-apa. Saya tidak tahu. Dia dikendalikan oleh pasukan Sains Data. Apabila balak bermula, mereka memutuskan untuk menggunakannya, supaya tidak meletakkannya sendiri. Kini kami telah mengemas kini Graylog, dan kami telah kehilangan keserasian, kerana terdapat versi lama Kafka. Kami terpaksa membuat sendiri. Pada masa yang sama, kami menyingkirkan empat topik ini untuk setiap API. Kami membuat satu gasing lebar untuk semua secara langsung, satu gasing lebar lebar untuk semua pementasan dan kami hanya merakam segala-galanya di sana. Graylog mengumpul semua ini secara selari.
soalan: Mengapa kita memerlukan dukun ini dengan soket? Pernahkah anda mencuba menggunakan pemacu log syslog untuk bekas.
Jawab: Pada masa kami bertanya soalan ini, kami mempunyai hubungan tegang dengan pekerja pelabuhan. Ia adalah docker 1.0 atau 0.9. Docker sendiri adalah pelik. Kedua, jika anda juga memasukkan log masuk ke dalamnya ... saya mempunyai syak wasangka yang tidak disahkan bahawa ia melepasi semua log melalui dirinya sendiri, melalui daemon docker. Jika kita mempunyai satu API yang menjadi gila, maka API yang lain akan menghadapi fakta bahawa mereka tidak boleh menghantar stdout dan stderr. Saya tidak tahu ke mana ini akan membawa. Saya mempunyai syak wasangka pada tahap merasakan bahawa tidak perlu menggunakan pemandu syslog docker di tempat ini. Jabatan ujian fungsi kami mempunyai kelompok Graylog sendiri dengan log. Mereka menggunakan pemacu log docker dan semuanya nampaknya baik-baik saja di sana. Tetapi mereka segera menulis GELF kepada Graylog. Pada masa ini apabila kami memulakan semua ini, kami memerlukannya untuk berfungsi. Mungkin kemudian, apabila seseorang datang dan mengatakan bahawa ia telah berfungsi seperti biasa selama seratus tahun, kami akan cuba.
soalan: Anda menghantar antara pusat data menggunakan rsyslog. Mengapa tidak pada Kafka?
Jawab: Kami melakukan ini, dan ini adalah bagaimana ia sebenarnya. Atas dua sebab. Jika saluran itu mati sepenuhnya, maka semua log kami, walaupun dalam bentuk termampat, tidak akan memanjatnya. Dan kafka membenarkan mereka kalah dalam proses itu. Dengan cara ini, kita menyingkirkan kayu balak ini. Kami hanya menggunakan Kafka dalam kes ini secara langsung. Jika kami mempunyai saluran yang baik dan ingin membebaskannya, maka kami menggunakan rsyslog mereka. Tetapi sebenarnya, anda boleh menyediakannya supaya ia menjatuhkan apa yang tidak dapat dilaluinya. Pada masa ini kami hanya menggunakan penghantaran rsyslog terus di suatu tempat, di suatu tempat Kafka.
Sumber: www.habr.com