Docker болон Kubernetes дээр бүртгэл хийх үндсийг харцгаая, дараа нь үйлдвэрлэлд аюулгүй ашиглаж болох хоёр хэрэгслийг авч үзье: Grafana Loki болон EFK стек (Elasticsearch + Fluent Bit + Kibana).
Өгүүллийн материал --аас авсан . Хэрэв танд хүсэл байгаа бол, тэр байтугай үйлдвэрлэлийн хэрэгцээ байгаа бол та бүрэн сургалтанд хамрагдах боломжтой - курст бүртгүүлнэ үү .
Docker-д нэвтэрч байна
Kubernetes түвшинд програмууд нь pods хэлбэрээр ажилладаг боловч доод түвшинд ихэвчлэн Docker дээр ажилладаг. Тиймээс, та савнаас лог цуглуулах байдлаар бүртгэлийг тохируулах хэрэгтэй. Контейнеруудыг Docker ажиллуулдаг бөгөөд энэ нь Docker түвшинд бүртгэл хэрхэн явагддагийг ойлгох хэрэгтэй гэсэн үг юм.
Уншигчид бүгд мэддэг байх гэж найдаж байна: програмын бүртгэлийг stdout/stderr руу бичих ёстой, харин чингэлэг дотор биш. Логуудыг Docker Daemon нэгтгэдэг бөгөөд энэ нь яг stdout/stderr руу илгээгдсэн логуудтай ажилладаг. Нэмж дурдахад, чингэлэг дотор лог бичих нь асуудалтай тулгардаг: сав өсөн нэмэгдэж буй логоос хавдсан (учир нь саванд Logrotate байхгүй байх магадлалтай), Docker Daemon энэ бүртгэлийн талаар мэдэхгүй байна.
Docker нь контейнерийн бүртгэлийг цуглуулах хэд хэдэн бүртгэлийн драйвер эсвэл залгаасуудтай. Үнэгүй Docker Community Edition (CE) нь арилжааны Docker Enterprise Edition (EE)-ээс цөөн бүртгэлийн драйвертай.
Би хэзээ ч Docker EE-г практикт ашиглаж байгаагүй: Southbridge дээр бид Нээлттэй эхийн шийдлүүдийг дагаж мөрдөхийг хичээдэг бөгөөд үйлчлүүлэгчдэд Docker EE-ийн ихэнх нэмэлт функцүүд хэрэггүй.
Docker CE дахь драйверуудыг бүртгэх:
орон нутгийн — дотоод Docker Daemon файлд бүртгэл бичих;
json файл — чингэлэг бүрийн хавтсанд json-log үүсгэх;
сэтгүүл - тэмдэглэлийг тэмдэглэлд илгээх.
Docker бүртгэлийн тохиргоонууд нь daemon.json файлд байрладаг.
"Log-driver" талбар нь залгаасыг, "лог-opts" талбар нь түүний тохиргоог заана. Дээрх жишээнд "json-file" залгаасыг зааж өгсөн, бүртгэлийн хэмжээ хязгаар нь "max-size": "10m"; файлын тоог хязгаарлах (эргэлтийн тохиргоо) - "max-file": "3"; түүнчлэн бүртгэлд хавсаргах утгууд.
Зарим бүртгэлийн драйверын тохиргоог тушаалын хэрэгслээр тохируулж болно. Хэрэв тусдаа савыг өөр бүртгэлийн драйвераар эхлүүлэх шаардлагатай бол энэ нь тохиромжтой.
Докер дээр бүртгэлийн схем иймэрхүү харагдаж байна:
Уг схем хэрхэн ажилладаг вэ: json файл гэх мэт бүртгэлийн драйвер нь файл үүсгэдэг. Бүртгэл цуглуулагчид (Rsyslog, Fluentd, Logagent болон бусад) эдгээр файлуудыг цуглуулж, Elastic, Sematext эсвэл бусад хадгалах сан руу шилжүүлдэг.
Kubernetes-д нэвтрэх онцлогууд
Кубернетес дэх хялбаршуулсан бүртгэлийн схем нь иймэрхүү харагдаж байна: нэг хонхорцог байна, дотор нь контейнер ажиллаж байна, контейнер нь бүртгэлийг stdout/stderr руу илгээдэг. Дараа нь Docker файл үүсгэж, дараа нь эргүүлэх боломжтой лог бичдэг.
Kubernetes-д бүртгэл хийх онцлогуудыг харцгаая.
Байршлуулалтын хооронд бүртгэлийг хадгалах. Энэ нь бүртгэлийг зөв тохируулах урьдчилсан нөхцөл юм. Хэрэв та байршуулалтын хооронд бүртгэлээ хадгалахгүй бол програмын шинэ хувилбар гарах үед өмнөх логууд дарж бичигдэх бөгөөд контейнерийг дахин ачаалах нь бүртгэл алдагдах эрсдэлтэй байх болно. Kubernetes-д өмнөх түлхүүр байдаг бөгөөд энэ нь хамгийн сүүлд Pod дахин ачаалах хүртэлх програмын бүртгэлийг харах боломжийг олгодог боловч илүү гүнзгий биш юм.
Бүх тохиолдлын бүртгэлийг нэгтгэх. Хэрэв бичил үйлчилгээ нь үүлэн дээр байрладаг бол үүлэн үйлчилгээ үзүүлэгч нь системийг хянах үүрэгтэй. Хэрэв микро үйлчилгээнүүд нь өөрийн техник хангамж дээр байгаа бол контейнерийн бүртгэлээс гадна системийн бүртгэлийг цуглуулах хэрэгтэй.
Өмнө нь систем болон микро үйлчилгээний аль алиных нь бүртгэлийг цуглуулах тохиромжтой хэрэгсэл байгаагүй. Ихэвчлэн нэг хэрэгсэл нь системийн бүртгэлийг (жишээ нь, Rsyslog), хоёр дахь нь Docker-ийн логуудыг (жишээ нь, journald дээр тохируулсан Docker бүртгэлийн драйвер бүхий journal-bit) цуглуулдаг. Бид log-bit-ийг контейнерээс (Docker бүртгэлийн драйвер дээр та журналд лог бичих шаардлагатайг зааж өгсөн) болон системээс (CentOS 7-д аль хэдийн systemd болон journald) цуглуулахын тулд журнал битийг ашиглахыг оролдсон. Шийдэл нь ажиллаж байгаа боловч тохиромжтой биш юм. Хэрэв олон бүртгэл байгаа бол сэтгүүл бит хоцорч, мессеж алга болно.
Туршилтууд үргэлжилсээр - өөр арга зам олдсон. CentOS 7-д системийн үндсэн бүртгэлүүд (мессеж, аудит, хамгаалалт) нь var log-д файл хэлбэрээр хуулбарлагдсан байдаг. Docker дээр та бүртгэлийг json файлд хадгалах тохиргоог хийж болно. Үүний дагуу CentOS 7 болон Docker дээрх эдгээр файлуудыг хамтад нь цуглуулж болно.
Цаг хугацаа өнгөрөхөд ELK Stack шийдэл алдартай болсон. Энэ нь хэд хэдэн хэрэгслүүдийн нэгдэл юм: Elasticsearch, Logstash, Kibana.
Elasticsearch нь савнаас логуудыг хадгалдаг, Logstash нь жишээнүүдээс логуудыг цуглуулдаг, Кибана нь хүлээн авсан логуудыг боловсруулж, тэдгээрт үндэслэн график үүсгэх боломжийг олгодог. ELK Stack нь идэвхтэй ашиглагдаж байгаа хэдий ч миний бодлоор цаг хугацаа өнгөрч байна. Яагаад гэдгийг нь дараа хэлье.
Мета өгөгдөл нэмэх. Pod, програм, контейнерийг хаана ч ажиллуулж болно. Түүнчлэн, нэг програм хэд хэдэн тохиолдолтой байж болно. Бүртгэлүүд нь ижил форматаар бичигдсэн боловч энэ нь ямар хуулбар, аль Pod үүнийг бичдэг, ямар нэрийн талбарт байрлаж байгааг ойлгох хэрэгтэй. Ийм учраас логууд мета өгөгдөл нэмэх шаардлагатай болдог.
Бүртгэлийг задлан шинжлэх. Энэ нь инээдтэй боловч мод бэлтгэх, хянах системийг хадгалах зардал нь үндсэн хэрэглээний зардлаас давж болно. Секундэд хэдэн арван, хэдэн зуун мянган гуалин нисдэг бол энэ нь байгалийн юм шиг санагддаг, гэхдээ та шугамыг мэдэх шаардлагатай хэвээр байна. Энэ мөрийг олох нэг арга бол логуудыг задлан шинжлэх явдал юм.
Дүрмээр бол бүх бүртгэлийг цуглуулах, хадгалах шаардлагагүй, зөвхөн нэг хэсгийг нь хадгалахад илгээх ёстой - жишээлбэл, "анхаарал" эсвэл "алдаа" статустай бүртгэлүүд. Хэрэв бид nginx эсвэл оролт хянагчийн бүртгэлийн тухай ярьж байгаа бол та зөвхөн статус нь 200-аас өөр байгаа хүмүүсийг хадгалахад илгээж болно. Гэхдээ энэ нь бүх нийтийн зөвлөгөө биш юм: хэрэв та ямар нэгэн байдлаар Nginx лог дээр аналитик хийвэл тэдгээрийг цуглуулах нь мэдээжийн хэрэг.
Шүүгдсэн өгөгдөл нь ердийн аналитик хийхэд хангалтгүй байж болох тул бүртгэлийг бодолгүйгээр шүүхийг зөвлөдөггүй. Нөгөөтэйгүүр, аналитикийг бүртгэлийн түвшинд биш, хэмжүүр цуглуулах түвшинд хийх ёстой. Дараа нь та 200 кодтой хэдэн зуун мянган мөрийг хадгалах шаардлагагүй болно. Нэг арга нь нэвтрэлтийн хянагч хэмжигдэхүүнээс урсгал болон алдааны талаарх мэдээллийг авах явдал юм.
Ерөнхийдөө энд та сайтар бодох хэрэгтэй: та юу хадгалахыг хүсч байна, хэр удаан хадгалахыг хүсч байна, эс тэгвээс мод бэлтгэх систем нь үндсэн төслөөс илүү их нөөцийг авах нөхцөл байдал үүснэ.
Мод бэлтгэх стандарт шийдэл хараахан гараагүй байна. Хамгийн түгээмэл Prometheus шийдэл байдаг мониторингээс ялгаатай нь мод бэлтгэх стандарт байдаггүй.
Энэ лекцээр бид хоёр хэрэгслийг авч үзэх болно: нэг нь түгээмэл, хоёр дахь нь алдартай болж байна. Тэднээс гадна бусад хүмүүс байдаг, гэхдээ бид энэ нийтлэлд тэдгээрийг хөндөхгүй.
Дээр дурдсан бүх онцлогуудыг харгалзан Kubernetes-д нэвтрэхийг дараах диаграммд дүрсэлж болно.
Контейнерын бүртгэл ба эргэлт хэвээр байгаа боловч цуглуулгын агент гарч ирэх бөгөөд энэ нь бүртгэлийг сонгож, хадгалахад илгээдэг (диаграммд - Бүртгэлийн арын хэсэгт). Агент нь зангилаа бүр дээр ажилладаг бөгөөд ихэвчлэн Kubernetes дээр ажилладаг.
Одоо мод бэлтгэх хэрэгслүүдийг харцгаая.
Графана Локи
саяхан гарч ирсэн боловч аль хэдийн нэлээд алдартай болсон. Үүний давуу тал: суулгахад хялбар, нөөц бага зарцуулдаг, TSDB (цаг хугацааны цуврал мэдээллийн сан) -д өгөгдлийг хадгалдаг тул Elasticsearch суулгах шаардлагагүй. Өмнөх нийтлэлдээ би Prometheus ийм мэдээллийн санд өгөгдөл хадгалдаг гэж бичсэн бөгөөд энэ нь хоёр бүтээгдэхүүний ижил төстэй олон зүйлийн нэг юм. Хөгжүүлэгчид Локи бол "Мод бэлтгэх ертөнцөд зориулсан Прометей" гэж хүртэл мэдэгддэг.
Уншиж амжаагүй хүмүүст зориулсан ХХБ-ны тухай товч мэдээлэл : TSDB нь их хэмжээний хугацааны цуврал өгөгдлийг хадгалахад маш сайн боловч урт хугацааны хадгалалтад зориулагдаагүй. Хэрэв ямар нэг шалтгааны улмаас бүртгэлийг хоёр долоо хоногоос дээш хугацаагаар хадгалах шаардлагатай бол тэдгээрийг өөр мэдээллийн сан руу шилжүүлэхийг тохируулах нь дээр.
Loki-ийн бас нэг давуу тал бол Grafana-г өгөгдлийг дүрслэн харуулахад ашигладаг. Энэ нь маш тохиромжтой: Графана дээр бид хяналтын өгөгдлийг хардаг бөгөөд тэнд Loki-г холбож, бүртгэлүүдийг хардаг. Та лог ашиглан график үүсгэж болно.
Локи архитектур нь иймэрхүү харагдаж байна.
DaemonSet-ийг ашиглан, агент-Promtail эсвэл Fluent Bit-ийг кластерын бүх сервер дээр байрлуулна. Агент бүртгэл цуглуулдаг. Локи тэднийг аваад TSDB-дээ хадгалдаг. Мета өгөгдлийг бүртгэлд нэн даруй нэмдэг бөгөөд энэ нь тохиромжтой: та Pod, нэрийн орон зай, контейнерийн нэр, тэр ч байтугай шошгоор шүүж болно.
Loki нь танил Grafana интерфейс дээр ажилладаг. Локи нь өөрийн хүсэлтийн хэлтэй бөгөөд үүнийг LogQL гэж нэрлэдэг - нэр, синтаксээрээ Prometheus дахь PromQL-тэй төстэй. Локигийн интерфэйс нь асуулга бүхий сануулгатай тул та тэдгээрийг цээжээр мэдэх шаардлагагүй.
Grafana интерфейс дэх Loki
Шүүлтүүрийг ашигласнаар та Loki ("400", "404" болон бусад) кодуудыг олох боломжтой; бүх зангилааны бүртгэлийг харах; "алдаа" гэсэн үг агуулсан бүх бүртгэлийг шүүнэ. Хэрэв та бүртгэл дээр дарвал үйл явдлын талаархи бүх мэдээллийг агуулсан карт нээгдэнэ.
Локи нь шаардлагатай логуудыг гаргаж авах хангалттай хэрэгсэлтэй боловч үнэнийг хэлэхэд техникийн хувьд илүү олон байж болно. Одоо Локи идэвхтэй хөгжиж, алдартай болж байна.
Уян + Fluent Bit + Кибана (EFK Stack)
EFK стек нь илүү сонгодог, гэхдээ тийм ч алдартай мод бэлтгэх хэрэгсэл юм.
Өгүүллийн эхэнд ELK (Elasticsearch + Logstash + Kibana) гэж дурьдсан боловч энэ стек нь тийм ч бүтээмжгүй, нэгэн зэрэг нөөц их шаарддаг Logstash учраас хуучирсан байна. Үүний оронд тэд илүү хөнгөн, бүтээмжтэй Fluentd ашиглаж эхэлсэн бөгөөд хэсэг хугацааны дараа түүнд туслахаар болжээ. - илүү хөнгөн, бүр илүү бүтээмжтэй цуглуулагч бодис.
Хөгжүүлэгчдийн үзэж байгаагаар Fluent Bit нь гүйцэтгэлийн хувьд Fluentd-ээс 100 дахин илүү байдаг: "Fluentd 20 MB RAM ашигладаг бол Fluent Bit нь 150 KB зарцуулна" - баримт бичгийн шууд ишлэл. Үүнийг харахад Fluent Bit-ийг илүү олон удаа ашиглаж эхэлсэн.
Fluent Bit нь Fluentd-ээс цөөн онцлогтой боловч үндсэн хэрэгцээг хангадаг тул бид ихэвчлэн Fluent Bit ашигладаг.
EFK стекийн ажиллах схем: агент нь бүх pods-аас лог цуглуулдаг (дүрмээр бол энэ нь кластерын бүх сервер дээр ажилладаг DaemonSet юм) хадгалах сан руу илгээдэг (Elasticsearch, PostgreSQL эсвэл Kafka). Кибана нь хадгалах сан руу холбогдож шаардлагатай бүх мэдээллийг тэндээс авдаг.
тохиромжтой вэб интерфэйсээр мэдээллийг танилцуулдаг. График, шүүлтүүр болон бусад олон зүйл байдаг.
Та лог ашиглан хяналтын самбарыг бүхэлд нь үүсгэж болно.
Fluent Bit-ийн онцлогууд
Fluent Bit-ийн талаар ерөнхийдөө Logstash-аас бага сонсдог тул үүнийг илүү нарийвчлан авч үзье. Fluent Bit-ийг логикийн хувьд 6 модульд хувааж болно.
Оролтын модуль файлууд, системийн үйлчилгээнүүд, тэр ч байтугай tcp-сокетаас бүртгэл цуглуулдаг (та төгсгөлийн цэгийг зааж өгөхөд л Fluent Bit тэнд очиж эхэлнэ). Эдгээр чадварууд нь систем болон савнаас лог цуглуулахад хангалттай.
Үйлдвэрлэлд бид ихэвчлэн залгаасуудыг ашигладаг (үүнийг бүртгэлтэй хавтастай харьцуулж болно) болон (та түүнд ямар үйлчилгээнээс бүртгэл цуглуулахыг хэлж болно).
Шинжилгээний модуль логуудыг ерөнхий хэлбэрт оруулдаг. Анхдагч байдлаар, Nginx бүртгэл нь мөр юм. Plugin ашиглан энэ мөрийг JSON болгон хөрвүүлж болно: талбарууд болон тэдгээрийн утгыг тохируулна уу. Илүү уян хатан эрэмбэлэх сонголтууд байдаг тул JSON нь стринг логтой харьцуулахад илүү хялбар байдаг.
Шүүлтүүрийн модуль. Энэ түвшинд шаардлагагүй логуудыг шүүдэг. Жишээлбэл, зөвхөн "анхааруулах" утгатай эсвэл тодорхой шошготой бүртгэлийг хадгалахад илгээдэг. Сонгосон бүртгэлүүд буферт ордог.
Буфер модуль. Fluent Bit нь санах ойн буфер ба дискний буфер гэсэн хоёр төрлийн буфертэй. Буфер нь алдаа, доголдол гарсан тохиолдолд шаардлагатай бүртгэлийн түр зуурын хадгалалт юм. Хүн бүр RAM дээр хэмнэлт хийхийг хүсдэг тул ихэвчлэн дискний буферийг сонгодог. Гэхдээ та диск рүү орохын өмнө бүртгэлүүд санах ойд татагдсан хэвээр байгааг анхаарч үзэх хэрэгтэй.
Чиглүүлэлт/Гаралтын модуль лог илгээх дүрэм, хаягуудыг агуулсан. Өмнө дурьдсанчлан бүртгэлийг Elasticsearch, PostgreSQL эсвэл жишээ нь Кафка руу илгээж болно.
Сонирхолтой нь, Fluent Bit-ийн бүртгэлийг Fluentd руу илгээж болно. Эхнийх нь илүү хөнгөн, бага ажиллагаатай тул түүгээр дамжуулан та лог цуглуулж, Fluentd руу илгээх боломжтой бөгөөд нэмэлт залгаасуудын тусламжтайгаар тэдгээрийг цаашид боловсруулж, хадгалах газар руу илгээх боломжтой.
Хэрэв та Elasticsearch ашиглахаар төлөвлөж байгаа бол...
Эцэст нь, Elasticsearch-ийг үйлдвэрлэлд бүртгэлийн хадгалах газар болгон ашиглахаар төлөвлөж буй хүмүүст зориулсан хоёр зөвлөгөө.
- ашиглан анхааруулга тохируулна уу . Энэ програм нь бүртгэлийн ерөнхий урсгалаас чухал мессежүүдийг тусгаарлаж, шуудангаар эсвэл өөр суваг руу дохио өгдөг. Энэ нь тун удалгүй гарч ирсэн нь үнэн .
- Програмыг ашиглан логуудыг эргүүлнэ үү эсвэл Elasticsearch API руу залгана. Elastic өөрөө зарчмын хувьд гуравдагч этгээдийн хэрэгслийг ашиглахгүйгээр индексийн ашиглалтын хугацааг удирдах чухал алхамуудыг хийж байна. Ерөнхийдөө логыг удаан хугацаагаар хадгалах нь утгагүй юм: хоёр долоо хоногийн дараа ямар ч бүртгэл шаардагдахгүй - хэрэв энэ нь үнэхээр чухал бол хоёр долоо хоногийн дотор боловсруулагдах нь гарцаагүй. Хамгийн сүүлчийн арга бол хуучин логуудыг архивлаж, удаан хугацаагаар хадгалахын тулд хаа нэгтээ илгээж болно. Хуулиар 5 жил хүртэл хадгалагдах ёстой тусгай гуалинуудын талаар сонссон. Би хувьдаа ийм зүйлтэй тулгараагүй, гэхдээ би ийм мэдээллийг энгийн логуудтай адилтгахгүй, бүр тусад нь хадгалсан байх.
Үргэлжлэл бий…
Зохиогч: Марсель Ибраев, Kubernetes-ийн итгэмжлэгдсэн администратор, тус компанийн дадлагажигч инженер , илтгэгч, курс хөгжүүлэгч .
Эх сурвалж: www.habr.com
