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

Mulai Dengan Mengawasi Aplikasi Web Anda Menggunakan Tanda Relik Baru

Read Time: 29 mins
This post is part of a series called Performance Monitoring With New Relic.
Diagnose WordPress Performance Problems With New Relic
How to Use New Relic Browser to Improve Your Web App's User Experience
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)

Pengenalan

Mari kita mulai dengan contoh ekstrem. Setelah tiga tahun di pasar, menurut analytics situs berpikir game perkiraan, menara pertahanan memukul permainan Clash of Clans adalah masih top terlaris mobile permainan kemarin, membawa dalam menakjubkan $1,5 juta sehari—atau sedikit lebih dari $1.000 setiap menit. Di jantung permainan adalah cluster server web yang mengurus semuanya dari account pengguna untuk acara permainan dan pemrosesan pembayaran.

Bayangkan jika suatu hari tim mendorong membangun yang baru yang pecah proses pembayaran.

Setiap menit bug tidak dihiraukan akan berarti hilangnya seribu dolar!

Sekarang, bayangkan bug ini muncul pada malam hari ketika tidak ada di tempat kerja...

Nomor Anda mungkin lebih kecil, tetapi konsep dasar tetap sama: jika Anda membuat hidup Anda dari menjalankan aplikasi web, setiap masalah dengan layanan, baik itu bug dalam kode atau masalah dengan penyiapan server, berarti kehilangan penjualan.

Bahkan lebih buruk: jika bug yang terjadi pada sepotong kode bahwa Anda tidak menguji setiap hari, seperti komunikasi antara keranjang belanja Anda dan penyedia pembayaran eksternal, mungkin hari sebelum salah satu pelanggan Anda email Anda untuk membiarkan Anda tahu tentang masalah!

Ini adalah tempat server monitoring datang untuk bermain. Sementara menjalankan serangkaian tes sebelum setiap update yang baik pasti membantu, Anda tidak pernah dapat mengantisipasi segala sesuatu. Anda perlu mata di dalam server; pemantauan alat yang memungkinkan Anda melihat metrik kunci yang menggambarkan server Anda Kesehatan, dari server bug untuk memperlambat loading kali dan panggilan ke layanan eksternal yang berlangsung lebih lama dari yang seharusnya.

Tetapi bahkan pemantauan tidak cukup ketika Anda memiliki banyak di piring Anda dan lupa untuk memeriksa statistik Anda—atau ketika masalah timbul selama malam ketika Anda sedang suara tidur.

Itulah apa yang kita akan berbicara tentang dalam tutorial ini.

Dalam Tutorial ini

Meskipun ada berbagai pilihan untuk kedua perangkat lunak analisis dan peringatan tools, New Relic menawarkan salah satu solusi yang paling lengkap untuk menganalisis server Anda.

New Relic baru saja mulai terbuka beta untuk produk baru yang disebut New Relic Alerts—lapisan di atas mereka seperangkat alat yang dapat Anda gunakan untuk menjaga diri sendiri dan tim Anda diperbarui setiap peristiwa di aplikasi Anda membutuhkan perhatian Anda pemantauan.

Dalam tutorial ini, kita akan menggunakan baru peninggalan Alert untuk menciptakan serangkaian tanda untuk pemantauan aplikasi PHP yang sederhana yang berjalan pada contoh Amazon EC2. Sementara melakukan ini, kami juga akan berbicara tentang umum prinsip-prinsip dan praktek-praktek terbaik mendefinisikan lansiran perangkat lunak untuk membantu Anda membuat terbaik menyiagakan setup untuk kebutuhan bisnis Anda.

Mengatur peninggalan baru pada Server Anda

Sebelum Anda dapat mulai menggunakan baru peninggalan Alerts, Anda akan memerlukan account baru peninggalan yang telah ditetapkan untuk memantau layanan web.

Itulah mengapa, sebelum kita mulai mengkonfigurasi dan pengujian peringatan, saya akan cepat memandu Anda melalui langkah-langkah untuk mendirikan pemantauan pada contoh Amazon EC2 baru dibuat. Untuk melihat lebih rinci menggunakan alat pemantauan dalam aplikasi Anda sendiri, saya sarankan kursus gratis kami, pemantauan kinerja dengan New Relic.

Tutorial sebelumnya oleh Jeff Reifman dan Alan Skorkin juga akan membantu Anda mendapatkan sampai dengan kecepatan. Untuk informasi lebih lanjut tentang Amazon EC2, lihatlah tutorial ini tentang menginstal WordPress di Amazon Cloud.

Jika Anda sudah menggunakan peninggalan baru pada server Anda, Anda dapat melewati melewati bagian ini dan melanjutkan dari depan satu, memulai dengan New Relic Alerts.

Langkah 1: Buat Instance Amazon EC2 Baru

Memilih server untuk aplikasi Anda adalah sebuah pertanyaan di luar cakupan tutorial ini. Namun, untuk eksperimen seperti ini, saya penggemar AWS: menggunakan EC2, aku dapat mulai dan berhenti server yang saya butuhkan mereka, hanya menjadi dikenakan biaya untuk waktu saya menggunakan mereka.

Untuk membuat sebuah instance tes di Amazon EC2, pertama kali masuk ke Amazon Web Services admin Console (jika Anda tidak memiliki account belum, Anda akan perlu untuk membuat satu sebelum melanjutkan). Kemudian, dalam menu utama, pilih EC2 (Virtual Server di Cloud).

Pada EC2 Dashboard, klik pada tombol yang berlabel Launch Instance untuk memulai proses pembuatan server baru:

Launch a new EC2 instanceLaunch a new EC2 instanceLaunch a new EC2 instance

Selanjutnya, Anda akan diminta untuk memilih Amazon Machine Image (AMI) untuk server virtual yang akan Anda mulai. Untuk tutorial ini, opsi mulai cepat default, Amazon Linux AMI 2015.03, adalah apa yang kita butuhkan.

Klik Select untuk memilih yang satu itu.

The default Amazon Linux AMI is good for what were doingThe default Amazon Linux AMI is good for what were doingThe default Amazon Linux AMI is good for what were doing

Setelah memilih AMI, Anda akan diminta untuk memilih Jenis Instance—pada dasarnya ukuran mesin. Karena kami akan menggunakan mesin untuk eksperimen dan pembelajaran, yang terkecil, t2.micro, adalah yang baik untuk digunakan dengan:

Pick the t2micro instance typePick the t2micro instance typePick the t2micro instance type

Pastikan Anda telah memeriksa kotak centang di depan jenis contoh yang benar. Kemudian klik Review and Launch untuk melompat langsung ke langkah terakhir dalam panduan peluncuran.

Di halaman itu, Anda akan melihat pemberitahuan tentang meningkatkan grup keamanan Anda.

Review Instance LaunchReview Instance LaunchReview Instance Launch

Klik Edit grup keamanan untuk kembali ke langkah konfigurasi grup keamanan. Di sana, lakukan perubahan berikut pada grup keamanan Anda:

  • Edit aturan SSH yang ada untuk membatasi akses SSH ke hanya alamat IP Anda (pilih My IP di Source drop-down).
  • Tambahkan aturan baru untuk membuka port HTTP ke semua orang (pilih Anywhere di Source drop-down).

Berikut adalah bagaimana pengaturan grup keamanan harus dengan perubahan di tempat:

Example security group settingsExample security group settingsExample security group settings

Setelah melakukan perubahan, klik pada Review and Launch untuk kembali ke halaman Review Instance Launch dan meluncurkan server.

Sebagai langkah terakhir, Amazon akan meminta Anda untuk menciptakan sepasang kunci baru (atau untuk memilih yang sudah ada) untuk menghubungkan ke server baru melalui SSH. Berikan pasangan kunci sebuah nama, men-download dengan mengklik pada Key Download Pair, dan kemudian klik pada Launch Instances.

Set up key pairSet up key pairSet up key pair

Pada komputer Anda, Pindahkan pasangan kunci download file, misalnya test_keypair.pem, dari direktori mingguan untuk lokasi yang lebih baik, dan mengubah sifat akses sehingga tidak seorangpun kecuali Anda dapat membuka file.

Berikut adalah contoh tentang bagaimana untuk melakukan hal ini pada Mac OS X:

Sekarang, untuk menyambung ke server, memeriksa alamat IP contoh baru dari dashboard Amazon EC2 dan terhubung ke menggunakan file kunci pasangan (ganti alamat IP dengan satu pencocokan server Anda):

Jika server Anda dan berjalan, Anda seharusnya sekarang dapat login.

Menginstal PHP menggunakan perintah berikut. Menerima paket yang disarankan.

Kemudian mulai Apache:

Sekarang telah Anda buat setup server Apache, dan PHP sederhana di Amazon EC2. Selanjutnya, mari kita mulai memantau menggunakan baru peninggalan APM.

Langkah 2: Mengaktifkan baru peninggalan APM pada Server Anda

Pertama, jika Anda belum memiliki rekening baru relik, mulailah dengan membuat satu.

Pada halaman pendaftaran, mengisi semua kolom, dan kemudian klik Sign Up for New Relic.

SIgn up for New RelicSIgn up for New RelicSIgn up for New Relic

Selanjutnya, mari kita mengatur peninggalan baru aplikasi web monitoring tool, APM.

Di layar selamat datang, klik pada item New Relic APM:

Welcome to New RelicWelcome to New RelicWelcome to New Relic

Setelah memilih APM, Anda akan melihat halaman dengan petunjuk untuk memungkinkan pemantauan di lingkungan yang berbeda.

Jika Anda mengatur peninggalan baru pada server lain daripada Amazon EC2 berdasarkan salah satu yang kita buat di langkah sebelumnya, halaman memulai dengan New Relic ini adalah mana kau yang paling mungkin untuk menemukan petunjuk khusus untuk lingkungan Anda.

Juga, sementara perintah instalasi yang digunakan di bawah ini berlaku pada saat menulis, itu adalah ide yang baik untuk memeriksa Halaman ini untuk petunjuk paling up-to-date.

Sekarang, klik pada logo PHP untuk mengungkapkan petunjuk instalasi untuk agen PHP.

Get started with New Relic APMGet started with New Relic APMGet started with New Relic APM

Untuk menginstal PHP agen, pertama menggunakan SSH untuk terhubung ke contoh EC2 yang kami ciptakan di atas.

Kemudian, di jendela SSH Anda, ketik perintah berikut untuk menambahkan repositori baru peninggalan (misalnya EC2 didefinisikan di atas, kita menggunakan versi 64-bit):

Kemudian, untuk menginstal agen PHP:

Pada akhir instalasi, script akan meminta Anda untuk memasukkan kunci lisensi peninggalan baru Anda:

Enter New Relic license keyEnter New Relic license keyEnter New Relic license key

Untuk mendapatkan kunci lisensi Anda, kembali ke halaman  memulai dengan New Relic dan klik pada kunci lisensi reveal.

Get your license keyGet your license keyGet your license key

Tombol Salin dan paste di prompt shell untuk menyelesaikan instalasi.

Untuk menerapkan perubahan, restart web server, dan kemudian menunggu beberapa menit sehingga peninggalan baru akan mulai menerima data dari server Anda.

Sekali baru peninggalan APM adalah menerima data dari server Anda, bukan layar pengaturan yang ditunjukkan di atas, Anda akan melihat Dashboard APM dengan aplikasi PHP Anda tercantum di dalamnya:

New Relic APM DashboardNew Relic APM DashboardNew Relic APM Dashboard

Setelah ini terjadi, Anda siap untuk mulai menggunakan baru peninggalan Alerts.

Memulai dengan baru tanda peninggalan

Sekarang bahwa Anda telah menyiapkan server Anda dan memiliki baru peninggalan APM mengawasi itu, saatnya untuk pindah ke topik yang aktual dari tutorial ini: alerts.

Langkah 1: Aktifkan New Relic Alerts

Hal pertama yang harus dilakukan adalah mengaktifkan Alerts pada akun New Relic Anda.

Klik tautan AlertsBeta di sudut kanan atas jendela Relik Baru. Lansiran masih merupakan fitur beta, jadi sebelum memulai, Anda akan disajikan dengan layar yang menjelaskan fitur-fiturnya serta daftar hal-hal yang masih sedang dikembangkan.

Sementara sebagian besar fitur sudah ada, New Relic mengatakan Alerts akan mempertahankan status beta-nya sampai mereka menambahkan "server tidak melaporkan" peringatan, dukungan API, dan metode untuk memigrasi pemberitahuan yang ada ke sistem baru.

Selama beta, masih mungkin untuk menggunakan sistem baru secara berdampingan dengan lansiran lama, jadi bahkan jika Anda adalah pengguna New Relic yang ada, tidak ada salahnya mencoba Alerts.

Welcome to New Relic Alerts screenWelcome to New Relic Alerts screenWelcome to New Relic Alerts screen

Untuk mulai menggunakan New Relic Alerts, gulir ke bawah ke bagian bawah halaman, centang kotak centang yang mengatakan "Saya setuju untuk menerima syarat dan ketentuan New Relic AlertsBeta" dan klik pada tombol Try it out.

Enable New Relic Alerts betaEnable New Relic Alerts betaEnable New Relic Alerts beta

Langkah 2: Buat Kebijakan Siaga Pertama Anda

Setelah mengaktifkan Peringatan, hal pertama yang akan Anda lihat adalah halaman untuk membuat alert policy.

Create your first alert policyCreate your first alert policyCreate your first alert policy

Di New Relic Alerts, semua lansiran dikelompokkan ke dalam kebijakan peringatan yang masing-masing memiliki kumpulan saluran notifikasi sendiri. Ini berarti bahwa ketika kondisi peringatan dilanggar, peringatan dikirim ke semua pengguna dan saluran komunikasi yang ditentukan dalam kebijakan.

Itulah mengapa cara terbaik untuk memikirkan kebijakan peringatan adalah melalui notifikasi.

Tanyakan pada diri sendiri dua pertanyaan:

  • Siapa yang butuh untuk menerima pemberitahuan dari serangkaian lansiran?
  • Bagaimana mereka harus menerima pemberitahuan?

Sebagai contoh, masalah server kritis yang memerlukan perhatian segera terlepas dari waktu hari perlu dikirim ke kelompok yang berbeda dari orang-orang dan menggunakan saluran berbeda pemberitahuan (telepon berdengung untuk membangunkan Anda) daripada kurang parah kinerja isu-isu yang dapat diselesaikan selama hari (email pemberitahuan untuk memberitahu Anda untuk memulai mengoptimalkan kode).

Tapi jangan terjebak pada langkah ini terlalu lama. Jika Anda tidak bisa memikirkan cara sempurna pengorganisasian lansiran lagi, bahwa apa-apa: Anda dapat selalu datang kembali dan mengubah kebijakan alert Anda kemudian sebagai Anda mendapatkan lebih akrab dengan konsep.

Dalam tutorial ini, kita akan mulai dengan menciptakan sederhana, mencakup segala kebijakan waspada bahwa kami hanya akan memanggil "Application".

Ketik nama dalam kotak teks yang mengatakan Team name or name service dan klik Create policy.

Langkah 3: Mengenal Panel Kontrol Alerts

Anda sekarang siap untuk mulai membuat pemberitahuan untuk aplikasi Anda. Tetapi sebelum kita pergi ke sana, mari kita lihat cepat di dashboard Alerts:

Alerts dashboard showing alerts for the Application alert policyAlerts dashboard showing alerts for the Application alert policyAlerts dashboard showing alerts for the Application alert policy

Mulai dari kiri, opsinya adalah:

  • Incidents: Daftar pelanggaran peringatan dibagi menjadi dua tab. Open Incidents adalah lansiran yang belum diselesaikan dan perlu perhatian Anda sekarang. All Incidents adalah daftar riwayat yang dapat Anda gunakan untuk mencari pelanggaran kondisi peringatan sebelumnya dan untuk melihat apa yang dilakukan untuk memperbaikinya.
  • Events: Daftar semua acara dari sistem Alerts, dibagi menjadi dua tab. Violations menunjukkan semua pelanggaran ketentuan peringatan. Events juga mencantumkan pemberitahuan yang dikirim ke berbagai saluran notifikasi dan perubahan status insiden.
  • Alert policies: Ini adalah inti sistem Siaga, kumpulan aturan yang mengatur bagaimana dan kapan peringatan dikirim.
  • Notification channels: Ini adalah tempat Anda mengonfigurasi saluran notifikasi yang digunakan dalam kebijakan peringatan untuk memberi tahu Anda dan tim Anda tentang insiden di aplikasi Anda.

Item menu yang muncul setelah empat, beralih ke AlertsBeta, bingung saya pada awalnya. Karena namanya, saya mendapat kesan bahwa saya belum belum diaktifkan tanda baru. Itu bukan kasus, namun. Sebaliknya, ini adalah pilihan yang dapat Anda gunakan untuk pergi all-in dan sepenuhnya mengintegrasikan sistem peringatan baru untuk pengalaman New Relic, meninggalkan legacy alert.

Jika Anda mengklik menu item, Anda akan melihat halaman berikut:

Go all-in on New Relic AlertsGo all-in on New Relic AlertsGo all-in on New Relic Alerts

Halaman ini memberikan Anda gambaran dari perubahan yang akan terjadi jika Anda benar-benar beralih fungsi tanda baru. Paling penting, ini berarti integrasi yang lebih mendalam untuk peringatan dalam produk New Relic lain.

Jika Anda sudah pengguna New Relic dan aplikasi Anda saat ini bergantung pada sistem legacy alert, Anda mungkin ingin berpikir dua kali sebelum pindah. Juga, untuk mengikuti melalui sisa dari tutorial ini, Anda tidak perlu pergi ini jauh—seperti yang saya sebutkan sebelumnya, hal ini sangat OK untuk menggunakan kedua sistem berdampingan.

Tapi jika Anda berani dan ingin menggunakan dengan pendarahan tepi versi perangkat lunak Anda, Anda bisa sangat baik menerima kenyataan bahwa tidak ada akan kembali dan beralih akun Anda menggunakan hanya fungsi tanda baru dengan mengklik pada tombol Become an early adopter di bawah layar ini.

Become an early adopterBecome an early adopterBecome an early adopter

Pilihan adalah milikmu. Dan apapun cara yang Anda memutuskan untuk pergi, Anda sekarang siap untuk membuat peringatan pertama Anda.

Buat Peringatan Pertama Anda

Sekarang Anda telah mengaktifkan New Relic Alerts dan memiliki pemahaman menyeluruh tentang alat ini, saatnya untuk mulai bekerja dan membuat peringatan pertama Anda: peringatan yang mengirimkan pemberitahuan menggunakan email dan Slack jika tingkat kesalahan dalam aplikasi PHP Anda melebihi 5% setidaknya sekali dalam 5 menit.

Saya memilih peringatan ini karena ini adalah salah satu yang penting, tetapi juga karena mudah untuk diuji: setelah kondisi peringatan telah ditentukan, kami dapat merusak server dan menyebabkan peringatan menyala tanpa banyak kerja ekstra.

Tapi pertama-tama, mari kita bicara sedikit tentang apa yang membuat tanda baik perangkat lunak.

Langkah 1. Tentukan Masalah yang Ingin Anda Terima Peringatan

Dalam dongeng klasik Aesop, The Boy Who Cried Wolf, seorang anak gembala yang bosan lagi dan lagi berteriak alarm palsu tentang serigala yang menyerang kawanannya. Pada akhirnya, ketika seekor serigala akhirnya muncul, penduduk desa berpikir itu hanyalah alarm palsu dan tidak ada yang datang menyelamatkannya.

Demikian juga, jika Anda memiliki perangkat lunak peringatan yang memberitahu Anda setiap hari—atau lebih buruk lagi, banyak kali sehari—tentang sesuatu yang Anda tidak perlu untuk bertindak tepat pada saat itu, Anda bisa digunakan untuk mengabaikan kesalahan. Kemudian, ketika kesalahan penting akhirnya muncul, mereka akan hilang dalam kebisingan dan Anda kehilangan mereka.

Inilah sebabnya mengapa Anda harus selalu mulai merencanakan peringatan Anda dengan bertanya pada diri sendiri: "Seberapa penting peringatan ini?" dan "Bagaimana saya (atau tim saya) bereaksi terhadap peringatan ini?"

Jawaban Anda, kemudian akan memandu apa yang Anda lakukan selanjutnya:

  • Jika waspada adalah sesuatu yang perlu ditangani segera, menambahkannya ke kebijakan waspada yang bangun Anda (atau tim Anda) pada setiap saat hari.
  • Jika peringatan sesuatu mendesak yang diselesaikan dalam satu hari atau kurang, termasuk dalam polis waspada yang akan memberitahu Anda melalui saluran pemberitahuan kurang intrusif seperti email.
  • Jika waspada tidak memerlukan perhatian dalam satu atau dua hari, itu mungkin terbaik untuk tidak membuat lansiran sama sekali. Masalah akan melihat selama terlihat biasa alat pemantauan dan kemudian akan ditandai sebagai tugas alat manajemen proyek Anda kemudian pertimbangan.

Juga, pastikan bahwa Anda mengirim lansiran ke orang-orang yang memiliki sarana untuk melakukan sesuatu tentang mereka. Seorang manajer inbox mengisi dengan lansiran tentang bug dalam kode tidak lain hanyalah merupakan gangguan.

Hal lain yang perlu dipertimbangkan adalah ambang waspada, atau pertanyaan seperti:

  • Seberapa cepat harus waspada dikirim?
  • Apakah persentase kesalahan yang dapat diterima?
  • Bagaimana rendah dapat ruang disk server pergi sebelum kita perlu melakukan sesuatu tentang hal itu?

Ini bukanlah tugas yang mudah, dan mungkin akan mengambil beberapa mengutak-atik sebelum Anda mendapatkan Anda serangkaian lansiran didefinisikan tepat. Anda ingin mengirim pesan kesalahan awal cukup bahwa Anda tidak kehilangan kesalahan penting, tetapi tidak begitu cepat bahwa Anda mendapatkan terlalu banyak peringatan palsu.

Cara terbaik untuk melakukan hal ini adalah melalui eksperimen: mengubah kondisi peringatan cepat, karena tidak melibatkan perubahan file konfigurasi dan restart server, jadi terus mencoba nilai-nilai yang berbeda sampai Anda puas dengan hasilnya. Selain itu, seiring dengan berkembangnya aplikasi Anda, Anda mungkin juga ingin mengubah pemberitahuan, misalnya ambang batas pengingat yang longgar ketika Anda mengetahui pembaruan baru akan berdampak negatif terhadap waktu pemuatan Anda untuk sementara waktu.

Langkah 2: Pilih Produk dan Targetkan ke Monitor

Seperti yang saya jelaskan sebelumnya, setiap kondisi siaga di New Relic Alerts milik kebijakan peringatan. Jadi, untuk menambahkan kondisi baru, pertama-tama arahkan ke tab kebijakan Peringatan dan pilih kebijakan yang baru Anda buat, "Application".

Karena Anda belum membuat ketentuan peringatan apa pun, Anda akan melihat placeholder berikut di tengah halaman:

No conditions yetNo conditions yetNo conditions yet

Klik Buat ketentuan untuk mulai menentukan kondisi peringatan pertama Anda. Setelah Anda membuat kondisi pertama ini, Anda akan melihat daftar kondisi peringatan dan bukan tombol besar—​​pada titik itu, menambahkan ketentuan baru dimulai dengan menggunakan tombol kebijakan lansiran baru yang lebih kecil di sudut kanan atas daftar.

Mengeklik tombol memulai wizard kondisi baru tiga langkah:

Select a product for the alertSelect a product for the alertSelect a product for the alert

Di wizard, Anda akan diminta untuk memilih produk Relik Baru terlebih dahulu. Ini adalah produk yang akan Anda gunakan sebagai sumber metrik untuk kondisi peringatan yang Anda buat, dan karena itu juga akan menentukan opsi yang tersedia untuk Anda dalam dua langkah berikutnya di wizard.

Kesalahan PHP yang dipantau menggunakan APM, jadi mari kita memilih yang satu.

Pada langkah panduan yang sama, Anda masih memiliki pilihan kedua: memilih jenis kondisi yang ingin Anda buat. Opsi dalam pemilihan ini berubah saat Anda beralih antar produk. Untuk APM Anda memiliki tiga opsi berikut:

  • Aplikasi metrik: opsi ini memberi Anda akses ke aplikasi standar metrik diukur oleh APM (Apdex, persentase kesalahan, waktu respon dan Throughput) serta setiap metrik kustom yang sudah Anda tetapkan dalam alat monitoring.
  • Transaksi kunci metrik: sebagai fitur berbayar di APM, Anda dapat menandai beberapa transaksi dalam aplikasi Anda sebagai "kunci transaksi"-transaksi yang penting untuk bisnis Anda atau produk Anda. Jika Anda memilih opsi ini, Anda akan menciptakan kondisi siaga dengan cara yang sama seperti yang Anda akan menggunakan opsi aplikasi metrik, kecuali bahwa alih-alih pemantauan seluruh aplikasi (atau beberapa aplikasi), lansiran hanya akan api jika kondisi terpenuhi dalam transaksi kunci yang Anda pilih.
  • Layanan eksternal: Opsi ini memungkinkan Anda membuat ketentuan peringatan berdasarkan API atau panggilan lain yang dilakukan ke layanan eksternal.

Sebagai persentase kesalahan adalah aplikasi metrik dan kita belum ditentukan transaksi kunci, pilih aplikasi metrik dan klik Next, pilih target untuk pindah ke kedua langkah di wizard.

Select application to monitorSelect application to monitorSelect application to monitor

Pada layar ini kedua, Anda akan memilih aplikasi APM dimonitor yang kondisi peringatan harus memberitahu Anda tentang.

Pertama, klik pada semua aplikasi untuk mengungkapkan daftar aplikasi.

Kemudian, centang kotak centang di depan aplikasi kami (dalam contoh kita, kita hanya memiliki satu aplikasi, aplikasi PHP) dan pindah ke langkah terakhir dalam wizard dengan mengklik berikutnya, menentukan batas tombol.

Langkah 3: Menentukan kondisi Alert

Langkah yang ketiga dan terakhir dalam kondisi baru wizard adalah mana Anda menentukan kondisi alert sebenarnya.

Define the alert conditionDefine the alert conditionDefine the alert condition

Pilihan Anda akan melihat dalam langkah ini tergantung pada pilihan-pilihan yang Anda buat dalam dua langkah pertama. Namun, dalam setiap kasus, ide dasarnya adalah sama: ini adalah layar di mana Anda akan memilih metrik dan kesalahan (dan peringatan opsional) ambang batas untuk itu.

Untuk membuat kesalahan tinggi persentase waspada kondisi saya dijelaskan di atas:

  1. Pilih persentase kesalahan sebagai metrik aplikasi untuk memantau.
  2. Kemudian, pilih operator perbandingan cocok. Dalam kasus ini, di atas paling masuk akal (pilihan lain yang berada di bawah dan sama).
  3. Menetapkan threshold: Apakah persentase kesalahan yang masuk akal untuk laporan kesalahan? Membuat jumlah ini terlalu tinggi dan Anda akan kehilangan kesalahan penting. Membuatnya terlalu rendah dan Anda akan tenggelam dalam alerts. 5% adalah baik mulai titik, tetapi dalam kehidupan nyata Anda mungkin berakhir tweaker ambang naik atau turun tergantung pada aplikasi Anda dan preferensi Anda.
  4. Menetapkan jangka waktu: untuk menangkap sebagian kesalahan, pilih "setidaknya sekali dalam" "5 menit". Ini akan mengingatkan Anda segera jika ambang kesalahan melebihi bahkan sekali selama jangka waktu yang dipilih. Di sisi lain, jika Anda ingin memberikan aplikasi Anda sedikit lebih kendur, Anda dapat memilih "untuk setidaknya" dan hanya menerima pemberitahuan jika persentase kesalahan tetap tinggi untuk seluruh durasi frame waktu yang dipilih.
  5. Jika Anda suka, Anda juga dapat menetapkan batas peringatan yang menggunakan persentase kesalahan yang lebih rendah. Peringatan tidak akan memicu peringatan email tetapi Anda akan melihat mereka dalam daftar peristiwa juga seperti tampilan APM (jika Anda memiliki pergi all-in dan menjadi adopter awal-lihat diskusi sebelumnya dalam tutorial ini).
  6. Memberikan kondisi nama deskriptif atau—jika Anda puas dengan itu—menggunakan nama standar yang diusulkan oleh alat.
  7. Jika Anda ingin memberikan tim Anda dengan informasi tentang peristiwa dan bagaimana untuk memperbaikinya, Anda dapat menambahkan "runbook URL": link ke halaman web di luar, misalnya halaman dokumentasi yang menjelaskan apa yang ini peringatan berarti dan menjelaskan langkah-langkah untuk menyelesaikannya. Untuk melakukan ini, klik pada Add runbook URL dan masukkan URL di bidang teks.

Bila Anda senang dengan kondisi alert, klik buat kondisi untuk menyimpannya. Ingat bahwa Anda dapat selalu datang kembali untuk men-tweak itu kemudian.

Sekarang, kondisi tanda halaman akan terlihat seperti ini, dengan peringatan Anda baru ditambahkan ke:

Alert condition addedAlert condition addedAlert condition added

Jika setiap saat, Anda ingin memodifikasi kondisi alert, cukup klik pada aturan. Perhatikan juga menyalin dan menghapus tombol di sudut kanan atas kondisi alert Anda baru: ini datang dalam berguna jika pada titik tertentu Anda ingin memindahkan waspada untuk waspada kebijakan yang berbeda.

Langkah 4: Mengatur Email pemberitahuan untuk kebijakan Alert

Anda sekarang telah membuat peringatan pertama. Tapi peringatan tanpa pemberitahuan saluran tidak berguna: pelanggaran akan ditambahkan ke tab insiden, tapi tidak ada yang mendapat diberitahu. Untuk membuat kebijakan peringatan yang memberitahu Anda tentang sebuah insiden, kita harus menentukan saluran pemberitahuan dan link ke kebijakan ini waspada.

Mari kita mulai dengan satu, email paling umum.

Untuk mulai membuat saluran pemberitahuan pertama Anda, klik pada item menu saluran pemberitahuan. Kemudian, klik pada tombol besar yang mengatakan membuat saluran pemberitahuan.

No notification channels configured yetNo notification channels configured yetNo notification channels configured yet

Pada layar berikutnya, pertama Anda akan melihat kotak teks yang mengatakan "Pilih jenis saluran". Klik di atasnya untuk mengungkapkan daftar drop-down dengan pilihan pemberitahuan yang tersedia:

Select the type of notification channel to createSelect the type of notification channel to createSelect the type of notification channel to create

Pilihan yang tersedia saat ini (menurut dokumentasi, lebih banyak saluran akan ditambahkan di masa depan) adalah:

  • E-mail: Mengirimkan pesan email ke alamat email yang ditentukan dalam konfigurasi.
  • HipChat: Mengirim pesan ke ruang HipChat ditentukan dalam konfigurasi.
  • PagerDuty: Mengirimkan pemberitahuan melalui alat administrasi NetOps PagerDuty. Ini adalah pilihan lanjutan untuk pemberitahuan lebih penting yang perlu ditangani segera—lansiran bahkan dapat dikonfigurasi untuk menelepon Anda di telepon!
  • VictorOps: Serupa dengan PagerDuty, opsi ini mengirimkan pemberitahuan melalui alat NetOps VictorOps. Fungsionalitas dalam dua alat ini cukup mirip, sehingga pilihan tergantung sebagian besar pada apa yang sedang Anda gunakan.
  • Webhook: Mengirim pemberitahuan ke URL yang Anda tetapkan. Gunakan pilihan ini jika Anda ingin mengirim pemberitahuan ke saluran yang saat ini tidak didukung secara langsung oleh baru peninggalan Alert—atau jika Anda ingin membuat solusi kustom Anda sendiri...
  • Campfire: Mengirim pemberitahuan ke ruang chat Campfire ditentukan dalam konfigurasi.
  • Slack: Mengirim pemberitahuan ke saluran Slack ditentukan dalam konfigurasi.
  • OpsGenie: Mengirimkan pemberitahuan menggunakan sistem peringatan OpsGenie NetOps. OpsGenie adalah alat lain yang mirip dengan PagerDuty dan VictorOps yang dapat digunakan untuk memastikan bahwa tim Anda pemberitahuan lansiran ketika mereka muncul.

Selain itu, New Relic Alerts secara otomatis membuat saluran notifikasi Pengguna untuk setiap pengguna di akun Anda. Saluran ini dapat digunakan untuk mengirim email dan untuk mendorong notifikasi ke aplikasi iPhone dan Android New Relic.

Dalam situasi dunia nyata, Anda harus memilih alat yang paling cocok dengan kebijakan Alert Anda dan tim Anda budaya komunikasi: misalnya, menggunakan OpsGenie untuk mendesak Lansiran dan email untuk orang-orang tidak begitu mendesak. Dalam tutorial ini, kita hanya akan menambahkan dua sebagai contoh, dimulai dengan email.

Ketika Anda klik pada pilihan E-mail, sisa bentuk secara otomatis diperbarui untuk menunjukkan konfigurasi pemberitahuan email:

Create an e-mail notification channelCreate an e-mail notification channelCreate an e-mail notification channel

Masukkan alamat email Anda di bidang Email dan klik Buat saluran. Jika Anda ingin mengirim lebih banyak data tentang insiden tersebut bersama dengan pesan email (misalnya jika email tersebut dibaca secara terprogram), centang kotak Sertakan JSON lampiran.

Dan hanya itu, sebuah email pemberitahuan channel sekarang telah dibuat:

The e-mail notification channel was created successfullyThe e-mail notification channel was created successfullyThe e-mail notification channel was created successfully

Untuk memasang saluran pemberitahuan ini kebijakan peringatan yang Anda buat sebelumnya, kembali ke halaman kebijakan Alert dan pilih kebijakan alert "Aplikasi".

Kemudian, klik untuk melihat tab saluran pemberitahuan. Karena ada tidak ada saluran pemberitahuan yang didefinisikan untuk kebijakan peringatan ini belum, tab akan terlihat seperti ini:

The policy doesnt have any notification channels yetThe policy doesnt have any notification channels yetThe policy doesnt have any notification channels yet

Klik pada Tambahkan pemberitahuan saluran untuk membuka jendela pop-up untuk memilih saluran pemberitahuan untuk digunakan dalam kebijakan ini waspada.

Select the e-mail notification channelSelect the e-mail notification channelSelect the e-mail notification channel

Gunakan browser saluran pemberitahuan untuk mencari saluran E-mail dan centang kotak di depan alamat email Anda.

Kemudian klik Update kebijakan untuk menyimpan perubahan.

Langkah 5: Mengatur kendur pemberitahuan untuk kebijakan Alert

Selanjutnya, mari kita buat notifikasi muncul di saluran Slack. Jika Anda tidak menggunakan Slack, Anda dapat melewati langkah ini dan melanjutkan ke langkah berikutnya, di mana kami akan mulai menguji peringatan.

Pertama, di jendela obrolan kendur Anda, klik tanda panah bawah di samping nama pengguna Anda untuk membuka menu. Kemudian, pilih opsi mengkonfigurasi integrasi:

In Slack click on Configure IntegrationsIn Slack click on Configure IntegrationsIn Slack click on Configure Integrations

Ini akan membuka tab browser baru menampilkan Slack di integrasi halaman.

Gunakan bilah Cari di sudut kanan atas dari daftar layanan untuk mencari jenis integrasi New Relic.

Slack IntegrationsSlack IntegrationsSlack Integrations

Gulir ke bawah untuk masuk WebHooks opsi dan klik Add.

Klik View. Kemudian, pada halaman berikutnya, pilih atau membuat saluran Anda ingin memposting pemberitahuan ke. Ini bisa menjadi proyek yang sudah ada, saluran tertentu- atau mungkin Anda ingin untuk membuat saluran khusus untuk server Alert.

Add New Relic IntegrationAdd New Relic IntegrationAdd New Relic Integration

Setelah memilih saluran, lanjutkan dengan mengklik "Add New Relic Integration".

Pada halaman berikutnya, memperluas petunjuk untuk item pertama dalam daftar, "New Relic Alerts [Beta]". Kemudian, Salin URL Webhook yang ditampilkan dalam bagian berlabel langkah 2. Ini adalah URL yang unik, dihasilkan dan hanya akan digunakan untuk integrasi satu ini. Jika Anda memiliki alasan apapun untuk curiga bahwa URL memiliki bocor ke seseorang yang seharusnya tidak memilikinya, Anda dapat (dan harus) menghasilkan yang baru.

New Relic Alerts BetaNew Relic Alerts BetaNew Relic Alerts Beta

Kembali ke halaman saluran pemberitahuan peringatan peninggalan baru dan membuat saluran pemberitahuan baru memilih Slack sebagai jenis Channel. Dalam pilihan saluran baru ini, masukkan URL yang hanya disalin ke dalam bidang teks yang berlabel URL:

Notification ChannelsNotification ChannelsNotification Channels

Jika Anda suka, Anda dapat menggunakan bidang saluran tim untuk mendefinisikan nama saluran kendur Anda ingin pemberitahuan akan diposting ke. Jika Anda melakukannya, pastikan Anda ingat untuk memasukkan tanda hash di depan dari nama—jika tidak, menerima peringatan pada saluran kendur Anda, Anda hanya akan melihat kesalahan dalam log peristiwa.

Klik pada buat saluran untuk menyelamatkan definisi. Kemudian, ikuti langkah-langkah yang menghubungkan saluran pemberitahuan baru ke kebijakan Anda pemberitahuan yang kami gunakan saat menghubungkan email.

Langkah 6: Menguji waspada dengan membuat Anda gagal kode

Sebelum saya meninggalkan Anda untuk bekerja pada dunia nyata Lansiran dan pengaturan server produksi Anda, mari kita menempatkan tanda baru kami untuk tes dan melihat apa yang terjadi ketika kondisi alert dilanggar.

Seperti yang kita membuat server tes khusus untuk kebutuhan tutorial ini, kita dapat dengan aman memecahkan kode. Jika Anda menguji tanda pada server yang sudah ada Anda, Anda mungkin hanya ingin melakukan hal ini dalam pengujian atau pementasan lingkungan.

Untuk membuat PHP kesalahan di setup server yang kita buat sebelumnya, pertama menggunakan SSH untuk terhubung ke server Anda. Kemudian, melompat ke direktori root server web Anda:

Dalam direktori ini, membuat file PHP, misalnya error.php, dan menulis beberapa kode yang rusak untuk membuat script istirahat ketika Anda mencoba untuk muat di browser Anda:

Sekarang, buka URL di web browser, dan menyegarkan itu beberapa kali selama jangka waktu lima menit kita didefinisikan untuk kondisi alert. (Anda akan menemukan server Anda URL di dashboard Amazon EC2.)

Setelah sekitar lima menit, Anda akan menerima pemberitahuan di kotak masuk email Anda dan saluran kendur Anda tetapkan di atas.

Berikut adalah bagaimana kesalahan akan terlihat dalam email Anda:

The alert notification email messageThe alert notification email messageThe alert notification email message

Dan pemberitahuan sama di Slack:

Alert notification in SlackAlert notification in SlackAlert notification in Slack

Ketika Anda mengklik pada tampilan rincian insiden link dalam email atau nomor insiden di kendur, Anda akan diarahkan ke halaman baru peringatan peninggalan sesuai dengan lebih banyak informasi tentang masalah yang menyebabkan pemberitahuan:

View incident detailsView incident detailsView incident details

Jika Anda sudah siap untuk mulai bekerja pada waspada, klik pada tombol Acknowledge di sebelah kanan. Setelah Anda mengklik tombol, ia digantikan oleh sepotong informasi negara berikut:

Incident acknowledgedIncident acknowledgedIncident acknowledged

Anda (dan tim Anda, seperti yang dikonfigurasi di saluran pemberitahuan) juga akan menerima pemberitahuan tentang pengakuan melalui email dan Slack. Pengakuan ini berarti bahwa Anda mengambil kepemilikan dalam memperbaiki masalah, dan status tidak dapat diubah: setelah Anda telah mengakui peringatan, tidak ada orang lain bisa mengakui itu lagi.

Ketika Anda gulir ke bagian bawah halaman peringatan, Anda akan melihat tombol berikut yang dapat Anda gunakan untuk mendapatkan informasi lebih lanjut tentang memecahkan masalah (buka runbook), menyunting waspada kondisi (jika Anda percaya ini adalah tanda palsu) atau secara manual menutup pelanggaran (setelah Anda memiliki tetap masalah).

Incident actionsIncident actionsIncident actions

Untuk informasi lebih banyak tentang masalah, Anda juga dapat mengunjungi Error halaman APM:

More information about the errorMore information about the errorMore information about the error

Gunakan informasi dari APM untuk memperbaiki masalah (saat ini, itu mudah).

Kemudian memuat halaman beberapa kali lagi dan menunggu untuk pemberitahuan lain yang memberitahu Anda bahwa masalah ini tidak lagi aktif, atau pergi kembali ke halaman insiden dan klik pada pelanggaran secara manual tutup untuk menutup waspada segera.

Seperti baru peringatan peninggalan didorong oleh data, jika ada data yang berasal dari server setelah waspada dikirim, insiden tetap terbuka selamanya. Jadi, jika Anda bertanya-tanya tentang mengapa peringatan Anda tidak mendapatkan ditutup secara otomatis bahkan setelah Anda tetap bug di server tes ini, itu adalah karena tidak ada yang menggunakan situs—dan karena itu tidak ada akan khawatir tentang.

Anda telah sekarang berhasil menciptakan kondisi alert pertama Anda dan menggunakannya untuk memperbaiki bug pada server Anda, dan Anda sudah siap untuk mulai membuat kebijakan alert dunia nyata Anda untuk menjaga aplikasi web Anda aman.

Lain metrik untuk lansiran

Meskipun pemberitahuan galat yang kami hanya dibuat adalah salah satu yang sangat berguna, adalah masih hanya salah satu dari banyak tanda yang Anda dapat membuat menggunakan baru peninggalan Alerts.

Untuk membantu Anda ketika Anda melanjutkan dengan mengembangkan sendiri tanda ditetapkan untuk aplikasi web yang sebenarnya, berikut adalah sisa pilihan berlaku untuk aplikasi web, bersama dengan beberapa ide untuk isu-isu dalam aplikasi Anda Anda mungkin ingin untuk memonitor menggunakan mereka.

1. Kondisi Peringatan Berdasarkan APM Metrik

APM (singkat untuk Application Performance Monitoring) adalah produk unggulan peninggalan baru: aplikasi pemantauan alat yang turun ke tingkat kode, mengukur hal-hal seperti kesalahan dan berapa lama aplikasi Anda mengambil pada berbagai titik dalam pelaksanaan.

Selain tinggi persentase waspada kondisi kesalahan kami ciptakan di atas, metrik APM berikut dapat digunakan untuk membuat lansiran.

  • Apdex: Apdex (Application Performance Index) adalah suatu metode standar yang ditetapkan untuk mengukur dan membandingkan kinerja aplikasi perangkat lunak. Metrik untuk mengukur kepuasan pengguna akhir dan pergi dari 0 ke 1, dimana 1 berarti bahwa setiap pengguna puas dan 0 berarti bahwa tidak ada yang. Jumlah yang baik untuk memulai dari adalah 0.7, yang merupakan ambang tanda default di tanda baru peninggalan warisan.
  • Waktu Respons dan Throughput: Waktu respons memberi tahu Anda berapa lama permintaan yang dibuat untuk aplikasi Anda mengambil rata-rata. Throughput adalah metrik terkait yang menjelaskan berapa banyak permintaan yang berhasil diproses oleh layanan Anda selama jangka waktu tertentu. Sementara kedua metrik dimasukkan dalam perhitungan Apdex, menambahkan peringatan untuk mereka akan membuat lansiran Anda lebih spesifik dan dengan demikian lebih mudah dianalisis dan diarahkan ke orang yang tepat.
  • Kustom metrik: Jika Anda merekam metrik kustom Anda sendiri di APM, Anda dapat menggunakannya untuk menciptakan kondisi tanda khusus aplikasi Anda sendiri.
  • Layanan eksternal: Menggunakan jenis kondisi layanan eksternal, Anda dapat membuat lansiran yang didasarkan pada waktu respon dan throughput dari HTTP panggilan ke layanan eksternal. Misalnya, di situs saya sendiri, pemantauan permintaan layanan eksternal membantu saya mengidentifikasi panggilan API ke Tumblr sebagai alasan utama untuk lambat loading kali.

Jika Anda memilih metrik kunci transaksi (dibayar fitur di APM) sebagai jenis kondisi Anda, Anda akan memiliki akses ke semua metrik sama yang dijelaskan dalam daftar di atas, tetapi mereka akan digunakan untuk melacak hanya transaksi dipilih dan tidak seluruh aplikasi.

Dengan cara ini, Anda dapat memiliki peringatan tentang kesalahan dalam transaksi penting (seperti pemrosesan pembayaran) dikirim dengan prioritas yang lebih tinggi (SMS daripada email, misalnya) daripada kesalahan dalam transaksi kurang kritis.

2. Tanda Berdasarkan Metrik Browser

Browser adalah produk pemantauan peninggalan baru yang dirancang untuk memberi Anda pandangan tentang bagaimana sebenarnya pengguna pengalaman aplikasi web Anda: pemantauan untuk hal-hal yang terjadi di dalam browser. Untuk penjelasan lebih rinci alat dan petunjuk tentang cara mengaktifkan akun baru relik, memeriksa tutorial ini.

Sedangkan tanda berbasis APM memberitahu Anda tentang hal-hal yang salah di dalam server aplikasi, Browser peringatan dapat menjadi penting dalam penentuan kesalahan yang menyebabkan pengalaman pengguna untuk memecahkan.

  • End User Apdex: Metrik utama dalam peringatan berbasis Browser, End User Apdex mengukur persentase pengguna yang merasa puas dengan kinerja aplikasi, dengan mempertimbangkan juga kinerja aplikasi saat berjalan di browser.
  • Waktu Page Load: Sekelompok metrik untuk mengukur waktu yang dihabiskan di bagian yang berbeda dari loading halaman: waktu buka halaman total, rendering halaman, aplikasi web, Jaringan, pengolahan DOM, dan permintaan antrian semua dapat digunakan untuk mendapatkan lebih rinci lansiran tentang spesifik kemacetan di pengalaman pengguna akhir.
  • Page Views dengan JavaScript error: jumlah JavaScript kesalahan dalam aplikasi Anda dapat menjadi tanda buruk pemrograman yang harus ditangani dengan cepat. Menggunakan metrik ini, Anda dapat membuat lansiran mirip waspada persentase kesalahan yang kita buat dalam tutorial ini—hanya saja kali ini, mengukur JavaScript kesalahan bukan kesalahan dalam kode PHP aplikasi.
  • Waktu respon AJAX dan Throughput: jika aplikasi Anda menggunakan AJAX panggilan untuk tindakan akhir multi-user menghadap penting, sangat penting untuk menemukan masalah dalam mereka sejak awal. Untuk ini, Anda dapat menggunakan metrik mengukur berapa lama AJAX permintaan mengambil untuk memproses dan berapa banyak permintaan AJAX berhasil disajikan dalam jangka waktu tertentu.
  • Kustom metrik: Seperti di APM Alert, Anda juga dapat menggunakan metrik kustom di peringatan Browser Anda.

3. Tanda Berdasarkan Metrik Server

Server adalah peninggalan baru produk untuk mengukur apa yang terjadi secara fisik pada server Anda. Alih-alih melihat metrik aplikasi seperti yang kita lakukan dengan APM dan Browser, sekarang kita berbicara tentang hal-hal seperti beban CPU dan penggunaan disk-jenis metrik yang Anda ingin tim NetOps Anda (atau hanya Anda, jika Anda operasi kecil) selalu tetap di atas. Melihat tutorial ini untuk informasi lebih lanjut tentang server peninggalan baru.

Metrik ini merupakan sumber penting untuk—biasanya mendesak—peringatan:

  • CPU %: Jika aplikasi Anda menggunakan banyak sumber daya CPU, itu bisa menjadi tanda bahwa Anda perlu untuk mengoptimalkan aplikasi atau memindahkannya ke server yang lebih kuat. Dalam kedua kasus, ada baiknya untuk tahu ketika Anda mencapai batas-batas apa yang dapat menangani mesin.
  • Disk IO%: Di peninggalan server baru, metrik %IO disk yang memberitahu Anda berapa banyak waktu disk Anda berada dalam menggunakan, 0% berarti tidak ada disk operasi sama sekali dan menggunakan 100% bahwa disk di sepanjang waktu.
  • Memori %: Terutama ketika bekerja pada sebuah aplikasi data-berat, memori adalah salah satu sumber daya yang pertama Anda harus khawatir tentang. Pastikan Anda mendapatkan pemberitahuan awal cukup, sebelum mesin kehabisan memori gratis.
  • Fullest Disk %: Ketika server Anda berjalan keluar dari ruang hard drive, Anda dapat yakin aplikasi Anda tidak akan berfungsi sebagaimana mestinya. Sekali lagi, itu lebih baik untuk menangani masalah ruang disk sebelum itu mempengaruhi pengguna: sekitar 90% penuh atau begitu.
  • Load Average: Rata-rata beban memberitahu Anda seberapa baik server CPU adalah menghadapi pekerjaan itu dituntut dengan. Nilai 0 berarti komputer benar-benar siaga, dan setiap proses yang berjalan atau menunggu menambah nomor. Telah waspada ambang tergantung pada berapa banyak Core server Anda: pada single core sistem, rata-rata beban 1 berarti bahwa CPU digunakan pada kapasitas penuh (dengan dua Core, nomor adalah 2, dan seterusnya). Nilai-nilai yang lebih tinggi berarti bahwa ada beberapa proses menunggu dalam antrean.

Apa berikutnya?

Kami sekarang telah melihat bagaimana lansiran dapat membantu Anda memantau aplikasi web Anda dan memberi Anda ketenangan pikiran, membahas dasar-dasar merancang peringatan yang baik, dan melewati langkah-langkah menggunakan Relik Lansiran Baru untuk mengatur pemberitahuan untuk aplikasi web Anda.

Jika Anda suka mengotak-atik, Alerts memberi Anda berbagai kemungkinan untuk menyesuaikan dan menyesuaikan lansiran Anda sampai tepat: tambahkan beberapa metrik khusus ke kode Anda, gunakan data dari plugin New Relic, dan kirim pemberitahuan ke semua jenis notifikasi yang berbeda saluran—atau jika Anda pengembang seluler, lihat lansiran seluler. Kita hanya menggores permukaan.

Lansiran saat ini dalam versi beta, yang berarti bahwa fitur baru masih diterapkan saat kita bicara. Jadi, untuk tetap diperbarui pada perkembangan baru, perhatikan dokumentasi New Relic Alerts dan bergabunglah dengan diskusi di forum diskusi alat.

Tapi pertama, pergi ke depan dan membuat tanda beberapa!

Advertisement
Did you find this post useful?
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.