Masuk dalam aplikasi php yang didistribusikan

Artikel ini akan membahas manfaat penebangan. Saya akan menceritakan tentang log di PSR. Saya akan menambahkan beberapa rekomendasi pribadi untuk bekerja dengan level, pesan, dan konteks acara yang dicatat. Contoh akan diberikan tentang bagaimana mengatur logging dan pemantauan menggunakan ELK dalam aplikasi yang ditulis dalam Laravel dan diluncurkan melalui Docker pada beberapa contoh. Saya akan menandatangani aturan penting dari sistem peringatan. Saya akan memberikan contoh skrip yang meningkatkan seluruh tumpukan pemantauan dengan satu perintah.

Manfaat penebangan

Penebangan yang terorganisasi dengan baik memungkinkan setidaknya hal berikut:

• Untuk mengetahui bahwa sesuatu tidak berjalan sebagaimana mestinya (ada kesalahan)
• Ketahui detail kesalahan, yang akan membantu untuk mengatakan dengan siapa dan di mana kesalahan terjadi, dan mencegah pengulangan
• Untuk mengetahui bahwa semuanya berjalan sesuai rencana (access.log, debug-, info-level)

Pencatatan dengan sendirinya tidak akan memberi tahu Anda semua ini, tetapi dengan bantuan log, Anda dapat mengetahui detail acara sendiri, atau mengonfigurasi sistem pemantauan log yang dapat memberi tahu masalah. Jika pesan dalam log disertai dengan konteks yang cukup, ini sangat menyederhanakan debugging, karena Anda akan memiliki akses ke lebih banyak data tentang situasi di mana peristiwa itu terjadi.

Apa yang harus ditulis dan apa yang harus ditulis

Bagian dari komunitas php telah mengembangkan rekomendasi untuk beberapa tugas penulisan kode. Salah satu rekomendasi tersebut adalah Antarmuka Logger PSR-3 . Itu hanya menggambarkan apa yang Anda perlu login. Untuk ini, Psr\Log\LoggerInterface dari paket "psr / log" dikembangkan. Saat menggunakannya, Anda perlu tahu tentang tiga komponen acara:

1. Level - Pentingnya Acara
2. Pesan - teks yang menjelaskan acara tersebut
3. Konteks - serangkaian informasi tambahan tentang acara tersebut

Level Acara PSR-3

Level-level tersebut dipinjam dari RFC 5424 - Protokol Syslog, perkiraan deskripsi mereka adalah sebagai berikut:

• debug - Detail untuk debugging
• info - Acara menarik
• notice - Peristiwa material, tapi bukan kesalahan
• peringatan - Kasus luar biasa, tetapi tidak kesalahan
• error - Kesalahan eksekusi yang tidak memerlukan intervensi sesaat
• critical - Kondisi kritis (komponen sistem tidak tersedia, pengecualian tak terduga)
• waspada - Tindakan memerlukan intervensi segera
• darurat - Sistem tidak berfungsi

Ada deskripsi, tetapi tidak selalu mudah diikuti, karena kesulitan dalam menentukan pentingnya peristiwa tertentu. Misalnya, dalam konteks satu permintaan, tidak mungkin untuk mengakses sumber daya yang terhubung. Saat merekam acara ini, kami tidak tahu apakah satu permintaan seperti itu gagal, atau mungkin hanya satu pengguna yang gagal. Itu tergantung pada apakah intervensi segera diperlukan atau jika ini adalah kasus yang jarang, itu bisa menunggu atau bahkan diabaikan. Masalah-masalah seperti itu diselesaikan dalam kerangka pemantauan log. Tetapi Anda masih perlu menentukan levelnya. Oleh karena itu, level logging dalam tim dapat disepakati. Contoh:

• darurat adalah level untuk sistem eksternal yang dapat melihat sistem Anda dan menentukan dengan pasti bahwa itu benar-benar tidak berfungsi, atau diagnosa sendiri tidak berfungsi.
• waspada - sistem itu sendiri dapat mendiagnosis keadaannya, misalnya, dengan tugas yang dijadwalkan, dan sebagai hasilnya merekam acara dengan level ini. Ini bisa berupa pengecekan sumber daya yang terhubung atau sesuatu yang spesifik, misalnya, keseimbangan pada akun sumber daya eksternal yang digunakan.
• critical - suatu peristiwa ketika kegagalan memberikan komponen sistem yang sangat penting dan harus selalu berfungsi. Itu sudah sangat tergantung pada apa yang sistem lakukan. Cocok untuk acara yang penting untuk mencari tahu dengan cepat, bahkan jika itu terjadi hanya sekali.
• kesalahan - suatu peristiwa telah terjadi yang, ketika segera diulang, Anda perlu melaporkan. Gagal menyelesaikan tindakan, yang harus dilakukan, tetapi tindakan ini tidak termasuk dalam deskripsi kritis. Misalnya, tidak mungkin menyimpan gambar profil pengguna atas permintaannya, tetapi sistem itu bukan layanan gambar profil, tetapi sistem obrolan.
• peringatan - acara, untuk pemberitahuan segera yang perlu Anda hubungi sejumlah besar dari mereka selama periode waktu. Gagal melakukan suatu tindakan, kegagalan yang tidak merusak sesuatu yang serius. Ini masih kesalahan, tetapi koreksi yang mungkin menunggu jadwal kerja. Misalnya, tidak mungkin menyimpan avatar pengguna, dan sistemnya adalah toko online. Diperlukan pemberitahuan tentang mereka (pada frekuensi tinggi) untuk mempelajari tentang anomali yang tiba-tiba, karena mereka dapat menjadi gejala masalah yang lebih serius.
• perhatikan - ini adalah peristiwa yang melaporkan penyimpangan yang disediakan oleh sistem yang merupakan bagian dari fungsi normal sistem. Misalnya, pengguna menentukan kata sandi yang salah di pintu masuk, pengguna tidak mengisi nama tengah, tetapi tidak perlu, pengguna membeli pesanan untuk 0 rubel, tetapi ini disediakan untuk Anda dalam kasus yang jarang terjadi. Pemberitahuan pada mereka pada frekuensi tinggi juga diperlukan, karena peningkatan tajam dalam jumlah penyimpangan dapat merupakan hasil dari kesalahan yang sangat perlu diperbaiki.
• info - events, kejadian yang melaporkan fungsi normal sistem. Misalnya, pengguna telah mendaftar, pengguna telah membeli produk, pengguna telah meninggalkan umpan balik. Pemberitahuan untuk peristiwa semacam itu perlu dikonfigurasikan dengan cara yang berlawanan: jika jumlah peristiwa semacam itu tidak cukup terjadi selama periode waktu tertentu, maka Anda harus memberi tahu, karena penurunannya dapat disebabkan oleh kesalahan.
• debug - peristiwa untuk men -debug proses pada sistem. Ketika Anda menambahkan data yang cukup ke konteks acara, Anda dapat mendiagnosis masalahnya, atau menyimpulkan bahwa prosesnya berfungsi dengan baik dalam sistem. Misalnya, pengguna membuka halaman produk dan menerima daftar rekomendasi. Secara signifikan meningkatkan jumlah acara yang dikirim, sehingga diperbolehkan untuk menghapus pencatatan acara tersebut setelah beberapa saat. Akibatnya, jumlah kejadian seperti itu dalam operasi normal akan berubah-ubah, maka pemantauan untuk pemberitahuannya dapat dihilangkan.

Pesan acara

Dengan PSR-3, sebuah pesan harus berupa string atau objek dengan metode __toString() . Selain itu, menurut PSR-3, baris pesan dapat berisi placeholder dari formulir ”User {username} created” , yang dapat diganti dengan nilai-nilai dari array konteks. Saat menggunakan Elasticsearch dan Kibana untuk pemantauan, saya sarankan tidak menggunakan placeholder, tetapi menulis garis tetap, karena ini akan menyederhanakan penyaringan peristiwa, dan konteksnya akan selalu ada. Selain itu, saya mengusulkan untuk memperhatikan persyaratan tambahan untuk pesan:

1. Teksnya harus pendek tetapi bermakna. Ini adalah apa yang akan muncul dalam peringatan, dan apa yang akan ada dalam daftar peristiwa yang telah terjadi.
2. Teks lebih baik menjadi unik untuk berbagai bagian program. Ini akan memungkinkan dari peringatan, tanpa melihat konteksnya, untuk memahami di bagian mana peristiwa itu terjadi.

Konteks acara

Konteks acara untuk PSR-3 adalah larik (kemungkinan bersarang) dari nilai variabel, misalnya, ID entitas. Konteksnya dapat dibiarkan kosong jika pesannya jelas tentang acara tersebut. Dalam hal mencatat pengecualian, Anda harus melewati seluruh pengecualian, bukan hanya getMessage() . Saat menggunakan Monolog melalui NormalizerFormatter, data yang berguna akan secara otomatis diekstraksi dari pengecualian dan ditambahkan ke konteks peristiwa, termasuk jejak stack. Artinya, Anda malah perlu

 [ 'exception' => $exception->getMessage(), ] 

untuk digunakan

 [ 'exception' => $exception, ] 

Di Laravel, Anda dapat secara otomatis memasukkan data untuk acara dalam acara. Ini dapat dilakukan melalui Konteks Log Global (hanya untuk pengecualian yang tidak berhasil atau melalui report() ), atau melalui LogFormatter (untuk semua acara). Biasanya, informasi ditambahkan dengan id pengguna saat ini, permintaan URI, IP, permintaan UUID dan sejenisnya.

Saat menggunakan Elasticsearch sebagai repositori log, ingatlah bahwa ia menggunakan tipe data tetap. Yaitu, jika Anda meneruskan customer_id dalam konteks angka, maka ketika Anda mencoba menyimpan acara dengan tipe yang berbeda, misalnya string (uuid), pesan seperti itu tidak akan ditulis. Jenis dalam indeks ditetapkan ketika nilai pertama kali diterima. Jika indeks dibuat setiap hari, maka tipe baru akan direkam hanya pada hari berikutnya. Tetapi bahkan ini tidak akan menyelesaikan semua masalah, karena untuk Kibana jenis akan dicampur dan beberapa operasi yang terkait dengan jenis tidak akan tersedia sampai ada indeks campuran.

Untuk mencegah masalah ini, saya sarankan Anda mengikuti aturan:

• Jangan gunakan nama kunci yang terlalu umum, yang bisa dari tipe yang berbeda
• Lakukan casting eksplisit ke tipe nilai jika Anda tidak yakin dengan tipenya

Contoh: sebagai gantinya

 [ 'response' => $response->all(), 'customer_id' => $id, 'value' => $someValue, ] 

untuk digunakan

 [ 'smsc_response_data' => json_encode($response->all()), 'customer_id' => (string) $customer_id, 'smsc_request_some_value' => (string) $someValue, ] 

Memanggil logger dari kode

Untuk merekam acara dengan cepat di log, Anda dapat membuat beberapa opsi. Mari kita pertimbangkan beberapa di antaranya.

1. Deklarasikan log() fungsi global log() dan panggil dari berbagai bagian program. Pendekatan ini memiliki banyak kelemahan. Misalnya, di kelas di mana kita mengakses fungsi ini, ketergantungan implisit terbentuk. Ini harus dihindari. Selain itu, logger seperti ini sulit untuk dikonfigurasi ketika sistem perlu memiliki beberapa yang berbeda. Kelemahan lain, jika kita berbicara tentang bekerja dengan Laravel, adalah bahwa kita tidak menggunakan fitur yang disediakan oleh kerangka kerja untuk menyelesaikan masalah ini.
2. Gunakan fasad Laravel \ Log. Dengan pendekatan ini, bagian-bagian sistem yang mengakses fasad ini mulai bergantung pada kerangka kerja. Pada bagian-bagian sistem yang tidak akan kita hapus dari kerangka kerja, solusi semacam itu sangat cocok. Misalnya, tulis dari beberapa contoh perintah konsol, tugas latar belakang, pengontrol. Atau ketika sudah ada struktur layanan yang rumit, dan melempar instance dari logger ke dalamnya tidak begitu sederhana.
3. Mengatasi ketergantungan logger melalui bantuan kerangka app() dan kerangka resolve() . Pendekatan ini memiliki kelemahan yang sama dengan menggunakan fasad, tetapi Anda perlu menulis sedikit lebih banyak kode.
4. Tentukan ketergantungan pada logger di konstruktor kelas yang akan digunakan logger ini. Pada saat yang sama, LoggerInterface sama harus ditentukan sebagai jenis untuk memenuhi DIP . Berkat kerangka kerja autowiring, dependensi akan secara otomatis diselesaikan dalam implementasi abstraksi yang mereka nyatakan. Di Laravel, beberapa kelas dependensi dapat ditentukan dalam metode terpisah, alih-alih ditentukan dalam konstruktor seluruh kelas.

Di mana dalam kode untuk memanggil logger

Saat mengatur kode dalam proyek, pertanyaan mungkin muncul di kelas mana saya harus menulis ke log. Haruskah itu menjadi layanan? Atau haruskah itu dilakukan di mana layanan dipanggil dari: controller, tugas latar belakang, perintah konsol? Atau haruskah setiap pengecualian memutuskan apa yang akan ditulis ke log menggunakan metode report (Laravel)? Tidak ada jawaban sederhana untuk semua pertanyaan sekaligus.

Pertimbangkan peluang yang diberikan oleh Laravel untuk mendelegasikan tugas pengecualian ke kelas pengecualian itu sendiri. Pengecualian tidak dapat mengetahui betapa pentingnya sistem untuk menentukan tingkat suatu peristiwa. Selain itu, pengecualian tidak memiliki akses ke konteks kecuali jika secara khusus ditambahkan ketika pengecualian ini dipanggil. Untuk memanggil metode render pada pengecualian, Anda harus tidak menangkap pengecualian (global ErrorHandler akan digunakan), atau menangkap dan menggunakan report() global helper. Metode ini memungkinkan kita untuk tidak memanggil logger PSR-3 setiap kali kita dapat menangkap pengecualian ini. Tapi saya pikir tidak layak untuk memberikan pengecualian tanggung jawab tersebut.

Tampaknya kita selalu dapat login hanya di layanan. Memang, di beberapa layanan Anda bisa melakukan logging. Tetapi pertimbangkan layanan yang tidak tergantung pada proyek dan, secara umum, kami berencana untuk memasukkannya ke dalam paket terpisah. Maka layanan ini tidak tahu tentang pentingnya dalam proyek, dan, oleh karena itu, tidak akan dapat menentukan tingkat pembalakan. Misalnya, layanan integrasi dengan gateway SMS tertentu. Jika kita mendapatkan kesalahan jaringan, maka ini tidak berarti itu cukup serius. Mungkin sistem memiliki layanan integrasi dengan gateway SMS lain di mana akan ada upaya kedua untuk mengirim, maka kesalahan dari yang pertama dapat dilaporkan sebagai peringatan, dan kesalahan yang kedua sebagai kesalahan. Hanya sekarang semua integrasi ini harus dipanggil dari layanan lain, yang akan masuk dengan tepat. Ternyata kesalahan ada di satu layanan, dan kami masuk di layanan lain. Namun terkadang kami tidak memiliki pembungkus layanan di atas layanan lain - kami menyebutnya langsung dari pengontrol. Dalam hal ini, saya menganggap diperbolehkan untuk menulis ke log di controller daripada menulis dekorator layanan untuk logging.

Contoh yang menunjukkan penggunaan dependensi dan konteks lewat:

 <?php namespace App\Console\Commands; use App\Services\ExampleService; use Illuminate\Console\Command; use Psr\Log\LoggerInterface; class Example extends Command { protected $signature = 'example'; public function handle(ExampleService $service, LoggerInterface $logger) { try { $service->example(); } catch (\Exception $exception) { $logger->critical('Example error', [ 'exception' => $exception, ]); } } } 

Tempat menulis

Pertimbangkan opsi berikut.

1. Menurut aplikasi 12 faktor dan beberapa rekomendasi lain, Anda perlu menulis di stdout, stderr dari runtime aplikasi. Untuk melakukan ini, Anda dapat menentukan di php://stdout config logger php://stdout *.
2. Abaikan 12 faktor, cara buruh pelabuhan dan tulis ke file. Laravel (Monolog) bahkan memungkinkan Anda untuk mengkonfigurasi rotasi log. Pesan lebih lanjut dari file dapat dikumpulkan menggunakan Filebeat dan dikirim ke Logstash untuk dianalisis.
3. Kirim log dari aplikasi secara langsung lebih lanjut, misalnya, melalui UDP untuk meningkatkan kinerja.
4. Kombinasikan solusi. Menulis ke file yang menggunakan Filebeat akan dikumpulkan dan dikirim ke Logstash. Tuliskan dalam wadah stderr agar dapat menggunakan perintah docker logs dan siap untuk mengumpulkan kayu dari lingkungan orkestrasi wadah. Dalam hal ini, Anda dapat menulis beberapa saluran hanya secara lokal, beberapa mengirim melalui jaringan.

* Dalam php-fpm 7.2, ketika menulis log ke stdout, kita mendapatkan "PERINGATAN: [kelompok www] child X berkata ke stdout ...", dan pesan yang panjang terpotong. Salah satu solusi untuk masalah ini ada di sini . Tidak ada masalah seperti itu di php-fpm 7.3.

Opsi format perekaman:

• Dapat dibaca oleh manusia (penghentian baris, indentasi, dll.)
• Dapat dibaca mesin (biasanya json)
• Kedua format sekaligus: dapat dibaca mesin di stdout untuk perutean lebih lanjut, dapat dibaca manusia jika terjadi masalah perutean mendadak dan debugging cepat

Salah satu opsi mengasumsikan bahwa log dirutekan - setidaknya, mereka dikirim ke sistem pemrosesan tunggal (penyimpanan) log karena alasan berikut:

1. Penyimpanan dan pengarsipan jangka panjang
2. Tren skala besar
3. Sistem pemberitahuan acara yang fleksibel

Docker memiliki kemampuan untuk menentukan manajer log. Standarnya adalah json-file , yaitu buruh pelabuhan menambahkan output dari wadah ke file json di host. Jika kami memilih manajer log yang akan mengirim catatan di suatu tempat melalui jaringan, maka kami tidak dapat lagi menggunakan perintah docker logs . Jika stdout / stderr dari wadah dipilih sebagai satu-satunya tempat untuk merekam log aplikasi, maka dalam kasus masalah jaringan atau masalah dengan repositori tunggal, tidak mungkin untuk dengan cepat mengekstraksi catatan untuk debug.

Kita bisa menggunakan dock file json dan Filebeat. Kami akan menerima log lokal dan perutean lebih lanjut. Perlu dicatat di sini adalah fitur lain dari buruh pelabuhan. Saat merekam acara yang lebih panjang dari 16KB, buruh pelabuhan memecah catatan dengan simbol \n , yang membingungkan banyak pengumpul log. Ada masalah tentang ini. Masalah pada bagian buruh pelabuhan tidak bisa diselesaikan, jadi itu diselesaikan oleh para kolektor. Dengan beberapa versi, Filebeat mendukung perilaku buruh pelabuhan ini dan menggabungkan acara dengan benar.

Apa kombinasi dari semua kemungkinan tujuan dan format rekaman yang dapat Anda pilih untuk proyek Anda sendiri.

Menggunakan Filebeat + ELK + Elastalert

Secara singkat, peran masing-masing layanan dapat digambarkan sebagai berikut:

• Filebeat - mengumpulkan acara dari file dan mengirim
• Logstash - mem-parsing acara dan mengirim
• Elasticsearch - menyimpan acara terstruktur
• Kibana - menampilkan acara (grafik, agregasi, dll.)
• Elastalert - Mengirim pemberitahuan berdasarkan permintaan

Selain itu, Anda dapat: zabbix, metricbeat, grafana, dan lainnya.

Sekarang, lebih banyak tentang masing-masing.

Filebeat

Anda dapat menjalankan sebagai layanan terpisah pada host, Anda dapat menggunakan wadah buruh pelabuhan yang terpisah. Untuk bekerja dengan aliran peristiwa dari buruh pelabuhan, ia menggunakan jalur host /var/lib/docker/containers/*/*.log . Filebeat memiliki beragam opsi untuk mengatur perilaku dalam berbagai situasi (file diubah namanya, file dihapus, dan sejenisnya). Filebeat itu sendiri dapat mem-parsing json di dalam acara, tetapi tidak json juga bisa masuk ke acara, yang akan menyebabkan kesalahan. Semua pemrosesan acara paling baik dilakukan di satu tempat.

 filebeat.inputs: - type: docker containers: ids: - "*" processors: - add_docker_metadata: ~ 

Logstash

Dapat menerima acara dari banyak sumber, tetapi di sini kami mempertimbangkan Filebeat.
Di setiap acara, selain acara itu sendiri dari stdout / stderr, ada metadata (tuan rumah, wadah, dll.). Ada banyak filter pemrosesan bawaan: parse dengan interval reguler, parse json, modifikasi, tambah, hapus bidang, dll. Cocok untuk mengurai log aplikasi dan nginx access.log dalam format apa pun. Dapat mentransfer data ke berbagai repositori, tetapi di sini kami mempertimbangkan Elasticsearch.

 if [status] { date { match => ["timestamp_nginx_access", "dd/MMM/yyyy:HH:mm:ss Z"] target => "timestamp_nginx" remove_field => ["timestamp_nginx_access"] } mutate { convert => { "bytes_sent" => "integer" "body_bytes_sent" => "integer" "request_length" => "integer" "request_time" => "float" "upstream_response_time" => "float" "upstream_connect_time" => "float" "upstream_header_time" => "float" "status" => "integer" "upstream_status" => "integer" } remove_field => [ "message" ] rename => { "@timestamp" => "event_timestamp" "timestamp_nginx" => "@timestamp" } } } 

Pencarian Elastics

Elasticsearch adalah alat yang sangat kuat untuk berbagai tugas, tetapi untuk tujuan pemantauan, log dapat digunakan hanya dengan mengetahui minimum tertentu.
Peristiwa tersimpan adalah dokumen, dokumen disimpan dalam indeks.
Setiap indeks adalah skema di mana suatu tipe didefinisikan untuk setiap bidang dokumen. Anda tidak dapat menyimpan acara di indeks jika setidaknya satu bidang memiliki tipe yang salah.
Jenis yang berbeda memungkinkan Anda untuk melakukan operasi yang berbeda pada sekelompok dokumen (untuk angka - jumlah, min, maks, rata, dll, untuk string - pencarian fuzzy, dan sebagainya).
Untuk log, manajemen biasanya merekomendasikan penggunaan indeks harian - indeks baru setiap hari.

Memastikan operasi Elasticsearch yang stabil dengan pertumbuhan volume data adalah tugas yang membutuhkan pengetahuan lebih dalam tentang alat ini. Tapi solusi cepat untuk masalah stabilitas, Anda dapat memilih untuk secara otomatis menghapus data yang sudah usang. Untuk melakukan ini, saya sarankan membagi level peristiwa dalam logstash di indeks yang berbeda. Ini akan memungkinkan lebih lama untuk menyimpan acara yang jarang, tetapi lebih penting.

 output { if [fields][log_type] == "app_log" { if [level] in ["DEBUG", "INFO", "NOTICE"] { elasticsearch { hosts => "${ES_HOST}" index => "logstash-app-log-debug-%{+YYYY.MM.dd}" } } else { elasticsearch { hosts => "${ES_HOST}" index => "logstash-app-log-error-%{+YYYY.MM.dd}" } } } } 

Untuk secara otomatis menghapus indeks usang, saya sarankan menggunakan program dari Kurator Elastis. Peluncuran program ditambahkan ke jadwal Cron, konfigurasinya sendiri dapat disimpan dalam file terpisah.

 action: delete_indices description: logstash-app-log-error options: ignore_empty_list: True filters: - filtertype: pattern kind: prefix value: logstash-app-log-error- - filtertype: age source: name direction: older timestring: '%Y.%m.%d' unit: months unit_count: 6 

, Filebeat Logstash, . Elasticsearch -- , , .

Kibana

Kibana . -, Elasticsearch. .

Kibana — Discovery . , Discovery app warning , time, message, exception class, host, client_id.

, Discovery nginx, 404 time, message, request, status.
Kibana , : , , . , ( ).

Elastalert

Elastalert Elasticsearch . , . , .
, (), .

:

• ALERT, EMERGENCY. — 10
• CRITICAL. — 30
• , N X M
• 10 INFO 3
• nginx 200, 201, 304 75% , 50

 name: Blacklist ALERT, EMERGENCY type: blacklist index: logstash-app-* compare_key: "level" blacklist: - "ALERT" - "EMERGENCY" realert: minutes: 5 alert: - "slack" 

— . , , . Kibana.

, , http- 75% , , , , . - , , , .

, , , , Kibana, .

5 . , , , , , .

, . .

Kibana . .

docker-. , , staging- production-, .

, Elastalert, . Elastalert ,
envsubst < /opt/elastalert/config.dist.yaml > /opt/elastalert/config.yaml entrypoint- , .

, , , .

 build: docker build -t some-registry/elasticsearch elasticsearch docker build -t some-registry/logstash logstash docker build -t some-registry/kibana kibana docker build -t some-registry/nginx nginx docker build -t some-registry/curator curator docker build -t some-registry/elastalert elastalert push: docker push some-registry/elasticsearch docker push some-registry/logstash docker push some-registry/kibana docker push some-registry/nginx docker push some-registry/curator docker push some-registry/elastalert pull: docker pull some-registry/elasticsearch docker pull some-registry/logstash docker pull some-registry/kibana docker pull some-registry/nginx docker pull some-registry/curator docker pull some-registry/elastalert prepare: docker network create -d bridge elk-network || echo "ok" stop: docker rm -f kibana || true docker rm -f logstash || true docker rm -f elasticsearch || true docker rm -f nginx || true docker rm -f elastalert || true run-logstash: docker rm -f logstash || echo "ok" docker run -d --restart=always --network=elk-network --name=logstash -p 127.0.0.1:5001:5001 -e "LS_JAVA_OPTS=-Xms256m -Xmx256m" -e "ES_HOST=elasticsearch:9200" some-registry/logstash run-kibana: docker rm -f kibana || echo "ok" docker run -d --restart=always --network=elk-network --name=kibana -p 127.0.0.1:5601:5601 --mount source=elk-kibana,target=/usr/share/kibana/optimize some-registry/kibana run-elasticsearch: docker rm -f elasticsearch || echo "ok" docker run -d --restart=always --network=elk-network --name=elasticsearch -e "ES_JAVA_OPTS=-Xms1g -Xmx1g" --mount source=elk-esdata,target=/usr/share/elasticsearch/data some-registry/elasticsearch run-nginx: docker rm -f nginx || echo "ok" docker run -d --restart=always --network=elk-network --name=nginx -p 80:80 -v /root/elk/.htpasswd:/etc/nginx/.htpasswd some-registry/nginx run-elastalert: docker rm -f elastalert || echo "ok" docker run -d --restart=always --network=elk-network --name=elastalert --env-file=./elastalert/.env some-registry/elastalert run: prepare run-elasticsearch run-kibana run-logstash run-elastalert delete-old-indices: docker run --rm --network=elk-network -e "ES_HOST=elasticsearch:9200" some-registry/curator curator --config /curator/curator.yml /curator/actions.yml 

:

• 80 nginx, basic auth Kibana
• Logstash . ssh-
• nginx
• , docker-
• , .env- nginx-
• *_JAVA_OPTS , 4GB RAM ( ES).

, xpack-.

docker-compose. , , Dockerfile-, Filebeat, Logstash, , , , , VCS.

. . , ( Laravel scheduler), , 5 . ALERT. , . , , .

Kesimpulan

, , , . . , - . . , , .