Ayeuna 2019, sareng urang masih teu gaduh solusi standar pikeun agrégasi log di Kubernetes. Dina artikel ieu, urang hoyong, ngagunakeun conto tina praktek nyata, babagi pilarian urang, masalah encountered jeung solusi maranéhanana.
Nanging, mimitina, kuring bakal ngadamel reservasi yén para nasabah anu béda ngartos hal anu béda-béda ku cara ngumpulkeun log:
- batur hayang ningali kaamanan sarta Inok log;
- batur - logging terpusat tina sakabéh infrastruktur;
- jeung sababaraha, éta cukup pikeun ngumpulkeun ukur log aplikasi, teu kaasup, contona, balancers.
Di handap ieu cut di handap ngeunaan kumaha urang nerapkeun rupa-rupa "hayang daptar" na naon kasusah kami encountered.
Téori: ngeunaan parabot logging
Latar dina komponén sistem logging
Logging parantos lami, salaku hasil tina metodologi pikeun ngumpulkeun sareng nganalisa log parantos dikembangkeun, anu kami anggo ayeuna. Deui dina taun 1950-an, Fortran ngenalkeun analog tina aliran input / output standar, anu ngabantosan programer debug programna. Ieu mangrupikeun log komputer munggaran anu ngajantenkeun hirup langkung gampang pikeun programer jaman éta. Dinten ieu kami ningali aranjeunna komponén mimiti sistem logging - sumber atawa "produser" log.
Élmu komputer teu nangtung kénéh: jaringan komputer mucunghul, klaster munggaran ... Sistem kompléks diwangun ku sababaraha komputer mimiti jalan. Ayeuna pangurus sistem kapaksa ngumpulkeun log tina sababaraha mesin, sareng dina kasus khusus aranjeunna tiasa nambihan pesen kernel OS upami aranjeunna kedah nalungtik gagal sistem. Pikeun ngajelaskeun sistem koleksi log terpusat, dina awal 2000s ieu diterbitkeun , nu standardized remote_syslog. Ieu kumaha komponén penting séjén muncul: kolektor log jeung neundeun maranéhna.
Kalayan paningkatan dina volume log sareng bubuka téknologi wéb anu nyebar, timbul patarosan ngeunaan log naon anu kedah ditingalikeun ka pangguna. parabot konsol basajan (awk / sed / grep) geus diganti ku leuwih canggih pemirsa log - komponén katilu.
Kusabab kanaékan volume log, hal anu sanés janten jelas: log diperyogikeun, tapi henteu sadayana. Sareng log anu béda butuh tingkat pelestarian anu béda: sababaraha tiasa leungit dina sadinten, sedengkeun anu sanésna kedah disimpen salami 5 taun. Janten, komponén pikeun nyaring sareng routing aliran data parantos ditambahkeun kana sistem logging - hayu urang nyebatna tapis.
Panyimpenan ogé parantos ngadamel kabisat utama: tina file biasa ka pangkalan data relasional, teras ka panyimpenan anu berorientasi dokumén (contona, Elasticsearch). Jadi gudang dipisahkeun ti kolektor.
Pamustunganana, pisan konsép log geus dimekarkeun jadi jenis aliran abstrak kajadian nu urang hoyong ngawétkeun pikeun sajarah. Atanapi, upami anjeun kedah ngalaksanakeun panalungtikan atanapi ngadamel laporan analitik...
Hasilna, dina jangka waktu nu relatif pondok, kumpulan log geus dimekarkeun jadi subsistem penting, nu rightfully bisa disebut salah sahiji subsections dina Big Data.
Lamun sakali-kali prints biasa bisa cukup pikeun "sistem logging," ayeuna kaayaan geus robah pisan.
Kubernetes jeung log
Nalika Kubernetes sumping ka infrastruktur, masalah anu parantos aya pikeun ngumpulkeun log ogé henteu ngalangkunganana. Ku sababaraha cara, éta janten langkung nyeri: ngatur platform infrastruktur henteu ngan disederhanakeun, tapi ogé rumit dina waktos anu sami. Loba jasa heubeul geus dimimitian migrasi ka microservices. Dina kontéks log, ieu katémbong dina jumlah sumber log, daur hirup khususna, sareng kabutuhan pikeun ngalacak hubungan sadaya komponén sistem ngalangkungan log ...
Ningali payun, abdi tiasa nyatakeun yén ayeuna, hanjakalna, teu aya pilihan logging standar pikeun Kubernetes anu bakal dibandingkeun sareng anu sanés. Skéma anu pang populerna di masarakat nyaéta kieu:
- batur unrolls tumpukan EFK (Elasticsearch, Fluentd, Kibana);
- aya nu nyobian nu nembe dirilis atawa kagunaan ;
- urang (sareng panginten henteu ngan ukur urang?..) Kuring sabagéan ageung wareg sareng pamekaran kuring sorangan - ...
Sakumaha aturan, kami nganggo bungkusan di handap ieu dina kluster K8s (pikeun solusi anu di-host sorangan):
- ;
- .
Najan kitu, kuring moal Huni on parentah pikeun instalasi tur konfigurasi maranéhanana. Gantina, kuring baris difokuskeun shortcomings maranéhanana sarta conclusions leuwih global ngeunaan kaayaan kalawan log sacara umum.
Latihan kalawan log di K8s
"Log sapopoe", sabaraha anjeun aya?..
Koléksi log terpusat tina infrastruktur anu cukup ageung ngabutuhkeun sumber daya anu ageung, anu bakal dianggo pikeun ngumpulkeun, nyimpen sareng ngolah log. Salila operasi rupa-rupa proyék, kami disanghareupan ku rupa-rupa sarat sareng masalah operasional anu timbul ti aranjeunna.
Hayu urang coba ClickHouse
Hayu urang tingali panyimpen terpusat dina proyék kalayan aplikasi anu ngahasilkeun log anu cukup aktip: langkung ti 5000 garis per detik. Hayu urang ngamimitian damel sareng log na, nambihanana kana ClickHouse.
Pas realtime maksimum diperlukeun, server 4-inti kalawan ClickHouse bakal geus overloaded dina subsistem disk:
jenis ieu loading téh alatan kanyataan yén urang nyoba nulis dina ClickHouse gancang-gancang. Sareng pangkalan data ngaréspon kana ieu kalayan ningkat beban disk, anu tiasa nyababkeun kasalahan ieu:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Point nu dina ClickHouse (aranjeunna ngandung data log) boga kasusah sorangan salila operasi nulis. Data anu diselapkeun kana aranjeunna ngahasilkeun partisi samentawis, anu teras dihijikeun sareng tabel utama. Hasilna, ngarékam tétéla pisan nuntut dina disk, sarta ogé tunduk kana watesan anu kami nampi bewara ngeunaan di luhur: teu leuwih ti 1 subpartitions bisa dihijikeun dina 300 detik (dina kanyataanana, ieu 300 sisipan). per detik).
Pikeun nyingkahan kabiasaan ieu, dina potongan saloba mungkin jeung teu leuwih ti 1 kali unggal 2 detik. Sanajan kitu, nulis dina bursts badag nunjukkeun yen urang kudu nulis kirang remen di ClickHouse. Ieu, kahareupna bisa ngakibatkeun mudal panyangga sarta leungitna log. Solusina nyaéta ningkatkeun panyangga Fluentd, tapi konsumsi mémori ogé bakal ningkat.
nyarios: Aspék masalah sejen tina solusi kami kalawan ClickHouse ieu patali jeung kanyataan yén partitioning bisi urang (loghouse) dilaksanakeun ngaliwatan tabel éksternal disambungkeun. . Ieu ngakibatkeun kanyataan yén nalika sampling interval waktu badag, RAM kaleuleuwihan diperlukeun, saprak metatable nu iterates ngaliwatan sagala partitions - malah maranéhanana anu écés teu ngandung data diperlukeun. Nanging, ayeuna pendekatan ieu tiasa sacara aman dinyatakeun leungit pikeun versi ClickHouse ayeuna (c ).
Hasilna, janten jelas yén teu unggal proyék boga cukup sumberdaya pikeun ngumpulkeun log sacara real waktu di ClickHouse (leuwih tepat, distribusi maranéhanana moal luyu). Salaku tambahan, anjeun kedah nganggo аккумулятор, nu urang bakal balik engké. Kasus ditétélakeun di luhur nyata. Sareng dina waktos éta kami henteu tiasa nawiskeun solusi anu dipercaya sareng stabil anu cocog sareng palanggan sareng ngamungkinkeun urang pikeun ngumpulkeun log kalayan reureuh minimal ...
Kumaha upami Elasticsearch?
Elasticsearch dipikanyaho pikeun nanganan beban kerja anu beurat. Hayu urang cobian dina proyék anu sami. Ayeuna beban sapertos kieu:
Elasticsearch tiasa nyerna aliran data, kumaha oge, nyerat jilid sapertos kitu pisan ngagunakeun CPU. Ieu mutuskeun ku ngatur klaster. Téhnisna, ieu teu jadi masalah, tapi tétéla yén ngan pikeun ngajalankeun sistem kumpulan log kami geus ngagunakeun ngeunaan 8 cores sarta boga komponén tambahan kacida dimuat dina sistem ...
Garis handap: pilihan ieu tiasa diyakinkeun, tapi ngan upami proyekna ageung sareng manajeménna siap nyéépkeun sumber daya anu penting dina sistem logging terpusat.
Lajeng timbul patarosan alam:
Naon log anu diperyogikeun?
Hayu urang coba ngarobah pendekatan sorangan: log kudu sakaligus informatif jeung teu nutupan unggal kajadian dina sistem.
Anggap urang gaduh toko online anu suksés. Naon log anu penting? Ngumpulkeun salaku loba informasi sabisa, contona, ti gateway pamayaran, mangrupakeun ide nu sae. Tapi henteu sadayana log tina jasa nyiksikan gambar dina katalog produk penting pikeun kami: ngan ukur kasalahan sareng ngawaskeun canggih cekap (contona, persentase 500 kasalahan anu dibangkitkeun komponén ieu).
Ku kituna kami geus datang ka kacindekan yén logging terpusat henteu salawasna diyakinkeun. Sering pisan klien hoyong ngumpulkeun sadaya log dina hiji tempat, sanaos kanyataanna, tina sadaya log, ngan ukur 5% pesen anu penting pikeun bisnis anu diperyogikeun:
- Kadang-kadang cukup pikeun ngonpigurasikeun, sebutkeun, ngan ukur ukuran wadahna log sareng kolektor kasalahan (contona, Sentry).
- Bewara kasalahan sareng log lokal anu ageung tiasa sering cekap pikeun nalungtik kajadian.
- Kami ngagaduhan proyék anu dilakukeun ku tés fungsional éksklusif sareng sistem pangumpulan kasalahan. Pamekar henteu peryogi log sapertos kitu - aranjeunna ningali sadayana tina ngambah kasalahan.
Ilustrasi tina kahirupan
carita sejen bisa ngawula ka salaku conto alus. Kami nampi pamundut ti tim kaamanan salah sahiji klien kami anu parantos nganggo solusi komersil anu dikembangkeun lami sateuacan ngenalkeun Kubernetes.
Ieu diperlukeun pikeun "nyieun babaturan" tina sistem kumpulan log terpusat jeung sensor deteksi masalah perusahaan - QRadar. Sistem ieu tiasa nampi log ngalangkungan protokol syslog sareng nyandak deui tina FTP. Nanging, éta henteu tiasa langsung ngahijikeun sareng plugin remote_syslog pikeun fluentd (sakumaha tétéla, ). Masalah sareng nyetél QRadar tétéla aya di sisi tim kaamanan klien.
Hasilna, bagian tina log kritis bisnis ieu diunggah ka FTP QRadar, sarta bagian séjén dialihkeun via syslog jauh langsung ti titik. Pikeun ieu kami malah wrote - Panginten éta bakal ngabantosan batur ngabéréskeun masalah anu sami... Hatur nuhun kana skéma anu hasilna, klien nyalira nampi sareng nganalisa log kritis (ngagunakeun alat karesepna), sareng kami tiasa ngirangan biaya sistem logging, ngan ukur ngahemat bulan panungtungan.
conto sejen cukup indicative tina naon teu kudu ngalakukeun. Salah sahiji klien kami pikeun ngolah masing-masing acara datang ti pamaké, dijieun multiline kaluaran teu terstruktur inpormasi dina log. Sakumaha anjeun panginten, log sapertos kitu henteu pikaresepeun pisan pikeun dibaca sareng disimpen.
Kriteria pikeun log
Conto sapertos ngakibatkeun kacindekan yén salian milih sistem kempelan log, anjeun kedah ogé ngarancang log sorangan! Naon sarat di dieu?
- Log kedah dina format anu tiasa dibaca ku mesin (contona, JSON).
- Log kudu kompak tur mibanda kamampuhan pikeun ngarobah darajat logging guna debug mungkin masalah. Dina waktos anu sami, dina lingkungan produksi anjeun kedah ngajalankeun sistem kalayan tingkat logging sapertos pangeling-eling atawa kasalahan.
- Log kudu dinormalisasi, nyaeta, dina objék log, sadaya garis kudu boga tipe widang sarua.
Log anu teu terstruktur tiasa nyababkeun masalah sareng ngamuat log kana panyimpenan sareng lirén lengkep dina ngolahna. Salaku ilustrasi, ieu conto sareng kasalahan 400, anu seueur anu pasti kapendak dina log fluentd:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Kasalahan hartosna anjeun ngirim lapangan anu jinisna teu stabil kana indéks kalayan pemetaan anu siap-siap. Conto pangbasajanna nyaéta widang dina log nginx kalayan variabel $upstream_status. Bisa ngandung boh angka atawa string. Salaku conto:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Log némbongkeun yén server 10.100.0.10 direspon ku kasalahan 404 sarta pamundut ieu dikirim ka gudang eusi sejen. Hasilna, nilai dina log janten sapertos kieu:
"upstream_response_time": "0.001, 0.007"
kaayaan ieu téh jadi umum nu malah pantes misah .
Kumaha upami reliabilitas?
Aya waktos nalika sadaya log tanpa pangecualian penting pisan. Sareng ieu, skéma kempelan log has pikeun K8 diajukeun / dibahas di luhur ngagaduhan masalah.
Contona, fluentd teu bisa ngumpulkeun log tina wadahna pondok-cicing. Dina salah sahiji proyék kami, wadah migrasi database cicing kirang ti 4 detik teras dihapus - dumasar kana anotasi anu saluyu:
"helm.sh/hook-delete-policy": hook-succeeded
Kusabab ieu, log palaksanaan migrasi henteu kalebet dina panyimpenan. Pulitik tiasa ngabantosan dina hal ieu. before-hook-creation.
Conto sanésna nyaéta rotasi log Docker. Sebutkeun aya aplikasi anu aktip nyerat log. Dina kaayaan normal, urang ngatur pikeun ngolah sadaya log, tapi pas masalah muncul - contona, sakumaha ditétélakeun di luhur kalawan format salah - processing eureun, sarta Docker muterkeun file. Hasilna nyaéta log kritis bisnis tiasa leungit.
Éta pisan sababna naha hal anu penting pikeun misahkeun aliran log, embedding ngirim nu paling berharga langsung kana aplikasi pikeun mastikeun kasalametan maranéhanana. Sajaba ti éta, teu bakal superfluous nyieun sababaraha "akumulator" tina log, nu bisa salamet unavailability gudang ringkes bari nyimpen pesen kritis.
Tungtungna, urang teu kudu poho éta Penting pikeun ngawas subsistem anu leres. Upami teu kitu, éta gampang pikeun ngajalankeun kana kaayaan nu fluentd aya dina kaayaan CrashLoopBackOff sarta teu ngirim nanaon, sarta ieu janji leungitna informasi penting.
papanggihan
Dina tulisan ieu, urang henteu ningali solusi SaaS sapertos Datadog. Seueur masalah anu dijelaskeun di dieu parantos direngsekeun ku cara anu sanés ku perusahaan komérsial anu khusus dina ngumpulkeun log, tapi henteu sadayana tiasa nganggo SaaS pikeun sababaraha alesan. (Anu utama nyaéta biaya sareng patuh kana 152-FZ).
Koléksi log terpusat dina mimitina sigana tugas anu saderhana, tapi henteu pisan. Penting pikeun émut yén:
- Ngan komponén kritis kudu asup sacara rinci, bari ngawaskeun sarta ngumpulkeun kasalahan bisa ngonpigurasi pikeun sistem lianna.
- Log produksi kedah dijaga minimal supados henteu nambihan beban anu teu perlu.
- Log kedah tiasa dibaca mesin, dinormalisasi, sareng gaduh format anu ketat.
- Log anu leres-leres kritis kedah dikirim dina aliran anu misah, anu kedah dipisahkeun tina anu utama.
- Eta sia tempo accumulator log, nu bisa nyalametkeun anjeun tina bursts tina beban tinggi na nyieun beban dina gudang leuwih seragam.
Aturan saderhana ieu, upami diterapkeun di mana waé, bakal ngamungkinkeun sirkuit anu dijelaskeun di luhur tiasa dianggo - sanaos aranjeunna leungit komponén penting (batré). Upami anjeun henteu patuh kana prinsip sapertos kitu, tugasna bakal gampang ngajurung anjeun sareng infrastruktur ka komponén sistem anu sarat pisan (sareng henteu efektif).
PS
Baca ogé dina blog urang:
- «";
- «";
- «".
sumber: www.habr.com