Cara menggunakan ApsaraDB for MongoDB untuk menyimpan dan menganalisis log - ApsaraDB for MongoDB

Layanan online menghasilkan sejumlah besar log operasional dan log akses yang berisi informasi tentang kesalahan, peringatan, serta perilaku pengguna. Biasanya, log disimpan dalam file teks yang dapat dibaca untuk mempermudah identifikasi masalah dalam rutinitas O&M. Namun, ketika layanan menghasilkan volume log yang besar, diperlukan pendekatan penyimpanan dan analisis yang lebih canggih guna mendapatkan wawasan berharga dari data tersebut.

Topik ini menjelaskan cara menggunakan ApsaraDB for MongoDB untuk menyimpan dan menganalisis log akses layanan web, sehingga memaksimalkan nilai dari log-log tersebut. Metode dan operasi yang dijelaskan juga berlaku untuk jenis layanan penyimpanan log lainnya.

Log akses server web

Contoh berikut menunjukkan entri log akses dari server web, mencakup informasi seperti sumber akses, nama pengguna, URL sumber daya yang diakses, hasil akses, sistem operasi, dan jenis browser.

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "[http://www.example.com/start.html](http://www.example.com/start.html)" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Anda dapat menggunakan ApsaraDB for MongoDB untuk menyimpan setiap log akses dalam satu dokumen dengan format berikut:

{
            _id: ObjectId('4f442120eb03305789000000'),
            line: '127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "[http://www.example.com/start.html](http://www.example.com/start.html)" "Mozilla/4.08 [en] (Win98; I ;Nav)"'
            }

Format ini mudah dikonfigurasi, tetapi kurang optimal untuk analisis data karena ApsaraDB for MongoDB bukan layanan yang dirancang khusus untuk analisis teks. Oleh karena itu, kami merekomendasikan Anda mengonversi format log untuk mengekstraksi setiap bidang dan nilainya sebelum menyimpan log di ApsaraDB for MongoDB sebagai dokumen. Contoh kode berikut menunjukkan bagaimana log sebelumnya dikonversi menjadi bidang dan nilai terpisah:

{
            _id: ObjectId('4f442120eb03305789000000'),
            host: "127.0.0.1",
            logname: null,
            user: 'frank',
            time: ISODate("2000-10-10T20:55:36Z"),
            path: "/apache_pb.gif",
            request: "GET /apache_pb.gif HTTP/1.0",
            status: 200,
            response_size: 2326,
            referrer: "[http://www.example.com/start.html](http://www.example.com/start.html)",
            user_agent: "Mozilla/4.08 [en] (Win98; I ;Nav)"
            }

Saat mengonversi format log, Anda dapat menghapus bidang-bidang yang tidak relevan dengan analisis data untuk menghemat ruang penyimpanan. Misalnya, Anda dapat menghapus bidang user, request, status, dan waktu karena informasi waktu sudah tersedia di bidang _id. Namun, jika diperlukan, Anda bisa mempertahankan bidang waktu untuk mempermudah penulisan pernyataan SQL. Kami juga merekomendasikan pemilihan tipe data yang membutuhkan ruang penyimpanan lebih kecil. Berdasarkan pertimbangan ini, konten berikut yang telah diperbarui dapat disimpan dalam dokumen:

{
            _id: ObjectId('4f442120eb03305789000000'),
            host: "127.0.0.1",
            time: ISODate("2000-10-10T20:55:36Z"),
            path: "/apache_pb.gif",
            referer: "[http://www.example.com/start.html](http://www.example.com/start.html)",
            user_agent: "Mozilla/4.08 [en] (Win98; I ;Nav)"
            }

Tulis log ke ApsaraDB for MongoDB

Untuk mengumpulkan sejumlah besar log secara efisien, Anda dapat menentukan write concern untuk ApsaraDB for MongoDB guna mengelola operasi tulis. Sebagai contoh, Anda dapat menentukan write concern berikut:

db.events.insert({
                host: "127.0.0.1",
                time: ISODate("2000-10-10T20:55:36Z"),
                path: "/apache_pb.gif",
                referer: "[http://www.example.com/start.html](http://www.example.com/start.html)",
                user_agent: "Mozilla/4.08 [en] (Win98; I ;Nav)"
                },
                {
                 writeConcern:{w: 0} 
                }
                )

Catatan

Jika Anda membutuhkan throughput tulis tertinggi, atur opsi w dari write concern menjadi {w: 0}.
Jika log berisi informasi penting seperti kredensial penagihan layanan, atur opsi w dari write concern menjadi {w: 1} atau {w: "majority"}, yang lebih aman daripada {w: 0}.

Untuk meningkatkan efisiensi operasi tulis, Anda dapat menulis beberapa log ke ApsaraDB for MongoDB dalam satu permintaan. Format permintaannya adalah sebagai berikut:

db.events.insert([doc1, doc2, ...])

Kueri log di ApsaraDB for MongoDB

Setelah menggunakan metode sebelumnya untuk menyimpan log di ApsaraDB for MongoDB, Anda dapat mengkueri log sesuai kebutuhan.

Kueri log semua permintaan untuk mengakses /apache_pb.gif. q_events = db.events.find({'path': '/apache_pb.gif'})
Catatan
Jika Anda sering melakukan kueri ini, buat indeks pada bidang path untuk meningkatkan efisiensi kueri. Contoh: db.events.createIndex({path: 1}).
Kueri log semua permintaan dalam satu hari.
```
q_events = db.events.find({'time': { '$gte': ISODate("2016-12-19T00:00:00.00Z"),'$lt': ISODate("2016-12-20T00:00:00.00Z")}})
```
Catatan
Buat indeks pada bidang waktu untuk meningkatkan efisiensi kueri. Contoh: db.events.createIndex({time: 1}).
Kueri log semua permintaan yang dikirim ke server selama periode waktu tertentu.
```
q_events = db.events.find({
                'host': '127.0.0.1',
                'time': {'$gte': ISODate("2016-12-19T00:00:00.00Z"),'$lt': ISODate("2016-12-20T00:00:00.00Z" }
                })
                    
```
Selain itu, Anda dapat menggunakan pipeline agregasi atau kerangka MapReduce yang disediakan oleh ApsaraDB for MongoDB untuk menjalankan kueri kompleks guna analisis data. Kami merekomendasikan pembuatan indeks pada bidang yang relevan untuk meningkatkan efisiensi kueri.

Pembagian data (sharding)

Seiring bertambahnya jumlah node layanan yang menghasilkan log, kemampuan tulis dan penyimpanan layanan penyimpanan log diuji, dan tingkat kemampuan yang lebih tinggi diperlukan. Dalam hal ini, Anda dapat menggunakan metode sharding dari ApsaraDB for MongoDB untuk mendistribusikan data log di beberapa shard. Saat menggunakan metode sharding, fokus utama adalah pemilihan kunci shard.

Gunakan bidang yang menunjukkan timestamp sebagai kunci shard, misalnya bidang _id atau waktu. Namun, jenis sharding ini dapat menyebabkan masalah berikut:
- Seiring bertambahnya timestamp secara berurutan, data log baru yang dikumpulkan didistribusikan ke shard yang sama, sehingga kemampuan tulis ApsaraDB for MongoDB tidak meningkat.
- Banyak kueri menargetkan data log terbaru, yang hanya didistribusikan ke beberapa shard. Dalam hal ini, hanya statistik terkait shard-shard tersebut yang dikembalikan untuk kueri-kueri tersebut.
Gunakan metode sharding hash: Kunci shard default dari sharding hash diatur ke bidang _id. Metode ini mendistribusikan data log secara merata ke setiap shard, sehingga kemampuan tulis ApsaraDB for MongoDB meningkat secara linear dengan bertambahnya shard. Namun, sharding hash mendistribusikan data secara acak, menyebabkan ApsaraDB for MongoDB tidak dapat menangani permintaan kueri rentang tertentu (biasanya untuk analisis data) dengan efisien. Untuk menangani permintaan semacam itu, ApsaraDB for MongoDB perlu melintasi semua shard dan menggabungkan data yang dikueri untuk mengembalikan hasil akhir.
Gunakan metode sharding rentang: Sebagai contoh, nilai-nilai bidang path dalam contoh sebelumnya didistribusikan secara merata dan banyak kueri dilakukan berdasarkan bidang path. Dalam hal ini, Anda dapat menentukan bidang path sebagai kunci shard untuk membagi data menjadi rentang yang berdekatan. Metode ini memiliki keuntungan berikut:
- Permintaan tulis didistribusikan secara merata ke setiap shard.
- Permintaan kueri berdasarkan bidang path didistribusikan secara padat ke satu atau lebih shard, meningkatkan efisiensi kueri.
Namun, metode ini memiliki kekurangan berikut:
- Jika nilai bidang path sering diakses, log yang memiliki nilai kunci shard yang sama kemungkinan besar akan disimpan di chunk atau shard yang sama. Nilai tersebut diakses dengan frekuensi tinggi dan ukuran chunk mungkin besar.
- Jika bidang path memiliki sedikit nilai, ini dapat mengakibatkan distribusi data yang tidak merata di seluruh shard.
Untuk memperbaiki masalah ini, Anda dapat menambahkan bidang tambahan ke kunci shard. Sebagai contoh, nilai kunci shard asli adalah {path: 1}. Dalam hal ini, Anda dapat menambahkan bidang ssk ke kunci shard. Nilai kunci shard baru adalah {path: 1, ssk: 1}.
Anda dapat memberikan nilai acak ke bidang ssk, seperti nilai hash dari bidang _id, atau memberikan timestamp ke bidang ssk. Dalam hal ini, nilai kunci shard yang memiliki nilai path yang sama diurutkan berdasarkan waktu.
Dengan demikian, kunci shard memiliki beberapa nilai dengan frekuensi yang merata. Tidak ada nilai kunci shard yang berada pada frekuensi sangat tinggi. Setiap metode sharding sebelumnya memiliki kelebihan dan kompromi tersendiri. Anda dapat memilih metode berdasarkan kebutuhan bisnis Anda.

Solusi untuk pertumbuhan data

ApsaraDB for MongoDB menyediakan fitur sharding untuk menyimpan sejumlah besar data. Namun, biaya penyimpanan meningkat seiring dengan pertumbuhan volume data. Dalam kebanyakan kasus, nilai data log menurun seiring waktu. Data yang dihasilkan satu tahun lalu atau bahkan tiga bulan lalu, yang tidak bernilai untuk analisis, perlu dibersihkan untuk mengurangi biaya penyimpanan. ApsaraDB for MongoDB memungkinkan Anda menggunakan solusi berikut untuk memenuhi kebutuhan tersebut.

Gunakan indeks TTL: Indeks Time to live (TTL) adalah indeks single-field khusus yang dapat digunakan ApsaraDB for MongoDB untuk secara otomatis menghapus dokumen dari koleksi setelah periode waktu tertentu. Dalam contoh sebelumnya, bidang waktu menunjukkan waktu saat permintaan dikirim. Anda dapat menjalankan perintah berikut untuk membuat indeks TTL pada bidang waktu dan menentukan bahwa ApsaraDB for MongoDB menghapus dokumen setelah 30 jam: db.events.createIndex( { time: 1 }, { expireAfterSeconds: 108000 } ).
Catatan
Secara default, tugas latar belakang yang menghapus dokumen kedaluwarsa dalam mode single-threading berjalan setiap 60 detik setelah Anda membuat indeks TTL. Jika sejumlah besar data log ditulis ke ApsaraDB for MongoDB, banyak dokumen di ApsaraDB for MongoDB akan kedaluwarsa seiring waktu. Dokumen kedaluwarsa yang tidak dihapus menempati ruang penyimpanan yang besar.
Gunakan koleksi capped: Jika Anda tidak memiliki batasan ketat pada periode penyimpanan, tetapi ingin membatasi ruang penyimpanan, Anda dapat menggunakan koleksi capped untuk menyimpan data log. Koleksi capped bekerja dengan cara berikut: Jika Anda menentukan ruang penyimpanan maksimum atau jumlah maksimum dokumen yang disimpan untuk koleksi capped dan salah satu batas yang ditentukan tercapai, ApsaraDB for MongoDB secara otomatis menghapus dokumen terlama dalam koleksi. Sebagai contoh, Anda dapat menjalankan perintah berikut untuk membuat dan mengonfigurasi koleksi capped: db.createCollection("event", {capped: true, size: 104857600000}.
Arsipkan dokumen berdasarkan koleksi atau database secara berkala: Di akhir bulan, Anda dapat mengganti nama koleksi yang menyimpan dokumen bulan tersebut dan membuat koleksi lain untuk menyimpan dokumen bulan berikutnya. Kami merekomendasikan Anda menambahkan informasi tentang tahun dan bulan ke nama koleksi. Contoh berikut menunjukkan bagaimana 12 koleksi yang menyimpan dokumen yang ditulis di setiap bulan tahun 2016 dinamai:
```
events-201601
                events-201602
                events-201603
                events-201604
                ....
                events-201612
                    
```
Jika Anda harus membersihkan dokumen bulan tertentu, Anda dapat menjalankan perintah berikut untuk langsung menghapus koleksi yang sesuai:
```
 db["events-201601"].drop()
                db["events-201602"].drop()
                    
```
Jika Anda ingin mengkueri dokumen dari beberapa bulan, pernyataan kueri mungkin rumit karena ApsaraDB for MongoDB perlu menggabungkan data yang dikueri dari beberapa koleksi untuk mengembalikan hasil akhir.