Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby

5 Alasan Mengapa Relik Baru Adalah Sahabat Pengembang

by
Read Time:16 minsLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Getting Started With New Relic in 30 Minutes
3 New Relic Power Features You Should Be Using Today
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

Setelah Anda mulai menggali di sekitar New Relic, Anda mulai menyadari betapa banyak fitur menarik yang dimiliki layanan ini untuk membantu memantau kinerja dan kesehatan aplikasi Anda. Benar-benar sulit untuk memilih hanya lima hal untuk dibicarakan, jadi daripada berfokus pada fitur yang jelas, mari kita lihat beberapa fungsionalitas yang kurang menarik yang disediakan oleh New Relic dan bagaimana kita dapat menggunakannya dengan cara yang menarik dan terkadang tidak ortodoks.

Ketika kami meninggalkan Anda terakhir kali, kami memiliki aplikasi Rails 'Hello World' dasar (disebut New Relic_rails1, tinggal di ~/project/tmp/New Relic). Kami akan terus menggunakan aplikasi ini, memperluasnya dan melihat apakah kami dapat menggunakannya untuk mendemonstrasikan fitur-fitur dari New Relic yang akan kami lihat.

Konten yang disponsori

Konten ini ditugaskan oleh New Relic dan ditulis dan/atau diedit oleh tim Tuts+. Tujuan kami dengan konten yang disponsori adalah untuk mempublikasikan tutorial yang relevan dan objektif, studi kasus, dan wawancara inspirasional yang menawarkan nilai pendidikan asli kepada pembaca kami dan memungkinkan kami untuk mendanai pembuatan konten yang lebih bermanfaat.


Pemantauan Ketersediaan

Ini adalah salah satu fitur New Relic yang biasanya tidak membuat halaman depan materi pemasaran. Tidak banyak, tetapi jika Anda memikirkannya, apa yang lebih penting yang memastikan aplikasi Anda benar-benar berjalan dan dapat diakses oleh pengguna?

Pertama, ketika Anda mengatur pemantauan ketersediaan, aplikasi Anda mendapat tanda bintang bagus di dasbor aplikasi utama Anda:

newrelic_availability_asterisknewrelic_availability_asterisknewrelic_availability_asterisk

Ini pengingat visual yang bagus, sehingga Anda dapat melihat aplikasi mana yang masih membutuhkan pemantauan ketersediaan diaktifkan.

Sekarang mari kita lihat bagaimana kita bisa mengatur pemantauan ketersediaan dan apa yang bisa kita dapatkan darinya. Pertama, Anda perlu melompat ke aplikasi Anda dan kemudian masuk ke Settings->Availability Monitoring. Anda akan melihat sesuatu seperti ini:

newrelic_availability_monitoringnewrelic_availability_monitoringnewrelic_availability_monitoring

Anda perlu memberikan URL yang ingin Anda ping Relic Baru, centang kotak, simpan perubahan Anda dan Anda siap melakukannya. Relik Baru akan mulai mengenai URL Anda setiap 30 detik. Tapi kesenangan tidak berhenti di situ. Relik Baru akan melakukan ping URL Anda melalui permintaan HTTP HEAD (dan menganggap semuanya OK jika menerima 200 kode respons), tetapi Anda dapat menyediakan string respons yang ingin dicari New Relic dalam hal ini akan melakukan permintaan GET dan periksa respons untuk string yang Anda berikan. Ini bisa sangat berguna jika Anda memiliki halaman 'Pemeriksaan Kesehatan' khusus yang ingin Anda tekan.

Anda juga dapat mengatur notifikasi email jika downtime terjadi:

newrelic_availability_notificationsnewrelic_availability_notificationsnewrelic_availability_notifications

Sekarang Anda sedang memantau ketersediaan, Anda akan memiliki akses ke laporan yang bagus yang akan menunjukkan kepada Anda secara visual ketika terjadi downtime:

newrelic_availability_reportnewrelic_availability_reportnewrelic_availability_report

Faktanya, banyak grafik Anda (mis. Ikhtisar aplikasi) akan memiliki indikasi visual ini:

newrelic_availability_overviewnewrelic_availability_overviewnewrelic_availability_overview

Anda harus mengakui bahwa itu beberapa fungsi yang cukup bagus untuk usaha yang sangat sedikit.

Anda tentu saja dapat menonaktifkan dan mengaktifkan kembali pemantauan (melalui REST API New Relic) ketika Anda melakukan penyebaran, untuk memastikan Anda tidak mendapatkan acara downtime palsu.

Efek samping lain yang menarik dari hal ini adalah bahwa jika Anda menyebarkan proyek kesayangan Anda ke Heroku pada single dyno, Anda dapat menggunakan fungsi ping ini untuk mencegah dyno Anda tertidur, yang dapat membuat situs Anda lambat secara lambat jika Anda tidak memiliki banyak lalu lintas.


Rekaman Kesalahan Kustom

Jika kesalahan tak terduga terjadi di aplikasi Anda, Relik Baru akan mencatat ini untuk Anda dan memberi Anda grafik yang bagus. Aplikasi kecil "Hello World" kami telah tampil mengagumkan untuk saat ini, jadi tidak ada yang bisa kami lihat di bagian depan itu. Namun, kami dapat dengan sengaja merusak aplikasi kami dan melihat apa yang diberikan New Relic kepada kami.

Mari kita modifikasi HelloController kita untuk meningkatkan kesalahan secara acak sekitar 50% dari waktu:

Kami sekarang akan melakukan beberapa ratus panggilan ke aplikasi kami dan melihat apa yang terjadi:

Grafik kesalahan Relik Baru kami sekarang terlihat jauh lebih menarik:

newrelic_error_overviewnewrelic_error_overviewnewrelic_error_overview

Dan kita dapat menelusuri untuk mendapatkan beberapa spesifik:

newrelic_error_detailednewrelic_error_detailednewrelic_error_detailed

Seperti yang Anda lihat, kami dapat mengurutkan kesalahan dan memfilternya serta melihat kesalahan dari permintaan web dan tugas latar belakang secara terpisah. Ini adalah beberapa hal yang sangat kuat untuk membantu Anda mendiagnosis dan memperbaiki masalah dengan aplikasi Anda. Anda tentu saja juga dapat melihat jejak tumpukan untuk setiap kesalahan:

newrelic_error_tracenewrelic_error_tracenewrelic_error_trace

Ada layanan yang khusus didedikasikan untuk menangkap kesalahan dari aplikasi Anda, beberapa yang paling terkenal adalah Airbrake dan Bugsnag. Ini adalah layanan berbayar yang digunakan oleh banyak aplikasi, tetapi fungsionalitas yang disediakan New Relic hampir membuat layanan ini berlebihan. Bahkan jika kami dapat mengirim kesalahan khusus ke New Relic (daripada membiarkannya menangkap kesalahan yang belum kami selamatkan), kami dapat membuat kasus yang menarik karena tidak menggunakan layanan pengumpulan kesalahan terpisah (dan menghemat uang dan menyingkirkan tambahan permata dalam proses).

Walaupun New Relic tidak mendokumentasikan cara apa pun untuk melakukan ini, kita selalu dapat pergi ke sumber untuk melihat apakah yang ingin kita lakukan itu sulit. Bagi saya sepertinya sepele bagi kami untuk mengirim kesalahan khusus ke New Relic, jadi mari kita coba. Kami akan memodifikasi tindakan pengontrol kami lagi untuk menyelamatkan semua kesalahan dan mengirim kesalahan khusus ke New Relic:

Setelah kami melakukan beberapa panggilan lagi dan menunggu data datang, kami melihat yang berikut:

newrelic_error_customnewrelic_error_customnewrelic_error_custom

Berhasil, kesalahan khusus kami datang! New Relic pasti dapat bertindak sebagai layanan pengumpulan kesalahan kami. Kami tentu saja menggunakan antarmuka pribadi di sini yang tidak terlalu bagus, tapi kami dapat menempatkan panggilan notice_error di belakang fasad yang akan membuat segalanya lebih mudah bagi kami jika antarmuka berubah.

Pendekatan yang lebih baik mungkin adalah dengan tidak memperlakukan kesalahan khusus seperti kesalahan biasa sama sekali, tetapi membuat metrik khusus untuk dilacak dan kemudian membangun dasbor khusus untuk divisualisasikan. Dengan cara ini kami tidak menggunakan fungsionalitas tidak berdokumen apa pun dan masih akan mendapatkan semua manfaatnya - brilian!


Pelacakan Transaksi Kunci

New Relic biasanya akan melacak transaksi Anda untuk Anda:

newrelic_transaction_trackingnewrelic_transaction_trackingnewrelic_transaction_tracking

Anda akan dapat melihat di mana aplikasi Anda menghabiskan sebagian besar waktunya (mis. Dalam pengontrol, model, basis data dll.). Namun, New Relic tidak akan menangkap jejak terperinci kecuali transaksi membutuhkan waktu lebih lama dari Appdex & 4 detik. Biasanya ini OK, tetapi kadang-kadang Anda memiliki transaksi yang jauh lebih penting untuk aplikasi Anda atau bisnis Anda. Mungkin transaksi ini volumenya sangat tinggi atau berurusan dengan peristiwa penting seperti pembayaran. Cukuplah untuk mengatakan Anda perlu memastikan jenis transaksi ini selalu berkinerja sangat baik.

Masalahnya adalah, ketika sebuah transaksi penting ini mungkin telah menerima cukup banyak cinta dari Anda dan mungkin berkinerja cukup baik. Katakanlah Anda memiliki transaksi dengan throughput yang sangat tinggi (terjadi berkali-kali per menit). Jika transaksi ini berkinerja optimal, semuanya baik-baik saja, tetapi jika kinerjanya sedikit menurun, karena volume lalu lintas, hal itu mungkin memiliki efek merugikan yang tidak proporsional pada aplikasi Anda. Yang Anda inginkan adalah sesuatu seperti:

  • nilai T Apdex terpisah hanya untuk transaksi ini
  • kemampuan untuk menerima peringatan ketika kinerja transaksi ini menurun
  • jejak terperinci setiap kali transaksi ini melakukan sedikit bahkan tidak optimal

Inilah yang diberikan oleh Transaksi Kunci kepada Anda!

Sebelum kita membuat transaksi kunci untuk aplikasi 'Hello World' kita, kita perlu membuat transaksi yang lebih menarik yang biasanya akan berkinerja baik, tetapi terkadang akan berkinerja buruk. Kami akan membangun kemampuan untuk melihat merek dan model mobil dan mendapatkan merek tertentu untuk memperlambat transaksi. Pertama rute:

Kami ingin bisa mendapatkan mobil acak, ini akan dipetakan ke CarsController:

Kami mendapatkan mobil acak dari database dan jika mobil itu 'Ford' kami akan memiliki transaksi lambat di tangan kami. Tentu saja kita membutuhkan model Car:

Kami harus mengonfigurasi basis data kami untuk menggunakan MySql dalam pengembangan (saya melakukan ini, tetapi Anda dapat tetap menggunakan sqlite):

Kami membutuhkan migrasi untuk membuat tabel cars:

Dan kita membutuhkan beberapa data seed yang akan kita masukkan ke file db/seeds.rb:

Terakhir kita mungkin harus memiliki view cars/show_random.html.erb:

Anda juga harus menambahkan permata mysql2 ke Gemfile jika Anda menggunakan MySql. Setelah ini, kita hanya perlu membuat dan mengisi basis data, restart server kita dan kita siap:

Anda harus menekan URL, untuk memastikan New Relic mengakui bahwa transaksi ini ada:

Kami sekarang siap memantau transaksi ini sebagai transaksi utama. Pertama, lompat ke tab transaksi:

newrelic_transaction_tabnewrelic_transaction_tabnewrelic_transaction_tab

Klik tombol 'Lacak Transaksi Kunci', dan pilih transaksi kami yang baru dibuat:

newrelic_transaction_createnewrelic_transaction_createnewrelic_transaction_create

Kami dapat memberikan nama transaksi kunci baru kami, memilih T Apdex yang kami senangi serta mengatur beberapa peringatan. Saat transaksi kami membutuhkan waktu lebih lama dari Apdex yang kami pilih, Relik Baru akan menangkap jejak terperinci yang dapat kami gunakan untuk mencari tahu dari mana masalah kinerja berasal. Mari kita melakukan beberapa panggilan terhadap URL baru kita dan melihat data apa yang kita dapatkan:

Hmm, sepertinya beberapa transaksi kami membuat frustrasi pengguna kami:

newrelic_transaction_frustratingnewrelic_transaction_frustratingnewrelic_transaction_frustrating

Mari kita lihat apakah New Relic telah menangkap beberapa jejak transaksi untuk kita:

newrelic_transaction_slow_tracesnewrelic_transaction_slow_tracesnewrelic_transaction_slow_traces

Mari kita lihat salah satu jejak ini. Butuh sekitar 2 detik untuk merespons, tetapi hanya 10 milidetik yang menggunakan CPU:

newrelic_transaction_cpu_burnnewrelic_transaction_cpu_burnnewrelic_transaction_cpu_burn

Semua pernyataan SQL kami cepat sehingga database tidak menjadi masalah:

newrelic_transaction_sql_tracenewrelic_transaction_sql_tracenewrelic_transaction_sql_trace

Sepertinya sebagian besar waktu dihabiskan dalam aksi controller:

newrelic_transaction_controller_actionnewrelic_transaction_controller_actionnewrelic_transaction_controller_action

Mari kita menggali sedikit jejaknya. Sepertinya SQL SELECT cepat, Car.find juga cepat. Kemudian kita kehilangan sekitar 2 detik yang diikuti oleh beberapa rendering template yang sangat cepat:

newrelic_transaction_trace_detailnewrelic_transaction_trace_detailnewrelic_transaction_trace_detail

New Relic dengan baik hati menyoroti kami di mana kami kehilangan dua detik itu. Kita perlu melihat kode pengontrol kami setelah panggilan Car.find:

Hmm, SELECT awal harus menjadi panggilan Car.count, dan Car.find, harus karena panggilan Car.offset. Penundaan besar kami tepat setelah ini. Ahh lihat ini, beberapa orang konyol telah menunda 2 detik dalam kode kita ketika merek mobil 'Ford'. Itu akan menjelaskan mengapa penundaan 2 detik kami hanya terjadi beberapa saat. Saya lebih baik melakukan git blame pada repositori kami untuk mencari tahu siapa yang menaruh kode mengerikan itu di sana! Pada pemikiran kedua, saya lebih baik tidak, karena mungkin mengatakan bahwa itu adalah saya.


Rekaman Panggilan Layanan Eksternal

Setiap kali Anda melakukan panggilan ke layanan lain dari dalam aplikasi Anda (mis. Permintaan HTTP ke API seperti Twitter), New Relic akan memonitor ini sebagai panggilan eksternal. Dewasa ini aplikasi serius dapat diintegrasikan dengan sejumlah API eksternal. Seringkali layanan eksternal ini dapat secara signifikan menurunkan kinerja aplikasi Anda, terutama jika Anda membuat panggilan ini dalam proses. Relik Baru dapat menunjukkan panggilan eksternal mana yang paling lambat, mana yang paling Anda panggil dan yang merespons paling lambat. Anda juga dapat melihat kinerja masing-masing layanan eksternal yang Anda gunakan secara individual. Mari kita coba.

Kami akan membuat layanan eksternal kami sendiri, dengan membangun aplikasi Sinatra kecil. Pertama kami memasang permata:

Buat file baru untuk layanan kami:

Dan masukkan kode berikut di sana:

Layanan ini akan tidur untuk waktu acak (antara 0 dan 2000 milidetik) dan kemudian mengembalikan respons 'Halo' dengan waktu tidurnya. Sekarang yang harus kita lakukan adalah memulainya:

Kembali di aplikasi Rails kami, kami akan membangun controller baru untuk memanggil layanan eksternal kami. Kami akan menggunakan rute ini:

Pengendali kami akan memanggil layanan Sinatra kami melalui HTTP:

Dan kami membutuhkan tampilan untuk menampilkan hasilnya:

Yang harus kita lakukan sekarang adalah melakukan beberapa panggilan ke titik akhir baru kami:

Mari kita lihat apa yang diproduksi oleh New Relic untuk kita.

newrelic_transaction_external_servicenewrelic_transaction_external_servicenewrelic_transaction_external_service

New Relic memang mengangkat panggilan eksternal baru kami. Kami mendapat total panggilan per menit yang kami lakukan ke titik akhir eksternal. Dan total yang dihabiskan merespons oleh layanan eksternal. Tentu saja bagan kami terlihat sedikit karena kami hanya memiliki satu layanan eksternal, yang berarti kami tidak memiliki apa pun untuk dibandingkan.

Kami juga bisa mendapatkan data yang lebih rinci tentang panggilan eksternal tertentu serta dari mana di aplikasi kami panggilan ini dibuat:

newrelic_transaction_external_callnewrelic_transaction_external_callnewrelic_transaction_external_call

Kita dapat melihat kapan panggilan dilakukan, throughput dan waktu respons rata-rata. Ini mungkin tampak sederhana, tetapi ketika Anda memiliki aplikasi dengan banyak layanan eksternal, fitur ini dapat memberi Anda gambaran yang sangat bagus tentang bagaimana kinerja layanan eksternal ini, serta kapan dan di mana mereka digunakan. Ini dapat memungkinkan Anda untuk membuat keputusan mengenai caching tanggapan layanan eksternal tertentu jika memungkinkan, atau bahkan menjatuhkan layanan eksternal tertentu jika kinerjanya tidak sesuai dengan standar. Dan Anda tidak perlu lagi berdebat tentang hal-hal ini berdasarkan metrik rasa dan rumahan, Anda akan memiliki data yang sulit untuk membuktikan maksud Anda.

Analisis Skalabilitas dan Kapasitas

Tidak ada yang lebih menyebalkan bagi seorang pengembang selain membuat aplikasi Anda jatuh karena lonjakan lalu lintas. Semuanya berjalan lancar sampai beberapa ratus pengguna tambahan datang dan aplikasi Anda meledak. Anda memiliki perasaan bahwa ini mungkin terjadi, tetapi tidak bisa memastikan - sikap menunggu dan melihat tampaknya merupakan pendekatan yang paling pragmatis. Baik dengan laporan kapasitas dan skalabilitas New Relic, Anda tidak lagi harus 'menunggu dan melihat'. Anda dapat langsung mengetahui seberapa baik penskalaan aplikasi Anda, Anda dapat melakukan tes beban dan langsung melihat apakah aplikasi Anda dapat menangani beban. Anda dapat mengamati tren waktu respons aplikasi saat basis pengguna Anda tumbuh dan memperkirakan kapan Anda perlu menambah kapasitas. Semua itu adalah hal yang benar-benar luar biasa.

Pertama, mari kita lihat laporan kapasitas:

newrelic_capacity_instance_busynewrelic_capacity_instance_busynewrelic_capacity_instance_busy

Hmm, yang ini menunjukkan lonjakan besar, tetapi sebaliknya tidak ada. Kami sedang menjalankan mode pengembangan, jadi ini bisa dimengerti. Lonjakan itu terjadi ketika kami melakukan banyak permintaan secara bersamaan beberapa saat yang lalu. Seperti yang Anda lihat ketika kami melakukan permintaan bersamaan itu, kami memaksimalkan contoh Webrick kami yang sepi. Jika ini adalah produksi dan beban itu konstan, instance kita akan selalu 100% sibuk, yang mungkin akan menunjukkan bahwa kita membutuhkan instance lain

Laporan analisis instance sedikit berbeda:

newrelic_capacity_instance_analysisnewrelic_capacity_instance_analysisnewrelic_capacity_instance_analysis

Dalam kasus kami, kami tidak mendapatkan banyak hal dari itu, tetapi biasanya menunjukkan kepada kami jumlah instance yang sedang berjalan, dan jumlah instance yang sebenarnya kami perlukan untuk menangani beban jika semua instance 100% sibuk. Jadi jika kita menjalankan 10 instance dan load instance bersamaan 2, kita bisa dengan mudah membagi dua (atau bahkan lebih dari separuh) jumlah instance yang berjalan dan tidak menurunkan kinerja sama sekali. Untuk aplikasi kecil yang hanya menjalankan beberapa instance, ini bukan masalah besar, tetapi untuk aplikasi besar dengan puluhan dan ratusan instance, ini dapat diterjemahkan menjadi penghematan biaya yang signifikan.

Dan kemudian ada laporan skalabilitas. Laporan waktu respons mungkin yang paling menarik/penting:

newrelic_scalability_responsenewrelic_scalability_responsenewrelic_scalability_response

Sekali lagi, grafik kami sangat terdistorsi karena ini adalah aplikasi pengembangan yang kami mainkan secara acak. Gagasan dengan laporan ini adalah bahwa seiring peningkatan untuk aplikasi Anda (lebih banyak permintaan per menit), waktu respons harus tetap dekat dengan konstan (mis. Kinerja tidak menurun ketika ada lebih banyak lalu lintas). Ini berarti Anda harus selalu melihat sesuatu yang menyerupai garis datar di sini. Jika garis Anda miring ke atas secara signifikan, aplikasi Anda mungkin berjuang untuk menangani lalu lintas dan Anda mungkin perlu melihat penambahan kapasitas. Di mana menambah kapasitas adalah pertanyaan lain sepenuhnya (mis. Kapasitas basis data, lebih banyak server, dll.). Dua laporan skalabilitas lainnya dapat membantu Anda menjawabnya. Ada laporan basis data:

newrelic_scalability_databasenewrelic_scalability_databasenewrelic_scalability_database

Anda tidak dapat mengharapkan database Anda tidak akan terpengaruh oleh beban yang lebih tinggi, jadi apa yang seharusnya Anda lihat di sini adalah garis yang perlahan-lahan naik seiring peningkatan dari aplikasi Anda. Terserah Anda ketika waktu respons basis data dianggap tidak dapat diterima (mis. Terlalu memengaruhi respons aplikasi), tetapi ketika Anda memutuskan bahwa respons basis data terlalu lambat, Anda tahu sudah waktunya untuk menambahkan kapasitas basis data. Laporan lainnya adalah CPU:

newrelic_scalability_cpunewrelic_scalability_cpunewrelic_scalability_cpu

Sekali lagi Anda tidak dapat benar-benar mengharapkan throughput yang lebih tinggi untuk tidak mempengaruhi beban CPU Anda, Anda akan melihat garis yang perlahan-lahan naik dengan peningkatan throughput. Ini, bersama dengan laporan kapasitas yang telah kita bicarakan sebelumnya dapat memungkinkan Anda memutuskan kapan akan menambahkan lebih banyak proses/server Rails untuk memastikan kinerja Anda tetap layak.


Kesimpulan

Jika satu atau semua fitur itu mengangkat alis (atau dua) untuk Anda, kabar baiknya adalah bahwa kami baru saja menggaruk permukaan. Masing-masing fitur lebih dari layak artikel mendalam sendiri. Tetapi, New Relic juga memiliki sejumlah fitur lain yang berpotensi bahkan lebih kuat, termasuk Pemantauan Pengguna Nyata, Platform New Relic, Profiler Thread, Ambang Batas Pemberitahuan dan Pemberitahuan, dan banyak lainnya. Kami akan mencoba membahas beberapa atau mungkin bahkan semua ini dalam tutorial selanjutnya.

Untuk saat ini, coba New Relic, gunakan agen dalam bahasa favorit Anda dan lihat apakah Anda dapat menemukan cara luar biasa menggunakan beberapa fungsi yang disediakan New Relic. Dan jika Anda memiliki beberapa cara inovatif untuk menggunakan New Relic, pastikan untuk memberi tahu semua orang dengan meninggalkan komentar.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.