Pemantauan telah menjadi komponen yang sangat penting dalam mengembangkan solusi cloud seiring dengan meningkatnya kompleksitas sistem terdistribusi. Penting untuk memahami perilaku mereka. Kami memerlukan alat skalabel yang dapat mengumpulkan data dari semua layanan - dan menyediakan antarmuka tunggal kepada spesialis dengan analisis kinerja, demonstrasi kesalahan, ketersediaan, dan log.
Alat-alat yang sama harus efisien dan produktif. Pada artikel ini, kita akan melihat dua tumpukan teknologi populer: EFK (Elasticsearch) dan PLG (Loki) serta memeriksa arsitektur dan perbedaannya.
tumpukan EFK
Anda mungkin pernah mendengar tentang ELK atau EFK yang sangat populer. Tumpukan terdiri dari beberapa bagian berbeda: Elasticsearch (penyimpanan objek), Logstash atau FluentD (pengumpulan dan agregasi log), dan Kibana untuk visualisasi.
Alur kerja umumnya terlihat seperti ini:
Elasticsearch β penyimpanan objek terdistribusi dengan pencarian dan analisis waktu nyata. Solusi luar biasa untuk data semi-terstruktur seperti log. Informasi disimpan sebagai dokumen JSON, diindeks secara real-time dan didistribusikan ke seluruh node cluster. Indeks terbalik digunakan, berisi semua kata unik dan dokumen terkait untuk pencarian teks lengkap, yang didasarkan pada mesin pencari Apache Lucene.
LancarD adalah pengumpul data yang menyatukan data saat mengumpulkan dan menggunakannya. Ia mencoba mengatur data dalam JSON sebanyak mungkin. Arsitekturnya dapat diperluas, masih banyak lagi , didukung komunitas, untuk semua kesempatan.
Kibana - alat visualisasi data untuk Elasticsearch dengan berbagai kemampuan tambahan, misalnya analisis deret waktu, analisis grafik, pembelajaran mesin, dan lainnya.
Arsitektur pencarian elastis
Data cluster Elasticsearch disimpan tersebar di seluruh node-nya. Sebuah cluster terdiri dari beberapa node untuk meningkatkan ketersediaan dan ketahanan. Node mana pun dapat melakukan semua peran klaster, namun dalam penerapan skala besar, node biasanya diberi tugas individual.
Jenis simpul cluster:
- node utama - mengelola cluster, setidaknya diperlukan tiga, satu selalu aktif;
- simpul data - menyimpan data yang diindeks dan melakukan berbagai tugas dengannya;
- node penyerapan - mengatur saluran untuk mengubah data sebelum pengindeksan;
- mengoordinasikan node - merutekan permintaan, mengurangi fase pemrosesan pencarian, mengoordinasikan pengindeksan massal;
- node peringatan β meluncurkan tugas peringatan;
- simpul pembelajaran mesin - memproses tugas pembelajaran mesin.
Diagram di bawah menunjukkan bagaimana data disimpan dan direplikasi di seluruh node untuk mencapai ketersediaan data yang lebih tinggi.
Data setiap replika disimpan dalam indeks terbalik, diagram di bawah menunjukkan bagaimana hal ini terjadi:
Instalasi
Detailnya dapat dilihat , saya akan menggunakan diagram helm:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticstumpukan PLG
Jangan heran jika Anda tidak dapat menemukan akronim ini, karena lebih dikenal dengan sebutan Grafana Loki. Bagaimanapun, tumpukan ini mendapatkan popularitas karena menggunakan solusi teknis yang telah terbukti. Anda mungkin pernah mendengar tentang Grafana, alat visualisasi yang populer. Penciptanya, terinspirasi oleh Prometheus, mengembangkan Loki, sistem agregasi log berkinerja tinggi yang dapat diskalakan secara horizontal. Loki hanya mengindeks metadata, bukan jurnal itu sendiri, sebuah solusi teknis yang membuatnya mudah digunakan dan hemat biaya.
Promtail - agen untuk mengirimkan log dari sistem operasi ke cluster Loki. grafana adalah alat visualisasi berdasarkan data dari Loki.
Loki dibangun dengan prinsip yang sama seperti Prometheus, sehingga cocok untuk menyimpan dan menganalisis log Kubernetes.
Arsitektur Loki
Loki dapat dijalankan sebagai satu proses atau beberapa proses, memungkinkan penskalaan horizontal.
Ini juga dapat berfungsi sebagai aplikasi monolitik atau sebagai layanan mikro. Berjalan sebagai satu proses dapat berguna untuk pembangunan lokal atau untuk pemantauan kecil. Untuk implementasi industri dan beban kerja yang terukur, disarankan untuk menggunakan opsi layanan mikro. Jalur untuk menulis dan membaca data dipisahkan, sehingga dapat disesuaikan dan diskalakan sesuai kebutuhan.
Mari kita lihat arsitektur sistem pengumpulan log tanpa menjelaskan secara detail:
Dan berikut deskripsinya (arsitektur microservice):
Komponen:
Promtail β agen yang diinstal pada node (sebagai serangkaian layanan), ia menghapus log dari tugas dan mengakses API Kubernetes untuk mendapatkan metadata yang akan menandai log tersebut. Kemudian mengirimkan log ke layanan utama Loki. Pemetaan metadata mendukung aturan pemberian tag yang sama seperti Prometheus.
Distributor β distributor jasa yang berfungsi sebagai penyangga. Untuk memproses jutaan catatan, ia mengemas data yang masuk, mengompresinya dalam blok-blok saat data tersebut tiba. Beberapa data sink berjalan secara bersamaan, namun log milik satu aliran data masuk hanya akan muncul di salah satu data sink untuk semua bloknya. Ini disusun menjadi sebuah cincin sink dan hashing berurutan. Untuk toleransi kesalahan dan redundansi, ini dilakukan sebanyak n kali (3 kali jika tidak dikonfigurasi).
menelan β penerima layanan. Blok data tiba dalam bentuk terkompresi dengan log yang ditambahkan. Setelah blok berukuran cukup, blok tersebut dipindahkan ke database. Metadata masuk ke indeks, dan data dari blok log masuk ke Potongan (biasanya penyimpanan objek). Setelah reset, penerima membuat blok baru dimana entri baru akan ditambahkan.
Indeks - basis data, DynamoDB, Cassandra, Google BigTable, dll.
Bongkahan β blok log dalam bentuk terkompresi, biasanya disimpan di penyimpanan objek, misalnya S3.
pertanyaan - jalur membaca yang melakukan semua pekerjaan kotor. Ini melihat rentang waktu dan stempel waktu, lalu melihat indeks untuk menemukan kecocokan. Selanjutnya, ia membaca blok data dan memfilternya untuk mendapatkan hasilnya.
Sekarang mari kita lihat semuanya beraksi.
Instalasi
Cara termudah untuk menginstal di Kubernetes adalah dengan menggunakan helm. Kami berasumsi bahwa Anda telah menginstal dan mengkonfigurasinya ( kira-kira Penerjemah)
Tambahkan repositori dan instal tumpukan.
$ 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=falseDi bawah ini adalah contoh dasbor yang menampilkan data dari metrik Prometheus for Etcd dan log pod Loki for Etcd.
Sekarang mari kita bahas arsitektur kedua sistem, dan juga bandingkan kemampuannya satu sama lain.
Π‘ΡΠ°Π²Π½Π΅Π½ΠΈΠ΅
Bahasa kueri
Elasticsearch menggunakan Query DSL dan bahasa kueri Lucene untuk menyediakan kemampuan pencarian teks lengkap. Ini adalah mesin pencari yang mapan dan kuat dengan dukungan operator yang luas. Dengan itu, Anda dapat mencari berdasarkan konteks dan mengurutkan berdasarkan relevansi.
Di sisi lain adalah LogQL, yang digunakan di Loki, penerus PromQL (bahasa kueri Prometheus). Ia menggunakan tag log untuk memfilter dan memilih data log. Dimungkinkan untuk menggunakan beberapa operator dan aritmatika seperti yang dijelaskan , tetapi dalam hal kemampuannya tertinggal dari bahasa Elastic.
Karena kueri di Loki dikaitkan dengan tag, kueri tersebut mudah dikorelasikan dengan metrik, dan sebagai hasilnya, kueri tersebut lebih mudah untuk mengatur pemantauan operasional.
Skalabilitas
Kedua tumpukan tersebut dapat diskalakan secara horizontal, tetapi Loki membuatnya lebih mudah karena memiliki jalur baca dan tulis terpisah serta arsitektur layanan mikro. Loki dapat disesuaikan dengan kebutuhan Anda dan dapat digunakan untuk data log dalam jumlah yang sangat besar.
Multitenansi
Multitenancy cluster adalah tema umum dalam singkatan OPEX, kedua tumpukan menyediakan multitenancy. Ada beberapa untuk Elasticsearch pemisahan klien: indeks terpisah untuk setiap klien, perutean berbasis klien, bidang klien unik, filter pencarian. Loki punya dalam bentuk header HTTP X-Scope-OrgID.
Biaya
Loki cukup hemat biaya karena tidak mengindeks data, hanya metadata. Ini tercapai dan memori (cache), karena penyimpanan objek lebih murah daripada penyimpanan blok, yang digunakan dalam cluster Elasticsearch.
Kesimpulan
Tumpukan EFK dapat digunakan untuk berbagai tujuan, memberikan fleksibilitas maksimum dan antarmuka Kibana yang kaya fitur untuk analitik, visualisasi, dan kueri. Hal ini dapat lebih ditingkatkan dengan kemampuan pembelajaran mesin.
Tumpukan Loki berguna di ekosistem Kubernetes karena mekanisme penemuan metadatanya. Anda dapat dengan mudah mengkorelasikan data untuk pemantauan berdasarkan rangkaian waktu di Grafana dan log.
Dalam hal biaya dan penyimpanan log jangka panjang, Loki adalah titik masuk yang sangat baik ke dalam solusi cloud.
Ada lebih banyak alternatif di pasaran β beberapa mungkin lebih baik untuk Anda. Misalnya, GKE memiliki integrasi Stackdriver yang memberikan solusi pemantauan yang sangat baik. Kami tidak memasukkannya ke dalam analisis kami di artikel ini.
Π‘ΡΡΠ»ΠΊΠΈ:
Artikel tersebut diterjemahkan dan disiapkan untuk Habr oleh para karyawan β kursus intensif, kursus video, dan pelatihan perusahaan dari spesialis praktik (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Sumber: www.habr.com