Dua tahun lalu saya sudah membuat postingan Kegagalan sederhana untuk situs web tentang okerr. Sekarang ada beberapa pengembangan proyek, dan saya juga menerbitkannya kode sumber sisi server oker bawah lisensi terbuka, itulah mengapa saya memutuskan untuk menulis ulasan singkat ini di Habr.

[ ukuran penuh ]

Kepada siapa pun mungkin tertarik

Ini mungkin menarik bagi Anda jika Anda bekerja dalam tim kecil atau sendirian. Anda tidak memiliki pemantauan dan Anda tidak yakin apakah Anda benar-benar membutuhkannya. Entah Anda mencoba beberapa pemantauan serius yang populer “untuk orang-orang besar”, tetapi entah bagaimana “tidak berhasil” untuk Anda, atau ia bekerja dalam konfigurasi yang hampir default dan tidak banyak mengubah hidup Anda. Dan juga - jika Anda tidak berencana mengalokasikan seluruh karyawan (atau bahkan departemen) untuk memantau dasbor pemantauan setidaknya beberapa jam sehari atau mengkonfigurasinya.

Mengapa okerr tidak biasa

Selanjutnya saya akan menunjukkan fitur-fitur menarik dari okerra yang membedakannya dari beberapa sistem pemantauan lainnya.

Okerr adalah pemantauan hybrid

Selama pemantauan internal, sebuah "agen" berjalan pada mesin yang dipantau, yang mengirimkan data ke server pemantauan (misalnya, ruang disk kosong). Saat bersifat eksternal, server melakukan pemeriksaan melalui jaringan (misalnya, ping atau ketersediaan situs web). Setiap pendekatan memiliki keterbatasannya. Okerr menggunakan kedua opsi tersebut. Pemeriksaan di dalam server dilakukan oleh agen yang sangat ringan (30Kb) atau skrip dan aplikasi Anda sendiri, dan pemeriksaan jaringan dilakukan melalui sensor okerr di berbagai negara.

okerr bukan sekedar software, tapi juga layanan

Bagian server dari pemantauan apa pun berukuran besar dan kompleks, sulit dipasang dan dikonfigurasi, serta memerlukan sumber daya. Dengan okerr Anda dapat menginstal server pemantauan Anda sendiri (gratis dan sumber terbuka), atau Anda cukup menggunakan bagian klien saja dan menggunakan layanan server kami. Juga gratis.

Jika pemantauan memungkinkan Anda untuk mengkompensasi dan menutupi kurangnya keandalan server dan aplikasi, maka muncul pertanyaan filosofis - siapa penjaganya? Bagaimana pemantauan akan memberi tahu kita tentang suatu masalah jika masalah itu sendiri “mati” karena alasan tertentu, secara terpisah atau bersama-sama dengan sumber daya Anda yang lain (misalnya, saluran ke pusat data terputus)? Saat menggunakan layanan eksternal okerr - masalah ini terpecahkan - Anda akan menerima peringatan meskipun seluruh pusat data dengan server Anda mati atau diserang oleh zombie.

Tentu saja, ada risiko bahwa server okerr itu sendiri tidak akan tersedia, hal ini benar (seperti yang Anda ketahui, 90% keandalan selalu diperoleh dengan sederhana dan "gratis", 99% dengan sedikit usaha, dan setiap sembilan berikutnya adalah secara eksponensial lebih sulit). Namun, pertama, kemungkinan terjadinya hal ini lebih rendah, dan kedua, masalahnya mungkin luput dari perhatian hanya jika terjadi bersamaan dengan masalah pada server kami. Jika keandalan kami adalah 99.9%, dan Anda memiliki 99.9% (angka yang tidak terlalu tinggi), maka kemungkinan kegagalan yang tidak terdeteksi adalah 0.1% dari 0.1% = 0.0001%. Menambahkan tiga sembilan ke keandalan Anda hampir tanpa usaha dan tanpa biaya sangatlah bagus!

Keuntungan lain dari monitoring sebagai layanan adalah penyedia hosting atau studio web dapat menginstal server oker dan memberikan akses kepada klien sebagai layanan tambahan berbayar atau gratis. Pesaing Anda hanya memiliki hosting dan situs web, tetapi Anda memiliki hosting yang andal dengan pemantauan.

Okerr adalah tentang indikator

Indikatornya adalah “bola lampu”. Ini memiliki dua status utama - hijau (OK) atau merah (ERR). Proyek ini berisi banyak indikator yang dikelompokkan (misalnya, berdasarkan server). Di halaman utama proyek, Anda segera melihat semuanya berwarna hijau (dan Anda dapat menutupnya), atau ada sesuatu yang menyala merah dan perlu diperbaiki. Saat bertransisi di antara status-status ini, peringatan dikirimkan. Sekali sehari saat Anda menyiapkannya, ringkasan proyek dikirimkan.

Setiap indikator okerr memiliki kondisi bawaan yang dapat digunakan untuk mengubah status (di Zabbix, hal ini disebut pemicu). Misalnya, rata-rata beban tidak boleh lebih dari 2 (tentu saja, ini dapat dikonfigurasi). Dan untuk setiap pemeriksaan internal (rata-rata beban, bebas disk, ...) ada pengawas. Jika karena alasan tertentu kami tidak menerima konfirmasi berhasil pada waktu yang ditentukan, kesalahan akan dicatat dan peringatan dikirimkan.

Pola kerja kami yang biasa adalah memeriksa email di pagi hari, dan melihat ringkasan di antara surat-surat lainnya (kami menjadwalkannya di awal pekerjaan). Jika semuanya baik-baik saja di dalamnya, kami melakukan hal penting lainnya (tetapi untuk amannya, kami dapat segera melihat dasbor okerra dan memastikan semuanya berwarna hijau saat ini). Jika ada peringatan, kami bereaksi.

Tentu saja, dimungkinkan untuk hanya menyimpan indikator “informasional” (untuk melihat gambaran jaringan dari pemantauan), namun semuanya dilakukan dengan sederhana, mudah dan cepat membuat indikator khusus untuk pemantauan otomatis dan pengiriman peringatan.

Tujuan Anda mengatur okerr adalah dalam peringatan, sehingga Anda dapat membuat indikator dalam satu menit, indikator itu bisa "tidur" selama setahun, cukup menerima pembaruan, dan ketika setahun kemudian ada yang rusak, indikator itu menyala dan mengirimkan sebuah peringatan. Waktu yang Anda habiskan untuk membuat indikator membuahkan hasil; Anda segera mengetahui masalahnya, sebelum orang lain. Mungkin saja mereka memperbaikinya sebelum ada yang menyadarinya. Sesuatu yang diangkat dengan cepat tidak dianggap jatuh!

keamanan

Akan sangat disayangkan jika Anda mengatur pemantauan demi meningkatkan keandalan, tetapi akibatnya, Anda diserang melalui jaringan, dan ada cukup banyak kerentanan jaringan di berbagai alat pemantauan (Zabbix, nagios).

Agen (okerrmod dari paket okerrperbarui) yang berjalan pada sistem bukanlah server jaringan, tetapi klien. Oleh karena itu, tidak ada port terbuka tambahan di server yang dipantau, klien dengan mudah bekerja di belakang firewall atau NAT dan sangat sulit (menurut saya "tidak mungkin") untuk meretas jaringan, karena pada prinsipnya ia tidak mendengarkan jaringan stopkontak.

Cakupan pemantauan penuh

Sekarang aturan kami adalah kami mempelajari semua masalah teknis dari okerr. Jika tiba-tiba aturan tersebut dilanggar (okerr tidak memperingatkan tentang kejadian yang akan terjadi (jika memungkinkan) atau sudah terjadi) - kami menambahkan cek ke okerr.

Pemeriksaan eksternal

Satu set yang cukup khas:

ping
status http
memeriksa validitas dan kesegaran sertifikat SSL (akan memperingatkan jika akan kedaluwarsa)
buka port TCP dan spanduk di atasnya
http grep (halaman [tidak boleh] berisi teks tertentu)
sha1 hash untuk menangkap perubahan halaman.
DNS (catatan DNS harus memiliki nilai tertentu)
WHOIS (akan memperingatkan jika domain akan rusak)
Antispam DNSBL (pemeriksaan host terhadap 50+ daftar hitam antispam sekaligus)

Pemeriksaan internal

Juga, set yang cukup standar (tetapi mudah diperluas).

df (ruang disk kosong)
beban rata-rata
opentcp (buka soket pendengar TCP - akan memberi tahu jika ada sesuatu yang dimulai atau macet)
uptime - hanya uptime di server. Akan memberi tahu jika ada perubahan (yaitu server kelebihan beban)
klien_ip
dirsize - kami menggunakannya untuk melacak kapan rootf mesin virtual kami melebihi ukuran yang diizinkan, tanpa memperkenalkan batasan ketat, dan ukuran direktori home pengguna
kosong dan tidak kosong - pantau file yang seharusnya kosong (atau tidak kosong). Misalnya, log kesalahan server okerr itu sendiri harus kosong, dan jika ada baris di dalamnya, saya akan menerima pemberitahuan dan memeriksanya. Namun mail.log di server email TIDAK boleh kosong (N menit setelah rotasi). Dan terkadang rsyslog itu kosong setelah pembaruan sistem, ketika logrotate tidak dapat memulai ulang rsyslog dengan benar.
linecount - jumlah baris dalam file (seperti wc -l). Kami menggunakannya sebagai pengganti yang lebih lembut untuk yang kosong, ketika log kesalahan masih dapat bertambah, tetapi hanya perlahan (misalnya, Googlebot membuka beberapa halaman yang ditutup). Ada batasan 2 baris dalam 20 menit. Jika lebih tinggi maka akan ada peringatan

Pemeriksaan internal yang menarik

Jika selama ini Anda selama ini membaca “secara diagonal”, kini akan lebih menarik untuk membaca lebih cermat.

backup

Memantau cadangan di direktori. File cadangan kami memiliki nama seperti “ServerName-20200530.tar.gz”. Untuk setiap server di okerr, indikator ServerName-DATE.tar.gz dibuat (tanggal sebenarnya berubah menjadi baris “DATE”). Keberadaan cadangan baru dan ukurannya juga dipantau (misalnya, tidak boleh kurang dari 90% dari cadangan sebelumnya).

Apa yang perlu dilakukan agar cadangan baru mulai dilacak setelah kita mulai membuatnya dan meletakkannya di direktori ini? Tidak ada apa-apa! Ini adalah pendekatan yang sangat nyaman ketika Anda tidak perlu melakukan apa pun karena:

Tidak melakukan apa pun cukup cepat dan menghemat waktu
Sulit untuk melupakan "tidak melakukan apa-apa"
Sulit untuk melakukan “tidak ada” yang salah, jika ada kesalahan. Tidak ada metode yang paling dapat diandalkan

Jika tiba-tiba file cadangan baru berhenti muncul, akan ada peringatan. Jika, misalnya, Anda telah menonaktifkan salah satu server, dan tidak ada cadangan lagi, Anda perlu menghapus indikator tersebut (melalui antarmuka web atau dari shell melalui API).

maxfilesz

Melacak ukuran file terbesar (biasanya: /var/log/*). Hal ini memungkinkan Anda untuk mendeteksi masalah yang tidak terduga, misalnya, kata sandi yang kasar atau pengiriman spam melalui server.

status berjalan/runline

Ini adalah dua modul proxy penting untuk menjalankan program lain di server. Runstatus melaporkan kode keluar program ke indikator. Misalnya, okerr tidak (memerlukan) modul untuk memeriksa apakah layanan systemd sedang berjalan. Ini dilakukan melalui runstatus (lihat di bawah). Runline - melaporkan ke server baris yang dihasilkan program. Misalnya, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" dalam konfigurasi Runline di server kami membuat indikator servername:temp dengan suhu prosesor.

sql

Menjalankan kueri numerik ke MySQL dan melaporkan hasilnya ke indikator. Dalam kasus sederhana, Anda dapat melakukan, misalnya, "PILIH 1" - ini akan memeriksa apakah DBMS secara keseluruhan berfungsi.

Namun aplikasi yang jauh lebih menarik, misalnya, melacak jumlah pesanan di toko online. Jika Anda mengetahui bahwa Anda memiliki 100 atau lebih pesanan per jam, Anda dapat menetapkan batas minimum menjadi 100 atau 80. Kemudian jika penjualan Anda tiba-tiba turun, Anda akan menerima peringatan dan Anda dapat mengetahuinya.

Perhatikan bahwa tidak masalah apa pun alasan tak terduga hal ini terjadi:

Server tidak tersedia (tidak diberi energi atau tanpa jaringan), dan peringatan datang dari fakta bahwa indikatornya “busuk”.
Server kelebihan beban dengan sesuatu, bekerja lambat atau paket hilang, merepotkan pengguna dan mereka pergi tanpa melakukan pembelian
Server termasuk dalam daftar spam dan email darinya tidak diterima, pengguna tidak dapat mendaftar
Anggaran kampanye iklan sudah habis, spanduk tidak berputar.

Alasannya bisa bermacam-macam, dan semuanya tidak dapat diperkirakan sebelumnya, dan secara teknis sulit untuk dilacak. Namun Anda dapat dengan mudah memantau parameter akhir (perintah) dan menentukan dari parameter tersebut bahwa situasinya mencurigakan dan layak untuk ditangani.

Indikator logis

Mengizinkan penggunaan ekspresi Boolean (sintaks Python) melalui modul memvalidasi(artikel tentang Habré). Data dari proyek dan indikator-indikatornya tersedia untuk diungkapkan. Misalnya, dalam bab tentang pemeriksaan SQL di atas, Anda mungkin telah memperhatikan titik lemahnya - pada siang hari kami dapat memperoleh 100 penjualan per jam, tetapi pada malam hari - 20, dan ini biasa terjadi, bukan masalah. Apa yang harus saya lakukan? Indikatornya akan terus-menerus panik di malam hari.

Anda dapat membuat dua indikator, siang dan malam. Jadikan keduanya “diam” (mereka tidak akan mengirimkan peringatan). Dan buatlah indikator logis yang mengharuskan indikator siang OK sebelum jam 20, dan setelah jam 00 cukup indikator malam OK.

Contoh lain penggunaan indikator logika adalah eskalasi. Misalnya, manajer proyek berhenti berlangganan peringatan (dia tidak perlu melakukan ini, admin harus merespons masalah normal), tetapi berlangganan indikator logis yang berubah menjadi merah jika ada indikator dalam proyek yang tidak diperbaiki dalam waktu yang ditentukan.

Selain itu, dimungkinkan untuk mengatur waktu yang diizinkan untuk bekerja, misalnya dari jam 3 hingga jam 5 pagi. Kami tidak peduli jika server dan situs mogok selama ini. Tapi pada jam 5:00 mereka harus bekerja. Jika mereka tidak berfungsi di lain waktu - waspada. Indikator logis juga memungkinkan Anda memperhitungkan redundansi server. Jika Anda mempunyai 5 web server, maka admin dapat mematikan 1-2 server kapan saja. Namun jika ada kurang dari 3 dari 5 server dalam pertempuran, akan ada peringatan.

Contoh di atas bukanlah fungsi oker, bukan beberapa fitur yang perlu diaktifkan dan dikonfigurasi. Okerra tidak memiliki semua fungsi ini, tetapi ada modul logika yang memungkinkan Anda mengimplementasikan fungsi ini (Kira-kira seperti dalam bahasa pemrograman - jika kita memiliki operator aritmatika, maka kita tidak memerlukan fungsi khusus untuk menghitung PPN 20% dari bahasanya, Anda selalu bisa melakukannya sendiri sesuai kebutuhan Anda).

Indikator Logika mungkin adalah salah satu dari sedikit topik yang relatif kompleks di okerr, namun kabar baiknya adalah Anda tidak harus menguasainya sampai Anda membutuhkannya. Namun pada saat yang sama, mereka sangat memperluas kemampuannya, sekaligus menjaga sistem itu sendiri tetap sederhana.

Menambahkan cek Anda sendiri

Saya sangat ingin menyampaikan gagasan bahwa okerr bukanlah kumpulan ribuan cek yang sudah jadi untuk semua kesempatan, tetapi sebaliknya - pertama-tama - mesin sederhana dengan kemampuan sederhana untuk membuat cek Anda sendiri. Membuat cek Anda sendiri di okerr bukanlah tugas bagi peretas, rekan pengembang sistem, atau setidaknya pengguna okerr tingkat lanjut, tetapi tugas yang layak dilakukan oleh admin mana pun yang menginstal Linux untuk pertama kalinya sebulan yang lalu.

Pengecekan upah minimum dilakukan melalui modul status berjalan:

Baris ini di konfigurasi status berjalan akan memberi tahu Anda jika /bin/true tiba-tiba tidak memulai atau mengembalikan sesuatu selain 0.

true_OK=/bin/true

Hanya satu baris - dan ini dia sedikit diperluas fungsi okerr.

Bahkan pemeriksaan seperti itu sudah ada nilainya: jika tiba-tiba server Anda mogok, indikator yang sesuai di server okerr tidak akan diperbarui tepat waktu, dan setelah waktu berlalu, peringatan akan muncul.

Pemeriksaan ini akan memberitahukan bahwa server Apache2 telah crash (yah, Anda tidak pernah tahu...):

apache_OK="systemctl is-active --quiet apache2"

Jadi, jika Anda menguasai bahasa pemrograman apa pun, dan setidaknya bisa menulis skrip shell, maka Anda sudah bisa menambahkan cek Anda sendiri.

Lebih sulit - Anda dapat menulis (dalam bahasa apa pun) modul Anda sendiri untuk okerrmod. Dalam kasus paling sederhana, tampilannya seperti ini:

#!/usr/bin/python3

print("STATUS: OK")

Bukankah ini sangat sulit? Modul harus melakukan pemeriksaan sendiri dan menampilkan hasilnya ke STDOUT. Modul yang lebih kompleks memberikan, misalnya, ini:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Ini memperbarui beberapa indikator sekaligus (dipisahkan oleh baris kosong), membuatnya jika perlu, menunjukkan detail verifikasi dan tag yang memudahkan untuk menemukan indikator yang diperlukan di dasbor.

Ada bot Telegram @OkerrBot. Anda tidak perlu mengacaukan ponsel Anda dengan aplikasi terpisah (saya tidak suka bahwa untuk Pyaterochka Anda memerlukan satu aplikasi dengan peta, untuk Lenta yang lain, untuk MTS yang ketiga, dan seterusnya untuk semua orang, semua, semua). Satu telegram sudah cukup. Melalui telegram Anda dapat langsung menerima peringatan, memeriksa status proyek dan memberikan perintah untuk memeriksa ulang semua indikator yang bermasalah. Kami meninggalkan teater/pesawat, tidak memantau perkembangan selama dua jam, menyalakan telepon, menekan satu tombol di chatbot, dan memastikan semuanya baik-baik saja.

Halaman Status

Saat ini, halaman status hampir menjadi keharusan bagi setiap bisnis yang memiliki TI, sikap bertanggung jawab terhadap keandalan, dan memperlakukan klien/penggunanya dengan hormat.

Bayangkan sebuah situasi - pengguna ingin melakukan sesuatu, melihat informasi atau memesan, dan sesuatu tidak berfungsi. Dia tidak tahu apa yang sedang terjadi, di pihak siapa masalahnya, dan kapan masalah itu akan diselesaikan. Mungkin perusahaan Anda hanya memiliki situs web yang tidak berfungsi? Atau rusak enam bulan lalu dan akan diperbaiki dalam dua tahun? Tapi kamu perlu beli kulkas sekarang, sudah ada di troli... Dan lain halnya ketika seseorang melihat ada yang tidak beres dengan Anda (setidaknya jelas bahwa masalahnya bukan di pihaknya), bahwa masalah telah ditemukan, bahwa Anda sedang mengerjakannya, dan bahkan mungkin menuliskan perkiraan waktu untuk koreksi. Pengguna dapat berlangganan dan menerima email notifikasi ketika masalahnya telah teratasi dan dia dapat melakukan apa yang dia inginkan (membeli kulkas).

Masalah dan downtime terjadi pada semua orang. Namun pengguna dan mitra lebih mempercayai mereka yang lebih transparan dan bertanggung jawab dalam pendekatan mereka terhadap hal ini.

di sini adalah ulasan 10 proyek lain yang memungkinkan Anda membuat halaman status. Berikut adalah contoh tampilan halaman proyek tersebut Ular sanca и dropbox. halaman status oke.

Failover

Agar artikel ini tidak bertambah panjang lagi, saya akan merujuk kembali ke artikel saya sebelumnya - Kegagalan sederhana untuk situs web . Jika Anda dapat membuat server duplikat, maka dengan menggunakan failover, pada dasarnya Anda tidak akan mengalami waktu henti yang lama - segera setelah masalah terdeteksi, pengguna akan secara otomatis dialihkan ke server cadangan yang berfungsi. Dan menurut saya ini adalah fitur yang sangat menarik dan cemerlang yang jarang tersedia di mana pun.

Persyaratan sistem rendah

Untuk server okerr, kami menggunakan mesin dengan RAM mulai 2Gb. Untuk sensor jaringan, 512Mb saja sudah cukup. Bagian klien umumnya hampir nol. (Kantong plastik okerrperbarui beratnya 26 Kb, tetapi membutuhkan Python3 dan perpustakaan standar). Klien dijalankan dari skrip cron, sehingga tidak ada konsumsi memori persisten. Di antara mesin yang kami pantau, kami memiliki sensor (VPS super murah dengan RAM 512Mb) dan Raspberry Pi. Itu mungkin bahkan tanpa bagian klien kirim pembaruan melalui curl! (Lihat di bawah)

Mempertimbangkan hal ini - oke, mungkin paling gratis sistem pemantauan dari yang tersedia, karena bahkan untuk menggunakan sistem sumber terbuka gratis lainnya seperti Zabbix atau Nagios, Anda perlu mengalokasikan sumber daya (server) ke dalamnya, dan ini sudah berupa uang. Selain itu, beberapa pemeliharaan server masih diperlukan. Dengan okerr, bagian ini bisa dihilangkan. Atau Anda tidak perlu menghapusnya dan menggunakan server Anda sendiri, tergantung mana yang paling Anda sukai.

API dan integrasi ke dalam perangkat lunak berpemilik

Arsitektur sederhana dan terbuka. okerr punya yang cukup sederhana API, yang mudah untuk dikerjakan. Perlu membuat 1000 indikator? Satu skrip shell yang terdiri dari 3-4 baris akan melakukan ini. Perlu mengkonfigurasi ulang 1000 indikator? Ini juga sangat mudah. Misalnya, kami ingin memeriksa ulang semua sertifikat HTTPS kami dari sensor Rusia:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Anda dapat memperbarui indikator menggunakan modul klien kami, bahkan tanpa modul tersebut, hanya melalui curl.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Anda dapat memperbarui indikator langsung dari program Anda. Misalnya mengirimkan sinyal detak jantung agar okerr mengetahui sedang berjalan dan membunyikan alarm jika crash atau macet. Omong-omong, komponen okerr melakukan hal itu - okerr memonitor dirinya sendiri, dan masalah di hampir semua modul akan terdeteksi dan menghasilkan peringatan tentang masalah tersebut. (Dan dalam kasus ini "hampir" - mereka diperiksa silang dari server lain)

Berikut kode (yang disederhanakan) di bot telegram kami:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Terdapat perpustakaan untuk memperbarui indikator dari program Python okerrperbarui, untuk bahasa lain tidak ada perpustakaan, tetapi Anda dapat memanggil skrip okerrupdate atau membuat permintaan HTTP ke server okerr.

Bagaimana okerr membantu kita

Okerr mengubah hidup kami. Memang. Mungkin sistem pemantauan lain dapat melakukan hal yang sama, namun bekerja dengan okerr mudah dan sederhana bagi kami dan memiliki semua fungsi yang kami perlukan (kami menambahkan apa yang tidak dimilikinya). Omong-omong, jika ada beberapa fitur yang hilang, tanyakan dan saya akan menambahkannya (saya tidak berjanji, tapi saya ingin okerr menjadi sistem pemantauan terbaik untuk proyek kecil-menengah). Atau lebih baik lagi, tambahkan sendiri - mudah.

Kami berhasil hidup dengan prinsip “belajar semua masalah dari kerra.” Jika tiba-tiba terjadi masalah yang tidak kita ketahui dari okerr, kita tambahkan tanda centang pada okerr. (dalam hal ini, yang saya maksud dengan “kami” adalah kami sebagai pengguna sistem, bukan rekan pengembang). Awalnya hal ini biasa terjadi, namun sekarang menjadi sangat jarang.

Pemantauan

Melalui okerr kami memantau ukuran log di semua server. Tentu saja, tidak mungkin untuk membaca setiap baris log dengan mata Anda, tetapi sekadar memantau tingkat pertumbuhan sudah memberikan banyak manfaat. Melalui ini, kami menemukan surat spam dan pencarian kata sandi secara paksa, dan ketika beberapa aplikasi "menjadi gila", ada sesuatu yang tidak berhasil bagi mereka dan mereka mengulanginya lagi dan lagi (setiap kali menambahkan beberapa baris ke log ).

Sertifikat SSL. Hampir segera setelah peluncuran Mari Enkripsi pelanggan kami mulai memberikan sertifikat SSL gratis kepada kliennya (sekitar seribu di antaranya). Dan ternyata administrasinya sangat buruk! Faktanya adalah bahwa situs itu "hidup", klien secara berkala meminta mereka melakukan sesuatu, pemrogram melakukannya. Mereka dapat dengan bebas mentransfer situs tersebut ke DocumentRoot lain, misalnya. Atau tambahkan Penulisan Ulang tanpa syarat ke konfigurasi virtualhost. Tentu saja, setelah ini, pembaruan otomatis sertifikat gagal. Sekarang kami memiliki semua host SSL yang ditambahkan ke okerr secara otomatis melalui utilitas berguna lainnya dari paket a2conf. Luncurkan saja a2okerr.py — dan jika beberapa situs baru muncul di server, otomatis akan muncul di okerr. Jika tiba-tiba karena suatu hal sertifikat tidak diperpanjang, tiga minggu sebelum masa berlaku sertifikat habis, kami mengetahuinya, dan kami akan mencari tahu mengapa tidak diperbarui, seperti anjing. a2certbot.py dari paket yang sama - ini sangat membantu dalam hal ini (ia segera memeriksa masalah yang paling mungkin terjadi - dan menulis apa yang telah diperiksa dengan baik, dan di mana kemungkinan besar ada masalah).

Kami memantau tanggal kedaluwarsa semua domain kami. Dan semua server email kami yang mengirim email juga diperiksa berdasarkan 50+ daftar hitam berbeda. (Dan terkadang mereka terjerumus ke dalamnya). Ngomong-ngomong, tahukah Anda kalau server email Google juga masuk daftar hitam? Hanya untuk pengujian mandiri, kami menambahkan mail-wr1-f54.google.com ke server yang dipantau, dan masih ada dalam daftar hitam SORBS! (Ini tentang nilai “anti-spammer”)

Cadangan - Saya sudah menulis di atas betapa mudahnya memantaunya dengan okerr. Namun kami memantau cadangan terbaru di server kami dan (menggunakan utilitas terpisah yang menggunakan okerr) cadangan yang kami unggah ke Amazon Glacier. Dan ya, masalah terjadi dari waktu ke waktu. Tidak heran mereka menonton.

Kami menggunakan indikator eskalasi. Ini menunjukkan jika beberapa masalah sudah lama tidak diperbaiki. Dan saya sendiri, ketika saya menyelesaikan beberapa masalah, terkadang saya bisa melupakannya. Eskalasi adalah pengingat yang baik, bahkan jika Anda memantau diri sendiri.

Secara keseluruhan, saya yakin kualitas pekerjaan kami telah meningkat pesat. Hampir tidak ada downtime (atau klien tidak punya waktu untuk menyadarinya. Ssst!), sementara jumlah pekerjaan menjadi lebih kecil dan kondisi kerja menjadi lebih tenang. Kami telah beralih dari pekerjaan darurat dengan menambal lubang dengan selotip ke pekerjaan yang tenang dan terukur, ketika banyak masalah telah diprediksi sebelumnya dan ada waktu untuk mencegahnya. Bahkan masalah yang pernah terjadi juga menjadi lebih mudah untuk diperbaiki: pertama, kita mengetahuinya sebelum klien panik, dan kedua, sering kali masalahnya terkait dengan pekerjaan baru-baru ini (saat saya melakukan satu hal, saya merusak hal lain) - jadi panas. Lebih mudah bagi jejak untuk mengatasinya.

Tapi ada kasus lain...

Tahukah Anda bahwa di Debian 9 (Stretch) yang populer, paket populer seperti phpmyadmin masih (selama berbulan-bulan!) dalam status rentan? (CVE-2019-6798). Ketika kerentanan muncul, kami segera menutupinya dengan berbagai cara. Namun saya mengatur pemantauan halaman pelacak keamanan di okerr untuk mengetahui kapan solusi "indah" akan keluar (melalui jumlah konten SHA1). Indikatornya membuat saya berkedut beberapa kali, halamannya berubah, tetapi seperti yang Anda lihat, indikator tersebut masih (sejak Januari 2019!) tidak menunjukkan bahwa masalahnya telah teratasi. Mungkin ngomong-ngomong, ada yang tahu apa masalahnya paket penting seperti itu masih rentan selama lebih dari setahun?

Lain waktu dalam situasi serupa: setelah kerentanan di SSH, semua server perlu diperbarui. Dan saat Anda menetapkan tugas, Anda perlu mengontrol eksekusi. (Bawahan cenderung salah paham, lupa, bingung, dan melakukan kesalahan). Oleh karena itu, pertama-tama kami menambahkan pemeriksaan versi SSH ke okerr di semua server, dan melalui okerr kami memastikan bahwa pembaruan diluncurkan di semua server. (Nyaman! Saya memilih jenis indikator ini, dan Anda dapat langsung melihat server mana yang memiliki versi berapa). Ketika kami yakin bahwa tugas telah selesai di semua server, kami menghapus indikatornya.

Beberapa kali ada situasi ketika masalah tertentu muncul dan kemudian hilang dengan sendirinya. (mungkin familiar bagi semua orang?). Pada saat Anda menyadarinya, pada saat Anda memeriksa—dan tidak ada yang perlu diperiksa—semuanya sudah berfungsi dengan baik. Tapi kemudian rusak lagi. Hal ini misalnya terjadi pada produk yang kami unggah ke Amazon Marketplace (MWS). Pada titik tertentu, persediaan yang dimuat salah (jumlah barang salah dan harga salah). Kami menemukan jawabannya. Namun untuk mengetahuinya, penting untuk segera mengetahui masalahnya. Sayangnya, MWS, seperti semua layanan Amazon, sedikit lambat, jadi selalu ada jeda, namun tetap saja, kami setidaknya dapat memahami secara kasar hubungan antara masalah dan skrip yang menyebabkannya (kami melakukan pengecekan, macet ke okerr, dan memeriksanya segera menerima peringatan).

Kasus menarik baru-baru ini ditambahkan ke koleksi oleh hoster Eropa yang besar dan mahal, yang digunakan oleh pelanggan kami. Tiba-tiba, SEMUA server kami menghilang dari radar! Pertama, pelanggan itu sendiri (lebih cepat dari okerra!) menyadari bahwa situs tempat dia bekerja tidak dibuka dan membuat tiket tentang hal itu. Tapi bukan hanya satu situs yang down, tapi semuanya! (Natasha, kami meninggalkan semuanya!). Disini Okerr mulai mengirimkan foot wrap panjang dengan semua indikator yang menyala untuknya. Panik, panik, kita berlari berputar-putar (apa lagi yang bisa kita lakukan?). Lalu semuanya bangkit. Ternyata ada pemeliharaan rutin di data center (setiap beberapa tahun sekali) dan tentunya kita patut diperingatkan. Tapi ada masalah yang terjadi pada mereka dan mereka tidak memperingatkan kita. Semakin banyak serangan jantung, semakin sedikit serangan jantung. Tapi setelah semuanya dipulihkan, Anda perlu memeriksa ulang semuanya! Saya tidak dapat membayangkan bagaimana saya akan melakukannya dengan tangan saya. Okerr menguji semuanya dalam beberapa menit. Ternyata sebagian besar server tidak tersedia untuk sementara waktu, tetapi berfungsi. Ada yang kelebihan beban, tapi juga berdiri sebagaimana mestinya. Dari semua kerugian tersebut, kami kehilangan dua cadangan, yang menurut mahkota seharusnya dibuat dan dimuat saat pisang penuh ini sedang berjalan. Saya bahkan tidak repot-repot membuatnya, hanya sehari kemudian muncul peringatan bahwa semuanya baik-baik saja, cadangan telah muncul. Saya sangat menyukai contoh ini karena okerr ternyata sangat berguna dalam situasi yang bahkan tidak terpikirkan sebelumnya, namun itulah tujuan pemantauan - untuk melawan hal-hal yang tidak dapat diprediksi.

Untuk sensor Okerr, kami menggunakan hosting termurah (yang kualitas dan keandalannya tidak penting, keduanya saling menjamin). Jadi, baru-baru ini kami menemukan hosting yang sangat bagus dan super murah, tolok ukurnya luar biasa. Tapi...terkadang ternyata koneksi keluar dari mesin virtual dibuat dari IP lain (tetangga). Keajaiban. Modul Client_ip dengan https://diagnostic.opendns.com/myip mendapat IP yang salah. Dan dari log server indikatornya terlihat jelas bahwa pembaruan juga berasal dari IP tetangga ini. Mari kita tangani dukungannya sekarang. Ada baiknya kita memperhatikan hal ini di masa damai. Namun, misalnya, sering kali akses didaftarkan sesuai dengan daftar putih IP - dan jika server terkadang berkedip seperti ini untuk waktu yang singkat - Anda dapat mencoba mengatasi masalah ini untuk waktu yang sangat lama.

Satu hal lagi – karena kita berbicara tentang hosting VPS – kami selalu menggunakan yang murah (hetzner, ovh, scaleway). Saya sangat menyukainya baik dari segi benchmark dan stabilitas. Kami juga menggunakan Amazon EC2 yang jauh lebih mahal untuk proyek lainnya. Jadi, berkat okerr, kami memiliki opini yang terinformasi. Mereka berdua jatuh. Dan saya tidak akan mengatakan bahwa dalam jangka waktu pengamatan kami yang panjang, hosting murah seperti hetzner ternyata kurang stabil dibandingkan EC2. Oleh karena itu, jika Anda tidak terikat dengan fitur Amazon lainnya, mengapa harus membayar lebih? 🙂

Apa selanjutnya?

Jika pada tahap ini saya belum membuat Anda takut dari Okerr, cobalah! Anda bisa langsung menuju tautan ini akun demo oke (Klik sekarang!) Namun perlu diingat bahwa hanya ada satu akun demo untuk semua orang, jadi jika Anda melakukan sesuatu, orang lain di akun yang sama mungkin mengganggu Anda pada saat yang bersamaan. Atau (lebih baik) mendaftar melalui tautan ke di luar lokasi okerr - semuanya sederhana, tanpa SMS. Jika Anda tidak suka menggunakan email asli, Anda dapat menggunakan email sekali pakai, seperti mailinator (saya sarankan getnada.com). Akun tersebut mungkin akan dihapus seiring berjalannya waktu, tetapi akun tersebut akan baik-baik saja untuk pengujian.

Setelah registrasi, Anda akan diminta untuk menjalani pelatihan (melakukan beberapa tugas pelatihan yang tidak terlalu sulit). Batasan awalnya sangat kecil, tetapi untuk pelatihan atau satu server sudah cukup. Setelah menyelesaikan pelatihan, batasannya (misalnya, jumlah maksimum indikator) akan ditingkatkan.

Dari dokumentasi - pertama-tama WIKI di sisi server dan di klien (okerr perbarui wiki). Namun jika ada yang kurang jelas, tulis ke support (at) okerr.com atau tinggalkan tiket - kami akan mencoba menyelesaikan semuanya dengan cepat.

Jika Anda menggunakannya dengan serius dan peningkatan batas ini tidak cukup, tulis ke dukungan dan kami akan meningkatkannya (gratis).

Apakah Anda ingin menginstal server oker di server Anda? Di Sini repositori okerr-dev. Kami merekomendasikan penginstalan pada mesin virtual yang bersih, lalu Anda cukup melakukannya dengan skrip penginstalan. Di mesin virtual Anda - tidak ada batasan :-). Nah, sekali lagi, jika terjadi sesuatu, kami akan selalu berusaha membantu.

Kami ingin proyek ini berjalan lancar, sehingga dunia menjadi lebih dapat diandalkan berkat kami. Berkat perangkat lunak dan layanan gratis, dunia menjadi lebih bersahabat dan berkembang lebih dinamis. Sumber dapat disimpan di github gratis, untuk email Anda dapat menggunakan gmail gratis. Kami menggunakan gratis pekerjaan baru untuk dukungan. Untuk semua ini, Anda tidak perlu membayar server, Anda tidak perlu mengunduh dan mengkonfigurasi, dan Anda tidak perlu menyelesaikan berbagai masalah operasional. Setiap proyek baru, setiap tim segera memiliki email, repositori, dan CRM. Dan semua ini berkualitas sangat tinggi dan gratis dan segera. Kami ingin hal yang sama untuk pemantauan - perusahaan dan proyek kecil dapat menggunakan okerr secara gratis dan bahkan pada tahap kelahiran dan pertumbuhan memiliki keandalan proyek dewasa yang serius.

Sumber: www.habr.com

Ikhtisar sistem pemantauan hibrida Okerr