Chen2021 en Id

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.
com
Survei Instrumentasi Log Perangkat Lunak
BOYUAN CHEN dan ZHEN MING (JACK) JIANG,Universitas York, Kanada
Pesan log telah digunakan secara luas di banyak sistem perangkat lunak untuk berbagai tujuan selama pengembangan
perangkat lunak dan operasi lapangan. Ada dua fase dalam logging perangkat lunak: instrumentasi log dan manajemen log.
Instrumentasi log mengacu pada praktik yang dilakukan pengembang untuk memasukkan kode logging ke dalam kode sumber
untuk merekam informasi runtime. Manajemen log mengacu pada praktik di mana operator mengumpulkan pesan log yang
dihasilkan dan melakukan teknik analisis data untuk memberikan wawasan berharga tentang perilaku runtime. Ada banyak
sumber terbuka dan alat manajemen log komersial yang tersedia. Namun, keefektifannya sangat bergantung pada kualitas kode
logging yang diinstrumentasi, karena pesan log yang dihasilkan oleh kode logging berkualitas tinggi dapat sangat memudahkan
proses berbagai tugas analisis log (misalnya pemantauan, diagnosis kegagalan, dan audit). Karenanya, dalam artikel ini, kami
melakukan survei sistematis tentang penelitian canggih tentang instrumentasi log dengan mempelajari 69 makalah antara tahun
1997 dan 2019. Secara khusus, kami berfokus pada tantangan dan solusi yang diusulkan yang digunakan dalam tiga langkah
instrumentasi log : (1) pendekatan penebangan; (2) integrasi utilitas logging; dan (3) komposisi kode logging. Survei ini akan
bermanfaat bagi para praktisi dan peneliti DevOps yang tertarik dengan logging perangkat lunak.
Konsep CCS: •Perangkat lunak dan rekayasanya→Pembuatan dan pengelolaan perangkat lunak;
Kata Kunci dan Frasa Tambahan: Survei sistematis, logging perangkat lunak, instrumentasi
Format Referensi ACM:

Boyuan Chen dan Zhen Ming (Jack) Jiang. 2021. Survei Instrumentasi Log Perangkat Lunak.komputasi ACM. Bertahan54,
4, Pasal 90 (April 2021), 34 halaman. https://doi.org/10.1145/3448976
1. PERKENALAN
Pencatatan perangkat lunak adalah praktik pemrograman umum yang digunakan pengembang untuk melacak
90
dan merekam perilaku runtime sistem perangkat lunak. Pencatatan perangkat lunak telah digunakan secara
luas untuk pemantauan [107,117], diagnosis kegagalan [55,127], analisis kinerja [54,75,99,115], analisis uji [45,
70], keamanan dan kepatuhan hukum [22,98,103], dan analitik bisnis [31,96].
Seperti yang ditunjukkan pada Gambar1, pencatatan perangkat lunak [48] terdiri dari dua fase: (1)
Instrumentasi Log, dan (2)Manajemen Log. Fase instrumentasi log, yang berkaitan dengan
pengembangan dan pemeliharaan kode logging, terdiri dari tiga langkah:Pendekatan Pencatatan,
Integrasi Logging Utility (LU)., danKode Logging (LC)Komposisi. Fase manajemen log, yang berfokus
pada pemrosesan pesan log yang dihasilkan setelah sistem diterapkan, terdiri dari tiga langkah:
Pembuatan Log,Koleksi Log, danAnalisis Log.
Alamat penulis: B. Chen dan ZM (Jack) Jiang, Universitas York, 4700 Keele St, Toronto, ON, Kanada M3J 1P3; email:
{chenfsd, zmjiang}@eecs.yorku.ca.
Izin untuk membuat salinan digital atau hard copy dari semua atau sebagian dari karya ini untuk penggunaan pribadi atau ruang kelas diberikan tanpa
biaya asalkan salinan tidak dibuat atau didistribusikan untuk keuntungan atau keuntungan komersial dan salinan memuat pemberitahuan ini dan
kutipan lengkap pada halaman pertama . Hak cipta untuk komponen karya ini dimiliki oleh orang lain selain ACM harus dihormati. Mengabstraksi
dengan kredit diperbolehkan. Untuk menyalin sebaliknya, atau menerbitkan ulang, untuk memposting di server atau untuk mendistribusikan ulang ke
daftar, memerlukan izin khusus sebelumnya dan/atau biaya. Minta izin daripermissions@acm.org. © 2021 Asosiasi Mesin Komputasi.
0360-0300/2021/04-ART90 $15.00
https://doi.org/10.1145/3448976
Survei Komputasi ACM, Vol. 54, No. 4, Pasal 90. Tanggal publikasi: April 2021.
90:2 B. Chen dan ZM (Jack) Jiang
Gambar 1. Keseluruhan proses software logging.
Ada banyak alat kekuatan industri yang sudah tersedia untuk membantu manajemen log yang efektif.
Misalnya, tumpukan ELK (Elasticsearch [6], Logstash [15], dan Kibana [11]) adalah platform yang sangat
populer untuk mengumpulkan, mencari, dan menganalisis log. Splunk [21], salah satu platform
manajemen log komersial paling populer, memberikan solusi terintegrasi untuk memantau dan
mengelola data telemetri yang kompleks. Menurut Gartner, pasar alat pengelolaan log diperkirakan
mencapai $1,5 miliar dan telah berkembang pesat setiap tahunnya [7].
Namun, efektivitas pengelolaan log sangat bergantung pada kualitas kode logging yang dihasilkan
dari fase instrumentasi log. Kode logging berkualitas rendah dapat menyebabkan masalah dalam
diagnosis masalah [129], upaya pemeliharaan yang tinggi [41,78,95], kinerja melambat [54], atau bahkan
sistem crash [9]. Di satu sisi, ada banyak LU yang tersedia bagi pengembang untuk memperlengkapi
kode logging mereka. Misalnya, Chen dan Jiang [44] menemukan bahwa ada lebih dari 800 LU pihak
ketiga open source yang digunakan oleh berbagai proyek GitHub berbasis Java. Di antara LU ini, SLF4Jdan
Pencatatan Androidadalah dua LU paling populer. Di sisi lain, tidak seperti aspek lain dalam proses
pengembangan perangkat lunak (misalnya, desain perangkat lunak [61] dan pemfaktoran ulang kode [59
]), studi empiris baru-baru ini menunjukkan bahwa tidak ada praktik penebangan yang mapan dalam
praktik [31, 60,109]. Proses instrumentasi log umumnya ad hoc dan biasanya mengandalkan akal sehat
pengembang. Karena semakin banyak sistem yang bermigrasi ke cloud [36] dengan meningkatnya
lapisan kompleksitas [136], paradigma pengembangan perangkat lunak baru sepertiPengembangan
Berbasis Observabilitas (ODD)[121] diperkenalkan. ODD, di mana instrumentasi log memainkan peran
kunci, menekankan paparan negara dan perilaku aSistem Dalam Studi (SUS)selama runtime.
Sayangnya, selain menjelaskan kemampuan LU yang menyertainya, platform cloud yang ada (mis.,
Microsoft Azure [2], Layanan Web Amazon [3], dan Google Cloud [8]) memberikan sedikit informasi
tentang pengembangan dan pemeliharaan kode logging yang efektif. Oleh karena itu, dalam artikel ini,
kami telah melakukan survei sistematis [86] pada teknik instrumentasi yang digunakan dalam software
logging. Kontribusi artikel ini adalah:
• Ini adalah survei pertama yang secara sistematis mencakup teknik yang digunakan dalam ketiga pendekatan
instrumentasi log perangkat lunak: logging konvensional, logging berbasis aturan, dan penelusuran
terdistribusi.
• Melalui proses survei sistematis, kami telah mengidentifikasi sembilan tantangan dalam
empat kategori yang terkait dengan instrumentasi log dan menjelaskan solusi yang
diusulkan melalui tiga langkah dalam fase instrumentasi log. Kami juga telah membahas
batasan dan pekerjaan di masa mendatang yang terkait dengan solusi canggih ini jika
berlaku. Tantangan, solusi, dan diskusi akan bermanfaat bagi para praktisi dan peneliti yang
tertarik untuk mengembangkan dan memelihara solusi logging perangkat lunak.
Organisasi Kertas
Struktur artikel ini disusun sebagai berikut: Bagian2menjelaskan alur kerja fase instrumentasi
log. Bagian3memberikan ikhtisar dari proses survei sistematis kami dan merangkum temuan
dari makalah yang dipelajari. Bagian4membahas tantangan dan solusinya
Survei Instrumentasi Log Perangkat Lunak 90:3
Gambar 2. Langkah-langkah dalam tiga fase instrumentasi log.
terkait dengan instrumentasi log. Bagian5menyajikan diskusi dan arah penelitian masa
depan. Bagian6menyimpulkan survei ini.
2 Alur Kerja INSTRUMENTASI LOGGING PERANGKAT LUNAK

Di bagian ini, kami akan memperkenalkan keseluruhan alur kerja instrumentasi log perangkat lunak
melalui contoh yang berjalan. Bagian2.1memberikan ikhtisar tentang fase instrumentasi log; Bagian2.2
menjelaskan tiga pendekatan penebangan umum; Bagian2.3mengusulkan dua masalah dalam Integrasi
LU; dan Bagian2.4mengilustrasikan tiga langkah komposisi kode logging.
2.1 Gambaran Umum Fase Instrumentasi Log

Software logging terdiri dari dua fase: (1)Instrumentasi Log, yang menyangkut tentang
pengembangan dan pemeliharaan kode logging, dan (2)Manajemen Log, yang berkaitan dengan
pengumpulan dan analisis pesan log yang dihasilkan. Di sini, kami menjelaskan lebih lanjut tiga
langkah dalam fase instrumentasi log, yang menjadi fokus survei ini. Langkah-langkah rinci
ditunjukkan pada Gambar2.
(1)Pendekatan Pencatatan: Pencatatan adalah masalah lintas sektoral, karena cuplikan LC tersebar di seluruh
sistem dan terjerat dengan kode fitur [82]. Selain itu, logging menimbulkan overhead kinerja [54] dan jika
tidak hati-hati dapat memperlambat eksekusi sistem dan memengaruhi pengalaman pengguna. Oleh karena
itu, pendekatan penebangan tambahan telah diusulkan untuk menyelesaikan beberapa masalah ini. Namun,
mereka juga menimbulkan masalah tambahan. Misalnya, meskipunPemrograman Berorientasi Aspek
(AOP)meningkatkan modularitas potongan LC, ini memperkenalkan kurva pembelajaran yang curam dari
paradigma pemrograman yang berbeda dan sulit untuk menggeneralisasi masalah logging individu ke dalam
aturan [44]. Pengembang harus terlebih dahulu memutuskan pendekatan logging mana yang akan diadopsi
untuk SUS mereka sebelum melengkapi SUS mereka dengan LC.
(2)Integrasi LU: Alih-alih langsung menggunakan fungsi keluaran standar seperti System.out.print,
pengembang lebih suka instrumen sistem mereka menggunakan LU seperti
SLF4J [19] untuk Java dan spdlog [20] untuk C++ untuk fungsionalitas tambahan seperti threadsafety
(pencatatan tersinkronisasi dalam sistem multi-utas) dan tingkat verbositas (mengontrol jumlah log yang
dihasilkan). Saat mengintegrasikan LU, pengembang harus mengatasi dua masalah berikut:apa-untuk-adopsi:
LU yang berbeda menyediakan fungsionalitas yang berbeda [44]. Bergantung pada konteks penggunaan
sebenarnya, pengembang dapat mengintegrasikan LU pihak ketiga yang ada atau mengembangkannya
sendiri; dancara mengkonfigurasi: setiap proyek dapat berisi satu atau lebih LU(s), yang masing-masing
memiliki banyak pilihan konfigurasi yang berbeda. Penting untuk mengonfigurasi LU dengan benar dan
efektif sehingga SUS dapat menghasilkan pesan log berkualitas tinggi selama runtime.
(3)Komposisi LC: Setelah pengembang mengintegrasikan LU, mereka perlu memasukkan LC ke

dalam SUS untuk mengekspos status dan perilaku SUS selama runtime. Saat menyusun LC,
pengembang harus mengatasi tiga masalah berikut:di mana-untuk-log: menentukan titik
logging yang sesuai;apa yang harus dicatat: memberikan informasi yang cukup dalam LC; dan
cara login: mengembangkan dan memelihara LC berkualitas tinggi.
2.2 Pendekatan Penebangan
Langkah pertama dalam fase instrumentasi log adalah memilih pendekatan logging yang tepat. Ada tiga pendekatan
penebangan umum, yang masing-masing memiliki pro dan kontra. Kami akan menjelaskan dan membandingkan
pendekatan logging ini dengan menggunakan contoh yang sedang berjalan. Skenarionya adalah tentang mencatat
perilaku server web selama proses otentikasi pengguna. Skenario ini diimplementasikan menggunakan ketiga
pendekatan logging umum, seperti yang ditunjukkan pada Gambar3.
2.2.1 Penebangan Konvensional.Cuplikan kode menggunakan pendekatan logging konvensional

ditunjukkan pada Gambar3(sebuah). Sebelum kita dapat melengkapi SUS dengan snippet LC, pertama-
tama kita harus mengimpor LU, yang menyediakan fungsionalitas logging konvensional. Seperti yang
ditunjukkan dari baris 1 dan 2 cuplikan kode, kami menggunakanLog4J 2Perpustakaan [14], LU populer
untuk sistem berbasis Java. Kemudian objek logging, yang bertanggung jawab untuk melakukan
instrumentasi log di sisa contoh ini, dibuat pada baris 6. Baris 9 dan 21 menunjukkan dua baris cuplikan
LC, yang mencatat nama pengguna dan alamat IP mereka sebelum dan sesudah proses otentikasi. Mirip
dengan metode I/O standar sepertiSystem.out.printlnatauSistem.err,cuplikan LC berisi teks statis dan
konten dinamis. Selain itu, ini juga berisi objek logging serta level verbositas untuk mengontrol jumlah
pesan log yang dikeluarkan. Ambil potongan LC pada baris 9 sebagai contoh. Keempat komponen
disorot dalam warna berbeda: objek logging (penebang)merah, tingkat verbositas (informasi)dengan
warna kuning, teks statis (“Diterima dari klien”)berwarna hijau, dan konten dinamis (req.namapengguna)
berwarna abu-abu.
Cuplikan sampel dari pesan log yang dihasilkan ditunjukkan pada Gambar3(d). Selain teks statis
dan konten dinamis, setiap pesan log juga berisi informasi dasar seperti stempel waktu dan lokasi
kode log. Mirip dengan teks bahasa alami, pesan log yang dihasilkan biasanya diformat secara
longgar dan tidak dapat dengan mudah diuraikan oleh program komputer [138].
Logging konvensional sangat mudah diatur dan potongan LC yang dihasilkan dapat ditempatkan hampir di
mana saja di SUS. Namun, ada dua masalah utama mengenai penebangan konvensional: (1) Kekhawatiran lintas
sektoral: cuplikan LC yang dihasilkan tersebar di seluruh sistem dan terjerat dengan kode fitur [32,34,82,87]. Hal
ini menimbulkan tantangan dalam mengembangkan dan memelihara LC berkualitas tinggi, sementara SUS
berkembang. Untuk mengatasi masalah ini, pendekatan logging berbasis aturan diperkenalkan (Bagian2.2.2).
(2)Kurangnya Konteks Eksekusi: Sangat menantang untuk mengkorelasikan pesan log dari berbagai proses atau
bahkan mesin [133]. Ini terutama berlaku untuk sistem terdistribusi skala besar. Oleh karena itu, pelacakan
terdistribusi diperkenalkan (Bagian2.2.3).
Gambar 3. Contoh skenario autentikasi pengguna yang dilengkapi dengan tiga pendekatan logging umum.
2.2.2 Logging Berbasis Aturan.Berbeda dari pendekatan logging konvensional, di mana LC bercampur dengan kode
fitur, pendekatan logging berbasis aturan menggeneralisasikan perilaku logging dengan menentukan seperangkat
aturan. Ini sangat meningkatkan modularitas LC dan karenanya memberikan dukungan yang jauh lebih baik bagi
pengembang untuk melacak dan memelihara LC mereka sementara SUS berkembang.
Pemrograman Berorientasi Aspek (AOP)Logging berbasis aturan adalah salah satu teknik logging berbasis
aturan yang paling umum digunakan. AOP adalah paradigma pemrograman, yang dirancang untuk
meningkatkan modularitas dengan mengurangi jumlah masalah lintas sektoral [82], salah satunya adalah
software logging. Pencatatan berbasis AOP telah digunakan untuk mendukung diagnosis kegagalan fungsional
[34,87]. Pengembang menentukan aturan melalui file aspek. File aspek tipikal terdiri dari pointcuts dan saran.
Pointcut adalah untuk menentukan titik eksekusi di mana perhatian lintas sektoral (misalnya, penebangan)
perlu diterapkan. Sebuah saran adalah kode tambahan (misalnya, LC) yang dieksekusi saat pointcut tercapai.
Angka3(b) melanjutkan contoh lari kita dengan menggunakanaspekJLU, yang merupakan pendekatan
berbasis AOP yang sangat populer untuk sistem berbasis Java. BerkasLogAspect.javabertindak sebagai
file aspek. Aturan (alias titik instrumen) didefinisikan melalui anotasi Java pada baris 5. Dalam hal ini
contoh, anotasi @Sekitarberarti awal dan akhir metode akan diinstrumentasi. Nilai di dalam tanda
kurung menentukan metode yang diinstrumentasi. Dalam contoh ini, metode dengan nama
autentikasidalam kelasServerkuakan diinstrumentasi. Kode instrumen ditentukan pada baris 7 dan
baris 9, yang menampilkan pesan log yang sama dengan contoh logging konvensional. Berkas
Server.javatidak termasuk LC apa pun, karena semua LC dimodulasi dan ditentukan dalam file
aspek. Seperti yang ditunjukkan pada Gambar3(e), pesan log yang sama akan dikeluarkan selama
runtime.
Di satu sisi, logging berbasis aturan memungkinkan developer memisahkan aturan dengan instrumentasi
sebenarnya. Memperbarui LC itu mudah, karena pengembang hanya perlu merevisi aturan tanpa mengubah
kode di banyak lokasi. Ini meningkatkan modularitas LC. Di sisi lain, logging berbasis aturan kurang fleksibel,
karena LC tidak dapat diinstrumentasi di mana pun karena keterbatasan implementasi [27, 44,104]. Misalnya,
ketika kita mengadopsi AOP dalam kerangka kerja Spring, hanya metode publik yang dapat disarankan dalam
Spring AOP, sedangkan metode pribadi atau yang dilindungi tidak dapat [4,17].
2.2.3 Penelusuran Terdistribusi.Meskipun fleksibel dan mudah untuk melakukan logging

konvensional, pesan log yang dihasilkan adalah teks bentuk bebas, yang tidak dapat dengan
mudah dihubungkan silang di berbagai proses atau bahkan mesin. Ini akan menjadi masalah besar
untuk sistem terdistribusi, di mana satu skenario dapat dijalankan pada beberapa mesin. Untuk
mengatasi tantangan ini, pelacakan terdistribusi diperkenalkan. Berbeda dari logging
konvensional, di mana pengembang SUS terutama melakukan aktivitas instrumentasi log,
pengembang perpustakaan terutama bertanggung jawab atas tugas instrumentasi log. Meskipun
pengembang SUS dapat melakukan instrumentasi log tambahan, tugas utama mereka adalah
mengimpor pustaka penelusuran dan melakukan beberapa tindakan penyiapan. Akibatnya, pesan
log yang dihasilkan terstruktur dan dapat dihubungkan dengan satu set variabel umum.jejak.
Untuk singkatnya, kami menyebutnya sebagai ajejakdi sisa bagian ini.
Angka3(c) melanjutkan contoh berjalan kami dengan menggunakan pelacakan terdistribusi sebagai
pendekatan instrumentasi log kami. Contoh ini menggunakanBukaPelacakan,LU yang sangat populer yang
mendukung pendekatan logging berbasis penelusuran terdistribusi [108]. Untuk potongan kode di bagian atas
Gambar3(c), objek pelacak dan instance server terlacak dibuat masing-masing pada baris 3 dan baris 5. Selain
itu, tidak ada upaya instrumentasi log tambahan yang diperlukan dari pengembang SUS. Komposisi LC
sebenarnya dilakukan oleh pengembang perpustakaan yang cuplikan kodenya ditampilkan di bagian bawah
Gambar3(c). Mereka menerapkanserver terlacak,yang memperpanjang aslinyaServerkelas dan menimpa dua
metode penting:onReceivedanonSend.Kedua metode ini akan dipanggil masing-masing saat menerima
permintaan dan mengirim balasan.
Tipikaljejakdalam konteks pelacakan terdistribusi terdiri dari beberapa pesan log yang terhubung bersama.
Pesan log yang terhubung ini membentuk alur kerja permintaan yang lengkap. Di BukaPelacakan,pesan log
seperti itu disebutrentang.Baik di sisi klien dan sisi server, pengembang perpustakaan menyusun log rentang
menggunakan API sepertispan.log.Rentang ini diteruskan dari sisi klien ke sisi server dengan protokol
komunikasi tertentu (misalnya, HTTP) sehingga rentang dari kedua ujungnya dapat dihubungkan. Dengan cara
ini, informasi perekaman jejak lengkap dari kedua ujungnya dapat dihasilkan. Dalam contoh kami, kami hanya
menampilkan kode di sisi server, karena kode pelacakan di sisi klien serupa. Untuk diperhatikan, di dalam
metodepada Terima,di mana kami menerima permintaan klien, kami mengekstrak data konteks yang dikirim
dari klien pada baris 10. Pada baris 11, kami membuat rentang sebagai turunan dari rentang yang kami ekstrak
dari klien. Pada baris 13, kami menyimpan pesan yang sama seperti contoh dalam logging konvensional dan
berbasis aturan. Setelah permintaan diproses, di dalam onSendmetode, span log pada baris 32 akan dikirim ke
klien.
Jejak yang dihasilkan ditunjukkan pada Gambar3(f). Seperti yang bisa kita lihat, jejaknya disusun dalam
format JSON. JSON menyimpan informasi dengan cara nilai kunci. Misalnya, informasi yang direkam
Tabel 1. Perbandingan antara Tiga Pendekatan Penebangan
Penebangan Konvensional Logging berbasis aturan Pelacakan Terdistribusi

Siapa pengembang SUS pengembang SUS pengembang perpustakaan
Penyaringan Tingkat verbositas Tingkat verbositas Contoh

Format Bebas dari Bebas dari Tersusun
Domain Umum Umum Sistem terdistribusi
Fleksibilitas Tinggi Rendah Sedang
Penyebaran Tinggi Rendah Rendah
potongan LC pada baris 13 memiliki dua kunci:KliendanPesan.Kunci (Klien)sesuai dengan informasi

runtime: thenama belakangdari permintaan dan kunci (Pesan)sesuai dengan teks statis yang
menjelaskan konteks logging. Dibandingkan dengan logging konvensional dan berbasis aturan, pesan
log yang dihasilkan oleh pelacakan terdistribusi lebih terstruktur. Pesan log terkait dapat dengan mudah
ditautkan ke berbagai mesin oleh yang terkaittraceID.
2.2.4 Perbandingan antara Tiga Pendekatan Penebangan.Meja1membandingkan pendekatan ini di

antara enam dimensi berikut:
• Siapamengacu pada jenis pengembang yang bertanggung jawab untuk melakukan tugas instrumentasi log.
Pengembang SUS terutama bertanggung jawab atas tugas instrumentasi log jika mereka mengadopsi
pendekatan logging konvensional atau berbasis aturan. Jika SUS mengimpor pustaka pihak ketiga, maka
mereka mungkin perlu mengonfigurasi LU di dalam pustaka ini untuk mendapatkan gambaran lengkap tentang
perilaku SUS selama runtime. Sebaliknya, pengembang perpustakaan pihak ketiga adalah pihak yang
bertanggung jawab atas sebagian besar tugas instrumentasi log jika mereka mengadopsi pendekatan
penelusuran terdistribusi. Hanya jika diperlukan, pengembang SUS dapat menambahkan LC tambahan di SUS.
• Penyaringanmengacu pada proses menghapus pesan log yang tidak diinginkan selama runtime untuk mengurangi
overhead. Tingkat verbositas digunakan dalam logging konvensional dan berbasis aturan untuk menunjukkan tingkat
keparahan LC. Sementara dalam pelacakan terdistribusi, pengambilan sampel diadopsi untuk memfilter pesan log.
Keputusan pengambilan sampel dapat dikontrol dengan probabilitas, laju, atau bahkan adaptif yang telah ditentukan
sebelumnya.
• Formatmengacu pada persyaratan pada struktur dan isi pesan log yang dihasilkan. Instrumen LC
bentuk bebas sebagian besar diadopsi dalam logging konvensional dan berbasis aturan. Namun,
utilitas penelusuran terdistribusi merekam informasi dengan cara yang lebih terstruktur.
Misalnya, pasangan kunci-nilai adalah paradigma populer untuk menyusun pesan log yang
dihasilkan.
• Domainmengacu pada kategori SUS yang berlaku untuk setiap pendekatan logging. Logging konvensional dan
berbasis aturan dapat diterapkan di hampir semua jenis SUS, sementara penelusuran terdistribusi sebagian
besar diadopsi dalam sistem terdistribusi.
• Fleksibilitasmengacu pada kelayakan dan upaya yang diperlukan untuk menerapkan pendekatan logging
tertentu di bawah berbagai skenario instrumentasi. Melakukan logging konvensional paling fleksibel, karena
pengembang SUS dapat memasukkan LC di setiap titik program. Menginstrumen LC dalam pelacakan
terdistribusi kurang fleksibel, karena sebagian besar cuplikan LC berada dalam batasan komponen perangkat
lunak. Logging berbasis aturan adalah yang paling tidak fleksibel, karena lokasi cuplikan LC harus mengikuti
aturan yang telah ditentukan sebelumnya.
• Penyebaranmengacu pada penyebaran cuplikan LC yang diinstrumentasi di seluruh basis kode dengan
mengadopsi pendekatan logging tertentu. Derajat sebaran LC pada penebangan konvensional tinggi,
karena fleksibilitasnya yang tinggi. Namun, cuplikan LC dalam logging berbasis aturan dan
pelacakan terdistribusi kurang tersebar, karena lokasinya mengikuti aturan yang ditentukan (mis., awal
metode) atau pola tertentu (mis., sebelum pemanggilan RPC).
2.3 Integrasi LU
Alih-alih langsung menggunakan fungsi keluaran standar sepertiSistem.keluar.cetak,pengembang lebih
memilih instrumen SUS mereka menggunakan LU (misalnya,SLF4J [19] untuk Jawa danspdlog [20] untuk
C++) karena fungsionalitas tambahan seperti keamanan utas (pencatatan tersinkronisasi dalam sistem
multi-utas), konfigurasi arsip data (rotasi otomatis file log), dan tingkat verbositas (mengontrol jumlah
pesan log yang dikeluarkan). Biasanya ada dua masalah yang terkait dengan integrasi LU:
• apa-untuk-adopsi: Dengan meningkatnya jumlah LU yang tersedia di alam liar [44],

mengintegrasikan LU yang sesuai dengan persyaratan SUS individu adalah penting. Masalah apa
yang harus diadopsi berfokus pada masalah ini sehubungan dengan pemeliharaan dan
kepatuhan keamanan LU. Setelah itu, penting juga untuk mengonfigurasi LU ini untuk
meningkatkan kegunaannya.
Perangkat lunak modern sering memanfaatkan fungsionalitas yang disediakan oleh LU untuk
melengkapi SUS mereka. Sebuah pelajaran [44] pada 11.194 proyek GitHub berbasis Java menunjukkan
bahwa ada lebih dari 3.000 LU yang diadopsi di alam bebas. Misalnya, banyak pengembang mengadopsi
LU sepertiLog4j [13] danPencatatan Apache Commons [1] untuk instrumen SUS berbasis Java mereka [
90]. Banyak dari proyek ini mengadopsi banyak LU atau bahkan mengimplementasikan LU mereka
sendiri. Pengembang perlu memutuskan mana atau apakah LU yang ada diperlukan untuk SUS mereka.
Selain itu, untuk proyek dengan LU yang sudah terintegrasi, pengembang harus menentukan apakah
mereka ingin bermigrasi ke LU lain atau yang lebih baru. Misalnya, pada Gambar3(a), pengembang
mengadopsiLog4J 2untuk merekam perilaku runtime server. Karena ada ketergantungan perpustakaan
pihak ketigaOKHttp3untuk mengelolaHTTPkoneksi dalam program ini, LUPengantar HTTPLogging,
disediakan olehOKHttp3ditunjukkan pada baris 11, harus diadopsi juga.
• cara mengkonfigurasi: LU berisi banyak pilihan konfigurasi yang berbeda. Mereka dapat dikaitkan
dengan pengontrolan jumlah pesan log yang dikeluarkan, atau lokasi file log, dan ukuran file log.
Pengembang perlu mengonfigurasi LU dengan benar untuk SUS mereka untuk mengumpulkan cukup
data logging sambil meminimalkan overhead kinerja dan persyaratan penyimpanan. Misalnya, tingkat
verbositas default diLog4J 2dapat dikonfigurasi baik secara statis (misalnya, melalui file konfigurasi) atau
secara dinamis (melalui API). Dalam contoh kami yang sedang berjalan, baris 8 pada Gambar3(a)
menunjukkan cara mengonfigurasi level default LU. Untuk LU yang disediakan oleh pustaka pihak
ketiga, pengembang perlu mengonfigurasi opsi satu per satu.
2.4 Komposisi LC
Langkah terakhir dari fase instrumentasi log adalah komposisi LC. Ada tiga sub-langkah dalam
komposisi LC:
(1) Langkah daridi mana-untuk-logadalah tentang menentukan titik logging yang tepat. Berbagai studi [42,60,109
,128,130] telah menunjukkan bahwa logging meresap dalam proses pengembangan perangkat lunak.
Pengembang biasanya mengandalkan pengalaman atau firasat mereka saat memutuskan titik logging di
kode sumber. Dalam contoh berjalan kami, Gambar3(a) menunjukkan bahwa pengembang memilih untuk
memasukkan cuplikan kode logging pada saat masuk dan keluar dari metode autentikasiuntuk merekam
status program. Di satu sisi, pencatatan log yang terlalu sedikit akan menghambat diagnosis pesan log.
Misalnya, pernyataan logging yang hilang di blok pengecualian akan menyebabkan informasi kegagalan yang
tidak lengkap, membuat diagnosis kegagalan menjadi lebih sulit [127]. Cuplikan LC yang tidak lengkap juga
menghalangi pemahaman pengembang, merugikan LC
kualitas, karena mereka hanya dapat memulihkan jalur eksekusi yang ambigu dari pesan log eksekusi
[132]. Di sisi lain, meskipun logging yang berlebihan—di mana cuplikan LC disisipkan di mana-mana
dalam kode sumber—akan memberikan informasi waktu proses yang kaya, ini akan menghasilkan
overhead kinerja yang sangat besar dan biaya penyimpanan yang tinggi terkait dengan pesan log
yang dihasilkan. Selain itu, sangat menantang untuk mendiagnosis masalah dengan menganalisis
sejumlah besar pesan log, yang sebagian besar tidak terkait dengan skenario masalah [74].
(2) Langkah dariapa yang harus dicatatadalah tentang memberikan informasi yang memadai dalam tiga komponen dari
setiap cuplikan LC:
• Tingkat verbositasmenentukan apakah cuplikan LC harus dikeluarkan selama eksekusi SUS. Memilih
tingkat verbositas yang sesuai untuk cuplikan LC adalah penting. Misalnya, jika snippet LC mencatat
informasi tentang eksekusi yang gagal, tingkat verbositas harus ditetapkan sebagaikesalahanatau
fatal.Jika salah disetel sebagaimen-debug,pesan log semacam itu mungkin tidak dikeluarkan atau
bahkan jika ya, pengembang mungkin mengabaikannya. Pengabaian seperti itu dapat
memengaruhi pengalaman pelanggan dan berdampak negatif pada kualitas produk.
• Teks statismenggambarkan konteks logging dengan cara yang dapat dibaca manusia. Saat ini,
pengembang bertanggung jawab untuk menyusun teks statis secara manual di cuplikan LC. Teks statis
yang ditulis dengan buruk atau kedaluwarsa dapat menyebabkan kebingungan bagi para praktisi dan
memengaruhi berbagai tugas analisis log mereka.
• Konten dinamismencerminkan keadaan SUS selama runtime. Itu adalah hasil dari variabel eksekusi
dan pemanggilan metode yang disertakan dalam setiap cuplikan LC. Penting untuk merekam
informasi runtime yang diperlukan untuk memenuhi berbagai kebutuhan logging dari
pengembang dan operator.
(3) Langkah daricara loginadalah tentang mengembangkan dan memelihara LC berkualitas tinggi, yang
tersebar di seluruh sistem dan terkait dengan kode fitur. Meskipun pendekatan rulebased logging
menyediakan pengelolaan LC yang lebih baik, banyak industri dan sistem open source masih memilih
untuk menggabungkan LC dengan kode fitur [40,41]. Sebuah pelajaran [78] menunjukkan bahwa 20%–
45% dari LC telah diubah setidaknya sekali selama masa pakainya. Jumlah rata-rata hari antara
cuplikan LC diperkenalkan dan perubahan pertamanya berkisar antara 1 hingga 17 hari. Tidak seperti
kode fitur, yang kualitasnya dapat diverifikasi melalui pengujian, kebenaran LC sangat sulit diverifikasi.
Ini dapat menghambat pemahaman program atau bahkan menyebabkan masalah runtime seperti
crash [9].
3 TINJAUAN SURVEI SISTEMATIS KAMI

Pada bagian ini, pertama-tama kami akan menjelaskan proses survei sistematis kami di Bagian3.1. Kemudian,
kami akan meringkas hasil survei kami di Bagian3.2. Terakhir, kami akan menjelaskan perbedaan survei kami
terhadap karya yang ada di Bagian3.3.
3.1 Metodologi
Survei sistematis adalah jenis tinjauan literatur, yang menggunakan pendekatan sistematis untuk mengidentifikasi dan
menganalisis studi utama yang terkait dengan topik penelitian tertentu [86]. Manfaat utama dari melakukan survei
sistematis adalah: (1) hasil studi yang dipilih cenderung tidak bias, karena menerapkan strategi pencarian yang telah
ditentukan sebelumnya; (2) proses pencarian didokumentasikan sehingga penelitian dapat dengan mudah direplikasi.
Di bawah ini, kami menjelaskan secara singkat proses survei sistematis kami. Selain "logging" dan "instrumentasi",
kami juga memasukkan kata "tracing" sebagai kata kunci pencarian kami, karena "logging" dan "tracing" digunakan
secara bergantian dalam literatur dan praktik penelitian. Misalnya, "jejak" biasanya merupakan tingkat verbositas umum
yang ditentukan di banyak LU untuk menangkap arus informasi melalui SUS
[24,92]. Selain itu, banyak kerangka penelusuran [79,99,120] juga menggunakan istilah "logging" untuk
merekam berbagai perilaku runtime SUS. Oleh karena itu, untuk menangkap semua karya terkait yang
mungkin, kami mencari repositori publikasi IEEE Xplore, ACM, dan DBLP dengan bentuk akar dari tiga kata ini:
catatan,jejak, daninstrumen.
• Untuk IEEE Xplore, kami menyetel bidang "Judul Publikasi" menjadi perangkat lunak, dan memeriksa apakah
bidang "Metadata" memenuhi salah satu kriteria berikut:
— berisi kata-kata logging dan software logging, atau praktik logging; atau
— mengandung kata tracing, software tracing, atau tracing practice; atau
— mengandung kata instrumentasi atau perangkat lunak instrumentasi.
• Demikian pula, untuk ACM, kami menyetel bidang "acmdlCCS" menjadi perangkat lunak dan memeriksa apakah
judul dan abstrak berisi kata "logging", "pelacakan", atau "instrumentasi".
• Karena API DBLP tidak mendukung fungsi pencarian lanjutan, kami terutama menggunakannya untuk tujuan
verifikasi.
Kami kemudian memeriksa hasil pencarian secara manual dengan menggunakan kriteria penyertaan dan pengecualian
berikut:
(1) Kami mengecualikan semua makalah yang hanya mempelajari masalah dalam fase manajemen
log dengan membaca abstrak. Misalnya, ada banyak penelitian yang berfokus pada analisis log
(misalnya, Referensi [75,118,124]) dan log abstraksi (misalnya, Referensi [67,76]), yang tidak
relevan dengan survei ini.
(2) Kami hanya menyertakan makalah yang dipublikasikan di bidang rekayasa perangkat lunak atau tempat terkait
sistem komputer, karena audiens target kami adalah praktisi atau peneliti perangkat lunak.
(3) Karena kami hanya berfokus pada SUS, yang berada di atas sistem operasi dan dihubungkan oleh
jaringan komputer, kami akan mengecualikan makalah yang berfokus pada logging di kernel
(misalnya, Referensi [62]) atau tingkat jaringan (misalnya, Referensi [64]).
Setelah kami mengumpulkan kumpulan kertas pertama, kami selanjutnya menerapkan metode bola salju [
116] dari referensi makalah ini serta melihat melalui makalah yang mengutipnya. Proses ini menghasilkan total
69 makalah yang sesuai dengan kriteria kami. Untuk memverifikasi kelengkapan makalah yang disurvei, hasil
akhir mencakup semua makalah yang kami ketahui sebelumnya yang terkait dengan instrumentasi log
perangkat lunak (misalnya, Referensi [41,60,128]). Kami menyertakan 69 makalah ini dan metadatanya
(misalnya, tahun, tempat publikasi) serta hasil pencarian awal dari IEEE dan ACM dalam paket replikasi kami [18
].
3.2 Ringkasan Survei Kami

Kami melakukan proses pengumpulan kertas kami pada 30 Oktober 2019. Gambar4mengilustrasikan jumlah
makalah terkait antara 23 tahun ini (1997–2019), sebagai makalah penelitian pertama di bidang ini [80] muncul
pada tahun 1997. Ada tren peningkatan yang jelas dalam hal jumlah makalah penelitian selama bertahun-tahun
tentang topik ini. Secara khusus, minat penelitian di bidang ini melonjak setelah 2012, karena 62% (43) makalah
yang dipelajari telah dipublikasikan sejak saat itu. Ini juga sebagian hasil dari meningkatnya jumlah penelitian di
bidang rekayasa perangkat lunak selama periode ini [101].
Setelah mempelajari setiap makalah dengan cermat, kami telah mengidentifikasi sembilan tantangan, yang selanjutnya
dikelompokkan ke dalam empat kategori utama berikut. Perhatikan bahwa beberapa makalah mungkin menyentuh beberapa
tantangan.
(1)Kegunaanmengacu pada teknik instrumentasi log yang memfasilitasi adopsi berbagai

teknik logging. Ada dua tantangan khusus dalam kategori ini:
(sebuah)Dapat dikonfigurasimengacu pada tantangan apakah makalah yang dipelajari memberikan
dukungan untuk memudahkan proses konfigurasi berbagai teknik instrumentasi log.
Gambar 4. Makalah terkait instrumentasi Log dari 1997 hingga 2019.
(b)Overhead Kinerjamengacu pada tantangan apakah studi bertujuan untuk meminimalkan perlambatan
yang disebabkan oleh penebangan.
(2)Dapat didiagnosismengacu pada teknik instrumentasi log yang mendukung tugas
analisis dan debugging berbagai masalah fungsional dan non-fungsional. Kategori ini
terdiri dari dua tantangan berikut:
(sebuah)Diagnosis Kegagalanmengacu pada tantangan yang terkait dengan penyediaan informasi logging yang
memadai untuk mendiagnosis kegagalan fungsional.
(b)Analisis Kinerjamengacu pada tantangan yang terkait dengan penyediaan informasi logging yang
memadai untuk mendeteksi dan men-debug masalah kinerja.
(3)Kualitas LCmengacu pada teknik instrumentasi log yang meningkatkan berbagai
aspek pengembangan LC. Kategori ini terdiri dari tiga tantangan berikut:
(sebuah)Kejelasanmengacu pada tantangan untuk membuat LC mudah dipahami dan tidak terlalu ambigu
bagi pengembang dan operator.
(b)Pemeliharaanmengacu pada tantangan untuk mendukung pemeliharaan dan evolusi
LC, karena LC tersebar di seluruh sistem dan terjerat dengan kode fitur yang terus
berkembang.
(c)Konsistensimengacu pada tantangan untuk memastikan gaya logging yang seragam di
berbagai komponen SUS.
(4)Kepatuhan Keamananmengacu pada teknik instrumentasi log yang menangani masalah
keamanan atau hukum SUS. Kategori ini terdiri dari dua tantangan berikut:
(sebuah)Auditmengacu pada tantangan merekam serangkaian peristiwa yang relevan dengan keamanan untuk
memenuhi berbagai peraturan hukum seperti Undang-Undang Sarbanes-Oxley tahun 2002 [22].
(b)Analisis forensikmengacu pada tantangan merekam aktivitas pengguna untuk
mendukung investigasi aktivitas kriminal seperti intrusi atau deteksi penipuan.
Meja2selanjutnya memecah makalah yang disurvei dengan menghubungkan setiap studi dengan tantangan yang
ditangani, solusi yang diusulkan, dan langkah-langkah yang diterapkan. Beberapa solusi dapat diusulkan untuk
menyelesaikan satu tantangan. Solusi juga dapat diterapkan pada beberapa langkah atau sub-langkah dari
Tabel 2. Tinjauan Survei Ini dengan Mengkategorikan Makalah yang Berbeda di bawah Kategori Tantangan,
Detil Tantangannya, Solusi Yang Dikembangkannya, Serta Langkah-Langkah Yang Diterapkannya
Kategori Tantangan Solusi Langkah Terapan
Dapat dikonfigurasi Sejarah [134] LU/Bagaimana-konfigurasi
Pengolahan pasca [100,125] LA/Logging konvensional

Kegunaan Contoh [39,57,58,79,99,115,120,122] LA/Penelusuran terdistribusi
Pertunjukan
LU/Bagaimana-konfigurasi
Atas
Pengoptimalan biaya
LC/Tempat-untuk-masuk
[54,126,131,132]
Aturan-generasi
Logging berbasis LA/Aturan
[28,49,51,52,123]
Kegagalan
Analisis program LC/Tempat-untuk-masuk
Dapat didiagnosis [50,53,72,73,127,129] LC/What-to-log

Pelacakan kausalitas LA/Penelusuran terdistribusi
Analisis Kinerja [29,30,39,46,47,56–58,68,79,80,99, LC/Tempat-untuk-masuk

102,111,115,120,122,135] LC/What-to-log
NLP [66]
Kejelasan Visualisasi [110] LC/What-to-log
Entropi [113]
Pembelajaran mesin
Kualitas LC Konsistensi [60,83,88,89,91–94,97,137] LC/*

Kloning kode [128]
Bahasa Khusus Domain [
Logging berbasis LA/Aturan
Pemeliharaan 26,35]
Sejarah [41,65,95] LC/Cara-log
AOP [26] Berbasis LA/Aturan
Audit
Keamanan desain LU [44] LU/Apa yang harus diadopsi
Forensik Heuristik [84,85] LC/What-to-log
Di bawah kolom langkah-langkah yang diterapkan, “*” berarti semua sub-langkah dalam langkah ini akan diterapkan.
fase instrumentasi log. Misalnya, Rapper [120] mencoba memecahkan tantangan untuk mengontrol
kinerja overhead logging. Ini diklasifikasikan sebagai solusi berbasis pengambilan sampel. Langkah-
langkah yang dapat diterapkan adalah pendekatan pelacakan terdistribusi dari langkah Logging
Approach dan sub-langkah how-to-configure dari langkah Integrasi LU. Satu studi juga dapat
memberikan solusi untuk berbagai tantangan. Misalnya, selain mengatasi tantangan overhead kinerja
yang disebutkan di atas, Dapper [120] juga mengusulkan solusi berbasis pelacakan kausalitas untuk
mendukung analisis kinerja.
Angka5menunjukkan distribusi makalah yang dipelajari berdasarkan tantangan yang mereka tangani. Perhatikan
bahwa mereka tidak menambahkan hingga 69, karena beberapa makalah mengatasi banyak tantangan. Mayoritas dari
mereka fokus pada aspek diagnosis (45%) atau kualitas LC (43%). 25% makalah membahas tantangan kegunaan dan
hanya 6% makalah yang mempelajari tantangan terkait keamanan.
Bagian4akan menjelaskan setiap tantangan dan solusi yang diusulkan oleh makalah yang dipelajari.
3.3 Membandingkan dengan Survei yang Ada

Ada tiga karya yang ada [37,112,114] yang terkait dengan survei kami tentang instrumentasi log:
• Rong dkk. [112] melakukan kajian sistematis terhadap praktik instrumentasi kayu gelondongan pada salah satu
jenis pendekatan penebangan, penebangan konvensional. Mereka tidak mencakup penebangan lainnya
Gambar 5. Distribusi makalah yang diklasifikasikan berdasarkan tantangan terkait.
pendekatan atau membahas teknik dalam integrasi LU. Selanjutnya, dibandingkan dengan Referensi [112],
kami telah menempatkan setiap makalah yang dipelajari dalam konteks tantangan terkait sehingga praktisi
atau peneliti dapat dengan mudah menemukan solusi yang relevan untuk mengadopsi dan memahami
keterbatasan mereka jika ada.
• Sambasivan dkk. [114] melakukan survei pada sistem pelacakan terdistribusi, yang merupakan
kerangka kerja logging untuk mendukung pemantauan dan diagnosis masalah pada sistem
terdistribusi. Mereka memeriksa fitur dari 15 kerangka kerja (misalnya, menjaga hubungan kausal
atau visualisasi) dan berfokus pada kategori diagnosa dari teknik instrumentasi log. Survei kami
mencakup ketiga pendekatan penebangan umum, yang mencakup pelacakan terdistribusi.
Selanjutnya, di atas diagnosa, kami telah mengidentifikasi dan memeriksa kategori tantangan
tambahan (misalnya, kegunaan dan keamanan) dan solusi terkaitnya.
• Candido dkk. [37] melakukan tinjauan sistematis pada teknik logging untuk pemantauan
perangkat lunak kontemporer. Mereka memfokuskan studi mereka pada empat dimensi berikut:
rekayasa log, infrastruktur log, analisis log, dan platform log. Rekayasa log hanya berfokus pada
komposisi kode logging dari logging konvensional, sementara survei kami tidak hanya membahas
pendekatan logging lainnya, tetapi juga mencakup integrasi LU. Tiga dimensi lainnya semuanya
terkait dengan fase pengelolaan log, yang tidak menjadi fokus survei ini.
Selain itu, ada juga survei terkait teknik instrumentasi dinamis yang digunakan selama pemantauan [
38,63,69], karena fokus artikel ini adalah pada instrumentasi log, yang umumnya mengacu pada teknik
instrumentasi statis yang diterapkan selama pengembangan dan pemeliharaan perangkat lunak.
3.4 Membandingkan dengan Pekerjaan Industri dan Perangkat Lunak Open Source
Beberapa penelitian yang ada dilakukan di lingkungan industri. Suatu studi dianggap sebagai pekerjaan
industri, jika afiliasi penulis pertama adalah organisasi industri (misalnya, laboratorium penelitian atau
perusahaan perangkat lunak) dan studi tersebut dilakukan terutama pada sistem perangkat lunak
industri. Dua penelitian telah dilakukan untuk meneliti dan mengembangkan infrastruktur sistem
pelacakan terdistribusi dari Google [120] dan Facebook [79]. Tiga studi dari Microsoft [31,54,60]
menangani langkah di mana-untuk-log dalam fase Komposisi LC. Dua studi dari Critiware [28, 109]
mengusulkan logging berbasis aturan dalam fase Pendekatan Logging. Ada kekurangan pekerjaan
industri pada langkah atau fase lain, seperti fase integrasi LU. Alasannya ada dua: (1) instrumentasi
log sangat terkait dengan kode sumber, karena alasan kerahasiaan, banyak perusahaan tidak mau
mempublikasikan infrastruktur atau praktik internal mereka; dan (2) instrumentasi log umumnya
dilakukan sebagai upaya setelah pemikiran [128], karena organisasi industri mungkin tidak
mengetahui manfaat dari pengembangan dan pemeliharaan cuplikan LC secara proaktif.
Mirip dengan survei literatur sistematis lainnya [37,112,116], dalam artikel ini, fokus utama kami adalah pada
makalah penelitian yang diterbitkan alih-alih alat dan kerangka kerja. Selain itu, mendukung para praktisi, kami
juga membuat daftar alat dan kerangka kerja yang telah kami temukan sejauh ini. Ada banyak sistem industri
dan perangkat lunak open source yang tersedia untuk fase Logging Approach. Misalnya, utilitas logging yang
paling umum digunakan termasuk Log 4J 2 [14] dan Logging Apache Commons [1], yang menggunakan
pendekatan penebangan konvensional. Sistem perangkat lunak seperti OpenTracing [108], OpenCensus
(Google) [16], Jaeger (Uber) [10], Zipkin (Twitter) [25] banyak digunakan untuk pelacakan terdistribusi. Solusi dan
platform komersial sumber tertutup juga ada untuk instrumentasi dan manajemen log, seperti Datadog [5],
Lightstep [12], dan Splunk [21]. Namun, sepengetahuan terbaik kami, ada kekurangan alat dan kerangka kerja
industri dan sumber terbuka yang diadopsi secara luas yang berfokus pada fase Integrasi LU dan Komposisi LC.
4 TANTANGAN DAN SOLUSI

Pada bagian ini, kami membahas secara rinci tentang sembilan tantangan berbeda dalam empat kategori dan
melaporkan solusi yang diambil dari literatur yang ada. Untuk setiap solusi, kami mengidentifikasi langkah/sub-
langkah yang diterapkan dari fase instrumentasi log dan mendiskusikan pro dan kontra.
4.1 Kegunaan
Kegunaan instrumentasi log berkaitan dengan seberapa efektif pengguna dapat mengadopsi
berbagai teknik logging dan mengelola perilaku logging selama runtime. Ini menantang karena:
(1) perilaku logging dikelola melalui berbagai fungsi konfigurasi. Karena sistem perangkat lunak
berskala besar berkembang pesat, perilaku pencatatannya perlu diubah; dan (2) logging intensif,
meskipun membantu banyak tugas sampai tingkat tertentu, pasti akan menurunkan kinerja SUS
dan bahkan dapat mengganggu pengoperasian normal. Oleh karena itu, overhead kinerja yang
disebabkan oleh penebangan harus dikontrol dalam batas tertentu. Dalam subbagian ini, kita akan
membahas dua tantangan ini (konfigurasi dan overhead kinerja) dan solusi yang diusulkan untuk
mengatasinya.
4.1.1 Dapat dikonfigurasi.Mengkonfigurasi LU adalah tugas yang tidak sepele. Sebuah studi yang dilakukan
oleh Hassani et al. [65] menunjukkan bahwa masalah terkait konfigurasi log mungkin dapat menyebabkan
masalah serius seperti pengecualian runtime dan log yang hilang. Masalah ini sering kali disebabkan oleh
inkonsistensi antara konfigurasi log dan kode fitur. Misalnya, nama logger yang salah dapat menyebabkan a
Berkas tidak ditemukanpengecualian, mencegah log ditulis ke disk. Ada kekurangan dukungan alat otomatis
untuk mendeteksi ketidakkonsistenan tersebut. Ada satu solusi yang diusulkan untuk tantangan ini:
• Solusi berbasis sejarah.Zhi et al. [134] melakukan studi empiris dengan menganalisis evolusi
konfigurasi logging dari 10 proyek sumber terbuka dan 10 proyek industri dari Alibaba. Banyak
proyek open source yang dipelajari (misalnya, Hadoop, HBase) juga digunakan secara luas di
industri. Mereka menemukan, untuk kemudahan mengelola perilaku logging berbeda
komponen sistem skala besar, penebang akan diberi nama setelah tiga konvensi: berbasis topik,
berbasis paket, dan penamaan campuran. Dalam proyek industri, penamaan berbasis topik paling
sering digunakan sementara dalam proyek sumber terbuka, dan penamaan berbasis paket paling sering
digunakan. Selain itu, nama penebang sering diubah karena ketidakkonsistenan dan evolusi perangkat
lunak. Berdasarkan temuan ini, mereka mengusulkan solusi berbasis sejarah untuk mengidentifikasi
penebang yang tidak valid. Itu membandingkan nama semua penebang dalam file konfigurasi dan yang
disebutkan dalam file kode sumber. Yang tak tertandingi antara dua set dilaporkan ke pengembang.
Semua masalah yang terdeteksi dikonfirmasi oleh pengembang SUS. Solusi ini diterapkan dicara
mengkonfigurasisub-langkah dalam langkah Integrasi LU. Meskipun mampu mendeteksi
ketidakkonsistenan dalam konfigurasi log secara statis, banyak jenis masalah lainnya, seperti rendahnya
keterbacaan logger dan penyetelan parameter terkait kinerja, masih tidak dapat dideteksi secara
otomatis. Oleh karena itu, penelitian lebih lanjut diperlukan untuk memfasilitasi konfigurasi log
sehingga mereka dapat berevolusi bersama dengan komponen SUS lainnya.
4.1.2 Overhead Kinerja.Di satu sisi, analisis log yang efektif memerlukan log kaya yang dihasilkan
oleh eksekusi cuplikan LC yang diinstrumentasi. Di sisi lain, instrumentasi log yang berlebihan akan
menyebabkan overhead performa runtime dan memengaruhi pengalaman pelanggan. Tantangan
ini adalah tentang bagaimana menyeimbangkan biaya kinerja dan manfaat dari instrumentasi log.
Tiga jenis solusi berikut telah diusulkan untuk tantangan ini:
• Solusi berbasis pasca-pemrosesan: Untuk mengurangi biaya I/O yang terkait dengan logging
konvensional, solusi berbasis pasca-pemrosesan telah diusulkan. Gagasan utamanya adalah menunda
keluaran pesan log hanya jika diperlukan. NanoLog [125] adalah sistem logging skala nanodetik yang
diimplementasikan dalam C++. Ini pertama-tama menganalisis kode sumber secara statis selama waktu
kompilasi dan menghasilkan fungsi kompresi untuk setiap cuplikan LC. Selama runtime, hanya pesan
log ringkas yang akan dibuat. Versi tekstual lengkap dari pesan log hanya akan dihasilkan selama waktu
pasca-pemrosesan. Dengan cara ini, NanoLog dapat mencapai urutan besarnya 1–2 lebih cepat daripada
pustaka logging konvensional (misalnya, Log4J 2 [14], splog[20]). Demikian pula,Log++ [100] adalah
sistem logging yang mengoptimalkan performa logging untuk platform Node.js dengan menunda
pembuatan log secara offline.
Solusi berbasis pasca-pemrosesan diterapkan diPenebangan Konvensionalsub-langkah dalam
langkah Pendekatan Logging. Meskipun solusi yang diusulkan lebih cepat daripada pustaka
logging yang ada, namun terbatas pada bahasa pemrograman tertentu (C++ dan Javascript).
Selain itu, solusi ini tidak akan berlaku jika log juga digunakan untuk tujuan analisis real-time
(misalnya pemantauan), karena analisis real-time mengharuskan log segera tersedia untuk
berbagai alat otomatis. Oleh karena itu, runtime akan sama dengan pendekatan logging
konvensional yang umum.
• Solusi berbasis sampel: Salah satu masalah utama yang terkait dengan pelacakan terdistribusi adalah biaya kinerja yang
dibebankan ke SUS. Banyak LU (misalnya, Dapper Google [120] atau Kanopi Facebook [79]) menerapkan pendekatan
logging berbasis pelacakan terdistribusi biasanya mendukung pengambilan sampel, yang merupakan teknik untuk
menghasilkan dan mempertahankan pesan log secara selektif untuk mengurangi overhead runtime. Ada tiga teknik
pengambilan sampel: pengambilan sampel berdasarkan kepala, pengambilan sampel berdasarkan ekor, dan
pengambilan sampel kesatuan [114,119]:
—Pengambilan Sampel Berbasis Kepala: Keputusan pengambilan sampel dibuat di awal setiap penelusuran. Entah itu
mempertahankan seluruh jejak (termasuk setiap titik jejak) atau tidak ada jejak sama sekali. Teknik pengambilan
sampel berbasis kepala dapat dibagi lagi menjadi tiga jenis teknik pengambilan sampel berikut: (1)Sampling
probabilitas, yang membuat keputusan pengambilan sampel berdasarkan probabilitas yang telah ditentukan
sebelumnya; (2)Pengambilan sampel batas-tingkat, yang membuat keputusan pengambilan sampel berdasarkan
pada tingkat pengambilan sampel yang telah ditentukan sebelumnya; dan (3)Pengambilan sampel adaptif, yang secara dinamis
menyesuaikan keputusan pengambilan sampel selama runtime.
—Sampling berbasis ekormembuat keputusan sampling pada akhir setiap jejak. Dibandingkan dengan
pengambilan sampel berbasis kepala, itu dapat membuat keputusan yang lebih tepat setelah semua jejak
yang dikumpulkan tersedia. Oleh karena itu, pengembang dapat lebih memperhatikan jejak yang mungkin
mengandung anomali dan membuang jejak normal yang berulang. Namun, pengambilan sampel berbasis
ekor tidak didukung oleh banyak LU karena persyaratan sumber dayanya yang tinggi pada memori/disk
untuk menyimpan sementara semua jejak yang dihasilkan.
—Pengambilan sampel kesatuanmembuat keputusan pengambilan sampel di setiap titik jejak. Oleh karena itu, jejak
lengkap tidak dapat dipulihkan melalui pendekatan ini. Teknik ini hanya memiliki skenario penggunaan yang sangat
terbatas.
Solusi berbasis pengambilan sampel diterapkan diPelacakan Terdistribusisub-langkah dalam langkah
Pendekatan Logging dancara mengkonfigurasisub-langkah dalam langkah integrasi LU. Ini adalah solusi yang
diadopsi secara luas dalam praktiknya untuk mengurangi overhead kinerja dalam pelacakan terdistribusi.
Kelemahan dari solusi berbasis pengambilan sampel adalah bahwa log penting dapat disaring karena tingkat
pengambilan sampel yang rendah. Namun, dalam SUS throughput tinggi, kejadian penting pada akhirnya akan
ditangkap. SUS throughput rendah direkomendasikan untuk mempertahankan setiap jejak jika sistem tidak
toleran terhadap informasi yang hilang [120].
• Solusi berbasis optimalisasi biaya: Tiga solusi berbasis optimalisasi biaya telah
diusulkan untuk menentukan titik instrumentasi optimal di SUS di bawah ambang
batas tertentu:
—Teori Informasi: Untuk memulihkan jalur eksekusi dengan lebih baik menggunakan pesan log, Zhao
et al. [131,132] mengusulkanLog20, yang merupakan alat untuk menyisipkan cuplikan LC secara
otomatis. Untuk mengevaluasi kemampuan tersebut, konsep entropi digunakan. Entropi berasal dari
teori informasi Shannon. Dalam konteks diagnosis masalah, semakin tinggi entropi, semakin tidak
pasti jalur eksekusi yang ada dalam blok kode. Pada saat yang sama, biaya performa cuplikan LC yang
diinstrumentasi tidak boleh melebihi ambang batas yang disesuaikan untuk meminimalkan overhead
performa. Poin logging terbaik adalah yang menyelesaikan sebagian besar ketidakpastian selama
diagnosis masalah dalam rentang overhead kinerja yang dapat diterima.
—Pemecahan Kendala: Untuk secara dinamis mengontrol overhead kinerja, Ding et al. [54]
mengusulkan metode pemecahan kendala untuk menentukan titik logging optimal yang
menghasilkan overhead kinerja minimum dengan jumlah maksimum informasi runtime.
Pendekatan ini menyediakan konfigurasi yang secara dinamis menyesuaikan jenis pesan log
yang dikeluarkan selama runtime berdasarkan kinerja SUS.
—Pemodelan Statistik: Untuk memantau kinerja SUS dengan lebih baik, Yao et al. [126]
mengusulkan Log4Perf untuk menyarankan poin logging. Mereka pertama membangun model
kinerja dengan menjalankan tes kinerja. Melalui model ini, cuplikan kode sumber yang
memengaruhi kinerja diidentifikasi. Untuk semua metode dalam kode sumber, titik masuk dan
titik keluar dilengkapi dengan cuplikan LC. Setelah menjalankan ulang pengujian kinerja,
metode yang menghabiskan waktu eksekusi konstan diidentifikasi dan potongan LC terkait
dihapus. Kumpulan cuplikan LC yang tersisa akan membantu pengembang dalam
mendiagnosis dan mengoptimalkan kinerja sistem dengan meningkatkan visibilitas masalah
kinerja.
Solusi berbasis optimalisasi biaya diterapkan didi mana-untuk-logsub-langkah dalam langkah Komposisi
LC. Mereka mampu mengurangi overhead kinerja yang disebabkan oleh instrumentasi log sambil
mempertahankan kemampuan mereka untuk tugas-tugas seperti pemulihan jalur kode dan analisis
kinerja. Namun, log digunakan di banyak skenario lain (misalnya, kepatuhan keamanan). Penting untuk
memperluas masalah pengoptimalan mutli-objektif ini ke faktor logging lainnya.
4.2 Dapat didiagnosis

Diagnosability adalah sejauh mana praktisi dapat memanfaatkan instrumentasi log untuk mendiagnosis
masalah sistem, fungsional atau non-fungsional. Lebih sering, log adalah satu-satunya sumber yang diandalkan
oleh praktisi untuk tugas ini. Namun, sekitar sepertiga dari instrumentasi log dilakukan secara ad hoc [42,128],
yang menyiratkan bahwa praktisi sering menambahkan instrumentasi log setelah mereka menyadari kurangnya
informasi. Hal ini akan menyebabkan keterlambatan diagnosis dan potensi kerugian finansial. Oleh karena itu,
dalam subbagian ini, kami akan menjelaskan dua tantangan dalam diagnosa (diagnosis kegagalan dan analisis
kinerja) dan solusi yang sesuai untuk mengatasinya.
4.2.1 Diagnosis Kegagalan.Praktisi sering memanfaatkan log untuk diagnosis kegagalan. Mereka sering
memulai dengan memetakan log ke cuplikan LC dan bekerja mundur untuk memahami jalur kode yang
dieksekusi selama runtime. Namun, jika informasi yang direkam dalam log tidak cukup untuk menunjukkan
dengan tepat jalur kode yang dieksekusi dengan tepat, sejumlah jalur yang mungkin perlu diidentifikasi dan
dianalisis secara menyeluruh untuk menyimpulkan jalur sebenarnya. Ini secara dramatis akan meningkatkan
waktu analisis dan merusak kualitas produk. Oleh karena itu, teknik instrumentasi log proaktif diperlukan untuk
mengidentifikasi poin-poin program utama yang perlu diinstrumentasi. Dua solusi berikut telah diusulkan untuk
mengatasi tantangan diagnosis kegagalan:
• Solusi berbasis pembuatan aturan: Cinque dkk. [49] menemukan bahwa kualitas data telemetri yang dihasilkan
memiliki korelasi kuat dengan kemampuan untuk melaporkan kegagalan, yang menyoroti pentingnya kualitas
log. Termotivasi oleh temuan, mereka [51,52] meringkas lebih lanjut delapan aturan umum untuk instrumentasi
log dengan mempelajari artefak desain sistem seperti model arsitektur dan diagram UML. Untuk melakukan ini,
pertama-tama mereka mengabstraksi artefak-artefak ini ke dalam model representasi sistem, yang terdiri dari
interaksi di antara sekumpulan entitas dalam sistem. Kemudian aturan untuk cuplikan LC instrumentasi disusun
untuk merekam interaksi kunci, yang harus mencakup data yang diperlukan untuk diagnosis kegagalan. Aturan
ini dirancang untuk memenuhi kebutuhan diagnosis empat jenis kegagalan fungsional: (1) kesalahan layanan,
(2) keluhan layanan, (3) kesalahan interaksi, dan (4) kesalahan crash. Misalnya, ketika sebuah layanan tidak
dapat mencapai titik keluar, itu dianggap sebagai kesalahan layanan. Untuk menangani kesalahan seperti itu,
kejadian awal layanan dan akhir layanan harus dicatat dalam log. Kesalahan kerusakan mengacu pada
penghentian entitas yang tidak normal. Untuk menangani kesalahan seperti itu, cuplikan LC detak jantung
perlu dipanggil secara berkala untuk memantau eksekusi layanan.
Baccanico dkk. [28] menemukan beberapa masalah penebangan yang ada di Selex ES, sebuah perusahaan
Finmeccanica terkemuka. Mereka mengusulkan untuk menggunakan kebijakan logging, yaitu seperangkat aturan,
untuk mendukung rekayasa ulang log di semua tim produk. Sebagai contoh, mereka mengusulkan bahwa pernyataan
logging pelaporan kesalahan harus dimasukkan setelah memeriksa pernyataan. Mereka bertujuan untuk mendukung
diagnosis kegagalan dengan meningkatkan instrumentasi log melalui pendekatan berbasis aturan.
Varvaressos et al. [123] mengusulkan kerangka kerja berbasis aturan untuk mendeteksi bug di video
game. Mereka meningkatkan proses instrumentasi tradisional dengan mengidentifikasi properti utama
video game. Artinya, setiap video game memiliki loop game utama dan karenanya satu-satunya tempat
yang perlu diinstrumentasi. Peristiwa penting yang mewakili status program dapat ditangkap. Mereka
menginstrumentasi lima game menggunakan aturan yang sama: mengidentifikasi loop game,
menginstrumentasi instruksi template, dan memeriksa apakah properti (diwakili sebagai serangkaian
status game) dilanggar. Kerangka instrumentasi log ini mampu mendeteksi bug yang ada dari video
game yang dipelajari dengan tepat.
Solusi berbasis Rule-generation-based diterapkan diLogging berbasis aturansub-langkah dalam
langkah Pendekatan Logging. Ini membantu melengkapi instrumentasi log yang ada di SUS
dengan memasukkan instrumentasi log secara otomatis sesuai dengan aturan yang dibuat.
Overhead instrumentasi tambahan juga dikendalikan pada tingkat yang dapat diterima. Namun, semua
pendekatan di atas menghasilkan aturan secara manual dan memerlukan pengetahuan domain yang
mendalam. Oleh karena itu, bidang penelitian masa depan yang menarik adalah menyelidiki pendekatan
otomatis untuk menemukan dan memperbarui aturan berdasarkan perilaku runtime SUS dan masalah historis.
• Solusi berbasis analisis program: Analisis program [106] adalah teknik yang menganalisis
perilaku SUS secara otomatis melalui statis [33] atau analisis dinamis [105]. Kedua jenis
teknik telah digunakan untuk memfasilitasi diagnosis kegagalan fungsional:
—Analisis statisberbasis teknik menganalisis kode sumber tanpa mengeksekusi SUS. Ada banyak alat
analisis program, yang secara otomatis memindai melalui kode sumber SUS, seperti keluaran
representasi abstrakAST (pohon sintaksis abstrak)dan grafik panggilan, dan mengungkapkan
kekurangan dalam kode sumber. Misalnya, grafik panggilan dapat dianalisis lebih lanjut untuk
mengidentifikasi titik logging yang cocok untuk diagnosis kegagalan. Yuan dkk. telah melakukan dua
pekerjaan sebelumnya untuk meningkatkan diagnosis kegagalan dengan memanfaatkan analisis
statis [127, 129]. Misalnya, mereka menyelidiki 250 laporan bug dan mencirikan pola pengecualian
yang memerlukan pencatatan tambahan [127]. Alat pemeriksaan statis, Errlog, diusulkan untuk
memindai basis kode untuk jenis blok pengecualian ini dan secara otomatis memperlengkapi
cuplikan LC untuk merekam lokasi kesalahan dan konteks kesalahan. Mereka juga mengusulkan
LogEnhancer [127] untuk melengkapi variabel tambahan dalam cuplikan LC yang ada. Variabel-
variabel ini diekstraksi dengan menganalisis aliran kontrol dan aliran data dari kode sumber SUS
secara statis, sehingga pesan log dapat berisi informasi runtime lengkap untuk memutar ulang dan
mendiagnosis konteks kegagalan secara dekat. Berbeda dari pendekatan di atas, di mana titik
logging disarankan secara manual satu per satu, SmartLog [73] diusulkan untuk melengkapi cuplikan
LC secara otomatis dengan memanfaatkan teknik penambangan data pada hasil analisis statis.
Konteks (misalnya, fungsi yang berada) dari cuplikan LC dianalisis untuk menghasilkan model niat
log. Model niat log mewakili keputusan logging (alias apakah cuplikan LC ini dicatat atau tidak dicatat)
dari cuplikan kode. Model penambangan data kemudian dilatih pada kumpulan data tersebut dan
selanjutnya digunakan untuk menyarankan poin program untuk instrumentasi log.
—Analisis Dinamisteknik berbasis menyarankan titik logging dengan menganalisis perilaku
runtime SUS. Dibandingkan dengan teknik berbasis analisis statis, teknik berbasis analisis
dinamis perlu mengeksekusi SUS. Data keluaran yang dihasilkan oleh eksekusi kemudian
dianalisis untuk berbagai tugas. Informasi yang ambigu dan hilang dalam output mengarah
kembali ke saran logging. Oleh karena itu, solusi berbasis analisis dinamis biasanya terdiri dari
tiga langkah:
(1)Menjalankan SUS di bawah pengaturan yang berbeda: Pengembang dapat menyuntikkan kesalahan yang disesuaikan
ke dalam SUS atau hanya menjalankan dengan beban kerja umum. Tujuan langkah ini adalah untuk mengumpulkan
data keluaran, seperti pesan log, pelacakan tumpukan, dan dump memori.
(2)Analisis log: Tujuan dari langkah ini adalah untuk memeriksa apakah data keluaran saat
ini mampu mendiagnosis kegagalan. Jika tidak, maka informasi yang hilang menunjukkan
titik-titik logging potensial dan variabel kunci apa yang perlu dicatat.
(3)Perbarui instrumentasi: Instrumentasi tambahan akan dilakukan pada SUS. Kemudian
percobaan yang sama dari langkah 1 akan dijalankan lagi. Tujuan dari langkah ini adalah untuk
mengevaluasi apakah LC yang baru diinstrumentasi dapat memperbaiki proses diagnosis
kegagalan.
Ada tiga karya penelitian yang memanfaatkan teknik berbasis analisis dinamis untuk menyarankan
poin logging tambahan. Cinque dkk. [50] mengusulkan teknik untuk meningkatkan diagnosa
kegagalan pesan log. Mereka pertama menyuntikkan kesalahan ke dalam tiga proyek open source
populer dan mengeksekusi SUS untuk mengumpulkan pesan log dan dump memori. Menganalisis
data keluaran, mereka meringkas 10 fungsi teratas yang sering dieksekusi dari kegagalan berhenti dan
kegagalan senyap. Cuplikan LC tambahan dimasukkan ke dalam fungsi ini. Crameri et al. [53] juga
mengusulkan teknik serupa untuk menyarankan cabang mana yang akan ditebang. Mereka pertama kali
mengeksekusi SUS dengan input berbeda menggunakan mesin simbolik. Setelah setiap proses berakhir,
mereka merekam batasan antara variabel simbolik dan cabang yang dieksekusi. Instrumentasi log tambahan
dilakukan dengan mengidentifikasi asosiasi cabang dan variabel yang dieksekusi. Jia et al. [72] mengusulkan
pendekatan untuk memasukkan potongan LC untuk memudahkan lokalisasi kesalahan. Mereka pertama kali
menjalankan SUS dengan kesalahan yang disuntikkan. Kemudian mereka membandingkan pesan log antara
proses yang berhasil dan proses yang gagal untuk mengidentifikasi variabel kunci untuk dicatat. Solusi
berbasis analisis program diterapkan didi mana-untuk-logdanapa yang harus dicatatsublangkah dalam langkah
komposisi LC.
Teknik berbasis analisis statis membutuhkan biaya rendah, karena analisis dapat dijalankan secara
offline. Teknik berbasis analisis dinamis dapat memberikan hasil yang lebih akurat, karena didasarkan
pada eksekusi nyata, bukan inferensi offline. Namun, dengan siklus rilis perangkat lunak yang cepat saat
ini, kedua pendekatan perlu sering dijalankan ulang untuk mencerminkan perubahan kode fitur. Oleh
karena itu, untuk mencegah hasil menjadi basi, diperlukan alat untuk mengintegrasikan solusi ini ke
dalam proses Continuous Integration/Continuous Delivery.
4.2.2 Analisis Kinerja.Masalah kinerja sering kali disebabkan oleh interaksi antar komponen
perangkat lunak yang berbeda. Dengan semakin populernya aplikasi cloud native dan arsitektur
layanan mikro, satu sistem dapat berisi ratusan atau bahkan ribuan layanan kecil, banyak di
antaranya dikembangkan oleh tim teknik yang berbeda. Log yang dihasilkan oleh pendekatan
logging tradisional tidak cukup untuk menganalisis masalah performa, karena kurangnya
informasi kontekstual membuat tidak mungkin merekonstruksi urutan kejadian. Tanpa informasi
tersebut, sangat sulit untuk menentukan hambatan kinerja.
Solusi berbasis pelacakan kausalitas diterapkan diPelacakan Terdistribusisub-langkah di langkah Pendekatan
Logging dan didi mana-untuk-logdanapa yang harus dicatatdalam langkah Komposisi LC. Mereka dirancang
untuk melengkapi dan menyimpan data kontekstual dalam log untuk memfasilitasi analisis kinerja yang
kompleks. Mereka diadopsi secara luas dalam sistem perangkat lunak terdistribusi modern. Ada satu solusi
yang diusulkan untuk mengatasi tantangan analisis kinerja:
• Solusi berbasis pelacakan kausalitasUntuk mengaktifkan analisis kinerja end-to-end menyeluruh, solusi
berbasis pelacakan kausalitas diusulkan. Secara khusus, pelacakan kausalitas dilakukan dengan dua
cara [114,119]:
—Teknik berbasis skema: Teknik berbasis skema mengkorelasikan log yang relevan berdasarkan aturan yang
telah ditentukan sebelumnya [29,30,47,68]. Pengembang perlu merancang skema acara untuk bergabung
dengan acara individu untuk merekonstruksi permintaan lengkap. Misalnya acaraSEBUAHdan acaraBberbagi
nilai variabel yang samax,peristiwaBdan acaraCberbagi nilai variabel yang samay,kemudian acaraA, B,danC
akan bergabung. Kausalitas kemudian diputuskan melalui hubungan kejadian-sebelum.
—Teknik berbasis propagasi: Teknik berbasis propagasi melacak kausalitas dalam

permintaan dengan menyebarkan metadata konteks di antara komponen yang
diinstrumentasi. Jejak lengkap permintaan terdiri dari beberapa pesan log (yaitu, rentang)
yang ditautkan oleh metadata. Metadata berisi ID jejak global yang unik. Metadata
diteruskan saat permintaan mengalir dari satu komponen ke komponen lainnya. Selain ID
jejak global, ia juga merekam informasi lain yang diperlukan seperti ID induk untuk
menjaga hubungan kausalitas antara rentang individu. Format metadata harus mengikuti
standar atau protokol tertentu sehingga pengirim dan penerima dapat mengemas dan
membongkar informasi.
Sebagian besar kerangka penelusuran terdistribusi modern mengadopsi teknik berbasis propagasi
alih-alih teknik berbasis skema. Terdapat tiga alasan untuk ini:
• Overhead Kinerja: Teknik berbasis skema tidak mendukung pengambilan sampel, karena teknik tersebut tidak
dapat memutuskan pesan log mana yang akan dibuang tanpa mengorbankan kemampuan untuk melakukan
operasi gabungan. Oleh karena itu, untuk SUS yang menghasilkan pesan log dalam jumlah besar setiap hari,
akan terlalu mahal untuk mengadopsi teknik berbasis skema.
• Generalisasi: Teknik berbasis propagasi bersifat umum di berbagai SUS. Sebaliknya, untuk teknik
berbasis skema, pengembang perlu mengimplementasikan skema gabungan untuk setiap SUS yang
berbeda berdasarkan karakteristiknya, yang dapat memakan waktu dan rawan kesalahan.
• Umpan balik waktu nyata: Teknik berbasis skema sebagian besar dilakukan secara offline setelah
semua pesan log dikumpulkan. Untuk SUS yang membutuhkan pemantauan atau analisis dan
deteksi online, teknik berbasis propagasi lebih tepat.
4.3 Kualitas LC
Mengembangkan dan memelihara kode logging berkualitas tinggi sangat menantang, terutama di SUS
yang terus berkembang. Ada dua alasan utama: (1) Manajemen: pencatatan perangkat lunak merupakan
masalah lintas sektoral, yang terkait dengan kode fitur. Meskipun ada ekstensi bahasa (misalnya, AspectJ)
untuk mendukung manajemen kode logging yang lebih baik, banyak proyek industri dan open source
masih memilih untuk menggabungkan kode logging dengan kode fitur. (2) Verifikasi: tidak seperti kode
fitur atau jenis masalah lintas sektor lainnya (misalnya, penanganan pengecualian atau konfigurasi), yang
kebenarannya dapat diverifikasi melalui pengujian perangkat lunak; sangat menantang untuk
memverifikasi kebenaran kode logging. Dalam subbagian ini, kami menyajikan tiga tantangan yang
berkaitan dengan Kualitas LC: kejelasan, konsistensi, dan pemeliharaan. Untuk setiap tantangan,
4.3.1 Kejelasan.Ada dua komponen dalam cuplikan LC, yang menyediakan konteks pencatatan:
teks statis dan informasi dinamis. Teks statis umumnya menggambarkan sekitar konteks logging
(misalnya, "Transaksi selesai") sedangkan informasi dinamis, termasuk pemanggilan variabel dan
metode, menyediakan informasi/status runtime (misalnya, jumlah total untuk transaksi itu) dari
SUS. Teks statis yang tidak jelas dan informasi dinamis yang hilang akan menyebabkan
kebingungan dan bahkan menyesatkan keputusan pengembang. Namun, karena kejelasan
cuplikan LC biasanya tidak memengaruhi eksekusi normal SUS, sulit untuk mengidentifikasi
masalah kejelasan dalam cuplikan LC yang ada. Pendekatan otomatis untuk meningkatkan
kejelasan cuplikan LC diperlukan untuk memastikan kualitas LC.
Oleh karena itu, penting untuk mendeskripsikan dengan jelas konteks statis dari setiap cuplikan LC untuk
menghindari kebingungan dan menambahkan informasi dinamis yang sesuai di LC untuk menangkap konteks
runtime yang jelas. Ada tiga solusi yang dilaporkan dalam literatur. Solusi berbasis NLP diusulkan untuk
menghasilkan teks statis secara otomatis. Solusi berbasis visualisasi dan berbasis Entropi diusulkan untuk
mengklarifikasi informasi dinamis.
• Solusi berbasis NLP: Dia dkk. [66] melakukan studi tentang karakterisasi teks statis dari kode logging
menggunakanPemrosesan Bahasa Alami (NLP)teknik. Mereka menemukan bahwa teks statis dalam
cuplikan LC bersifat endemik, yaitu cuplikan LC dalam file yang sama atau dalam konteks yang sama
cenderung menggunakan teks statis serupa untuk menggambarkan perilaku program. Terinspirasi oleh
temuan ini, mereka mengusulkan solusi untuk menghasilkan teks statis secara otomatis untuk cuplikan
LC. Solusinya terdiri dari tiga langkah: (1) untuk cuplikan LC kandidat, cuplikan kode di sekitarnya (
Cuplikan A) diekstrak; (2) dalam kumpulan cuplikan kode yang berisi cuplikan LC, kami mengekstrak
cuplikan kode yang paling miripCuplikan Bdibandingkan denganCuplikan A. Kesamaannya adalah
dihitung dengan jarak Levenshtein; (3) teks statis dari cuplikan LC diCuplikan Bkemudian
digunakan sebagai teks statis dari cuplikan LC kandidat.
Solusi berbasis NLP diterapkan diapa yang harus dicatatsub-langkah dalam langkah Komposisi
LC. Solusi ini adalah pekerjaan pertama pada pembuatan teks statis otomatis dan dapat mencapai
skor BLEU dan ROUGE yang layak (dua metrik yang umum digunakan dalam studi NLP). Itu
memang menderita dari beberapa keterbatasan. Misalnya, cuplikan LC dalam cuplikan kode
serupa belum tentu memiliki teks statis yang sama, karena dalam metode yang berbeda. Teknik
lain seperti deteksi klon dan pembelajaran mendalam mungkin berguna untuk tugas ini.
• Solusi berbasis visualisasi: Rabkin dkk. [110] mengusulkan solusi berbasis visualisasi untuk menambahkan
variabel cuplikan LC yang hilang. Untuk setiap pesan log, pertama-tama mereka membuat representasi grafis
yang berisi semua pengenal di dalamnya (misalnya, ID transaksi atau operasi). Grafik pengidentifikasi kemudian
dibangun dengan menghubungkan pesan log dengan pengidentifikasi yang sama. Karena pengidentifikasi
dapat hilang, tidak konsisten, atau ambigu, grafik pengidentifikasi dapat digunakan untuk memvisualisasikan
kekurangan. Misalnya, pesan log dengan pengidentifikasi yang tidak memadai akan menyebabkan tepi yang
hilang dalam grafik, di mana semantik kode sumber menunjukkan bahwa tepi tersebut seharusnya ada.
Berdasarkan temuan tersebut, saran seperti menambahkan pengidentifikasi yang hilang dibuat untuk
meningkatkan kejelasan cuplikan LC. Mereka mengevaluasi solusi ini dalam tiga proyek open source populer
dan mendemonstrasikannya dapat secara efektif menunjukkan kekurangan dalam cuplikan LC. Solusi berbasis
visualisasi diterapkan diapa yang harus dicatatsub-langkah dalam langkah Komposisi LC. Ini mudah dan mudah
diterapkan. Namun, ini memerlukan upaya manual untuk memeriksa visualisasi dan karenanya tidak dapat
menskalakan cuplikan LC dalam volume besar.
• Solusi berbasis entropi: Salfner et al. [113] mengusulkan solusi berbasis entropi untuk mengukur
kelengkapan dan ekspresi log. Mereka mendefinisikan satu set metrik dengan mengadaptasi
entropi informasi Shannon ke konteks log. Hal ini memungkinkan praktisi untuk membandingkan
kejelasan cuplikan LC yang berbeda. Mereka mengevaluasi solusi ini pada kumpulan log nyata
yang diambil dari wadah Java Enterprise Beans. Hasil menunjukkan bahwa informasi tertentu
dianggap berlebihan dan harus dihapus dengan hati-hati. Solusi berbasis entropi diterapkan di
apa yang harus dicatatsub-langkah dalam langkah Komposisi LC. Mengukur kejelasan log
berguna bagi praktisi untuk membuat keputusan yang tepat tentang cara meningkatkan cuplikan
LC. Namun, diperlukan teknik otomatis yang mendukung proses peningkatan untuk cuplikan LC
lawas.
4.3.2 Konsistensi.Konsistensi cuplikan LC menunjukkan apakah lokasi, konten, atau gaya cuplikan LC
seragam. Karena cuplikan LC biasanya tersebar di seluruh basis kode, sulit untuk mengidentifikasi dan
memperbaiki ketidakkonsistenan yang ada. Cuplikan LC yang konsisten umumnya memiliki tiga manfaat: (1)
dalam fase instrumentasi, ini membantu pengembang membuat keputusan berdasarkan informasidi mana-
untuk-log,apa yang harus dicatat, dancara login; (2) dalam waktu proses, kehilangan informasi dihindari dengan
tingkat verbositas yang konsisten; dan (3) pada fase operasi, log yang konsisten dapat memfasilitasi analisis
otomatis seperti diagnosis kegagalan dan analisis kinerja.
Ada dua solusi yang diusulkan untuk memastikan konsistensi cuplikan LC: solusi berbasis
pembelajaran mesin dan solusi berbasis kloning kode:
• Solusi berbasis pembelajaran mesin: Karena logging meresap dalam perangkat lunak [42,128], wajar untuk
menerapkan teknik pembelajaran mesin untuk belajar secara otomatis dari praktik yang ada dan memberikan
wawasan yang bermanfaat. Bergantung pada tujuan tugas, ada dua jenis ML yang umum: pembelajaran yang
diawasi dan pembelajaran yang tidak diawasi. Pembelajaran yang diawasi membutuhkan data pelatihan untuk
memiliki label yang tersedia dan memprediksi label data baru. Namun,
pembelajaran tanpa pengawasan tidak memerlukan data pelatihan untuk memiliki label. Ini sebagian besar digunakan untuk
menurunkan pola dalam kumpulan data.
—Pembelajaran yang diawasiteknik diadopsi untuk membantu komposisi LC, karena tujuannya adalah
memberi label jika cuplikan kode harus dicatat (di mana-untuk-masuk)atau jika tingkat variabel/
verbositas tertentu harus digunakan untuk logging (apa yang harus dicatat).Proses umum biasanya
terdiri dari empat langkah berikut: (1)Pengumpulan data:Langkah ini untuk mengumpulkan data
pelatihan untuk melakukan tugas. Data pelatihan terdiri dari sekumpulan instance dengan label; (2)
Rekayasa fitur:Langkah ini untuk mengekstraksi fitur yang menggambarkan instance. Fitur-fitur ini
adalah masukan untuk model pembelajaran mesin; (3)Model bangunan:Langkah ini untuk
membangun model pembelajaran mesin dari data pelatihan berlabel. Parameter disetel pada
langkah ini untuk meningkatkan performa model; dan (4)Membuat prediksi:Langkah ini menerapkan
model pada data baru untuk memprediksi label. Langkah ini merupakan keluaran akhir dari proses
pembelajaran terbimbing.
Teknik pembelajaran yang diawasi telah diterapkan dalam dua sub-langkah berikut dalam
fase komposisi LC:
* Memprediksi di mana-untuk-log: Fu dkk. [60] mengusulkan teknik untuk memprediksi apakah
cuplikan kode harus dicatat. Secara khusus, mereka berfokus pada dua jenis cuplikan kode:
menangkap blok dankembali-nilai-cekblok. Setiap cuplikan kode yang dicatat atau tidak dicatat
dikumpulkan dan diberi label. Kata kunci kontekstual, seperti nama fungsi yang berada, kemudian
dikumpulkan sebagai fitur. Model pohon keputusan dibangun untuk tugas berdasarkan fitur yang
dikumpulkan. Mereka mengevaluasi solusi pada dua sistem Microsoft dan mencapai lebih dari 80%
presisi dan daya ingat. Zhu dkk. [137] mengusulkan LogAdvisor, yang meningkatkan teknik
sebelumnya dengan mengumpulkan lebih banyak jenis fitur. Fitur-fiturnya termasuk fitur
struktural, yang merupakan kata kunci kontekstual, fitur tekstual, yang dihasilkan dengan
mengubah cuplikan kode menjadi kata-kata bertangkai, dan fitur sintaksis, yang merupakan
properti dari cuplikan kode seperti total baris potongan kode . Selain itu, mereka juga menyertakan
proses baru seperti penanganan kebisingan dan evaluasi lintas proyek. Studi pengguna
menunjukkan 70% peserta menganggap saran yang dibuat oleh LogAdvisor bermanfaat. Lal et al.
mengusulkan teknik serupa menggunakan serangkaian fitur yang berbeda untuk memprediksi
penyisipan cuplikan LC dalam dua jenis blok kode:menangkap blok [89] danjikablok kode [88]. Li
dkk. [91] menggunakan topik yang dihitung secara otomatis untuk mendeskripsikan fungsionalitas
cuplikan kode. Informasi ini kemudian digunakan sebagai fitur tambahan untuk model
pembelajaran mesin yang sudah ada, yang digunakan untuk memprediksi apakah cuplikan kode
perlu dicatat. Hasil menunjukkan bahwa fitur berbasis topik sangat membantu dalam menjelaskan
kemungkinan instrumentasi log. Dengan fitur ini, nilai AUC dan balanced akurasi meningkat lebih
dari 10%. Selain potongan kode, mereka [93] juga mengusulkan teknik serupa untuk memprediksi
apakah komit baru memerlukan perubahan tepat waktu untuk cuplikan LC.
* Memprediksi apa yang akan dicatat: Teknik pembelajaran yang diawasi juga digunakan
untuk memprediksi modifikasi konten dalam cuplikan LC. Mereka dapat dibagi lagi menjadi
dua area berikut tergantung pada jenis komponen logging:
. Tingkat verbositas: Li dkk. [92] mengusulkan untuk merekomendasikan tingkat verbositas yang
paling sesuai untuk cuplikan LC yang baru ditambahkan. Karena ada lebih dari dua tingkat
verbositas untuk cuplikan LC, mereka membuat model regresi ordinal untuk tugas ini. Mereka
mengumpulkan data pelatihan dari riwayat pengembangan dan mengumpulkan tiga jenis fitur:
metrik file, metrik perubahan, dan metrik historis. Hasil menunjukkan bahwa model
mengungguli model baseline. Fitur seperti karakteristik blok penampung cuplikan LC yang baru
ditambahkan dan cuplikan LC yang ada di sumber penampung
file kode penting dalam menjelaskan prediksi. Kim dkk. [83] mengusulkan untuk menggunakan
fitur semantik cuplikan LC untuk memvalidasi konsistensi tingkat verbositas. Mereka pertama-
tama mengumpulkan set fitur yang serupa seperti Li et al. [92]. Selain itu, mereka menerapkan
word2vecmodel untuk menghasilkan penyisipan kata dari cuplikan LC sebagai fitur semantik.
Kemudian mereka membangun model randomforest dan KNN sebagai pengklasifikasinya. Hasil
menunjukkan bahwa teknik ini mencapai lebih dari 85% presisi dan daya ingat.
. Konten Dinamis: Liu dkk. [97] menyajikan teknik berbasis pembelajaran mendalam untuk
merekomendasikan variabel dalam cuplikan LC. Berbeda dengan memprediksi tingkat verbositas, yang
memiliki kumpulan label tetap, variabel dalam cuplikan LC dipilih dari kumpulan kandidat yang
dinamis. Selain itu, nama variabel mungkin tidak ada dalam dataset pelatihan, yang dikenal sebagai
masalah “out-of-vocabulary”. Untuk mengatasi masalah pertama, pertama-tama mereka menggunakan
jaringan saraf denganRNN (jaringan saraf berulang)layer dan layer perhatian diri untuk mempelajari
representasi dari setiap token program dan memprediksi token mana yang harus disertakan dalam
cuplikan LC menggunakan pengklasifikasi biner. Untuk mengatasi masalah kedua. mereka memetakan
token program ke penyisipan kata dari token bahasa alami. Mereka mengevaluasi teknik tersebut pada
sembilan proyek sumber terbuka dan menunjukkan bahwa teknik tersebut mengungguli metode dasar
dengan margin yang besar.
—Pembelajaran tanpa pengawasanditerapkan untuk membantu modifikasi cuplikan LC pada langkah
cara login.Li dkk. [94] menemukan bahwa cuplikan LC dengan konteks serupa cenderung berbagi
modifikasi serupa. Terinspirasi oleh temuan ini, mereka mengusulkan LogTracker, teknik berbasis
pengelompokan untuk mempelajari aturan revisi log secara otomatis. Untuk setiap instance cuplikan
LC, fitur dihasilkan dari semantik konteks. Kemudian mereka menerapkan algoritma pengelompokan
hierarkis agglomerative untuk menambang aturan revisi log. Aturan revisi log kemudian digunakan
untuk menyarankan modifikasi pada cuplikan LC dalam grup serupa. Lebih dari 65% masalah yang
dilaporkan terdeteksi oleh LogTracker telah dikonfirmasi dan diperbaiki.
Solusi berbasis pembelajaran mesin diterapkan pada ketiga sub-langkah komposisi LC. Mereka dapat
membantu praktisi membuat keputusan logging yang terinformasi tanpa intervensi manual. Namun, umumnya
mereka mengandalkan ukuran dan kualitas data logging yang ada. Oleh karena itu, mereka mungkin tidak
berlaku untuk proyek baru atau berukuran kecil.
• Solusi berbasis Kloning Kode: Ide dari solusi berbasis kloning kode adalah untuk memvalidasi kualitas LC
dengan mencari cuplikan LC yang serupa. Misalnya, Yuan dkk. [128] mengusulkan teknik berbasis
kloning kode untuk memperbaiki tingkat verbositas yang tidak konsisten dalam cuplikan LC. Mereka
pertama-tama mengekstrak semua grup klon kode dan mengidentifikasi grup cuplikan kode yang berisi
cuplikan LC. Jika dalam grup klon yang sama, cuplikan LC memiliki tingkat verbositas yang tidak
konsisten, maka setidaknya salah satunya dianggap salah. Solusi berbasis kloning kode diterapkan di
cara loginsub-langkah dalam langkah Komposisi LC. Meskipun solusi berbasis kloning kode langsung
dan mudah diimplementasikan, kemampuannya terbatas. Ini karena tidak semua cuplikan kode yang
berisi cuplikan LC memiliki klon [43].
4.3.3 Pemeliharaan.Tantangan pemeliharaan adalah mengenai masalah mendukung evolusi dan

pemeliharaan LU dan LC. Karena instrumentasi log merupakan masalah lintas sektoral, menjaga agar kode
logging tetap diperbarui dengan kode fitur saat ini berkembang dengan cepat merupakan tantangan. Cuplikan
LC yang diinstrumentasi dapat menjadi usang, tidak mencukupi, dan menyesatkan karena kurangnya
pemeliharaan berkelanjutan. Meskipun banyak proyek menggunakan LU tujuan umum, beberapa LU digunakan
khusus untuk meningkatkan pemeliharaan LC [87]. Misalnya, Bartsch dan Harrison [32] bandingkan SUS yang
ditulis dalam Berorientasi Objek dengan Berorientasi Aspek. Mereka menyimpulkan bahwa pemisahan yang
jelas dari masalah penebangan memiliki dampak positif pada pemeliharaan LC. Pencatatan JBoss [71]
mendukung banyak bahasa yang dapat dibaca manusia di log dengan menyediakan
API terkait internasionalisasi. Sangat umum untuk menemukan LU saat ini tidak memenuhi kebutuhan
perangkat lunak yang terus berkembang. Oleh karena itu, pengembang [77] memigrasikan LU untuk
fleksibilitas, kinerja, dan pemeliharaan yang lebih baik. Namun, lebih dari 70% proyek yang berhasil
dimigrasikan mungkin mengalami bug pascamigrasi. Studi yang ada menunjukkan bahwa logging tersebar luas
dan cuplikan LC sering diperbarui sebagai pertimbangan untuk mencerminkan perubahan kode fitur [40–43,128
,130]. Sebagian besar cuplikan LC telah diubah setidaknya sekali selama siklus hidupnya [78]. Ada dua jenis
solusi yang dilaporkan dalam literatur yang ada untuk meningkatkan kemampuan pemeliharaan:
• Solusi berbasis Bahasa khusus domain: Salah satu masalah utama yang terkait dengan logging berbasis
aturan adalah kurva pembelajaran yang curam [44]. Untuk memudahkan upaya migrasi dari
penebangan konvensional ke penebangan berbasis aturan, Bruntink et al. [35] dan Mohammadian et al.
[26] mengusulkan teknik untuk dengan mudah mengungkapkan masalah logging dengan cara
termodulasi dalam bahasa khusus domain. Kekhawatiran ini dapat dihasilkan ke AspectC [23] kode dan
kemudian dihapus dari basis kode asli. Solusi berbasis Bahasa Khusus Domain diterapkan diLogging
berbasis aturansub-langkah dalam langkah Pendekatan Logging. Ini menyediakan utilitas untuk
mengotomatiskan pemisahan masalah dan mengurangi kesulitan teknis penerapan logging berbasis
aturan. Namun, proses ini masih memerlukan pengetahuan domain yang mendalam dan dengan
demikian sulit untuk diperluas ke sistem lain.
• Solusi berbasis sejarah: Tanpa perawatan yang hati-hati, jumlah snippet LC yang kedaluwarsa akan
bertambah seiring berkembangnya SUS. Cuplikan LC yang kedaluwarsa ada karena berbagai alasan.
Pertama, karena cuplikan LC sebagian besar disusun secara manual, kesalahan manusia (mis. kesalahan
ketik dalam teks statis) tidak dapat dihindari. Selain itu, karena cuplikan LC tersebar di seluruh basis
kode dan memotong dengan kode fitur, sulit untuk melacaknya secara efisien. Karena SUS berkembang
pesat, pengembang mungkin lupa memperbarui LC sesuai dengan kode fitur. Oleh karena itu,
diperlukan solusi untuk memelihara LC secara otomatis. Karya-karya yang ada [41,65, 95] terutama
mengandalkan riwayat pengembangan untuk memandu pemeliharaan cuplikan LC. Mereka biasanya
terdiri dari langkah-langkah berikut:
(1) Periksa riwayat pengembangan, misalnya, perubahan kode dan laporan masalah.
(2) Mencirikan perubahan kode yang memperbaiki masalah kode logging.
(3) Identifikasi dan ekstrak anti-pola (alias masalah umum) dalam kode logging dari langkah
sebelumnya dan terapkan alat otomatis untuk mendeteksinya.
Bergantung pada jenis artefak pengembangan yang dipelajari, ada tiga jenis teknik:
—Berbasis komitmen: Chen dan Jiang [41] mengusulkan pekerjaan pertama untuk mengkarakterisasi
dan mendeteksi anti-pola dalam kode logging. Mereka telah memeriksa secara manual 352 pasang
potongan kode logging yang diubah secara independen, yang diekstraksi dari komit kode dalam
riwayat pengembangan, dari tiga sistem open source yang terpelihara dengan baik. Enam anti-pola
dalam kode logging diidentifikasi. Untuk mendemonstrasikan nilai temuan, mereka telah
menyandikan anti-pola ini ke dalam alat analisis kode statis, LCAnalyzer. Studi kasus menunjukkan
bahwa LCAnalyzer memiliki daya ingat rata-rata 95% dan presisi 60% serta dapat digunakan untuk
secara otomatis mendeteksi anti-pola yang sebelumnya tidak diketahui dalam kode logging.
—Berbasis kode sumber: Li dkk. [95] mengusulkan DLFinder untuk mengkarakterisasi dan mendeteksi
bau kode logging duplikat. Mereka secara manual mempelajari cuplikan 3K LC yang memiliki duplikat
teks statis dan konteks sekitarnya dari kode sumber empat proyek sumber terbuka. Mereka
mengidentifikasi apakah teks statis duplikat bermasalah berdasarkan konteksnya. Untuk yang
bermasalah, mereka menyandikan anti-pola menjadi aturan statis dan mengembangkan pemeriksa
kode yang disebut DLFinder. Hasil menunjukkan bahwa DLfinder mampu mendeteksi bau kode
pendataan duplikat yang sebelumnya tidak diketahui.
—Berbasis laporan masalah: Alih-alih menganalisis komit historis atau kode sumber, Hassani et al. [65]
mempelajari laporan masalah terkait log dan meringkas tujuh akar penyebab masalah terkait log secara
manual. Mereka menerapkan alat berbasis aturan untuk mendeteksi empat dari tujuh akar penyebab. Hasil
menunjukkan bahwa alat mereka dapat menemukan masalah terkait log yang sebelumnya tidak diketahui.
Solusi berbasis sejarah diterapkan dicara loginsub-langkah dalam langkah Komposisi LC. Mereka telah
digunakan untuk mendeteksi masalah dalam kode log proyek perangkat lunak sumber terbuka. Namun, seperti
dilansir Chen et al. [43], hanya sebagian kecil dari masalah kode logging yang dapat dideteksi dengan teknik
yang ada. Diperlukan penelitian untuk mendeteksi lebih banyak jenis masalah kode logging. Selain itu, solusi
berbasis riwayat sering disertai dengan pemeriksa kode statis, yang umumnya memiliki tingkat positif palsu
yang tinggi. Ada baiknya untuk melihat kemungkinan jenis teknik lain (misalnya, berbasis pembelajaran mesin,
berbasis analisis dinamis) untuk melengkapi solusi saat ini.
4.4 Kepatuhan Keamanan

Kepatuhan keamanan berarti bahwa instrumentasi log harus memenuhi tujuan keselamatan dan kepatuhan
hukum. Ini penting, karena log seringkali merupakan satu-satunya sumber yang tersedia untuk merekam
aktivitas pengguna. Dalam subbagian ini, kami akan menjelaskan dua tantangan: tantangan audit untuk
merekam aktivitas terkait keamanan dan tantangan forensik untuk merekam aktivitas terkait kejahatan.
4.4.1 Audit.Audit mengacu pada praktik merekam rangkaian peristiwa yang relevan dengan keamanan
untuk memenuhi berbagai peraturan hukum. Persyaratan audit sering dijelaskan dalam spesifikasi
berbasis teks. Mengubah spesifikasi menjadi instrumentasi tidaklah mudah. Selain itu, sistem perangkat
lunak berskala besar biasanya berisi instrumentasi log yang intensif, sehingga sulit untuk mengelola
perilaku yang berbeda dari instrumentasi log audit dan instrumentasi log biasa, karena keduanya
memiliki persyaratan yang berbeda. Ada dua jenis solusi yang mengatasi tantangan ini:
• Solusi berbasis AOP: Beberapa SUS (misalnya, sistem kontrol medis dan pesawat) memerlukan log audit
yang benar dan baik untuk memenuhi persyaratan keamanan. Mereka memiliki spesifikasi rinci pada log
audit. Alat telah dikembangkan untuk mengubah spesifikasi ini menjadi instrumentasi AOP, sehingga
log audit dapat dibuat dan dikelola dengan mudah. Mohammadian et al. [26] mengusulkan untuk
menggunakan Spring AOP untuk mengubah spesifikasi menjadi instrumentasi logging. Mereka
menyusun algoritme penulisan ulang kode dan mengimplementasikan prototipe pada OpenMRS, sistem
rekam medis populer. Solusi berbasis AOP diterapkan diLogging berbasis aturansub-langkah dalam
langkah Pendekatan Logging. Ini meningkatkan modularitas sistem dan mengurangi kekusutan dan
hamburan kode. Itu membuat log audit mudah dipelihara dan dipantau. Namun, solusi berbasis AOP
memiliki kurva pembelajaran yang tinggi dan proses transformasi masih memerlukan upaya manual
yang tinggi.
• Solusi berbasis LU Design: Beberapa proyek (misalnya, Hadoop) mengembangkan LU mereka sendiri
untuk mendukung audit dengan lebih baik. Log audit umumnya lebih terstruktur dibandingkan dengan
pesan log biasa. Format log audit dapat bervariasi di berbagai komponen perangkat lunak. Oleh karena
itu, untuk memfasilitasi penggunaan kembali kode, dikembangkan LU internal untuk tujuan audit. Solusi
berbasis LU Design diterapkan diapa-untuk-adopsisub-langkah dalam langkah Integrasi LU. Di satu sisi,
ini bisa sangat disesuaikan, karena praktisi dapat merancang utilitas logging audit secara manual. Di sisi
lain, solusi ini memerlukan biaya pemeliharaan tambahan.
4.4.2 Forensik.Forensik komputer adalah praktik pengumpulan data untuk tujuan hukum. Data ini
selanjutnya dimanfaatkan untuk penyelidikan kejahatan. Pesan log adalah salah satu sumber bukti
terpenting [81]. Sulit untuk memutuskan aktivitas pengguna apa yang harus dicatat. Ada satu solusi yang
diusulkan untuk mengatasi tantangan ini:
• Solusi berbasis heuristik: Raja dkk. [84] mengusulkan solusi berbasis heuristik untuk mengidentifikasi
apakah peristiwa pengguna harus dicatat atau tidak dari perspektif forensik. Mereka pertama-tama
mengekstrak pasangan kata kerja-objek dari artefak bahasa alami seperti spesifikasi dan dokumen
persyaratan. Kemudian mereka mengusulkan 12 aturan berbasis heuristik untuk mengidentifikasi
peristiwa logging wajib (MLE)dari pasangan kata kerja-objek ini. Mereka menindaklanjuti dengan
membandingkan solusi berbasis heuristik [85] dengan metode dasar lainnya: digerakkan oleh standar
dan digerakkan oleh sumber daya. Metode berbasis standar mengharuskan peserta untuk
mengidentifikasi MLE dari spesifikasi pencatatan dunia nyata, seperti standar pencatatan industri
layanan kesehatan dan kartu pembayaran yang ada. Metode berbasis sumber daya mengharuskan
peserta untuk mengidentifikasi sumber daya sensitif sebelum MLE sehingga mereka dapat
mengekstraksi MLE dari interaksi dengan sumber daya sensitif. Eksperimen terkontrol dilakukan pada
103 mahasiswa ilmu komputer. Solusi berbasis heuristik diterapkan diapa yang harus dicatatsub-
langkah dalam langkah Komposisi LC. Sayangnya, hasil evaluasi menunjukkan bahwa tidak ada metode
yang direkomendasikan yang mengungguli kedua metode lainnya pada tingkat yang signifikan secara
statistik. Diperlukan lebih banyak penelitian untuk mengidentifikasi MLE yang benar secara efisien.
5 DISKUSI DAN PEKERJAAN KE DEPAN

Pada bagian ini, kami membahas keterbatasan dalam penelitian saat ini dan menyajikan arah penelitian masa
depan di antara tiga langkah instrumentasi log.
5.1 Pendekatan Penebangan
Diantara ketiga pendekatan penebangan tersebut, penebangan konvensional merupakan pendekatan yang paling
banyak digunakan. Namun, karena siklus rilis perangkat lunak meningkat dengan cepat, cuplikan LC yang
diinstrumentasi oleh logging konvensional mengalami masalah seperti kekusutan dan hamburan kode. Selain itu, untuk
memungkinkan penggunaan ulang dalam komponen perangkat lunak dan mendukung skalabilitas, banyak sistem
perangkat lunak memilih untuk mengadopsi arsitektur layanan mikro daripada arsitektur monolitik tradisional. Penting
untuk mencatat interaksi di antara berbagai layanan, karena kurangnya informasi tersebut dapat berdampak pada
efektivitas banyak tugas analisis post-mortem.
Logging berbasis aturan melengkapi logging konvensional dengan menyediakan aturan instrumentasi yang telah
ditentukan sebelumnya. Karena aturan biasanya ditentukan dengan jelas (misalnya, log di awal setiap metode), proses
instrumentasi dapat dengan mudah diotomatisasi. Oleh karena itu, pendekatan ini dapat mengurangi upaya manual
dalam menyusun cuplikan LC. Namun, penelitian sebelumnya [27,104] menemukan bahwa pendekatan berbasis aturan
tidak diadopsi secara luas di antara proyek sumber terbuka. Masih belum jelas bagi kami mengapa para praktisi merasa
enggan mengadopsi pendekatan ini. Investigasi lebih lanjut diperlukan untuk mengatasi masalah ini.
Penelusuran terdistribusi menjadi sangat populer dalam beberapa tahun terakhir. Dibandingkan dengan logging
konvensional, ini memberikan gambaran ujung ke ujung tentang bagaimana permintaan mengalir melalui beberapa
layanan perangkat lunak. Namun, untuk menggunakan utilitas penelusuran terdistribusi, perubahan ekstensif pada
kode sumber perlu dilakukan untuk mengonversi cuplikan LC yang ditulis dalam logging konvensional. Proses migrasi
sulit, rawan kesalahan, dan memakan waktu. Oleh karena itu, penting untuk mengkarakterisasi tantangan dalam proses
dan menghasilkan praktik terbaik, pedoman, dan dukungan alat untuk kemudahan upaya.
Kami mengusulkan tiga masalah terbuka berdasarkan diskusi di atas:
• Bisakah kita mengidentifikasi konteks penggunaan pendekatan logging?Pendekatan logging yang berbeda
dapat digunakan dalam konteks yang heterogen dan melayani tujuan yang berbeda. Penting untuk
mengekstrak dan meringkas persyaratan kompleks dari pencatatan perangkat lunak dalam berbagai konteks.
Misalnya, jika SUS mengadopsi arsitektur layanan mikro, maka identifikasi hubungan sebab akibat
antara peristiwa adalah salah satu persyaratan penting untuk pencatatan, karena membantu memantau dan
memecahkan masalah perilaku sistem. Dalam konteks ini, pelacakan terdistribusi lebih tepat daripada logging
konvensional karena kemampuannya menyebarkan metadata. Mengumpulkan dokumentasi semacam itu
membantu kami memahami konteks penggunaan setiap pendekatan logging dan mengeksplorasi jenis
pendekatan logging baru.
• Bisakah kita memahami alasan di balik mengadopsi pendekatan penebangan yang berbeda?Banyak
sistem perangkat lunak mungkin mengadopsi lebih dari satu pendekatan logging. Untuk memahami
keuntungan dan kerugian dari setiap pendekatan penebangan, kita perlu melakukan studi kuantitatif
dan kualitatif. Secara kuantitatif, kita harus mengusulkan metrik yang mengevaluasi dampak
pendekatan logging pada SUS, seperti pemeliharaan, konfigurasi, dan sebagainya. Secara kualitatif, kita
perlu melakukan wawancara atau survei online (misalnya kuesioner, masalah terbuka, pertanyaan skala
Likert) dengan para praktisi untuk memahami mengapa mereka memilih pendekatan logging tertentu
untuk proyek mereka. Temuan ini kemudian dapat digunakan untuk memberikan panduan dalam
mengadopsi pendekatan pembalakan.
• Dapatkah kami memberikan dukungan untuk memperkenalkan pendekatan penebangan baru?Biaya
pengenalan pendekatan logging baru atau migrasi dari satu pendekatan logging ke yang lain ke dalam sistem
perangkat lunak tinggi. Karena kurangnya dukungan alat, proses ini hanya dapat dilakukan secara manual dan
seringkali rawan kesalahan. Akan sangat berharga untuk menghasilkan satu set metrik untuk mengukur upaya
membantu praktisi untuk memutuskan apakah bermanfaat untuk melakukan proses seperti itu.
Selain itu, dukungan alat diperlukan untuk mengotomatiskan proses ini. Misalnya, untuk mengubah cuplikan LC
menggunakan log konvensional menjadi cuplikan LC menggunakan pelacakan terdistribusi, kami dapat
memanfaatkan alat transformasi kode statis seperti JDT dan Spoon.
5.2 Interaksi LU
Seperti yang disarankan oleh penelitian kami sebelumnya [44], banyak sistem perangkat lunak mengadopsi lebih dari
satu utilitas logging untuk memenuhi berbagai jenis persyaratan. Praktisi perlu berinteraksi dengan LU ini melalui API
yang berbeda. Ini akan menyebabkan konfigurasi tambahan dan overhead pemeliharaan. Zhi et al. [134] menemukan
bahwa mengelola konfigurasi satu LU untuk sistem perangkat lunak yang terus berkembang sudah bukan hal sepele
dan bug konfigurasi seperti penebang yang tidak valid dapat terjadi selama proses ini. Dengan lebih banyak LU yang
digunakan dalam sistem perangkat lunak, prosesnya akan menjadi lebih kompleks dan rawan kesalahan. Oleh karena
itu, kami mengusulkan tiga masalah terbuka berikut:
• Bagaimana cara merekomendasikan LU yang sesuai?Ada banyak LU yang tersedia di alam liar yang
menyediakan berbagai fungsi tentang pencatatan perangkat lunak. Pada saat yang sama, LU baru juga
terus diperkenalkan. Ada kekurangan perbandingan menyeluruh dan kuantitatif dari berbagai LU dari
berbagai dimensi seperti kinerja, kemampuan konfigurasi, kompatibilitas, dan sebagainya.
Perbandingan seperti itu akan memberikan panduan bagi para praktisi dalam memilih LU yang sesuai
untuk SUS.
• Bagaimana mengelola banyak LU?Sistem perangkat lunak berskala besar biasanya bergantung pada banyak pustaka
pihak ketiga, yang mungkin berisi LU mereka sendiri atau memanfaatkan LU eksternal. Semua LU ini perlu diperiksa
untuk memastikan mereka berperilaku seperti yang diharapkan. Ada dua manfaat: (1) membantu mencapai
keteramatan penuh dari keseluruhan sistem; (2) membantu mengidentifikasi masalah yang sebelumnya tidak diketahui
dalam interaksi. Oleh karena itu, salah satu peluang potensial adalah mengembangkan teknik untuk mengonfigurasi
perilaku logging secara otomatis di beberapa LU dalam satu SUS.
• Bisakah kita memberikan panduan dan meringkas praktik terbaik untuk mengembangkan LU internal?
Meskipun ada banyak LU eksternal yang tersedia di alam liar, praktisi masih mengimplementasikan LU
mereka sendiri demi penyesuaian. Beberapa penelitian mengeksplorasi alasan di balik penerapan LU
rumahan dan mengevaluasi manfaat dan biayanya. Temuan dari studi tersebut dapat
disintesis lebih lanjut sebagai pedoman dan praktik terbaik untuk mendukung proses pemilihan/
penyesuaian LU.
5.3 Komposisi LC
Studi yang ada tentang komposisi LC sebagian besar berfokus pada saran otomatis penyisipan cuplikan
LC baru atau pembaruan cuplikan LC yang ada. Beberapa solusi yang dijelaskan dalam Bagian4sudah
diterapkan dalam praktek. Namun, komposisi LC yang cerdas masih dalam tahap awal, karena solusi ini
hanya mampu menemukan sebagian kecil dari semua masalah di LC [43]. Selain itu, sulit untuk
membandingkan teknik ini karena kurangnya tolok ukur yang diterima dengan baik. Oleh karena itu,
kami mengusulkan empat masalah terbuka berikut:
• Bagaimana cara mem-bootstrap praktik logging secara efektif?Sejauh ini, banyak penelitian yang bertujuan untuk
meningkatkan praktik penebangan dibangun di atas praktik penebangan yang ada di SUS. Misalnya, model
pembelajaran mesin perlu dilatih dari korpus besar kumpulan data pelatihan. Fitur dalam kumpulan data pelatihan ini
diekstrak dari cuplikan LC yang ada. Namun, ada banyak proyek perangkat lunak dengan sedikit atau bahkan tanpa
cuplikan LC. Instrumentasi logging bootstrapping dalam proyek ini membutuhkan pengetahuan lintas proyek. Salah
satu solusi yang mungkin adalah mengeksplorasi apakah kita dapat memanfaatkan praktik logging dalam sistem
perangkat lunak yang matang, yang memiliki sejarah pengembangan yang panjang, untuk membantu sistem perangkat
lunak yang baru dimulai.
• Bagaimana mengevaluasi keefektifan praktik penebangan?Saat ini, tidak ada standar atau metrik yang
diterima dengan baik dalam mengevaluasi efektivitas praktik penebangan. Misalnya, di bidang
pengujian perangkat lunak, cakupan kode merupakan metrik penting untuk mengevaluasi kualitas
rangkaian pengujian. Metrik serupa harus dikembangkan untuk mengevaluasi praktik logging dari
dimensi yang berbeda seperti kegunaan, diagnosa, dan sebagainya. Metrik tersebut dapat membantu
para praktisi untuk memahami kematangan praktik penebangan saat ini dan mengidentifikasi lebih
lanjut peluang untuk perbaikan.
• Bisakah kita memberikan tolok ukur untuk meningkatkan komposisi LC?Chen dan Jiang [43] telah melakukan
upaya pertama untuk mengekstrak fileLogging-Kode-Masalah-Memperkenalkan (LCII)perubahan dengan
menambang data perkembangan historis. Setiap perubahan LCII terkait dengan potensi masalah logging.
Kumpulan data seperti itu bisa sangat berguna bagi peneliti yang tertarik untuk mengembangkan teknik baru
di bidang tersebutcara loginsub-langkah komposisi LC. Namun, lebih banyak tolok ukur diperlukan untuk
mengevaluasi solusi dalam dua sub-langkah komposisi LC lainnya.
• Apa karakteristik praktik penebangan untuk dua pendekatan penebangan lainnya?Studi yang ada (misalnya,
Referensi [42,128]) terutama berfokus pada praktik penebangan menggunakan penebangan konvensional.
Beberapa karya sampai saat ini berfokus pada karakterisasi praktik penebangan dengan menggunakan dua
pendekatan penebangan lainnya. Seperti yang telah kita bahas sebelumnya, ketiga pendekatan logging ini
berbeda dalam banyak hal, termasuk konteks adopsi dan upaya pemeliharaan, dan seterusnya. Perbedaan-
perbedaan ini akan sangat mempengaruhi cara para praktisi mengembangkan dan memelihara LC yang
diinstrumentasi. Oleh karena itu, studi semacam itu akan sangat membantu kita untuk memahami dan
meningkatkan langkah Komposisi LC menggunakan dua pendekatan logging lainnya.
6. KESIMPULAN
Pencatatan perangkat lunak digunakan secara luas oleh praktisi DevOps untuk berbagai tujuan. Pencatatan perangkat
lunak terdiri dari dua fase: instrumentasi log dan manajemen log. Tidak seperti manajemen log, yang memiliki
dukungan alat yang ekstensif, ada sedikit penelitian dan praktik yang dilakukan di bidang instrumentasi log. Berbeda
dengan survei-survei yang ada, yang fokus pada penebangan konvensional [112], pelacakan terdistribusi [114], dan
manajemen log [37], survei ini memberikan pandangan komprehensif tentang ketiganya
langkah-langkah instrumentasi log dan merangkum tantangan dan solusi terkait. Beberapa temuan kami
konsisten dengan survei yang ada. Rong dkk. [112] merasa sangat sulit untuk mempertahankan cuplikan LC
berkualitas baik dan sulit untuk menyeimbangkan biaya dan manfaat instrumentasi log. Sambasivan dkk. [114]
menemukan bahwa penelusuran terdistribusi secara luas digunakan untuk analisis kinerja dan pengambilan
sampel penting dalam mengendalikan overhead. Candido dkk. [37] temukan bahwa ada tiga langkah dalam
komposisi kode logging. Namun, survei kami menyajikan beberapa temuan unik yang tidak dibahas oleh survei
yang ada. Pertama, kami mensurvei studi yang ada berdasarkan tiga langkah dalam fase instrumentasi log:
pendekatan logging, interaksi LU, dan komposisi LC. Ini adalah survei pertama yang secara sistematis
membandingkan tiga pendekatan pembalakan yang berbeda. Kedua, kami menemukan ada sedikit diskusi
tentang interaksi beberapa LU, yang dapat membawa tantangan dalam konfigurasi dan pemeliharaan. Ketiga,
kami mengidentifikasi kebutuhan untuk membuat tolok ukur untuk secara efektif mengevaluasi berbagai teknik
komposisi LC.
Kami berharap survei ini akan bermanfaat bagi para peneliti, karena kami meringkas teknik mutakhir pada
instrumentasi log dan mengidentifikasi beberapa arah penelitian di masa mendatang. Kami juga berharap survei ini
dapat membantu para praktisi untuk tugas pengembangan dan pemeliharaan harian mereka. Untuk memudahkan
peniruan dan studi lebih lanjut tentang survei ini, kami telah menyediakan dataset kami di Referensi [18].
REFERENSI
[1] Yayasan Perangkat Lunak Apache. 2020. Pencatatan Apache Commons. Diterima darihttps://commons.apache.org/proper/
commons-logging/.
[2] Biru. 2020. Pencatatan dan audit keamanan Azure. Diterima darihttps://docs.microsoft.com/en-us/azure/security/
fundamentals/log-audit.
[3] AWS. 2020. Pencatatan Terpusat. Diterima darihttps://aws.amazon.com/solutions/implementations/
centralizedlogging.
[4] Baeldung. 2020. Membandingkan Spring AOP dan AspectJ. Diterima darihttps://www.baeldung.com/spring-aop-vsaspectj.
[5] Anjing data. 2020. Datadog. Diterima darihttps://datadoghq.com.

[6] Elastis. 2020. Elastis. Diterima darihttps://www.elastic.co.
[7] Gartner. 2014. Laporan Kepemimpinan SIEM Magic Quadrant Gartner 2014. Diterima darihttp://www.gartner.com/
document/2780017.
[8] Google. 2020. Operasi Google Cloud. Diterima darihttps://cloud.google.com/products/operations.
[9] Yayasan Perangkat Lunak Apache. 2020. HBASE-750: NPE disebabkan oleh StoreFileScanner.updateReaders. Diterima dari
https://issues.apache.org/jira/browse/HBASE-750/.
[10] Jaeger. 2020. Jejak Jaeger. Diterima darihttp://www.jaegertracing.io.
[11] Kibana. 2020. Kibana. Diterima darihttps://www.elastic.co/kibana.
[12] Langkah ringan. 2020. Lightstep. Diterima darihttps://lightstep.com.
[13] Yayasan Perangkat Lunak Apache. 2020. Log4J. Diterima darihttp://logging.apache.org/log4j/1.2.
[14] Yayasan Perangkat Lunak Apache. 2020. LOG4J 2 Apache Log4j 2. Diperoleh darihttp://logging.apache.org/log4j/2.x.
[15] LogStash. 2020. logstash - manajemen log sumber terbuka. Diterima darihttp://logstash.net/.
[16] Sensus Terbuka. 2020. Sensus Terbuka. Diterima darihttps://opencensus.io/.
[17] Dzone. 2020. Ikhtisar Pemrograman Berorientasi Aspek Pegas (AOP). Diterima darihttps://dzone.com/articles/
overview-of-spring-aspect-oriented-programming-aop.
[18] Boyuan Chen. 2021. Paket replikasi. Diterima darihttps://www.eecs.yorku.ca/∼chenfsd/resources/
survey.zip.
[19] SLF4J. 2020. Fasad Logging Sederhana untuk Java (SLF4J). Diterima darihttps://www.slf4j.org/.
[20] GitHub. 2020. spdlog - Pustaka logging C++ yang sangat cepat, hanya header/dikompilasi. Diperoleh darihttps://github.com/gabime/
spdlog.
[21] Splunk. 2020. Splunk. Diterima darihttp://www.splunk.com/.
[22] Sarbanes-Oxley Act. 2002. Ringkasan Sarbanes-Oxley Act of 2002. Diperoleh darihttp://www.soxlaw.com/.
[23] UBC. 2020. Proyek AspectC. Diterima darihttps://www.cs.ubc.ca/labs/spl/projects/aspectc.html.
[24] Yayasan Perangkat Lunak Apache. 2020. JavaDoc dari Log4J 2. Diperoleh darihttps://logging.apache.org/log4j/2.x/ log4j-api/
apidocs/org/
apache/logging/log4j/Level.html.
[25] Zipkin. 2020. Zipkin. Diterima darihttps://zipkin.io/.
[26] Sepehr Amir-Mohammadian, Stephen Chong, dan Christian Skalka. 2016. Pencatatan audit yang benar: Teori. DiProsiding Konferensi
Internasional ke-5 tentang Prinsip Keamanan dan Kepercayaan, Diadakan sebagai Bagian dari Konferensi Bersama Eropa tentang
Teori dan Praktik Perangkat Lunak. 139–162.
[27] Sven Apel dan Don Batory. 2008. Bagaimana AspectJ digunakan: Analisis terhadap sebelas program Aspectj.J. Obj. Technol.9, 1 (2008).
[28] Fabio Baccanico, Gabriella Carrozza, Marcello Cinque, Domenico Cotroneo, Antonio Pecchia, dan Agostino Savignano. 2014.
Pencatatan peristiwa dalam proses pengembangan industri: Praktik dan tantangan rekayasa ulang. Di Prosiding
Simposium Internasional IEEE ke-25 tentang Lokakarya Rekayasa Keandalan Perangkat Lunak.
[29] Paul Barham, Austin Donnelly, Rebecca Isaacs, dan Richard Mortier. 2004. Menggunakan Magpie untuk ekstraksi permintaan dan
pemodelan beban kerja. DiProsiding Simposium ke-6 Perancangan dan Implementasi Sistem Operasi. 259–272.
[30] Paul Barham, Rebecca Isaacs, Richard Mortier, dan Dushyanth Narayanan. 2003. Magpie: Pemodelan online dan
sistem sadar kinerja. DiProsiding Lokakarya ke-9 tentang Topik Hangat di Sistem Operasi. 85–90.
[31] Titus Barik, Robert DeLine, Steven M. Drucker, dan Danyel Fisher. 2016. Kerangka sistem: Studi kasus logging dan
telemetri di Microsoft. DiProsiding Konferensi Internasional ke-38 tentang Rekayasa Perangkat Lunak. 92–101.
[32] Marc Bartsch dan Rachel Harrison. 2008. Sebuah studi eksplorasi pengaruh pemrograman berorientasi aspek pada
pemeliharaan.Lembutw. Kual. J.16, 1 (2008), 23–44.
[33] Moritz Beller, Radjino Bholanath, Shane McIntosh, dan Andy Zaidman. 2016. Menganalisis keadaan analisis statis: Evaluasi skala besar
dalam perangkat lunak sumber terbuka. DiProsiding Konferensi Internasional ke-23 IEEE tentang Analisis Perangkat Lunak, Evolusi,
dan Reengineering. 470–481.
[34] Lionel C. Briand, Wojciech J. Dzidek, dan Yvan Labiche. 2005. Menginstrumen kontrak dengan pemrograman berorientasi aspek untuk
meningkatkan kemampuan observasi dan mendukung debugging. DiProsiding Konferensi Internasional IEEE ke-21 tentang
Pemeliharaan Perangkat Lunak. 687–690.
[35] Magiel Bruntink, Arie van Deursen, dan Tom Tourwé. 2005. Mengisolasi keprihatinan lintas sektor idiomatis. DiProsiding Konferensi
Internasional IEEE ke-21 tentang Pemeliharaan Perangkat Lunak. 37–46.
[36] Rajkumar Buyya, Satish Narayana Srirama, Giuliano Casale, Rodrigo N. Calheiros, Yogesh Simmhan, Blesson Varghese, Erol
Gelenbe, Bahman Javadi, Luis Miguel Vaquero, Marco AS Netto, Adel Nadjaran Toosi, Maria Alejandra Rodriguez, Ignacio
Martín Llorente, Sabrina De Capitani di Vimercati, Pierangela Samarati, Dejan S. Milojicic, Carlos A. Varela, Rami Bahsoon,
Marcos Dias de Assunção, Omer Rana, Wanlei Zhou, Hai Jin, Wolfgang Gentzsch, Albert Y. Zomaya, and Haiying Shen.
2019. Manifesto untuk komputasi awan generasi masa depan: Arah penelitian untuk dekade berikutnya.komputasi ACM.
Bertahan51, 5 (2019), 105:1–105:38.
[37] Jeanderson Cândido, Maurício Aniche, dan Arie van Deursen. 2019. Pemantauan Perangkat Lunak Kontemporer: Tinjauan
Literatur Sistematis. arxiv:cs.SE/1912.05878 (2019).
[38] Ian Cassar, Adrian Francalanza, Luca Aceto, and Anna Ingólfsdóttir. 2017. Survei teknik instrumentasi pemantauan
runtime. DiProsiding Lokakarya Internasional ke-2 tentang Teknik Verifikasi Pra dan Pasca-Penempatan.
[39] Anupam Chanda, Alan L. Cox, dan Willy Zwaenepoel. 2007. Whodunit: Pembuatan profil transaksional untuk
aplikasi multi-tier. DiProsiding Konferensi EuroSys. 17–30.
[40] Boyuan Chen. 2019. Meningkatkan praktik logging perangkat lunak di DevOps. DiProsiding Konferensi Internasional ke-41
tentang Rekayasa Perangkat Lunak.194–197.
[41] Boyuan Chen dan Zhen Ming (Jack) Jiang. 2017. Mengkarakterisasi dan mendeteksi anti-pola pada kode logging. Di
Prosiding Konferensi Internasional ke-39 tentang Rekayasa Perangkat Lunak. 71–81.
[42] Boyuan Chen dan Zhen Ming (Jack) Jiang. 2017. Mencirikan praktik logging dalam proyek perangkat lunak open source
berbasis Java—Studi replikasi di Apache Software Foundation.Empir. Lembutw. Eng.22, 1 (2017), 330–374.
[43] Boyuan Chen dan Zhen Ming (Jack) Jiang. 2019. Mengekstrak dan mempelajari Logging-Code-Issue- Memperkenalkan perubahan
dalam sistem perangkat lunak open source berskala besar berbasis Java.Empir. Lembutw. Eng.24, 4 (2019), 2285–2322.
[44] Boyuan Chen dan Zhen Ming (Jack) Jiang. 2020. Mempelajari penggunaan utilitas logging Java di alam liar. DiProsiding
Konferensi Internasional ke-42 tentang Rekayasa Perangkat Lunak.
[45] Boyuan Chen, Jian Song, Peng Xu, Xing Hu, dan Zhen Ming (Jack) Jiang. 2018. Pendekatan otomatis untuk memperkirakan
ukuran cakupan kode melalui log eksekusi. DiProsiding Konferensi Internasional ACM/IEEE ke-33 tentang Rekayasa
Perangkat Lunak Otomatis. 305–316.
[46] Mike Y. Chen, Anthony J. Accardi, Emre Kiciman, David A. Patterson, Armando Fox, dan Eric A. Brewer. 2004.
Kegagalan berbasis jalur dan manajemen evolusi. DiProsiding Simposium 1 Desain dan Implementasi Sistem
Jaringan. 309–322.
[47] Mike Y. Chen, Emre Kiciman, Eugene Fratkin, Armando Fox, dan Eric A. Brewer. 2002. Pinpoint: Penentuan masalah dalam layanan
internet yang besar dan dinamis. DiProsiding Konferensi Internasional tentang Sistem dan Jaringan yang Dapat Diandalkan. 595–
604.
[48] Anton Chuvakin, Kevin Schmidt, dan Chris Phillips. 2013.Pencatatan dan Manajemen Pencatatan. Syngress.
[49] Marcello Cinque, Domenico Cotroneo, Raffaele Della Corte, dan Antonio Pecchia. 2014. Menilai teknik pemantauan
langsung untuk menganalisis kegagalan sistem industri kritis. DiProsiding Simposium Internasional IEEE ke-25 tentang
Rekayasa Keandalan Perangkat Lunak. 212–222.
[50] Marcello Cinque, Domenico Cotroneo, Roberto Natella, dan Antonio Pecchia. 2010. Menilai dan meningkatkan efektivitas log
untuk analisis kesalahan perangkat lunak. DiProsiding Konferensi Internasional IEEE/IFIP tentang Sistem dan Jaringan
yang Dapat Diandalkan. 457–466.
[51] Marcello Cinque, Domenico Cotroneo, dan Antonio Pecchia. 2009. Pendekatan logging untuk evaluasi ketergantungan yang efektif
dari sistem yang kompleks. DiProsiding Konferensi Internasional ke-2 tentang Ketergantungan. 105–110.
[52] Marcello Cinque, Domenico Cotroneo, dan Antonio Pecchia. 2013. Log peristiwa untuk analisis kegagalan perangkat lunak: Pendekatan
berbasis aturan.Trans IEEE. Lembutw. Eng.39, 6 (2013), 806–821.
[53] Olivier Crameri, Ricardo Bianchini, dan Willy Zwaenepoel. 2011. Mencapai keseimbangan baru antara
instrumentasi program dan waktu debug. DiProsiding Konferensi Eropa ke-6 tentang Sistem Komputer. 199–214.
[54] Rui Ding, Hucheng Zhou, Jian-Guang Lou, Hongyu Zhang, Qingwei Lin, Qiang Fu, Dongmei Zhang, dan Tao Xie.
2015. Log2: Mekanisme logging sadar biaya untuk diagnosis kinerja. DiProsiding Konferensi Teknis Tahunan
USENIX. 139–150.
[55] Yuan Ding, Mai Haohui, Xiong Weiwei, Tan Lin, Zhou Yuanyuan, dan Pasupathy Shankar. 2010. SherLog: Diagnosis
kesalahan dengan menghubungkan petunjuk dari run-time log. DiProsiding ASPLOS Edisi ke-15 tentang Dukungan
Arsitektur untuk Bahasa Pemrograman dan Sistem Operasi.
[56] Rodrigo Fonseca, Prabal Dutta, Philip Levis, dan Ion Stoica. 2008. Quanto: Melacak energi dalam sistem tertanam jaringan.
DiProsiding Simposium USENIX ke-8 tentang Perancangan dan Implementasi Sistem Operasi. 323–338.
[57] Rodrigo Fonseca, Michael J. Freedman, dan George Porter. 2010. Pengalaman menelusuri kausalitas dalam
layanan jaringan. DiProsiding Workshop Manajemen Jaringan Internet/Workshop Riset Enterprise
Networking.
[58] Rodrigo Fonseca, George Porter, Randy H. Katz, Scott Shenker, dan Ion Stoica. 2007. X-Trace: Kerangka penelusuran
jaringan yang meresap. DiProsiding Simposium ke-4 Perancangan dan Implementasi Sistem Jaringan.
[59] Martin Fowler, Kent Beck, John Brant, William Opdyke, dan Don Roberts. 1999.Refactoring: Meningkatkan Desain Kode yang
Ada. Addison-Wesley Longman Publishing Co., Inc.
[60] Qiang Fu, Jieming Zhu, Wenlu Hu, Jian-Guang Lou, Rui Ding, Qingwei Lin, Dongmei Zhang, dan Tao Xie. 2014. Di mana pengembang
masuk? Sebuah studi empiris tentang praktik penebangan di industri. DiProsiding Konferensi Internasional ke-36 tentang Rekayasa
Perangkat Lunak. 24–33.
[61] Erich Gamma, Richard Helm, Ralph Johnson, dan John Vlissides. 1995.Pola Desain: Elemen Perangkat Lunak Berorientasi Objek yang
Dapat Digunakan Kembali. Addison-Wesley Longman Publishing Co., Inc.
[62] Mohamad Gebai dan Michel R. Dagenais. 2018. Survei dan analisis pelacak kernel dan userspace di Linux: Desain,
implementasi, dan overhead.komputasi ACM. Bertahan51, 2 (2018), 26:1–26:33.
[63] Marco Grochowski, Stefan Kowalewski, Melanie Buchsbaum, dan Christian Brecher. 2019. Menerapkan
pemantauan runtime ke Internet of Things industri. DiProsiding Konferensi Internasional IEEE ke-24 tentang
Teknologi Baru dan Otomasi Pabrik.
[64] Chuanxiong Guo, Lihua Yuan, Dong Xiang, Yingnon Dang, Ray Huang, David A. Maltz, Zhaoyi Liu, Vin Wang, Bin
Pang, Hua Chen, Zhi-Wei Lin, dan Varugis Kurien. 2015. Pingmesh: Sistem berskala besar untuk pengukuran dan
analisis latensi jaringan pusat data. DiProsiding Konferensi ACM tentang Kelompok Minat Khusus tentang
Komunikasi Data. 139–152.
[65] Mehran Hassani, Weiyi Shang, Emad Shihab, dan Nikolaos Tsantalis. 2018. Mempelajari dan mendeteksi masalah terkait log. Empir.
Lembutw. Eng.23, 6 (2018), 3248–3280.
[66] Pinjia He, Zhuangbin Chen, Shilin He, dan Michael R. Lyu. 2018. Mengkarakterisasi deskripsi bahasa alami dalam pernyataan
logging perangkat lunak. DiProsiding Konferensi Internasional ACM/IEEE ke-33 tentang Rekayasa Perangkat Lunak
Otomatis. 178–189.
[67] Pinjia He, Jieming Zhu, Shilin He, Jian Li, dan Michael R. Lyu. 2016. Studi evaluasi parsing log dan penggunaannya dalam penambangan
log. DiProsiding Konferensi Internasional IEEE/IFIP ke-46 tentang Sistem dan Jaringan yang Dapat Diandalkan. 654–661.
[68] Joseph L. Hellerstein, Mark M. Maccabee, W. Nathaniel Mills III, dan John Turek. 1999. ETE: Pendekatan yang dapat
disesuaikan untuk mengukur waktu respons end-to-end dan komponennya dalam sistem terdistribusi. DiProsiding
Konferensi Internasional ke-19 tentang Sistem Komputasi Terdistribusi. 152–162.
[69] Nicolas Hili, Mojtaba Bagherzadeh, Karim Jahed, dan Juergen Dingel. 2020. Arsitektur berbasis model untuk pemantauan
run-time interaktif.Lembutw. Sistem. Model.19, 4 (2020).
[70] Ferenc Horváth, Tamás Gergely, Árpád Beszédes, Dávid Tengeri, Gergő Balogh, and Tibor Gyimóthy. 2017. Perbedaan
cakupan kode bytecode Java dan alat instrumentasi kode sumber.Lembutw. Kual. J.(Desember 2017).
[71] Pencatatan JBoss. 2019. Diperoleh darihttps://developer.jboss.org/wiki/JBossLoggingTooling.
[72] Tong Jia, Ying Li, Chengbo Zhang, Wensheng Xia, Jie Jiang, dan Yuhong Liu. 2018. Mesin layak mendapatkan logging yang lebih baik:
Pendekatan peningkatan log untuk diagnosis kesalahan otomatis. DiProsiding Simposium Internasional IEEE tentang Lokakarya
Rekayasa Keandalan Perangkat Lunak. 106–111.
[73] Zhouyang Jia, Shanshan Li, Xiaodong Liu, Xiangke Liao, and Yunhuai Liu. 2018. SMARTLOG: Tempatkan pernyataan log kesalahan
dengan pemahaman mendalam tentang niat log. DiProsiding Konferensi Internasional ke-25 tentang Analisis Perangkat Lunak,
Evolusi dan Reengineering. 61–71.
[74] Zhen Ming Jiang, Ahmed E. Hassan, Gilbert Hamann, dan Parminder Flora. 2008. Identifikasi otomatis masalah pengujian
beban. DiProsiding Konferensi Internasional IEEE ke-24 tentang Pemeliharaan Perangkat Lunak. 307–316.
[75] Zhen Ming Jiang, Ahmed E. Hassan, Gilbert Hamann, dan Parminder Flora. 2009. Analisis kinerja uji beban otomatis. Di
Prosiding Konferensi Internasional IEEE ke-25 tentang Pemeliharaan Perangkat Lunak.
[76] Zhen Ming (Jack) Jiang, Ahmed E. Hassan, Gilbert Hamann, dan Parminder Flora. 2008. Pendekatan otomatis untuk
mengabstraksi log eksekusi ke peristiwa eksekusi.J.Softw. Pemeliharaan.20, 4 (2008), 249–267.
[77] Suhas Kabinna, Cor-Paul Bezemer, Weiyi Shang, dan Ahmed E. Hassan. 2016. Migrasi pustaka logging: Studi kasus untuk
proyek yayasan perangkat lunak Apache. DiProsiding Konferensi Internasional ke-13 tentang Repositori Perangkat Lunak
Pertambangan. 154–164.
[78] Suhas Kabinna, Weiyi Shang, Cor-Paul Bezemer, dan Ahmed E. Hassan. 2016. Meneliti stabilitas laporan logging. Di
Prosiding Konferensi Internasional ke-23 IEEE tentang Analisis Perangkat Lunak, Evolusi, dan Reengineering.
326–337.
[79] Jonathan Kaldor, Jonathan Mace, Michal Bejda, Edison Gao, Wiktor Kuropatwa, Joe O'Neill, Kian Win Ong, Bill
Schaller, Pingjia Shan, Brendan Viscomi, Vinod Venkataraman, Kaushik Veeraraghavan, dan Yee Jiun Song. 2017.
Kanopi: Sistem pelacakan dan analisis kinerja end-to-end. DiProsiding Simposium ke-26 tentang Prinsip Sistem
Operasi. 34–50.
[80] Michael James Katchabaw, Stephen L. Howard, Hanan Lutfi Lutfiyya, Andrew D. Marshall, dan Michael Anthony Bauer. 1997.
Membuat aplikasi terdistribusi dapat dikelola melalui instrumentasi. DiProsiding Simposium Internasional tentang
Rekayasa Perangkat Lunak untuk Sistem Paralel dan Terdistribusi. 84–94.
[81] Joakim Kävrestad. 2018.Dasar-dasar Forensik Digital—Teori, Metode, dan Aplikasi Kehidupan Nyata. Peloncat.
[82] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, dan John Irwin. 1997.
Pemrograman berorientasi aspek. Springer Berlin Heidelberg.
[83] Tae-young Kim, Suntae Kim, Cheol-Jung Yoo, Soohwan Cho, and Sooyong Park. 2018. Pendekatan otomatis untuk
memvalidasi level log di Java. DiProsiding Konferensi Rekayasa Perangkat Lunak Asia-Pasifik ke-25. 623–627.
[84] Jason King, Rahul Pandita, dan Laurie A. Williams. 2015. Mengaktifkan forensik dengan mengusulkan heuristik untuk
mengidentifikasi peristiwa log wajib. DiProsiding Simposium dan Bootcamp tentang Ilmu Keamanan. 6:1–6:11.
[85] Jason Tyler King, Jonathan Stallings, Maria Riaz, dan Laurie Williams. 2017. Untuk mencatat, atau tidak mencatat: Menggunakan heuristik untuk
mengidentifikasi peristiwa log wajib—Eksperimen terkontrol.Empir. Lembutw. Eng.22, 5 (2017), 2684–2717.
[86] Barbara Kitchenham dan Stuart Charters. 2007.Pedoman Melakukan Tinjauan Pustaka Sistematis pada Rekayasa Perangkat
Lunak.Laporan Teknis EBSE. Laporan Bersama Universitas Keele dan Universitas Durham.
[87] Kimmo Kiviluoma, Johannes Koskinen, dan Tommi Mikkonen. 2006. Pemantauan run-time dari perilaku arsitektur yang
signifikan menggunakan profil dan aspek perilaku. DiProsiding Simposium Internasional ACM/SIGSOFT tentang Pengujian
dan Analisis Perangkat Lunak.
[88] Sangeeta Lal, Neetu Sardana, dan Ashish Sureka. 2016. LogOptPlus: Belajar mengoptimalkan logging in catch dan if
konstruksi pemrograman. DiProsiding Konferensi Perangkat Lunak dan Aplikasi Komputer IEEE ke-40. 215–220.
[89] Sangeeta Lal dan Ashish Sureka. 2016. LogOpt: Ekstraksi fitur statis dari kode sumber untuk prediksi logging blok
tangkapan otomatis. DiProsiding Konferensi Rekayasa Perangkat Lunak India ke-9. 151–155.
[90] Ralf Lämmel, Ekaterina Pek, dan Jürgen Starek. 2011. Skala besar, analisis penggunaan API berbasis AST dari proyek Java
sumber terbuka. DiProsiding Simposium ACM tentang Komputasi Terapan. 1317–1324.
[91] Heng Li, Tse-Hsun (Peter) Chen, Weiyi Shang, dan Ahmed E. Hassan. 2018. Mempelajari software logging menggunakan model topik.
Empir. Lembutw. Eng.23, 5 (2018), 2655–2694.
[92] Heng Li, Weiyi Shang, dan Ahmed E. Hassan. 2017. Level log mana yang harus dipilih developer untuk pernyataan logging
baru?Empir. Lembutw. Eng.22, 4 (2017), 1684–1716.
[93] Heng Li, Weiyi Shang, Ying Zou, dan Ahmed E. Hassan. 2017. Menuju saran tepat waktu untuk perubahan log. Empir.
Lembutw. Eng.22, 4 (2017), 1831–1865.
[94] Shanshan Li, Xu Niu, Zhouyang Jia, Xiang-Ke Liao, Ji Wang, dan Tao Li. 2019. Memandu revisi log dengan belajar dari riwayat
evolusi perangkat lunak.Empir. Lembutw. Eng.25, 3 (09 2019).
[95] Zhenhao Li, Tse-Hsun (Peter) Chen, Jinqiu Yang, dan Weiyi Shang. 2019. DLFinder: Mengkarakterisasi dan mendeteksi bau
kode logging duplikat. DiProsiding Konferensi Internasional ke-41 tentang Rekayasa Perangkat Lunak. 152–163.
[96] Jimmy J. Lin dan Dmitriy V. Ryaboy. 2012. Menskalakan infrastruktur penambangan data besar: Pengalaman Twitter.SIGKDD
Eksplorasi.14, 2 (2012), 6–19.
[97] Zhongxin Liu, Xin Xia, David Lo, Zhenchang Xing, Ahmed E. Hassan, dan Shanping Li. 2019. Variabel mana yang harus saya catat?Trans
IEEE. Lembutw. Eng.(2019).
[98] Di Ma dan Gene Tsudik. 2009. Pendekatan baru untuk mengamankan penebangan.Trans. Lembutw.5, 1 (2009), 2:1–2:21.
[99] Jonathan Mace, Ryan Roelke, dan Rodrigo Fonseca. 2015. Pelacakan pivot: Pemantauan kausal dinamis untuk sistem
terdistribusi. DiProsiding Simposium ke-25 tentang Prinsip Sistem Operasi. 378–393.
[100] Tandai Marron. 2018. Log++ logging untuk dunia cloud-native. DiProsiding Simposium Internasional ACM SIGPLAN
ke-14 tentang Bahasa Dinamis. 25–36.
[101] George Mathew dan Tim Menzies. 2018. Topik, tren, dan peneliti utama rekayasa perangkat lunak.Perangkat lunak IEEE.35, 5 (2018).
[102] Jhonny Mertz dan Ingrid Nunes. 2019. Tentang kelayakan praktis pemantauan perangkat lunak: Kerangka kerja untuk pelacakan
eksekusi berdampak rendah. DiProsiding Simposium Internasional ke-14 tentang Rekayasa Perangkat Lunak untuk Sistem Adaptif
dan Pengelolaan Mandiri. 169–180.
[103] Daniel Le Métayer, Eduardo Mazza, dan Marie-Laure Potet. 2010. Merancang arsitektur log untuk bukti hukum. Di Prosiding
Konferensi Internasional IEEE ke-8 tentang Rekayasa Perangkat Lunak dan Metode Formal. 156–165.
[104] Freddy Munoz, Benoit Baudry, Romain Delamare, dan Yves Le Traon. 2013. Penggunaan dan testabilitas AOP: Studi
empiris AspectJ.Inf. Lembutw. Technol.55, 2 (2013).
[105] Nicholas Nethercote. 2004.Analisis dan Instrumentasi Biner Dinamis.tesis PhD. Universitas Cambridge,
Inggris Raya.
[106] Flemming Nielson, Hanne R. Nielson, dan Chris Hankin. 2010.Prinsip Analisis Program. Perusahaan Penerbitan
Springer, Dimasukkan.
[107] Adam Oliner, Archana Ganapathi, dan Wei Xu. 2012. Kemajuan dan tantangan dalam analisis log.Komunal. ACM55, 2 (2012).
[108] Opentracing: Vendor-neutral API dan instrumentasi untuk pelacakan terdistribusi. 2019. Diperoleh darihttps://
opentracing.io/.
[109] Antonio Pecchia, Marcello Cinque, Gabriella Carrozza, dan Domenico Cotroneo. 2015. Praktik industri dan pencatatan
peristiwa: Penilaian proses pengembangan perangkat lunak yang kritis. DiProsiding Konferensi Internasional IEEE/ACM
ke-37 tentang Rekayasa Perangkat Lunak. 169–178.
[110] Ariel Rabkin, Wei Xu, Avani Wildani, Armando Fox, David A. Patterson, and Randy H. Katz. 2010. Representasi grafis
untuk struktur pengidentifikasi dalam log. DiProsiding Lokakarya Mengelola Sistem melalui Analisis Log dan
Teknik Pembelajaran Mesin.
[111] Patrick Reynolds, Charles Edwin Killian, Janet L. Wiener, Jeffrey C. Mogul, Mehul A. Shah, and Amin Vahdat. 2006. Pip :
Mendeteksi yang tidak diharapkan pada sistem terdistribusi. DiProsiding Simposium ke-3 Perancangan dan Implementasi
Sistem Jaringan.
[112] Guoping Rong, Qiuping Zhang, Xinbei Liu, dan Shenghui Gu. 2017. Tinjauan sistematis praktik logging dalam rekayasa
perangkat lunak. DiProsiding Konferensi Rekayasa Perangkat Lunak Asia-Pasifik ke-24. 534–539.
[113] Felix Salfner, Steffen Tschirpke, dan Miroslaw Malek. 2004. File log komprehensif untuk sistem otonom. Di
Prosiding Simposium Pemrosesan Paralel dan Terdistribusi Internasional ke-18.
[114] Raja R. Sambasivan, Ilari Shafer, Jonathan Mace, Benjamin H. Sigelman, Rodrigo Fonseca, and Gregory R. Ganger. 2016. Pelacakan
berpusat pada alur kerja yang berprinsip pada sistem terdistribusi. DiProsiding Simposium ACM ke-7 tentang Cloud Computing.
401–414.
[115] Raja R. Sambasivan, Alice X. Zheng, Michael De Rosa, Elie Krevat, Spencer Whitman, Michael Stroucken, William Wang, Lianghong Xu,
and Gregory R. Ganger. 2011. Mendiagnosis perubahan kinerja dengan membandingkan aliran permintaan.
DiProsiding Simposium USENIX ke-8 tentang Desain dan Implementasi Sistem Jaringan.
[116] Mohammed Sayagh, Noureddine Kerzazi, Bram Adams, dan Fabio Petrillo. 2018. Rekayasa konfigurasi perangkat lunak
dalam praktik: Wawancara, survei, dan tinjauan literatur sistematis.Trans IEEE. Lembutw. Eng.46, 6 (2018).
[117] Weiyi Shang, Zhen Ming Jiang, Bram Adams, Ahmed E. Hassan, Michael W. Godfrey, Mohamed Nasser, dan
Parminder Flora. 2014. Studi eksplorasi evolusi informasi yang dikomunikasikan tentang pelaksanaan sistem
perangkat lunak besar.J.Softw: Evol. Proses26, 1 (2014).
[118] Weiyi Shang, Zhen Ming Jiang, Hadi Hemmati, Bram Adams, Ahmed E. Hassan, dan Patrick Martin. 2013. Membantu
pengembang aplikasi analitik data besar saat menerapkan di cloud Hadoop. DiProsiding Konferensi Internasional ke-35
tentang Rekayasa Perangkat Lunak. 402–411.
[119] Yuri Shkuro. 2019.Menguasai Tracing Terdistribusi: Menganalisis Kinerja dalam Layanan Mikro dan Sistem Kompleks. Packt Publishing
Ltd.
[120] Benjamin H. Sigelman, Luiz André Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, and
Chandan Shanbhag. 2010.Dapper, Infrastruktur Pelacakan Sistem Terdistribusi Berskala Besar. Laporan teknikal. Google,
Inc. Diperoleh darihttps://research.google.com/archive/papers/dapper-2010-1.pdf.
[121] Cindy Sridharan. 2018.Observabilitas Sistem Terdistribusi. O'Reilly Media, Inc.
[122] Eno Thereska, Brandon Salmon, John D. Strunk, Matthew Wachs, Michael Abd-El-Malek, Julio López Hernandez, dan Gregory
R. Ganger. 2006. Stardust: Melacak aktivitas dalam sistem penyimpanan terdistribusi. DiProsiding Konferensi
Internasional Bersama tentang Pengukuran dan Pemodelan Sistem Komputer. 3–14.
[123] Simon Varvaressos, Kim Lavoie, Alexandre Blondin Massé, Sébastien Gaboury, dan Sylvain Hallé. 2014. Penemuan bug
otomatis di video game: Studi kasus untuk pemantauan runtime. DiProsiding Konferensi Internasional IEEE ke-7 tentang
Pengujian, Verifikasi, dan Validasi Perangkat Lunak. 143–152.
[124] Wei Xu. 2010.Deteksi Masalah Sistem oleh Mining Console Logs. Ph.D. Disertasi. Universitas California, Berkeley,
CA. Diterima darihttp://www.escholarship.org/uc/item/6jx4w194.
[125] Stephen Yang, Taman Seo Jin, dan John K. Ousterhout. 2018. NanoLog: Sistem logging berskala nanodetik. Di
Prosiding Konferensi Teknis Tahunan USENIX.335–350.
[126] Kundi Yao, Guilherme B. de Pádua, Weiyi Shang, Steve Sporea, Andrei Toma, and Sarah Sajedi. 2018. Log4Perf:
Menyarankan lokasi logging untuk pemantauan kinerja sistem berbasis web. DiProsiding Konferensi
Internasional ACM/SPEC tentang Rekayasa Kinerja.
[127] Ding Yuan, Taman Soyeon, Peng Huang, Yang Liu, Michael M. Lee, Xiaoming Tang, Yuanyuan Zhou, dan Stefan Savage.
2012. Jadilah konservatif: Meningkatkan diagnosis kegagalan dengan logging proaktif. DiProsiding Simposium USENIX
ke-10 tentang Desain dan Implementasi Sistem Operasi. 293–306.
[128] Ding Yuan, Soyeon Park, dan Yuanyuan Zhou. 2012. Mencirikan praktik logging dalam perangkat lunak sumber terbuka. Di Prosiding
Konferensi Internasional ke-34 tentang Rekayasa Perangkat Lunak. 102–112.
[129] Ding Yuan, Jing Zheng, Soyeon Park, Yuanyuan Zhou, dan Stefan Savage. 2011. Meningkatkan kemampuan diagnosis perangkat lunak
melalui peningkatan log. DiProsiding Konferensi Internasional ke-16 tentang Dukungan Arsitektur untuk Bahasa Pemrograman dan
Sistem Operasi. 3–14.
[130] Yi Zeng, Jinfu Chen, Weiyi Shang, dan Tse-Hsun Chen. 2019. Mempelajari karakteristik praktik logging di aplikasi
seluler: Studi kasus di F-Droid.Empir. Lembutw. Eng.(02 2019).DOI:https://doi.org/10.1007/s10664-019-09687-9
[131] Xu Zhao, Kirk Rodrigues, Yu Luo, Michael Stumm, Ding Yuan, dan Yuanyuan Zhou. 2017. Permainan dua puluh pertanyaan:
Apakah Anda tahu di mana harus login? DiProsiding Lokakarya ke-16 tentang Topik Hangat di Sistem Operasi. 125–131.
[132] Xu Zhao, Kirk Rodrigues, Yu Luo, Michael Stumm, Ding Yuan, dan Yuanyuan Zhou. 2017. Log20: Penempatan pernyataan pencetakan
log yang optimal sepenuhnya otomatis di bawah ambang batas overhead yang ditentukan. DiProsiding Simposium ke-26 tentang
Prinsip Sistem Operasi. 565–581.
[133] Xu Zhao, Yongle Zhang, David Lion, Muhammad Faizan Ullah, Yu Luo, Ding Yuan, dan Michael Stumm. 2014. lprof:
Profiler aliran permintaan non-intrusif untuk sistem terdistribusi. DiProsiding Simposium USENIX ke-11 tentang
Desain dan Implementasi Sistem Operasi. 629–644.
[134] Chen Zhi, Jianwei Yin, Shuiguang Deng, Maoxin Ye, Min Fu, dan Tao Xie. 2019. Studi eksplorasi praktik konfigurasi
logging di Jawa. DiProsiding Konferensi Internasional IEEE ke-35 tentang Pemeliharaan dan Evolusi Perangkat
Lunak.
[135] Jingwen Zhou, Zhenbang Chen, Haibo Mi, dan Ji Wang. 2014. MTracer: Kerangka pemantauan berorientasi jejak untuk
sistem terdistribusi skala menengah. DiProsiding Simposium Internasional IEEE ke-8 tentang Rekayasa Sistem
Berorientasi Layanan. 266–271.
[136] Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chao Ji, Wenhai Li, dan Dan Ding. 2018. Analisis kesalahan dan debugging sistem
layanan mikro: Survei industri, sistem benchmark, dan studi empiris.Trans IEEE. Lembutw. Eng.47, 2 (2018).
[137] Jieming Zhu, Pinjia He, Qiang Fu, Hongyu Zhang, Michael R. Lyu, and Dongmei Zhang. 2015. Belajar log: Membantu
pengembang membuat keputusan logging yang tepat. DiProsiding Konferensi Internasional IEEE/ACM ke-37 tentang
Rekayasa Perangkat Lunak.
[138] Jieming Zhu, Shilin He, Jinyang Liu, Pinjia He, Qi Xie, Zibin Zheng, dan Michael R. Lyu. 2019. Alat dan tolok ukur untuk
penguraian log otomatis. DiProsiding Konferensi Internasional ke-41 tentang Rekayasa Perangkat Lunak. 121–130.
Diterima Juni 2020; direvisi Desember 2020; diterima Januari 2021

Chen2021 en Id

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Chen2021 en Id

Diunggah oleh

Hak Cipta:

Format Tersedia

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

Survei Instrumentasi Log Perangkat Lunak

BOYUAN CHEN dan ZHEN MING (JACK) JIANG,Universitas York, Kanada

Format Referensi ACM:

Gambar 1. Keseluruhan proses software logging.

Gambar 2. Langkah-langkah dalam tiga fase instrumentasi log.

2 Alur Kerja INSTRUMENTASI LOGGING PERANGKAT LUNAK

2.1 Gambaran Umum Fase Instrumentasi Log

(3)Komposisi LC: Setelah pengembang mengintegrasikan LU, mereka perlu memasukkan LC ke

2.2 Pendekatan Penebangan

2.2.1 Penebangan Konvensional.Cuplikan kode menggunakan pendekatan logging konvensional

2.2.3 Penelusuran Terdistribusi.Meskipun fleksibel dan mudah untuk melakukan logging

Tabel 1. Perbandingan antara Tiga Pendekatan Penebangan

Penebangan Konvensional Logging berbasis aturan Pelacakan Terdistribusi

Penyaringan Tingkat verbositas Tingkat verbositas Contoh

potongan LC pada baris 13 memiliki dua kunci:KliendanPesan.Kunci (Klien)sesuai dengan informasi

2.2.4 Perbandingan antara Tiga Pendekatan Penebangan.Meja1membandingkan pendekatan ini di

• apa-untuk-adopsi: Dengan meningkatnya jumlah LU yang tersedia di alam liar [44],

3 TINJAUAN SURVEI SISTEMATIS KAMI

3.2 Ringkasan Survei Kami

(1)Kegunaanmengacu pada teknik instrumentasi log yang memfasilitasi adopsi berbagai

Gambar 4. Makalah terkait instrumentasi Log dari 1997 hingga 2019.

Kategori Tantangan Solusi Langkah Terapan

Dapat dikonfigurasi Sejarah [134] LU/Bagaimana-konfigurasi

Pengolahan pasca [100,125] LA/Logging konvensional

Dapat didiagnosis [50,53,72,73,127,129] LC/What-to-log

Analisis Kinerja [29,30,39,46,47,56–58,68,79,80,99, LC/Tempat-untuk-masuk

Kualitas LC Konsistensi [60,83,88,89,91–94,97,137] LC/*

Forensik Heuristik [84,85] LC/What-to-log

3.3 Membandingkan dengan Survei yang Ada

Gambar 5. Distribusi makalah yang diklasifikasikan berdasarkan tantangan terkait.

4 TANTANGAN DAN SOLUSI

menyesuaikan keputusan pengambilan sampel selama runtime.

4.2 Dapat didiagnosis

—Teknik berbasis propagasi: Teknik berbasis propagasi melacak kausalitas dalam

4.3.3 Pemeliharaan.Tantangan pemeliharaan adalah mengenai masalah mendukung evolusi dan

4.4 Kepatuhan Keamanan

5 DISKUSI DAN PEKERJAAN KE DEPAN

5.1 Pendekatan Penebangan

Kami mengusulkan tiga masalah terbuka berdasarkan diskusi di atas:

[5] Anjing data. 2020. Datadog. Diterima darihttps://datadoghq.com.

Diterima Juni 2020; direvisi Desember 2020; diterima Januari 2021

Anda mungkin juga menyukai