Clever Geek Handbook

Praktik Terbaik untuk Pencatatan Aplikasi Perusahaan (Dari Perspektif Teknisi Dukungan)



Log aplikasi mengungkapkan informasi tentang peristiwa eksternal dan internal yang dilihat aplikasi selama eksekusi. Saat bug, peretasan, atau anomali terjadi selama penerapan, log adalah bukti paling berguna dan andal untuk menganalisis penyebab insiden.



Mari kita lihat bagaimana menulis pesan berguna di jurnal yang akan disukai semua orang.



1. Apa yang harus dicatat



Pesan masuk dan keluar



Jika komponen berinteraksi satu sama lain menggunakan pesan, maka Anda perlu merekam pesan masuk dan keluar yang menunjukkan URL titik akhir API, parameter permintaan, permintaan IP awal dan menengah, header permintaan, informasi tentang penulis, badan permintaan dan respons, konteks bisnis , stempel waktu, dan langkah pemrosesan internal.



Sangat penting bahwa setiap pesan diberi pengenal unik (biasanya dibuat di manajer API atau tingkat layanan). Ini diperlukan untuk melacak pertukaran pesan antar layanan dalam sistem.



Layanan dan fungsi panggilan



Saat memanggil layanan atau fungsi, diinginkan untuk mencatat konteksnya secara lebih detail, terutama untuk debugging (gunakan TRACE atau DEBUG). Log ini akan membantu Anda memecahkan masalah logika bisnis, terutama jika Anda tidak memiliki hak istimewa untuk memasang debugger ke aplikasi (misalnya, saat menerapkan ke lingkungan pengujian, staging, atau pra-produksi).



Tindakan pengguna dan statistik bisnis



Setiap aplikasi memiliki skenario bisnis unik dan perjalanan pengguna yang memberikan banyak informasi kepada para profesional khusus. Misalnya, apakah transaksi tertentu memakan waktu terlalu lama, atau apakah pengguna terjebak pada beberapa fungsi - semua ini adalah data yang sangat penting dari sudut pandang pengalaman pengguna. Informasi lain yang terkait dengan bisnis - jumlah transaksi dan pengguna aktif, serta tahapannya - penting untuk menemukan hubungan sebab akibat, dan bahkan dapat digunakan dalam analisis bisnis.



Operasi Data (Jejak Audit)



Untuk alasan keamanan dan kepatuhan, sebagian besar aplikasi perusahaan memerlukan log transaksi terpisah dengan semua informasi penting seperti ID akses (pengguna dan sistem), contoh layanan yang tepat dan hak istimewa peran yang digunakan, stempel waktu, permintaan data, snapshot dan status baru dari data yang diubah (diff). Jejak audit harus merekam semua operasi dengan data (akses, impor, ekspor, dll.), Serta operasi CRUD (buat, baca, perbarui, hapus) yang dilakukan oleh pengguna, sistem dan layanan lain.



Peristiwa sistem



Ini termasuk informasi tentang perilaku (mulai, berhenti, restart dan peristiwa terkait keselamatan), mode sementara (dingin, pemanasan, panas), komunikasi antar-layanan (jabat tangan, status pembentukan koneksi - terhubung, terputus, terhubung kembali, coba lagi), pengidentifikasi instance layanan, secara aktif melayani API, secara aktif mendengarkan pada rentang IP dan port, konfigurasi yang dimuat (bootstrap dan pembaruan dinamis), status layanan keseluruhan, dan hal lain yang dapat membantu Anda memahami perilaku sistem.



Statistik kinerja



Ketekunan adalah karakteristik hebat dari perangkat komputasi, tetapi mungkin tidak berfungsi dengan sempurna. Setiap saat, mungkin ada masalah kinerja atau penurunan tiba-tiba yang tidak terduga dalam layanan (kebanyakan karena kesalahan yang tidak tertangani dan data yang rusak). Untuk menentukan ini, selalu disarankan untuk mempublikasikan statistik tentang kesehatan dan kinerja sistem secara keseluruhan. Ini dapat berisi informasi seperti penghitung panggilan API (berhasil dan gagal), latensi jaringan, durasi pulang-pergi rata-rata, konsumsi memori, dan informasi khusus aplikasi lainnya (biasanya ditentukan oleh konteks bisnis).



Ancaman dan kerentanan



Mengungkapkan ancaman dan kerentanan dengan aplikasi dan log waktu proses adalah seni yang harus dikuasai oleh setiap pengembang perangkat lunak perusahaan. Peretasan dan gangguan biasanya tidak terjadi secara tiba-tiba. Paling sering, ada tanda-tanda yang pada awalnya tidak diperhatikan oleh siapa pun. Oleh karena itu, Anda harus selalu mencatat aktivitas manusia yang mencurigakan (misalnya, upaya yang keliru pada otentikasi dan verifikasi dengan penerapan semua informasi tingkat rendah seperti jaringan yang digunakan, sumber permintaan, peran pengguna dan hak istimewa), serta perilaku sistem (misalnya, peningkatan puncak dalam pola konsumsi sumber daya, beban tinggi pada server web, kegagalan layanan sesekali). Saat Anda melihat peristiwa yang mencurigakan, pastikan log berisi semua informasi yang terkait dengannya. Sempurna,sehingga ini merupakan pelacakan tumpukan penuh dengan nilai parameter dan informasi tambahan yang diperoleh dari konteks aplikasi.



2. Apa yang tidak perlu Anda catat



Informasi pribadi



Hampir semua undang-undang privasi (misalnya GDPR, CCPA) secara eksplisit merekomendasikan pengembang untuk tidak mencatat informasi identitas pribadi. Ini termasuk nama, julukan, jenis kelamin, ulang tahun, alamat jalan, email, nomor telepon, nomor jaminan sosial, dan nomor kartu kredit.



Nama perusahaan dan informasi kontak



Pastikan Anda tidak menuliskan nama perusahaan, karyawan, pelanggan, informasi pemasok, atau informasi kontak perusahaan dan individu. Jurnal tidak boleh mengungkapkan hubungan bisnis dan transaksi dengan pihak ketiga. Untuk melacak transaksi tertentu, gunakan ID peristiwa yang dibuat sistem sebagai ganti nama asli dan teruskan ke layanan lain.



Data keuangan (rekening bank, detail kartu bank, jumlah yang dikirim, dll.)



Secara hukum, semua data keuangan harus dihapus atau disamarkan sepenuhnya. Pengungkapan informasi semacam itu di majalah dapat dengan mudah mengarah pada tindakan hukum yang serius (hingga pertanggungjawaban pidana). Hindari ini dengan segala cara.



Kata sandi, kunci keamanan dan rahasia, token otentikasi



Token kredensial dan otentikasi dianggap sebagai informasi rahasia, sehingga kehadirannya di log akan membantu penyerang dengan mudah menemukan lubang di sistem. Oleh karena itu, jangan biarkan data ini masuk ke dalam log.



Catatan: Anda akan mudah menentukan informasi apa yang disembunyikan dari log jika Anda menambahkan atribut ke setiap bidang yang menentukan tingkat visibilitas (misalnya, tampilkan, tutupi, sembunyikan, enkripsi). Jika Anda memiliki mekanisme seperti itu, Anda dapat mengubah visibilitas bidang hanya dengan memperbarui properti di konfigurasi. Ini adalah solusi yang baik jika Anda perlu mencatat beberapa informasi pengguna di lingkungan non-pertempuran, terutama untuk pengujian dan debugging. Atau, Anda dapat menulis parser yang memfilter log dan memproses bidang sensitif sesuai dengan petunjuk tertulis sebelumnya untuk lingkungan ini.



3. Praktik terbaik



Ketahui kapan harus menggunakan tingkat logging tertentu



Tingkat log digunakan untuk menunjukkan tingkat keparahan setiap elemen dalam sistem. Sebagian besar kerangka kerja logging memiliki level ini:



  • FATAL : kesalahan yang sangat serius yang kemungkinan besar akan menyebabkan aplikasi dihentikan. Ini biasanya berakhir dengan kegagalan yang serius.
  • EROR : kesalahan yang membuat aplikasi masih dapat terus bekerja, tetapi dengan penurunan kemampuan tertentu.
  • PERINGATAN : kejadian yang tidak terlalu berbahaya dibandingkan dengan kesalahan. Mereka biasanya tidak menurunkan atau merusak aplikasi. Tapi ini masih peristiwa penting yang perlu diselidiki.
  • INFO : spanduk acara penting dan pesan informasional dalam perilaku aplikasi.
  • DEBUG: , . .
  • TRACE: , , . .


Linux Syslog juga memiliki tingkatan yang lebih serius seperti Darurat, Peringatan, Kritis, Kesalahan, Peringatan, Pemberitahuan, Informasi, dan Debug.



Terlepas dari kerumitan dan kedalaman setiap tingkat pencatatan, kita harus mengonfigurasinya dengan benar dalam kode kita untuk memberikan jumlah informasi yang optimal di setiap skenario. Misalnya, semua data yang digunakan oleh pengembang untuk debugging dan analisis teknis harus berada di tingkat DEBUG atau TRACE, dan spanduk dengan data sistem harus berada di bawah INFO.



Gunakan Bahasa Inggris



Beberapa alat dan konsol tidak mendukung keluaran dan penyimpanan log dengan karakter Unicode tertentu. Oleh karena itu, pelokalan dan peningkatan lainnya bisa jadi sulit. Tetap gunakan bahasa Inggris dan selalu gunakan rangkaian karakter yang didukung secara luas untuk menulis pesan. 



2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all


Tambahkan pesan ramah pengembang (ringkas dan bermakna)



Jika ada terlalu sedikit pencatatan, kami tidak akan bisa mendapatkan informasi yang kami butuhkan untuk membuat ulang konteks setiap peristiwa penting. Dan jika Anda masuk terlalu banyak, itu akan menurunkan kinerja: menulis file log yang besar akan meningkatkan I / O dan konsumsi sumber daya penyimpanan disk. Jika sistem file tidak mendukungnya, itu akan mengurangi kinerja sistem secara keseluruhan.



Untuk mengoptimalkan pesan, Anda memerlukan pemahaman yang jelas tentang ekspektasi fungsional dan non-fungsional dari sistem dan perencanaan kualitas dan kuantitas pesan yang diinginkan. Setiap jurnal harus bermakna dan sesuai dengan konteks: selalu tulis dengan singkat dan langsung pada intinya. 



2020-11-11 13:52:27 DEBUG  Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERROR  Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)


Buat pengenal referensi, alias, dan templat yang disederhanakan untuk pesan yang sering digunakan dan panjang



Daripada menuliskan deskripsi lengkap setiap kali, coba buat pengenal referensi atau template yang disederhanakan untuk merepresentasikan deskripsi yang panjang dan berulang di log. Ini mengurangi jumlah dan panjang pesan, dan juga meningkatkan fleksibilitas untuk menyembunyikan informasi tertentu. Misalnya, daripada mendeskripsikan kerentanan dalam log teks, lebih baik menggunakan alias atau pengenal sehingga hanya pakar khusus yang dapat memahami skenario saat ini. 



2020-11-11 13:52:27 ERROR  DB:22 - Failed to write (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied" error message


Gunakan stempel waktu yang benar



Stempel waktu memungkinkan Anda memahami urutan peristiwa, yang diperlukan untuk debugging dan analisis. Saat mengatur waktu, disarankan untuk menggunakan nilai yang paling detail (misalnya, pada tingkat milidetik atau mikrodetik) sehingga lebih mudah untuk mengidentifikasi kejadian yang berdekatan. Pastikan juga bahwa stempel waktu berada di awal pesan dalam format tttt-bb-hh JJ: mm: dd. Selalu tentukan zona waktu Anda kecuali Anda menggunakan waktu default server (UTC). 



// with default server time (UTC)2020-11-11 13:52:12 INFO  XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO  XYZ Integration API Manager v2.0.0


Berikan sumber atau asal data log (untuk DEBUG, TRACE, ERROR)



Ini sangat berguna untuk mengidentifikasi dengan jelas lokasi yang mengarah ke pesan terkait. Beberapa kerangka kerja logging memungkinkan Anda menentukan sumber pada tingkat yang paling detail (sampai ke nama file dengan nomor baris), tetapi lebih sering daripada tidak, hanya menyebutkan kelas, fungsi, atau nama file sudah cukup. 



2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...


Setiap jurnal harus unik di dalam sistem



Kebanyakan pemula membuat kesalahan yang sama - mereka menyalin dan menempelkan contoh pesan di file yang berbeda, mengumpulkan log terakhir dari baris yang sama yang berasal dari berbagai bagian sistem. Dalam hal ini, sulit untuk melacak lokasi spesifik yang memicu peristiwa tersebut. Jika kumpulan kata tidak dapat diubah, setidaknya sebutkan sumber dalam pesan sehingga baris di file akhir berbeda satu sama lain. Selain itu, jika logging ditangani oleh kelas induk, kirimkan pengenal selama inisialisasi dan gunakan untuk merekam pesan tentang perilaku kelas anak. 



2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all


Tambahkan ID terlacak atau token pesan ke pesan



Saat sebuah peristiwa atau pesan memasuki sistem, biasanya diberikan pengenal unik. Ini dapat diteruskan ke tahap pemrosesan lain untuk melacak pergerakan suatu peristiwa melalui sistem, yang berguna untuk debugging, pemrosesan bersamaan, dan operasi berbasis data. Idealnya, sistem harus memiliki pengenal peristiwa unik dalam semua modul dan layanan. 



[87d4s-a98d7-9a8742jsd] Request Body: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "option_val": "IBM",
 "req_type_id": "0013",
 "data": {...........}
[87d4s-a98d7-9a8742jsd] Sending request to RefData: href="http://10.244.2.168:8280/v1


Cocokkan pengenal di titik transisi



Dalam kasus tertentu, terutama saat mentransmisikan peristiwa dari satu sistem ke sistem lain, pengenal berubah sesuai dengan konvensi yang diadopsi di sistem lain. Pada titik transisi seperti itu, perlu untuk secara eksplisit menunjukkan korespondensi antara pengenal lama dan baru dalam pesan terpisah, dengan tambahan konteks yang diperlukan. 



[1000508] ***** Incoming request from 10.244.2.168:3000 *****
[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508
[1000508] Transaction successfully added to Rabbit Queue


Tentukan pengenal untuk semua contoh layanan



Sebagian besar sistem perusahaan adalah platform komputasi terdistribusi di mana terdapat banyak contoh layanan yang sama dengan berbagai konfigurasi aplikasi, sumber daya, versi, dan properti jaringan. Anda disarankan untuk menetapkan pengenal ke instance dan menggunakannya untuk komunikasi antar-layanan. 



2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)


Konfigurasikan tingkat logging aktif



Tingkat logging aktif harus diubah tergantung pada lingkungan penerapan. Untuk produksi, disarankan untuk mengeluarkan log hingga level INFO. Di lingkungan lain, log dikeluarkan ke tingkat DEBUG atau TRACE, bergantung pada tingkat detail yang diperlukan oleh tim pengembangan dan operasi. 



// Active Log Level = DEBUG2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID APIM_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 05 (DEBUG)
2020-11-11 13:52:12 DEBUG  App:22 - Initializing Swagger UI..
2020-11-11 13:52:14 DEBUG  App:28 - Generating schemata..
2020-11-11 13:52:14 DEBUG  App:30 - Initializing REST services..
2020-11-11 13:52:15 DEBUG  App:32 - Generating documentation..
2020-11-11 13:52:18 DEBUG  App:36 - Loading adapters..
2020-11-11 13:52:21 DEBUG  Adapters:10 - Loading adapter docs/v1
2020-11-11 13:52:22 DEBUG  Adapters:16 - Loading adapter mongo/v1
2020-11-11 13:52:26 DEBUG  Docs:38 - docs adapter initialized
2020-11-11 13:52:27 DEBUG  Mongo:38 - mongo adapter initialized
2020-11-11 13:52:22 DEBUG  Adapters:20 - Successfully loaded all
2020-11-11 13:52:31 INFO  app - Started listening...// Active Log Level = INFO2020-11-11 13:52:12 INFO  app - XYZ Integration API Manager v2.0.0
2020-11-11 13:52:15 INFO  app - Loading configurations..
2020-11-11 13:52:18 INFO  app - *** InstanceID API_V2_I02
2020-11-11 13:52:18 INFO  app — *** BaseURL http://10.244.2.168:3000
2020-11-11 13:52:19 INFO  app - *** LogLevel 04 (INFO)
2020-11-11 13:52:31 INFO  app - Started listening...


Berikan Konteks yang Cukup untuk Error dan Error



Kesalahan dan kegagalan membutuhkan penyelidikan yang paling menyeluruh. Untuk melakukan ini, aplikasi harus menyediakan para ahli materi pelajaran dengan informasi yang mereka butuhkan, serta teknologi dan konteks bisnis. Misalnya, jika sebuah permintaan atau pesan tidak dapat diproses, sangat berguna untuk mencatat isi dari permintaan yang gagal selain kesalahannya. 



[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)[1000508] Failed Message: {
 "request_id": "87d4s-a98d7-9a8742jsd",
 "app_id": "TX001",
 "req_type_id": "0013",
 "data": {...........}
}


Cadangkan transaksi data dengan bukti (jangan berasumsi!)



Untuk setiap operasi data, jangan anggap remeh bahwa itu berhasil. Selalu periksa kondisi akhir dengan bukti. Misalnya, saat Anda membuat, memperbarui, atau menghapus rekaman dalam database, itu mengembalikan penghitung rekaman yang diubah dan rekaman yang diperbarui itu sendiri. Selalu periksa penghitung atau hasil yang diharapkan. Contoh lain: ketika Anda memasukkan record ke dalam struktur data (misalnya, ke dalam antrian), kemudian periksa apakah ukurannya bertambah. Misalkan sistem Anda menggunakan operasi bersamaan, tetapi antrian tidak mendukungnya. Kemudian Anda bisa kehilangan beberapa catatan, dan satu-satunya cara untuk mendeteksi kesalahan tersembunyi seperti itu dalam kode adalah dengan memeriksa panjangnya. 



DEBUG  BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts...DEBUG  BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24


Enkripsi atau tutupi data sensitif



Biasanya, undang-undang mewajibkan informasi rahasia pengguna dan sistem internal ditutup-tutupi dan / atau dienkripsi. Persyaratan peraturan mungkin berbeda-beda tergantung pada industri dan tempat kerja Anda. Temukan semua nuansa dan terapkan prosedur yang benar dalam aplikasi. Dalam beberapa kasus, Anda mungkin perlu mengirimkan strategi logging Anda ke layanan keamanan dan mendapatkan persetujuan atau sertifikasi mereka sebelum operasionalisasi. 



[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508[1000508] Request Body: {
”user_id”:”XXXXXXXXXX”,
”personal_details”:{
  ”firstName”:”XXXXXXXXXX”,
  ”lastName”:”XXXXXXXXXX”,
  ”DOB”:”XXXXXXXXXX”,
  ”gender”:”Male”,
  ”proffessional”:”Software Architect”,
  ”industry”:”IT”,
  ”SSN”:”XXXXXXXXXX”
},
”address_history”:[
  {”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”},
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”},  
  {”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”}
],
”card_info”:[
  {”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”},
  {”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}
]
}


Konfigurasikan penamaan file log, kebijakan rotasi, ukuran penyimpanan, dan prosedur pencadangan



Jika Anda menulis log ke file, pastikan bahwa log disimpan di disk terpisah yang tidak mempengaruhi aplikasi yang berjalan dengan cara apa pun (misalnya, Anda dapat mengalokasikan volume di server jauh dan melampirkannya ke server aplikasi). Juga cari tahu frekuensi penjurnalan dan bagaimana file tumbuh. Pastikan Anda memiliki kebijakan rotasi log dengan konvensi penamaan yang benar (misalnya, menambahkan stempel waktu ke nama saat membuat) untuk mempertahankan ukuran dan jumlah file yang ideal. Anda juga harus memiliki mekanisme untuk mencadangkan log lama ke tempat yang aman, dan mekanisme untuk membersihkan penyimpanan secara teratur. Bergantung pada industri Anda, Anda dapat menyiapkan cadangan berjangka waktu (biasanya setiap beberapa bulan atau tahun), menghancurkan semua file sebelumnya di akhir periode. 



[ec2-user@ip-XXX-XX-X-XXX logs]$ ls
..
APIM_V2_I02-2020-11-20_04:38:43.log
APIM_V2_I02-2020-11-23_02:05:35.log
APIM_V2_I02-2020-11-24_04:38:17.log
APIM_V2_I02-2020-11-27_03:28:37.log
APIM_V2_I02-2020-11-27_12:06:45.log
...


4.





Praktik yang sangat umum di antara pengembang aplikasi perusahaan adalah membuat server atau lokasi yang dapat diakses secara terpusat untuk mengumpulkan log. Biasanya, agregator melacak log tidak hanya dari aplikasi, tetapi juga dari perangkat dan sistem operasi (misalnya, Linux Syslog), jaringan, firewall, database, dll. Selain itu, mereka memisahkan file log dari server aplikasi dan memungkinkan Anda untuk menyimpan log lebih banyak. format terlindungi, teratur dan efisien untuk waktu yang lebih lama. Di beberapa industri (seperti perbankan dan keuangan), penting untuk menyimpan log di penyimpanan lokal dan pusat sehingga penyerang tidak dapat mengakses kedua tempat tersebut dan menghapus bukti aktivitas mereka pada saat yang bersamaan. Jadi redundansi data dan ketidakcocokan data antara dua penyimpanan dapat membantu menemukan gangguan.



Menulis parser dan melacak log dengan hati-hati



Kemampuan untuk menulis parser dan filter dibangun di sebagian besar alat pemantauan log - yang disebut integrasi informasi keamanan dan manajemen peristiwa (SIEM) . Pengurai membantu menjaga log dalam format yang lebih efisien, dan data kueri menjadi lebih mudah dan lebih cepat. Selain itu, data yang terorganisir dengan baik dapat ditransfer ke sistem pemantauan dan pencarian anomali untuk pemantauan proaktif dan memprediksi kejadian di masa depan. Alat ini sangat kuat dalam membuat grafik data berdasarkan deret waktu dan dalam waktu nyata.



Atur peringatan dan pemberitahuan push untuk insiden kritis



Hampir semua alat pemantauan log memungkinkan Anda menetapkan ambang batas tertentu untuk level tertentu. Ketika sistem mencapai nilai-nilai ini, alat akan mendeteksinya terlebih dahulu, membantu mencatat data, dan memberi tahu sysadmin melalui peringatan, API pemberitahuan push (seperti API Log Audit Slack ), email, dll. Mereka juga dapat dikonfigurasi sebelumnya untuk memulai proses otomatis. seperti penskalaan dinamis, backup sistem, load slinging, dan sebagainya. Tetapi jika Anda berinvestasi dalam perangkat lunak pemantauan log komersial, perhatikan baik-baik karena alat tersebut dapat berlebihan untuk sistem perangkat lunak berukuran kecil hingga menengah.



5. Alat yang direkomendasikan



Kerangka kerja logging



JavaScript / TypeScript: Log4js / pino

Java: Log4j

Golang: Logrus Serverless

-functions: aws-lambda-powertools-python / Menulis sendiri



Menjelajahi, Mengumpulkan, dan Memantau Log



Alat CLI: less, vim

Cloud tools: Fluentd, AWS CloudWatch

SIEM tools: SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar

Lainnya: ELK Stack (ElasticSearch, Logstash, Kibana, Beats), Loggly


More articles:


All Articles