Түгээмэл системийн нарийн төвөгтэй байдал нэмэгдэхийн хэрээр хяналт нь өсөн нэмэгдэж буй үүлэн шийдлүүдийн маш чухал бүрэлдэхүүн хэсэг болсон. Тэдний зан байдлыг ойлгох хэрэгтэй. Бидэнд бүх үйлчилгээнүүдээс мэдээлэл цуглуулах боломжтой өргөтгөх боломжтой хэрэгслүүд хэрэгтэй бөгөөд мэргэжилтнүүдийг гүйцэтгэлийн дүн шинжилгээ, алдааны үзүүлэн, хүртээмж, бүртгэл бүхий нэг интерфейсээр хангадаг.
Эдгээр ижил хэрэгслүүд нь үр дүнтэй, бүтээмжтэй байх ёстой. Энэ нийтлэлд бид EFK (Elasticsearch) ба PLG (Loki) гэсэн хоёр алдартай технологийн стекийг авч үзэх бөгөөд тэдгээрийн архитектур, ялгааг судлах болно.
EFK стек
Та маш алдартай ELK эсвэл EFK-ийн талаар аль хэдийн сонссон байх. Стек нь хэд хэдэн ялгаатай хэсгүүдээс бүрдэнэ: Elasticsearch (объект хадгалах), Logstash эсвэл FluentD (лог цуглуулах ба нэгтгэх), дүрслэх зориулалттай Кибана.
Ердийн ажлын урсгал дараах байдалтай байна.
Elasticsearch — хайлт болон бодит цагийн аналитик бүхий хуваарилагдсан объектын хадгалалт. Лог зэрэг хагас бүтэцтэй өгөгдөлд зориулсан маш сайн шийдэл. Мэдээллийг JSON баримт хэлбэрээр хадгалж, бодит цаг хугацаанд индексжүүлж, кластерийн зангилаанд тараадаг. Бүрэн текст хайхад бүх өвөрмөц үгс болон холбогдох баримт бичгүүдийг агуулсан урвуу индексийг ашигладаг бөгөөд энэ нь эргээд Apache Lucene хайлтын систем дээр суурилдаг.
Чадварлаг D Мэдээллийг цуглуулах, хэрэглэх үед өгөгдлийг нэгтгэдэг өгөгдөл цуглуулагч юм. Энэ нь аль болох JSON дахь өгөгдлийг зохион байгуулахыг хичээдэг. Түүний архитектур нь өргөтгөх боломжтой, илүү олон зүйл бий , олон нийтийн дэмжлэгтэй, бүх тохиолдолд.
Кибана - Elasticsearch-д зориулсан өгөгдлийн дүрслэх хэрэгсэл, тухайлбал, цагийн цувааны дүн шинжилгээ, графикийн шинжилгээ, машин суралцах гэх мэт янз бүрийн нэмэлт боломжуудтай.
Elasticsearch архитектур
Elasticsearch кластерын өгөгдөл нь түүний бүх зангилаанд тархсан хадгалагддаг. Кластер нь хүртээмж, уян хатан байдлыг сайжруулах олон зангилаанаас бүрддэг. Аливаа зангилаа нь кластерын бүх үүргийг гүйцэтгэх боломжтой боловч том хэмжээний байршилд зангилаанууд нь ихэвчлэн бие даасан даалгавруудыг хуваарилдаг.
Кластер зангилааны төрлүүд:
- мастер зангилаа - кластерыг удирддаг, дор хаяж гурвыг нь шаарддаг, нэг нь үргэлж идэвхтэй байдаг;
- өгөгдлийн зангилаа - индексжүүлсэн өгөгдлийг хадгалж, түүнтэй хамт янз бүрийн ажлыг гүйцэтгэдэг;
- ingest node - индексжүүлэхээс өмнө өгөгдлийг хувиргах дамжуулах хоолойг зохион байгуулдаг;
- зангилаа зохицуулах - хүсэлтийг чиглүүлэх, хайлтын боловсруулалтын үе шатыг багасгах, массын индексжүүлэлтийг зохицуулах;
- дохиоллын зангилаа — дохиоллын ажлыг эхлүүлэх;
- машин сургалтын зангилаа - машин сургалтын даалгавруудыг боловсруулах.
Доорх диаграмм нь өгөгдлийн хүртээмжийг нэмэгдүүлэхийн тулд зангилаанууд даяар өгөгдлийг хэрхэн хадгалж, хуулбарлаж байгааг харуулж байна.
Хуулбарын өгөгдөл бүрийг урвуу индекст хадгалдаг бөгөөд энэ нь хэрхэн тохиолддогийг доорх диаграммд харуулав.
тохиргоо
Дэлгэрэнгүйг үзэх боломжтой , Би жолооны график ашиглана:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG стек
Графана Локи гэгддэг энэ товчлолыг олж чадахгүй бол бүү гайхаарай. Ямар ч тохиолдолд энэ стек нь батлагдсан техникийн шийдлүүдийг ашигладаг тул түгээмэл болж байна. Алдартай дүрслэх хэрэгсэл болох Grafana-ийн талаар та аль хэдийн сонссон байх. Үүнийг бүтээгчид Прометейгээс санаа авч, хэвтээ байдлаар өргөтгөх боломжтой, өндөр хүчин чадалтай лог нэгтгэх систем болох Loki-г бүтээжээ. Локи нь сэтгүүлийг бус зөвхөн мета өгөгдлийг индексжүүлдэг бөгөөд үүнийг ашиглахад хялбар, хэмнэлттэй байх боломжийг олгодог техникийн шийдэл юм.
Promtail - үйлдлийн системээс Локи кластер руу лог илгээх агент. Графана нь Loki-ийн өгөгдөл дээр үндэслэсэн дүрслэх хэрэгсэл юм.
Локи нь Prometheus-тай ижил зарчмаар бүтээгдсэн тул Kubernetes логуудыг хадгалах, шинжлэхэд тохиромжтой.
Локи архитектур
Loki-г нэг процесс хэлбэрээр эсвэл олон процесс хэлбэрээр ажиллуулж, хэвтээ масштабтай болгох боломжтой.
Энэ нь цул програм эсвэл микро үйлчилгээ хэлбэрээр ажиллах боломжтой. Нэг процесс болгон ажиллуулах нь орон нутгийн хөгжилд эсвэл бага зэргийн мониторинг хийхэд тустай байж болно. Аж үйлдвэрийн хэрэглээ болон өргөтгөх боломжтой ажлын ачааллын хувьд микро үйлчилгээний сонголтыг ашиглахыг зөвлөж байна. Өгөгдлийг бичих, унших замууд нь тусдаа байдаг тул шаардлагатай бол нарийн тааруулж, масштабтай болгож болно.
Бүртгэл цуглуулах системийн архитектурыг нарийвчлан авч үзэхгүйгээр харцгаая.
Энд тайлбар байна (микросервис архитектур):
Бүрэлдэхүүн хэсгүүд:
Promtail — зангилаанууд дээр суулгасан агент (үйлчилгээний багц хэлбэрээр), энэ нь даалгавраас бүртгэлийг устгаж, логуудыг шошголох мета өгөгдлийг авахын тулд Kubernetes API-д ханддаг. Дараа нь бүртгэлийг үндсэн Loki үйлчилгээ рүү илгээдэг. Мета өгөгдлийн зураглал нь Prometheus-тай ижил шошгоны дүрмийг дэмждэг.
Дистрибьюторын — буферийн үүрэг гүйцэтгэдэг үйлчилгээний дистрибьютер. Сая сая бичлэгийг боловсруулахын тулд ирж буй өгөгдлийг багцалж, ирэхэд нь блок болгон шахдаг. Хэд хэдэн өгөгдөл шингээгч нэгэн зэрэг ажиллаж байгаа боловч нэг ирж буй өгөгдлийн урсгалд хамаарах лог нь зөвхөн тэдгээрийн аль нэгэнд нь түүний бүх блокт харагдах ёстой. Энэ нь угаалтуур болон дараалсан хэш хийх цагираг хэлбэрээр зохион байгуулагдсан. Гэмтлийг тэсвэрлэх чадвар, илүүдэлтэй байхын тулд үүнийг n удаа хийнэ (хэрэв тохируулаагүй бол 3).
Залгигч - үйлчилгээний хүлээн авагч. Өгөгдлийн блокууд нь лог нэмсэнээр шахагдаж ирдэг. Блок хангалттай хэмжээтэй болмогц блок нь мэдээллийн санд шилждэг. Мета өгөгдөл нь индекс рүү, бүртгэлийн блокийн өгөгдөл нь Chunks (ихэвчлэн объект хадгалах) руу очдог. Дахин тохируулсны дараа хүлээн авагч нь шинэ оруулгууд нэмэгдэх шинэ блок үүсгэдэг.
индекс - мэдээллийн сан, DynamoDB, Кассандра, Google BigTable гэх мэт.
Бяцхан гишүүд - шахсан хэлбэрийн бүртгэлийн блокууд, ихэвчлэн объектын хадгалалтад хадгалагддаг, жишээлбэл, S3.
Асуултчин - бүх бохир ажлыг хийдэг унших зам. Энэ нь цагийн хүрээ болон цагийн тэмдэгийг хардаг бөгөөд дараа нь тохирохыг олохын тулд индексийг хардаг. Дараа нь энэ нь өгөгдлийн блокуудыг уншиж, үр дүнг авахын тулд шүүдэг.
Одоо бүх зүйлийг ажил хэрэг болгон харцгаая.
тохиргоо
Kubernetes-д суулгах хамгийн хялбар арга бол жолоо ашиглах явдал юм. Таныг аль хэдийн суулгаж тохируулсан гэж бид үзэж байна ( ойролцоогоор. орчуулагч)
Репозитор нэмж, стек суулгана уу.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falsePrometheus for Etcd хэмжигдэхүүн болон Loki for Etcd pod логуудын өгөгдлийг харуулсан жишээ самбарыг доор харуулав.
Одоо хоёр системийн архитектурын талаар ярилцаж, тэдгээрийн чадавхийг бие биетэйгээ харьцуулцгаая.
Харьцуулалт
Асуулгын хэл
Elasticsearch нь Query DSL болон Lucene асуулгын хэлийг ашиглан бүрэн текст хайх боломжийг олгодог. Энэ нь операторын өргөн дэмжлэгтэй, хүчирхэг хайлтын систем юм. Үүний тусламжтайгаар та контекстээр хайж, хамаарлаар нь эрэмбэлэх боломжтой.
Бөгжний нөгөө талд PromQL (Prometheus query хэл) -ийн залгамжлагч Локи-д хэрэглэгддэг LogQL байдаг. Энэ нь бүртгэлийн өгөгдлийг шүүж, сонгохын тулд лог хаягуудыг ашигладаг. Тодорхойлогдсоны дагуу зарим оператор болон арифметик ашиглах боломжтой , гэхдээ чадварын хувьд уян хатан хэлнээс хоцорч байна.
Локи дахь асуулга нь шошготой холбоотой байдаг тул хэмжигдэхүүнтэй уялдуулахад хялбар бөгөөд үүний үр дүнд үйл ажиллагааны хяналтыг зохион байгуулахад хялбар байдаг.
Өргөтгөх чадвар
Хоёр стек нь хэвтээ байдлаар өргөтгөх боломжтой боловч Loki нь тусдаа унших, бичих зам, микро үйлчилгээний архитектуртай тул үүнийг илүү хялбар болгодог. Loki-г таны хэрэгцээнд тохируулан өөрчилж болох бөгөөд маш их хэмжээний бүртгэлийн өгөгдөлд ашиглаж болно.
Олон түрээслэх
Cluster multitenancy нь OPEX товчлолын нийтлэг сэдэв бөгөөд хоёр стек нь олон түрээслэлтийг хангадаг. Elasticsearch-д зориулсан хэд хэдэн зүйл байдаг үйлчлүүлэгчийг салгах: үйлчлүүлэгч бүрийн хувьд тусдаа индекс, үйлчлүүлэгчид суурилсан чиглүүлэлт, үйлчлүүлэгчийн өвөрмөц талбарууд, хайлтын шүүлтүүрүүд. Локи байна HTTP X-Scope-OrgID толгой хэлбэрээр.
зардал
Локи нь өгөгдлийг индексжүүлдэггүй, зөвхөн мета өгөгдлийг индексжүүлдэг тул зардал багатай байдаг. Үүнд хүрдэг болон санах ой (кэш), учир нь объектын хадгалалт нь Elasticsearch кластерт ашиглагддаг блок хадгалахаас хямд байдаг.
дүгнэлт
EFK стекийг янз бүрийн зорилгоор ашиглах боломжтой бөгөөд хамгийн их уян хатан байдал, аналитик, дүрслэл, асуулгад зориулж баялаг Кибана интерфейсээр хангадаг. Үүнийг машин сурах чадвараар улам сайжруулах боломжтой.
Локи стек нь мета өгөгдлийг илрүүлэх механизмтай учир Kubernetes экосистемд хэрэгтэй. Та Grafana болон лог дээрх хугацааны цуваа дээр үндэслэн мониторинг хийх өгөгдлийг хялбархан холбож болно.
Зардал, урт хугацааны бүртгэлийн хадгалалтын тухайд Локи бол үүлэн шийдэлд нэвтрэх маш сайн цэг юм.
Зах зээл дээр илүү олон хувилбарууд байдаг - зарим нь танд илүү дээр байж магадгүй юм. Жишээлбэл, GKE нь хяналтын маш сайн шийдлийг өгдөг Stackdriver интеграцчилалтай. Бид энэ нийтлэлд дүн шинжилгээ хийхдээ тэдгээрийг оруулаагүй болно.
Ашигласан материал:
Уг нийтлэлийг ажилчид орчуулан Хабр сэтгүүлд зориулан бэлтгэсэн - дадлагажигч мэргэжилтнүүдийн эрчимжүүлсэн сургалт, видео курс, корпорацийн сургалт (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Эх сурвалж: www.habr.com