Log prestasi adalah alat teras untuk analisis trend pekerjaan sumber sistem, dan perancangan kapasiti dan amaran kesesakan dicapai melalui gelung tertutup "pengumpulan-penyimpanan-analisis-tindakan". Alat yang serasi perlu dipilih mengikut persekitaran sistem, mengimbangi granulariti pengambilalihan dan overhead, menggabungkan platform visualisasi untuk mewujudkan garis dasar, mengenal pasti trend, dan mencari punca-punca yang tidak normal melalui analisis korelasi, akhirnya menyokong keputusan pengembangan dan pengoptimuman kos ke hadapan dan pengoptimuman kos.

Log prestasi, pada pendapat saya, bukan sekadar nombor dan timestamps, mereka adalah penyampai tingkah laku sistem, tetingkap yang paling langsung dan boleh dipercayai untuk memahami trend pekerjaan sumber. Dengan menggali lebih mendalam ke dalam balak ini, kita dapat melihat kesihatan sistem, meramalkan kemunculan yang berpotensi, dan juga mengambil tindakan sebelum masalah berlaku. Ini seperti pemeriksaan fizikal yang komprehensif untuk sistem ini, dan ia adalah pemeriksaan fizikal yang bersejarah dan bergaya.

Penyelesaian

Untuk menggunakan log prestasi untuk menjejaki trend pekerjaan sumber sistem, teras terletak pada gelung tertutup "pengumpulan-penyimpanan-analisis-tindakan".

Kumpulkan: Pertama, anda perlu menentukan sumber utama yang ingin anda pantau. Biasanya termasuk penggunaan CPU (keadaan pengguna, negeri kernel, Iowait), penggunaan memori (digunakan, tersedia, disimpan, ruang swap), cakera I/O (baca dan tulis kelajuan, IOPS, kedalaman giliran, latensi), trafik rangkaian (lebar jalur masuk dan keluar, sambungan, kadar ralat).

• Alam Sekitar Windows: Monitor Prestasi (Perfmon) adalah rakan lama anda, yang boleh mengkonfigurasi pemungut data yang ditetapkan untuk log data kaunter prestasi terpilih untuk log fail (seperti .blg atau .csv). Di samping itu, sistem log dalam penonton acara dapat menyediakan beberapa peristiwa kritikal, seperti memori yang tidak mencukupi atau kesilapan cakera.
• Persekitaran Linux:

   Sysstat

  Toolkit (terutamanya

   SAR

  perintah) adalah sangat diperlukan. Ia boleh mengumpul dan melaporkan data sejarah mengenai hampir semua sumber sistem, dan ia sangat mahal untuk sistem. Anda boleh mengkonfigurasi

   Cron

  Tugas, berjalan secara teratur

   SAR

  Dan simpan data.

   Atas

  atau

   htop

  Walaupun ia adalah alat masa nyata, anda juga boleh merebut gambar melalui skrip. Untuk prestasi aplikasi berbutir yang lebih baik, pertimbangkan

   Perf

  alat.
• Persekitaran awan: AWS CloudWatch, Azure Monitor, Pemantauan Awan Google dan perkhidmatan lain semuanya menyediakan keupayaan pengumpulan metrik yang kaya. Mereka biasanya mengintegrasikan secara mendalam dengan sumber masing -masing (contoh EC2, pangkalan data, pengimbang beban) dan secara automatik boleh mengumpulkan kebanyakan data prestasi yang anda sayangi.

Penyimpanan: Data log yang dikumpulkan perlu disimpan dengan betul untuk analisis berikutnya.

• Penyimpanan Tempatan: Untuk sistem kecil atau analisis jangka pendek, ia boleh disimpan secara langsung pada cakera tempatan pelayan. Tetapi perhatikan ruang cakera dan strategi putaran log.
• Sistem pembalakan berpusat: Untuk persekitaran yang diedarkan, platform pengurusan log terpusat diperlukan. Stack elastik (Elk/Eck), Grafana Loki, Prometheus (dengan Pengeksport Node, dan lain -lain) adalah semua pilihan yang sangat popular. Mereka boleh mengumpulkan data prestasi dari pelayan yang berbeza dan jenis yang berbeza di satu tempat, menjadikannya lebih mudah untuk mengurus dan menanyakan secara seragam.
• Pangkalan Data Masa: InfluxDB direka khas untuk menyimpan dan menanyakan data siri masa. Untuk perubahan berterusan dalam petunjuk prestasi, mereka menyediakan keupayaan penyimpanan dan pertanyaan yang cekap.

Analisis: Ini adalah langkah utama dalam mengubah data mentah ke dalam pandangan.

• Visualisasi: Visualisasi data adalah cara yang paling intuitif untuk memahami trend. Grafana adalah salah satu alat visualisasi sumber terbuka yang paling popular pada masa ini. Ia boleh menyambung ke pelbagai sumber data (Prometheus, Elasticsearch, InfluxDB, dan lain -lain), membuat pelbagai papan pemuka dan carta, dan dengan jelas memaparkan perubahan dalam CPU, memori, I/O dan penunjuk lain dari masa ke masa.
• Penubuhan asas: Memahami prestasi "sihat" sistem di bawah beban normal adalah penting. Sebagai contoh, pelayan web anda biasanya mempunyai kadar penggunaan CPU antara 30% dan 50% pada hari perniagaan biasa. Mana -mana turun naik yang berterusan di luar julat ini boleh menjadi isyarat yang tidak normal.
• Pengiktirafan Trend: Cari corak dalam data. Adakah pertumbuhan yang perlahan (seperti kebocoran memori atau pertumbuhan kapasiti pangkalan data), puncak berkala (seperti penjanaan laporan harian atau tugas batch), atau puncak tiba -tiba (yang mungkin banjir lalu lintas atau bug program).
• Analisis Persatuan: Menggabungkan log prestasi dengan log lain (seperti log aplikasi, log akses, log penempatan). CPU tiba -tiba lonjakan. Adakah ia sepadan dengan masa pelancaran ciri baru, pelaksanaan pertanyaan besar, atau memulakan tugas batch? Analisis korelasi ini dapat membantu anda dengan cepat mencari punca utama masalah.

Tindakan: Berdasarkan hasil analisis, ambil langkah pengoptimuman atau pencegahan yang sepadan.

• Perancangan Kapasiti: Jika anda mendapati bahawa CPU atau penggunaan memori terus berkembang dan sudah dekat atau mencapai ambang, sudah tiba masanya untuk mempertimbangkan skala.
• Pengoptimuman Bottleneck: Jika sumber (seperti cakera I/O) terus menjadi hambatan, mungkin perlu mengoptimumkan kod, menyesuaikan indeks pangkalan data, menaik taraf peranti storan, atau memperkenalkan mekanisme cache.
• Amaran Abnormal: Konfigurasi Peraturan Penggera untuk segera memberitahu kakitangan yang relevan apabila petunjuk utama melebihi ambang pratetap.

Apakah pertimbangan utama apabila memilih alat pengumpulan log prestasi yang betul?

Pilih alat pengumpulan log prestasi. Sejujurnya, ia seperti memilih satu set peralatan audio. Bukannya lebih mahal lebih baik, tetapi ia bergantung kepada sama ada ia sepadan dengan "persekitaran mendengar" anda. Pada pendapat saya, terdapat beberapa perkara teras yang mesti anda fikirkan dengan jelas.

Pertama sekali, persekitaran sistem dan keserasian . Adakah anda menjalankan aplikasi di Windows Server atau bermain Docker dalam kelompok Linux? Atau mungkin semuanya di awan? Sistem operasi dan mod pengendalian yang berbeza secara semulajadi sesuai dengan alat asli atau disyorkan yang berbeza. Windows mempunyai perfmon, Linux mempunyai

 Sysstat

, platform awan masing -masing mempunyai perkhidmatan pemantauan sendiri. Anda tidak boleh mengharapkan alat Linux sahaja untuk memantau tingkap, dan sebaliknya.

Kemudian terdapat koleksi granulariti dan overhead . Bagaimana terperinci yang anda perlukan? Sekali sesaat? Sekali seminit? Data yang terlalu tipis adalah mahal, kos penyimpanan dan pemprosesan adalah tinggi, dan koleksi itu sendiri juga boleh membawa overhead sistem tambahan (walaupun biasanya kecil). Data yang terlalu tebal mungkin terlepas beberapa puncak serta -merta. Ini memerlukan keseimbangan. Bagi persekitaran pengeluaran, kami biasanya memilih butiran yang memberikan wawasan yang mencukupi tanpa memberi kesan kepada perkhidmatan itu sendiri. contohnya,

 SAR

Lalai adalah untuk mengumpulnya sekali setiap 10 minit, anda boleh menyesuaikannya hingga 1 minit atau lebih pendek, tetapi pertimbangkan jumlah data.

Seterusnya adalah kemudahan penyimpanan dan analisis . Apabila data dikumpulkan, mesti ada tempat untuk diletakkan, dan ia mesti mudah dilihat dan divisualisasikan. Jika pasukan anda sudah menggunakan Elasticsearch dan Kibana, memilih alat yang juga boleh mengimport data prestasi ke dalam timbunan Elk akan mengurangkan kos pembelajaran dan kerumitan penyelenggaraan. Jika anda lebih suka Prometheus dan Grafana, maka pilih alat yang menyokong pengeksport Prometheus. Semakin tinggi integrasi, semakin banyak kebimbangan kakitangan operasi dan penyelenggaraan anda.

Skalabiliti dan fleksibiliti juga mesti dipertimbangkan. Perniagaan anda berkembang, skala sistem akan berkembang, dan susunan teknologi baru akan terus diperkenalkan. Bolehkah alat yang anda pilih dengan mudah untuk lebih banyak pelayan? Bolehkah metrik adat baru ditambah dengan mudah? Sesetengah alat adalah "keluar dari kotak" tetapi mempunyai keupayaan penyesuaian yang lemah; Ada yang menyediakan mekanisme API atau plug-in yang kaya yang boleh disesuaikan dengan keperluan anda.

Akhirnya, kos juga merupakan topik yang tidak dapat dielakkan. Ini termasuk yuran pelesenan untuk perisian itu sendiri (jika tidak sumber terbuka), serta yuran perkhidmatan perkakasan atau awan yang ditanggung dalam menyimpan dan memproses data log ini. Kadang -kadang, alat sumber terbuka yang kelihatan bebas boleh menelan kos lebih banyak untuk digunakan dan mengekalkan daripada penyelesaian komersial. Oleh itu, kita mesti menilai secara komprehensif "jumlah kos pemilikan".

Bagaimana untuk mengenal pasti dan mentafsir corak pengecualian secara berkesan dalam log prestasi?

Mengenal pasti dan mentafsirkan corak yang tidak normal dalam log prestasi adalah seperti mencari bintang yang tiba -tiba bersinar atau merendahkan di laut bintang yang luas. Ia memerlukan pengalaman dan beberapa metodologi. Saya secara peribadi berfikir bahawa perkara yang paling teras adalah untuk mempelajari "kontras" dan "korelasi".

Mewujudkan garis dasar "normal" anda adalah langkah pertama dan paling penting. Bagaimanakah sistem berfungsi apabila tidak ada masalah dan bebannya normal? Sebagai contoh, pelayan web saya, pada hari bekerja hari, penggunaan CPU biasanya berubah -ubah antara 30% dan 50%, penggunaan memori stabil pada 8GB, dan cakera IOPS jarang melebihi 100. Ini adalah garis dasar anda. Mana -mana data yang menyimpang dari garis dasar ini bernilai rupa tambahan anda. Tiba -tiba melompat dari 30% hingga 90%, atau perlahan -lahan tumbuh dari 8GB hingga 12GB, adalah isyarat yang tidak normal.

Seterusnya adalah untuk mencari trend dan corak . Anomali tidak selalunya pancang tiba -tiba, kadang -kadang ia adalah "kakisan" yang perlahan.

• Trend menaik yang berterusan: Sebagai contoh, penggunaan memori semakin sedikit setiap hari, atau ruang cakera dimakan pada kadar yang lebih cepat daripada yang dijangkakan. Ini mungkin kebocoran memori, fail log tidak berputar, jadual pangkalan data, dll.
• Keabnormalan berkala: Sebagai contoh, puncak CPU atau I/O berlaku semasa tempoh harian harian (mungkin pagi atau tengah hari). Ini sering berkaitan dengan operasi seperti tugas masa, skrip batch, penyegerakan data, dan lain -lain. Anda perlu mengesahkan sama ada puncak ini berada dalam jangkaan dan sama ada ia mempengaruhi perkhidmatan biasa.
• Spike secara tiba -tiba: Ini adalah pengecualian yang paling biasa, dengan CPU, memori, dan lalu lintas rangkaian melambung dengan serta -merta. Ini mungkin disebabkan oleh puncak lalu lintas, serangan berniat jahat, gelung mati yang disebabkan oleh bug program, pertanyaan perlahan pengimbasan meja penuh, atau kemalangan tiba -tiba dan restart berulang perkhidmatan.

Analisis korelasi adalah kunci untuk menafsirkan keabnormalan. Log prestasi itu sendiri memberitahu anda "apa yang berlaku", tetapi ia tidak memberitahu anda "mengapa berlaku". Pada masa ini, anda perlu menggabungkan log prestasi dengan log lain (seperti log aplikasi, log akses pelayan web, log pertanyaan perlahan pangkalan data, log peristiwa sistem, dan log penempatan).

• CPU tiba -tiba melonjak, dan sebilangan besar mereka muncul dalam log permohonan

   OutofMemoryError

  atau

   NullPointerException

  ? Itu mungkin masalah kod aplikasi.
• I/O sangat tinggi, dan pernyataan SQL dengan masa pelaksanaan yang sangat panjang muncul dalam log pertanyaan perlahan pangkalan data? Itu mungkin masalah dengan pengoptimuman pertanyaan pangkalan data.
• Adakah trafik rangkaian tidak normal, dan pada masa yang sama, terdapat sejumlah besar permintaan dari IP tertentu dalam log akses pelayan web? Itu boleh menderita serangan DDOS atau crawler.
• Metrik sumber tiba -tiba merosot, sejajar dengan titik penggunaan kod terbaru anda? Itu mungkin masalah yang diperkenalkan oleh kod baru.

Akhirnya, visualisasi adalah alat yang berkuasa untuk memahami corak ini. Dengan graf yang ditarik oleh Grafana atau alat lain, anda dapat melihat lompatan, penurunan, pertumbuhan yang berterusan atau turun naik berkala dalam data sekilas. Sebagai contoh, carta garis penggunaan CPU, carta kawasan penggunaan memori, dan carta bar cakera I/O boleh lebih intuitif menunjukkan "nadi" sistem daripada data teks biasa.

Apakah pandangan yang berpandangan ke hadapan yang dapat menyediakan data log prestasi dalam perancangan kapasiti?

Peranan data log prestasi dalam perancangan kapasiti tidak semestinya, tetapi "nabi" yang dapat meramalkan masa depan. Ia memberikan pandangan yang membolehkan anda membuat keputusan lebih awal sebelum sumber sistem habis, mengelakkan gangguan perkhidmatan atau kemalangan prestasi. Pada pendapat saya, ia memberikan pandangan yang berpandangan ke hadapan pada tahap berikut:

Pertama ialah ramalan trend pertumbuhan sejarah . Dengan menganalisis log prestasi sejak beberapa bulan yang lalu atau bahkan tahun, anda dapat melihat dengan jelas bagaimana penggunaan purata dan puncak CPU, memori, cakera I/O, dan jalur lebar rangkaian telah berubah. Sebagai contoh, jika penggunaan memori pelayan pangkalan data anda tumbuh pada 10% setiap suku tahun, anda boleh mengetahui berapa lama masa depan, memori sedia ada tidak akan memenuhi keperluan, dan dengan itu menjadualkan peningkatan terlebih dahulu. Keluk pertumbuhan ini berdasarkan data sebenar adalah lebih dipercayai daripada anggaran "Paiming".

Yang kedua adalah untuk mengenal pasti titik ketepuan sumber . Log prestasi boleh membantu anda menentukan sumber yang paling mungkin menjadi hambatan seterusnya dalam sistem anda. Jika penggunaan CPU telah dinormalisasi untuk mendekati 80-90%, dan cakera I/O dan ingatan masih banyak, maka jelas bahawa CPU akan menjadi tumpuan pengembangan seterusnya anda. sebaliknya. Wawasan ini dapat membantu anda melabur dengan tepat dan mengelakkan pelaburan terlalu banyak dalam sumber bukan botol. Saya pernah menemui kes di mana pasukan selalu berfikir bahawa CPU pangkalan data tidak mencukupi, tetapi melalui analisis log prestasi, didapati bahawa kesesakan itu sebenarnya adalah IOPS cakera, kerana CPU sedang menunggu cakera untuk bertindak balas banyak.

Dan yang lain adalah pencirian beban kerja . Jenis aplikasi yang berbeza mempunyai keperluan yang berbeza untuk sumber. Pelayan web boleh memberi tumpuan lebih kepada CPU dan jalur lebar rangkaian, pelayan pangkalan data boleh memberi tumpuan lebih kepada memori dan cakera I/O, dan tugas batch mungkin mengambil banyak CPU dalam tempoh masa tertentu. Log prestasi dapat membantu anda memahami mod penggunaan sumber sistem anda dalam tempoh masa yang berlainan dan dalam senario perniagaan yang berbeza. Dengan data ini, apabila anda ingin melancarkan perkhidmatan atau ciri baru, anda boleh menilai dengan lebih tepat kesan sumber yang boleh dibawa, dengan itu membuat tempahan sumber terlebih dahulu.

Di samping itu, ia dapat membantu dengan beban puncak dan penilaian permintaan elastik . Data log boleh merakam prestasi sistem pada beban tertinggi dalam sejarah. Sebagai contoh, apakah CPU sistem, memori, dan kadar penggunaan rangkaian pada momen -momen ini yang disebabkan oleh promosi dua kali ganda, siaran produk baru, peristiwa berita pecah, dan lain -lain. Data ini adalah asas utama untuk mereka bentuk strategi skala elastik sistem, seperti skala automatik dalam persekitaran awan. Ia memberitahu anda berapa banyak sumber asas sistem anda sekurang -kurangnya, dan berapa banyak sumber elastik tambahan yang anda perlukan dalam kes -kes yang melampau.

Akhirnya, log prestasi membantu dengan pengoptimuman kos . Banyak kali, kami mengatasi sumber -sumber untuk "hanya dalam kes", terutamanya dalam persekitaran awan, yang membawa kos yang tidak perlu. Dengan analisis log prestasi yang tepat, anda boleh mengurangkan sumber yang rendah untuk masa yang lama, atau mengurangkan kapasiti semasa tempoh luar, dengan itu mencapai penggunaan sumber yang lebih cekap dan penjimatan kos. Sudah tentu, ini memerlukan anda mempunyai pemahaman yang mendalam tentang turun naik perniagaan dan berani membuat keputusan berdasarkan data.

Atas ialah kandungan terperinci Bagaimana cara menggunakan log prestasi untuk menjejaki trend penggunaan sumber sistem?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!