Bagikan melalui

Pemecahan Masalah Performa IIS atau Kesalahan Aplikasi menggunakan LogParser

oleh Benjamin Perkins

Alat dan pengetahuan yang digunakan dalam Pemecah Masalah ini

Gambaran Umum

Pemecah masalah ini akan membantu Anda menganalisis file log IIS dalam upaya untuk menentukan penyebab ketika aplikasi yang dihosting di IIS gagal atau mengalami masalah performa. Sebelum memulai, penting untuk dicatat bahwa semua bidang yang dapat dicatat IIS tidak diaktifkan secara default. Misalnya, Byte Yang Dikirim dan Byte Diterima tidak dipilih, tetapi sangat berguna saat memecahkan masalah performa. Oleh karena itu, waktu terbaik untuk menyertakan bidang tambahan ini adalah sebelum Anda mengalami masalah sistem. Jadi, jika Anda belum melakukannya, pilih bidang tambahan ini, bidang tersebut akan membantu Anda menemukan solusi ketika masalah terjadi.

Blog berikut yang membahas cara melakukan ini di IIS 7+:

Memodifikasi data log IIS 7 di Windows 2008

Skenario

Sebagai Administrator Sistem, Anda mulai mendengar laporan dari pengguna sistem Anda yang dihosting di IIS bahwa responsnya lambat. Ada beberapa yang menyebutkan bahwa browser web hanya kehabisan waktu atau berhenti merespons sepenuhnya ketika mereka mengakses situs web Anda.

Anda langsung beraksi dan mendaur ulang proses pekerja; semua tampaknya bekerja lagi, seperti biasa.

Namun, Anda tidak dapat menerimanya sebagai solusi dan perlu tahu mengapa hal ini terjadi, tetapi tidak tahu harus mulai dari mana. Anda tidak memiliki detail dari pengguna, seperti kode kesalahan, cuplikan layar, dan yang lebih buruk, Anda tidak memiliki data performa untuk membandingkan apa yang baru saja terjadi dengan performa normal. Dalam banyak kasus, masalah baru lainnya membawa Anda pergi dari analisis akar penyebab yang serius.

LogParser Microsoft adalah alat yang bagus yang cepat dan mudah digunakan. Dalam banyak situasi, alat ini akan membantu Anda dengan cepat mendapatkan pemahaman yang lebih dalam tentang apa yang terjadi di server dan dapat membantu Anda mengidentifikasi masalah. Anda dapat mengambil informasi yang Anda kumpulkan dengan LogParser dan meneruskannya ke tim database, tim jaringan Anda, atau ke pengembang Anda untuk analisis lebih lanjut.

Kumpulan Data

Secara default, file log IIS terletak di direktori berikut:

  • IIS 7 dan yang lebih baru: %SystemDrive%\inetpub\logs\LogFiles
  • IIS 6 dan yang lebih lama: %WinDir%\System32\LogFiles

Dalam pemecah masalah ini, saya akan menggunakan IIS 8. Buka Manajer IIS dan pilih Situs, seperti yang ditunjukkan pada Gambar 1. Ini akan menunjukkan ID setiap situs web yang dihosting di server Anda. Anda akan memerlukan ID ini untuk menentukan direktori W3SVC* mana yang akan dianalisis.

Cuplikan layar jendela I I S Manager memperlihatkan Situs di panel utama.
Gambar 1: Mendapatkan ID situs web Anda

Buka Windows Explorer dan navigasi ke direktori yang berisi file log IIS situs web yang mengalami masalah performa. Gambar 2 menunjukkan bagaimana tampilannya.

Cuplikan layar Windows Explorer memperlihatkan lokasi file.
Gambar 2: Lokasi file Log IIS

File log IIS bisa sangat besar; misalnya, pada Gambar 2, file log u_ex12101858.log berukuran hampir 100MB. Karena file log ini mungkin besar dan berisi ratusan ribu entri file log individual, secara manual mencari setiap file ini untuk kesalahan bukanlah pendekatan yang baik, dan mengembalikan beberapa hasil untuk waktu yang Anda investasikan.

Ini adalah ketika LogParser menjadi alat yang sangat diperlukan dalam gudang pemecahan masalah Anda.

Analisis Data

Langkah pertama Anda adalah menentukan file log mana yang mungkin berisi kesalahan. Misalnya, jika pelanggan mengeluh tentang performa pada tanggal 3 Juni 2012, file log mungkin u_ex120603.log, di mana:

  • "12" adalah tahun yang disingkat untuk 2012
  • "06" mengacu pada bulan keenam (Juni)
  • "03" adalah hari ke-3 dalam sebulan

Catatan: Contoh di atas mengasumsikan bahwa pengelogan IIS dikonfigurasi untuk memutar file log setiap hari, yang merupakan default. Jika Anda telah mengubah pengaturan IIS untuk memutar file log pada interval waktu yang berbeda, seperti mingguan atau per jam, maka nama file log akan berbeda. Untuk informasi selengkapnya tentang sintaks untuk nama file log IIS, lihat artikel Sintaks Penamaan File Log IIS (https://support.microsoft.com/kb/242898).

Catatan

Secara default, tanggal dan waktu dalam log IIS disimpan menggunakan GMT; Anda harus mempertimbangkan hal ini ketika Anda menentukan log mana yang berisi kesalahan. Dengan demikian, Anda dapat menyesuaikan tanggal/waktu dengan menggunakan fungsi LogParser TO_LOCALTIME() , seperti yang diilustrasikan dalam contoh berikut:

Catatan

logparser.exe "SELECT TO_STRING(TO_LOCALTIME(TO_TIMESTAMP(date,time)),'yyyy-MM-dd hh:mm:ss') AS LocalTime,
COUNT(*) AS Hits FROM *.log WHERE date='2012-10-18'
GROUP BY LocalTime ORDER BY LocalTime" -i:w3c

Setelah mengidentifikasi file log IIS yang berisi kesalahan, Anda harus menyalinnya ke lokasi tempat file log tersebut dapat dianalisis. Langkah ini bersifat opsional, tetapi tidak disarankan agar Anda menganalisis log Anda di server IIS Anda karena kueri LogParser Anda mungkin membutuhkan waktu lama untuk dijalankan, dan jika file log Anda besar maka Log Parser dapat bersaing untuk sumber daya sistem.

Misalnya, Anda dapat menyalin log IIS Anda ke folder di komputer pribadi Anda di mana Anda telah menyalin file LogParser, yang merupakan cara saya biasanya menganalisis file log saya. Gambar 3 memperlihatkan contoh tempat saya menyimpannya untuk membuat artikel ini.

Cuplikan layar Windows Explorer memperlihatkan lokasi pengurai log yang dapat dieksekusi.Gambar 3: File Log IIS yang dihosting secara lokal untuk analisis menggunakan LogParser

Setelah mengunduh LogParser, Anda siap untuk memulai analisis. Kueri pertama yang saya jalankan diperlihatkan dalam Gambar 4. Hasilnya memberi Anda gambaran umum tentang bagaimana IIS telah merespons permintaan.

logparser.exe "SELECT sc-status, sc-substatus, COUNT(*) FROM *.log GROUP BY sc-status, sc-substatus ORDER BY sc-status" -i:w3c
    
    sc-status sc-substatus COUNT(ALL *)
    --------- ------------ ------------
    200       0            3920658
    206       0            2096
    301       0            1031
    302       0            65386
    304       0            178705
    400       0            35
    401       2            692096
    404       0            2935
    404       11           7
    405       0            1
    406       0            36
    500       0            11418
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    12
    Execution time:     7.70 seconds

Gambar 4: Kueri LogParser (sc-status dan sc-substatus)

Tempat-tempat menarik dalam hasil adalah:

  • Rasio antara 200 dan 304 kode status HTTP (permintaan yang berhasil)
  • Jumlah 500 kode status HTTP (permintaan gagal)

Signifikansi untuk masing-masing kode status ini dijelaskan di bawah ini.

Rasio Antara HTTP 200 dan 304 Kode Status (Menganalisis Permintaan yang Berhasil)

Rasio antara kode status HTTP 200 dan 304 penting karena menunjukkan berapa banyak permintaan yang diambil dari cache klien alih-alih langsung dari server. Hasil pada Gambar 4 menunjukkan bahwa ada 3.920.658 permintaan yang menghasilkan kode Status HTTP 200. Ini berarti bahwa file yang diminta dilayani dari server setiap kali. Sebaliknya, ada 178.705 permintaan yang menghasilkan kode status HTTP 304. Ini berarti bahwa file yang diminta diambil dari cache lokal. Dengan kata lain, 95,5% permintaan sedang ditangani dari server.

Penembolokan dapat memiliki beberapa dampak yang sangat positif pada performa sistem Anda; lihat detail untuk kompresi statis dan dinamis dalam artikel Mengonfigurasi Kompresi HTTP di IIS 7 .

Kode Status HTTP 500 (Menganalisis Permintaan Gagal)

Kode Status HTTP 500 mungkin menunjukkan masalah serius pada sistem Anda. Tingkat dampak yang mungkin ditimbulkan oleh akar penyebab kesalahan HTTP 500 pada sistem Anda dapat berkisar dari apa pun hingga crash proses pekerja. Oleh karena itu, ketika Anda melihat ini, Anda harus menjalankan kueri yang ditunjukkan pada Gambar 5 untuk menemukan permintaan mana yang menghasilkan kode Status HTTP 500.

logparser.exe "SELECT cs-uri-stem, COUNT(*) FROM *.log WHERE sc-status=500 GROUP BY cs-uri-stem ORDER BY COUNT(*) DESC" -i:w3c
    
    cs-uri-stem                 COUNT(ALL *)
    --------------------------- ------------
    /ShoppingCart/ViewCart.aspx 1378
    /DataService.asmx           1377  
    /Start/default.aspx         949
    /GetDetailsView.aspx        753
    /Details/ImageUrls.asmx     722
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     24.89 seconds

Gambar 5: Kueri LogParser (cs-uri-stem dengan 500 sc-status)

Hasil ini menunjukkan jalur dan nama file yang, ketika diminta, merespons dengan kode Status HTTP 500. Informasi semacam ini akan berharga bagi tim pengembangan. Misalnya, tim pengembangan dapat melihat lebih jauh ke dalam kode tertentu tersebut dan mencari kode yang dijalankan tanpa terkandung dalam try {...} catch {...} blok kode, atau mereka menjalankan kueri data besar yang perlu dioptimalkan.

Mari kita ambil contoh ini selangkah lebih jauh dan fokus pada kontributor teratas untuk kode Status HTTP 500. Akan menarik untuk mengetahui kapan kesalahan ini terjadi, karena informasi ini dapat digunakan untuk memeriksa apakah dependensi mengalami masalah pada saat yang sama.

logparser.exe "SELECT TO_STRING(TO_TIMESTAMP(date,time),'yyyy-MM-dd hh') AS Hour,
COUNT(*) FROM *.log WHERE sc-status=500 AND cs-uri-stem='/Start/default.aspx' AND date='2012-10-18' GROUP BY Hour ORDER BY Hour" -i:w3c
    
    Hour          COUNT(ALL *)
    ------------- ------------
    2012-10-18 08 191
    2012-10-18 09 163
    2012-10-18 14 150
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Gambar 6: Kueri LogParser (cs-uri-stem dengan 500 sc-status)

Subset hasil pada Gambar 6 membatasi rentang tanggal masalah. Informasi ini dapat diteruskan ke jaringan, database, administrator sistem operasi, dan tim pengembangan untuk memeriksa apakah ada hal lain yang terjadi pada saat yang sama. Misalnya: Apakah ada masalah tambahan antara 08:00 dan 09:59:59 GMT dan antara 14:00:00 dan 14:59:59 GMT?

Kumpulan kueri LogParser berikutnya menggunakan bidang berikut, yang dapat memberikan wawasan yang lebih baik tentang masalah performa:

Bidang Deskripsi Diaktifkan secara default
waktu yang diambil Lamanya waktu yang diambil tindakan, dalam milidetik Ya
sc-byte Jumlah byte yang dikirim oleh server Tidak
cs-byte Jumlah byte yang diterima server Tidak

Seperti disebutkan sebelumnya, luangkan waktu sekarang untuk meminta bidang sc-byte dan cs-byte diaktifkan atau, jika memungkinkan, aktifkan sendiri. Mereka memberikan beberapa wawasan berharga tentang sistem Anda dan perilakunya. Ambil Gambar 7, misalnya. Anda melihat bahwa waktu rata-rata cukup baik pada beberapa ratus milidetik. Namun, lihat waktu maksimum yang diambil, itu terlalu banyak waktu.

logparser.exe "SELECT  cs-method, COUNT(*) AS TotalCount, MAX(time-taken) AS MaximumTime, AVG(time-taken) AS AverageTime FROM *.log GROUP BY cs-method ORDER BY TotalCount DESC" -i:w3c
    
    cs-method TotalCount MaximumTime AverageTime
    --------- ---------- ----------- -----------
    GET       3172034    1366976     153
    POST      1011765    256539      359  
    HEAD      5363       26750       209  
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Gambar 7: Kueri LogParser (waktu MAX dan AVG yang diambil)

Saya tahu Anda bertanya pada diri sendiri sudah pertanyaan berikutnya yang perlu dijawab. Permintaan mana yang memakan banyak waktu? Gambar 8 menunjukkan jawaban atas pertanyaan tersebut. Seperti yang akan Anda perhatikan, saya telah melanjutkan dan menyertakan bidang sc-byte dalam kueri LogParser. Ingat, sc-byte mewakili ukuran file yang dikirim dari server kembali ke klien.

logparser.exe "SELECT cs-uri-stem, time-taken, sc-bytes FROM *.log WHERE time-taken > 250000 ORDER BY time-taken DESC" -i:w3c
    
    cs-uri-stem                 time-taken sc-bytes
    --------------------------- ---------- --------
    /ShoppingCart/ViewCart.aspx 1366976    256328
    /DataService.asmx           1265383    53860
    /Start/default.aspx         262796     8077
    /GetDetailsView.aspx        261305     5038
    /Details/ImageUrls.asmx     256539     2351
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     8.98 seconds

Gambar 8: Kueri LogParser (waktu MAX dan AVG yang diambil)

Kami mungkin semua setuju bahwa waktu yang diambil untuk permintaan melebihi waktu respons 'normal'. Namun, ukuran file adalah sesuatu yang perlu dianalisis oleh administrator atau pengembang untuk menentukan apakah ukurannya berada dalam rentang yang dapat diterima.

Kesimpulannya adalah bahwa file GetDetailsView.aspx telah melemparkan sejumlah 500 kode Status HTTP dan pada titik tertentu membutuhkan waktu lama untuk diselesaikan, meskipun itu adalah file yang relatif kecil. Anda mungkin ingin melihat tanggal dan waktu ketika masalah di mana terjadi untuk file ini, dan memeriksa kode dalam file dengan masalah apa pun yang terjadi. (Misalnya, log IIS berisi daftar variabel yang diteruskan dalam string kueri; Anda dapat memeriksa nilai-nilai tersebut untuk data yang buruk.)

Contoh yang diberikan pada gambar 4 - 8 membantu mendapatkan pemahaman tentang di mana akar penyebab masalah mungkin ada. Namun, kemungkinan analisis ini hanya merender pandangan yang lebih baik tentang situasi yang akan menyebabkan lebih banyak pertanyaan dan analisis yang lebih dalam. Jika demikian, Anda mungkin ingin membuat representasi data ini dengan cara yang lebih mudah disajikan. Bagian berikut mencakup ini secara rinci.

Pelaporan

Cuplikan layar jendela perintah yang berisi kueri LogParser dan hasilnya mungkin baik-baik saja selama fase analisis masalah performa; namun, jika Anda perlu pergi di depan manajer atau direktur untuk menjelaskan apa yang terjadi, itu mungkin tidak memenuhi tanda.

Catatan

Agar pembuatan bagan berfungsi melalui LogParser, Anda harus menginstal Komponen Web Office. Artikel berikut menjelaskan cara melakukannya:

Gambar 9 memperlihatkan kueri LogParser untuk membuat bagan pai 3D yang berisi jumlah permintaan dan kode Status HTTP terkait. Saya menghapus status 200, karena itu berhasil. Apa yang saya setelah di sini adalah permintaan yang merupakan sesuatu selain OK.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.gif FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Request Status"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Gambar 9: Kueri LogParser (Buat bagan pai 3D)

Hasil kueri diilustrasikan dalam Gambar 10. Ada sejumlah parameter tambahan yang dapat Anda teruskan ke LogParser yang memengaruhi gambar. Misalnya, legenda, groupSize, config, dll... Untuk mendapatkan daftar lengkap masukkan: LogParser -h -o:CHART untuk daftar semua parameter. Perintah ini juga akan menyediakan daftar jenis bagan yang berbeda.

Diagram bagan pai tiga dimensi memperlihatkan alokasi status permintaan.
Gambar 10: Bagan pai 3D LogParser

Bagan lain yang berguna adalah rasio antara permintaan yang di-cache dan aktual. Ingat dari bagian Analisis Data di mana saya membahas bahwa kode Status HTTP 200 berarti bahwa file yang diminta diambil dari server namun, 304 diambil dari klien. Gambar 11 memperlihatkan kueri LogParser untuk pembuatan bagan ini. Perhatikan bahwa saya menggunakan parameter -values .

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO cache.gif FROM *.log WHERE sc-status=200 OR sc-status=304 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Cache" -values:ON
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    2
    Execution time:     6.35 seconds

Gambar 11: Kueri LogParser (Buat bagan pai 3D)

Meskipun perbedaan antara kode Status HTTP 200 dan 304 terlihat jelas, saya pikir mungkin menambahkan beberapa nilai untuk menyertakan jumlah temuan untuk masing-masing. Gambar 12 mengilustrasikan output kueri LogParser sebelumnya.

Diagram bagan pai tiga dimensi memperlihatkan alokasi cache.
Gambar 12: Bagan pai 3D LogParser

Saya pikir Anda mendapatkan gambaran sekarang tentang bagaimana membuat bagan Log IIS menggunakan LogParser dapat membantu menyampaikan apa yang terjadi jauh lebih baik daripada tabel data. Tetapi sebelum saya berhenti, saya ingin menunjukkan satu contoh lagi menggunakan jenis bagan Kolom. Kueri LogParser yang diperlihatkan di Gambar 13 menghasilkan bagan Kolom 3D yang memperlihatkan jumlah 500 kode Status HTTPS per jam.

logparser.exe "SELECT to_string(to_timestamp(date, time), 'yyyy-MM-dd hh') AS Hour, COUNT(*) AS Count INTO 500.gif FROM *.log WHERE sc-status=500 GROUP BY Hour ORDER BY Hour" -i:w3c -o:CHART -chartType:Column3D -ChartTitle:"500 Errors by Hour"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    13
    Execution time:     6.32 seconds

Gambar 13: Kueri LogParser (Buat bagan kolom 3D)

Bagan yang dihasilkan diilustrasikan dalam Gambar 14.

Diagram bagan kolom tiga dimensi memperlihatkan jumlah kesalahan 500 per jam menurut tanggal.
Gambar 14: Bagan kolom 3D LogParser

Membuat bagan menggunakan Excel dan CSV

Di awal bagian ini saya menyebutkan bahwa penginstalan Office Web Component (OWC) adalah persyaratan jika Anda ingin menggunakan kemampuan bagan LogParser. Di organisasi Anda, mungkin ada batasan yang melarang ini atau Anda mungkin tidak ingin menginstalnya. Jika salah satunya adalah kasusnya, maka pertimbangkan untuk mengekspor hasil kueri LogParser ke file CSV dan mengimpornya ke Excel.

Gambar 15 memperlihatkan kueri LogParser yang mengekstrak kode Status HTTP untuk semua permintaan yang bukan 200 ke file CSV.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.csv FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:csv
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Gambar 15: Kueri LogParser (Buat file CSV untuk diimpor ke Excel)

Perhatikan pada Gambar 15 bahwa saya menggunakan parameter -o sehingga LogParser membuat output dalam format CSV.

Untuk mengimpor file CSV ke Excel sehingga bagan bisa dibuat, buka Excel, navigasikan ke tab DATA dan pilih Dari Teks. Gambar 16 menunjukkan seperti apa tampilannya.

Cuplikan layar memperlihatkan opsi menu tab Data Excel.Gambar 16: Impor file CSV yang dibuat oleh LogParser ke Excel

Pilih file status.csv yang dibuat oleh kueri LogParser dan navigasikan melalui wizard impor. Impor file CSV yang dibatasi 'koma' dan Anda akan berakhir dengan Status di kolom A dan jumlah kemunculan untuk setiap status di kolom B. Ini mengasumsikan Anda menjalankan kueri LogParser yang diperlihatkan dalam Gambar 15. Terakhir, pilih semua data dari kolom A dan B, termasuk header dan pilih jenis bagan Pai untuk dibuat. Gambar 17, menggambarkan bagaimana ini mungkin terlihat.

Cuplikan layar memperlihatkan opsi tab Sisipkan Excel. Data dalam kolom A dan B dipilih.Gambar 17: Membuat bagan Pai menggunakan file CSV

Hasil akhirnya adalah bagan Pai, Gambar 18 yang mirip dengan yang diperlihatkan sebelumnya di Gambar 10. Ada banyak opsi dalam hal warna, jenis bagan, label, dll. Dengan mengklik tombol, Anda dapat mengubah jenis bagan dari Pai ke Batang atau ke Garis. Ada banyak opsi untuk membuat bagan tampilan profesional dalam Excel.

Cuplikan layar bagan pai tiga dimensi memperlihatkan status permintaan.
Gambar 18: Bagan pai menggunakan file CSV yang mirip dengan Gambar 10

Ada begitu banyak opsi dan kemungkinan untuk menganalisis dan menyajikan hasil analisis tersebut menggunakan LogParser. Untuk beberapa tips dan contoh tambahan, lihat artikel-artikel ini ditulis oleh Robert McMurray. Ada juga file bantuan yang sangat berguna dan banyak skrip yang telah ditulis sebelumnya yang disediakan dalam paket penginstalan LogParser. Bagian berikutnya akan membahas ini dan topik lain secara lebih rinci.

Bantuan

Saat Anda menginstal LogParser 2.2 ke komputer Anda, LogParser diinstal secara default ke C:\Program Files (x86)\Log Parser 2.2 direktori. Navigasikan ke lokasi tersebut dan tinjau direktori Samples\Queries and Samples\Scripts untuk pasokan kode prewritten yang berlimpah yang akan membuat Anda bergerak cepat.

Anda juga akan mewujudkan manfaat besar dengan membaca konten dalam file LogParser.chm.

Mengurangi ukuran atau memisahkan file log IIS

Anda mungkin mengalami situasi di mana file log IIS terlalu besar untuk dikueri LogParser. Ini kemungkinan besar pada mesin 32-bit, tetapi juga dapat terjadi pada mesin 64-bit. Namun, jika Anda mengalami kesalahan 'kehabisan memori' saat menjalankan kueri LogParser, pertimbangkan untuk menjalankan perintah yang diperlihatkan dalam Gambar 19. Kueri mengekstrak beberapa bidang penting dari file log IIS besar dan menempatkannya ke bidang lain, yang menghasilkan file log yang lebih kecil.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 19712301
    Elements output:    19712301
    Execution time:     3.07 seconds

Gambar 19: Mengurangi ukuran file log IIS (dengan menghapus bidang)

Dalam contoh ini, saya menyadari pengurangan ukuran file sekitar 45%. Dalam banyak kasus ini mungkin cukup, pada orang lain mungkin tidak. Ini tergantung pada ukuran file log asli. Jika Anda menemukan bahwa Anda masih perlu mengurangi ukuran file log IIS, pertimbangkan untuk menambahkan batasan waktu tanggal ke kueri LogParser seperti yang ditunjukkan pada Gambar 20.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log WHERE to_timestamp(date, time) >= timestamp('2012-11-09 00:00:00', 'yyyy-MM-dd hh:mm:ss')" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 240123
    Elements output:    240123
    Execution time:     0.45 seconds

Gambar 20: Mengurangi ukuran file log IIS lebih lanjut dengan menambahkan klausa WHERE

Ini adalah teknik berharga untuk mengurangi ukuran file, tetapi juga berguna untuk menghapus entri yang tidak diinginkan dari Log IIS. Misalnya, ketika mulai memecahkan masalah, Anda menyadari bahwa time-take, sc-byte, dan cs-byte tidak dicatat. Anda mengaktifkannya di IIS dan ingin kueri hanya menganalisis entri tersebut dengan bidang yang baru diaktifkan. Gunakan pernyataan where untuk mengekstrak data dari file log IIS sejak bidang tersebut diaktifkan. Ini penting ketika Anda menggunakan agregat AVG, MIN, dan MAX.

Kesimpulan

LogParser adalah alat kecil tetapi kuat untuk menganalisis sejumlah jenis log sistem yang berbeda. Artikel ini berfokus pada kueri yang berlaku untuk Log IIS. Ketika masalah performa atau kesalahan dialami di lingkungan IIS Anda, terkadang sulit untuk mengetahui dari mana harus memulai.

LogParser dapat digunakan sebagai titik awal, karena administrator sistem yang memiliki beberapa keterampilan SQL dapat dengan cepat membangun beberapa kueri LogParser yang sangat canggih. Kueri ini dapat digunakan untuk lebih lanjut analisis akar penyebab masalah.

Berikut adalah tautan yang dimaksud dalam artikel ini, ditambah beberapa tautan dengan informasi tambahan.