Pemantauan edX Terbuka Lanjutan dengan AppSignal untuk Python

Dalam bahagian pertama siri ini, kami meneroka cara AppSignal boleh meningkatkan dengan ketara kekukuhan platform Open edX. Kami melihat cabaran yang dihadapi Open edX semasa ia berskala dan cara ciri AppSignal — termasuk pemantauan prestasi masa nyata dan penjejakan ralat automatik — menyediakan alatan penting untuk pasukan DevOps. Panduan kami merangkumi persediaan awal dan penyepaduan AppSignal dengan Open edX, yang menyerlahkan faedah serta-merta rangka kerja pemerhatian yang berkuasa ini.

Dalam siaran kedua ini, kami akan menyelami lebih mendalam keupayaan pemantauan lanjutan yang ditawarkan oleh AppSignal. Ini termasuk log penstriman daripada Open edX ke AppSignal, memantau pekerja latar belakang dengan Celery dan menjejak pertanyaan Redis. Kami akan menunjukkan cara ciri ini boleh dimanfaatkan untuk menangani cabaran operasi tertentu, memastikan platform pembelajaran kami kekal selamat gagal dalam pelbagai keadaan.

Menjelang akhir artikel ini, anda akan tahu cara menggunakan AppSignal sepenuhnya dalam mengekalkan dan meningkatkan prestasi serta kebolehpercayaan platform Open edX anda.

Menstrim Log ke AppSignal

Salah satu ciri terkuat AppSignal ialah pengurusan log berpusat.

Lazimnya di Open edX, pasukan sokongan melaporkan isu dengan tapak dan jurutera boleh SSH ke dalam pelayan serta-merta untuk menyemak log Aplikasi Nginx, Mongo, MySQL dan Open edX.

Tempat storan berpusat yang menempatkan log tanpa perlu anda SSH ke dalam pelayan adalah ciri yang sangat berkuasa. Kami juga boleh menyediakan pemberitahuan berdasarkan keterukan isu.

Sekarang mari kita lihat bagaimana kita boleh menstrim log kita daripada Open edX ke AppSignal.

Cipta Sumber

Di bawah bahagian Log, klik pada Urus sumber dan cipta sumber baharu, dengan HTTP sebagai platform dan JSON sebagai formatnya. Selepas mencipta sumber, AppSignal menyediakan titik akhir dan KUNCI API yang boleh kami POST log kami.

Untuk mempunyai lebih kawalan ke atas penghantaran log, kami boleh menulis skrip Python ringkas yang membaca log daripada Open edX tempatan kami, pra-memprosesnya dan mengalihkan yang penting ke AppSignal. Sebagai contoh, saya menulis skrip berikut untuk mengalihkan log ERROR sahaja ke AppSignal (melangkau INFO dan log AMARAN):

import requests
import json
from datetime import datetime
import logging

# Setup logging configuration
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')

# File to keep track of the last processed line
log_pointer_file = '/root/.local/share/tutor/data/lms/logs/processed.log'
log_file = '/root/.local/share/tutor/data/lms/logs/all.log'

# APpSignal API KEY
api_key = "MY-API-KEY"  # Replace with your actual API key
# URL to post the logs
url = f'https://appsignal-endpoint.net/logs?api_key={api_key}'

def read_last_processed():
    try:
        with open(log_pointer_file, 'r') as file:
            content = file.read().strip()
            last_processed = int(content) if content else 0
            logging.info(f"Last processed line number read: {last_processed}")
            return last_processed
    except (FileNotFoundError, ValueError) as e:
        logging.error(f"Could not read from log pointer file: {e}")
        return 0

def update_last_processed(line_number):
    try:
        with open(log_pointer_file, 'w') as file:
            file.write(str(line_number))
            logging.info(f"Updated last processed to line number: {line_number}")
    except Exception as e:
        logging.error(f"Could not update log pointer file: {e}")

def parse_log_line(line):
    if 'ERROR' in line:
        parts = line.split('ERROR', 1)
        timestamp = parts[0].strip()
        message_parts = parts[1].strip().split(' - ', 1)
        message = message_parts[1] if len(message_parts) > 1 else ''
        attributes_part = message_parts[0].strip('[]').split('] [')
        # Flatten attributes into a dictionary with string keys and values
        attributes = {}
        for attr in attributes_part:
            key_value = attr.split(None, 1)
            if len(key_value) == 2:
                key, value = key_value
                key = key.rstrip(']:').replace(' ', '_').replace('.', '_')  # Replace spaces and dots in keys
                if len(key)  last_processed:
                json_data = parse_log_line(line)
                if json_data:
                    response_code = post_logs(json_data)
                    if response_code == 200:
                        update_last_processed(i)
                    else:
                        logging.warning(f"Failed to post log, HTTP status code: {response_code}")

if __name__ == '__main__':
    logging.info("Starting log processing script.")
    process_logs()
    logging.info("Finished log processing.")

Begini cara skrip berfungsi:

1. Pengurusan Fail Log: Tutor menyimpan semua log dalam fail /root/.local/share/tutor/data/lms/logs/all.log. Fail ini mengandungi MySQL, LMS, CMS, Caddy, Celery dan perkhidmatan lain. Skrip menggunakan fail penuding /root/.local/share/tutor/data/lms/logs/processed.log yang menjejaki baris terakhir yang diproses. Ini memastikan setiap log diproses sekali sahaja.
2. Penapisan Ralat: Seperti yang dinyatakan, kami hanya menghantar log RALAT ke AppSignal.
3. Penghuraian dan Pemformatan Data: Setiap log ralat dihuraikan untuk mengekstrak cebisan maklumat penting, seperti cap masa dan mesej ralat. Skrip memformat data ini ke dalam struktur JSON yang sesuai untuk penghantaran.
4. Penghantaran Log: Data log yang diformatkan dihantar ke AppSignal menggunakan permintaan HTTP POST.

Penting: Sila pastikan anda tidak menghantar sebarang maklumat yang boleh dikenal pasti secara peribadi ke titik akhir.

Sekarang jalankan skrip ini dan ia sepatutnya mengalihkan log ERROR ke AppSignal:

Anda juga boleh membuat pencetus baharu untuk memberitahu anda sebaik sahaja acara tertentu seperti ERROR berlaku:

Pantau Celery dan Redis menggunakan AppSignal

Saderi (baris gilir tugas yang diedarkan) ialah komponen penting Open edX, bertanggungjawab untuk mengurus tugas latar belakang seperti penggredan, penjanaan sijil dan penghantaran e-mel pukal. Redis sering bertindak sebagai broker untuk Celery, menguruskan baris gilir tugas. Kedua-dua sistem adalah penting untuk pemprosesan tak segerak dan boleh menjadi kesesakan semasa tempoh penggunaan yang tinggi. Memantau perkhidmatan ini dengan AppSignal memberikan cerapan berharga tentang pelaksanaan tugas dan kesihatan baris gilir, membantu anda menangani isu yang berpotensi secara preemptive. Mari lihat bagaimana kita boleh memantau Celery dan Redis.

Mula-mula, pasang pakej yang diperlukan. Tambahkan yang berikut pada pembolehubah OPENEDX_EXTRA_PIP_REQUIREMENTS dalam fail .local/share/tutor/config.yml:

import requests
import json
from datetime import datetime
import logging

# Setup logging configuration
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')

# File to keep track of the last processed line
log_pointer_file = '/root/.local/share/tutor/data/lms/logs/processed.log'
log_file = '/root/.local/share/tutor/data/lms/logs/all.log'

# APpSignal API KEY
api_key = "MY-API-KEY"  # Replace with your actual API key
# URL to post the logs
url = f'https://appsignal-endpoint.net/logs?api_key={api_key}'

def read_last_processed():
    try:
        with open(log_pointer_file, 'r') as file:
            content = file.read().strip()
            last_processed = int(content) if content else 0
            logging.info(f"Last processed line number read: {last_processed}")
            return last_processed
    except (FileNotFoundError, ValueError) as e:
        logging.error(f"Could not read from log pointer file: {e}")
        return 0

def update_last_processed(line_number):
    try:
        with open(log_pointer_file, 'w') as file:
            file.write(str(line_number))
            logging.info(f"Updated last processed to line number: {line_number}")
    except Exception as e:
        logging.error(f"Could not update log pointer file: {e}")

def parse_log_line(line):
    if 'ERROR' in line:
        parts = line.split('ERROR', 1)
        timestamp = parts[0].strip()
        message_parts = parts[1].strip().split(' - ', 1)
        message = message_parts[1] if len(message_parts) > 1 else ''
        attributes_part = message_parts[0].strip('[]').split('] [')
        # Flatten attributes into a dictionary with string keys and values
        attributes = {}
        for attr in attributes_part:
            key_value = attr.split(None, 1)
            if len(key_value) == 2:
                key, value = key_value
                key = key.rstrip(']:').replace(' ', '_').replace('.', '_')  # Replace spaces and dots in keys
                if len(key)  last_processed:
                json_data = parse_log_line(line)
                if json_data:
                    response_code = post_logs(json_data)
                    if response_code == 200:
                        update_last_processed(i)
                    else:
                        logging.warning(f"Failed to post log, HTTP status code: {response_code}")

if __name__ == '__main__':
    logging.info("Starting log processing script.")
    process_logs()
    logging.info("Finished log processing.")

Ia sepatutnya kelihatan seperti berikut:

- opentelemetry-instrumentation-celery==0.45b0
- opentelemetry-instrumentation-redis==0.45b0

Seperti yang anda lihat, kami sedang memasang pakej opentelemetri untuk Saderi dan Redis.

Kini, kami boleh mengimplementasikan Celery dengan worker_process_init untuk melaporkan metriknya kepada AppSignal.

Kembali ke papan pemuka kami di AppSignal, kami akan melihat laporan Celery dan Redis dalam bahagian Prestasi, dengan latar belakang sebagai ruang nama.

Untuk pertanyaan Redis, anda boleh klik pada Pertanyaan perlahan:

Pemantauan Praktikal: Meningkatkan Open edX dengan AppSignal

Dalam bahagian ini, kami akan menyemak semula isu awal yang digariskan dalam bahagian satu siri ini dan menggunakan penyelesaian pemantauan AppSignal praktikal untuk memastikan platform Open edX kami kekal teguh dan boleh dipercayai. Berikut ialah pecahan.

Peningkatan Prestasi Tapak

Mari kita mulakan dengan menilai prestasi tapak keseluruhan. Dalam bahagian Prestasi, di bawah senarai isu, kita boleh melihat metrik utama untuk semua URL yang dilawati:

• Masa Tindak Balas: Secara langsung menggambarkan pengalaman pengguna dengan mengukur masa yang diambil untuk memproses dan membalas permintaan. Faktor yang mempengaruhi ini termasuk pertanyaan pangkalan data dan operasi perisian tengah.
• Throughput: Menunjukkan bilangan permintaan yang dikendalikan dalam jangka masa tertentu.
• Masa Maklum Balas Min: Menyediakan purata masa respons merentas semua permintaan ke titik akhir tertentu. Sebarang masa tindak balas min melebihi 1 saat adalah potensi kebimbangan dan menyerlahkan bidang yang memerlukan pengoptimuman.
• Masa Tindak Balas Persentil ke-90: Contohnya, masa tindak balas persentil ke-90 sebanyak 7 ms untuk kedai GET/ mencadangkan bahawa 90% permintaan selesai dalam 7 ms atau kurang.

Sekarang mari kita susun semua tindakan berdasarkan min. Mana-mana item yang lebih tinggi daripada 1 saat harus dianggap sebagai bendera merah:

Seperti yang kita lihat, tugasan Celery untuk menjaringkan semula dan menetapkan semula percubaan pelajar, LMS meminta untuk menunjukkan kandungan kursus dan sesetengah API mengambil masa lebih daripada 1 saat. Juga, kita harus ambil perhatian bahawa ini hanya untuk satu pengguna aktif. Jika kami mempunyai lebih ramai pengguna serentak, masa tindak balas ini akan meningkat. Penyelesaian pertama kami ialah menambah lebih banyak sumber pada pelayan (CPU dan memori) dan melakukan ujian prestasi yang lain.

Selepas mengenal pasti tindakan dengan masa tindak balas min melebihi 1 saat, pertimbangkan strategi pengoptimuman prestasi seperti:

• Meminimumkan pelaksanaan JavaScript
• Menggunakan CDN untuk kandungan statik
• Melaksanakan teknik caching.

Pemantauan Sumber Pelayan

Kami bercakap tentang pengesanan anomali dan pemantauan hos dalam artikel sebelumnya. Mari tambah pencetus untuk item berikut:

• Penggunaan CPU
• Penggunaan cakera
• Penggunaan memori
• Trafik rangkaian
• Kadar ralat

Metrik Tersuai

Dua metrik yang sangat penting untuk platform kami ialah bilangan pengguna aktif dan pendaftaran kami. Mari lihat cara kita boleh mengukur metrik ini menggunakan AppSignal.

Pertama, tambah increment_counter pada common/djangoapps/student/views/management.py dan openedx/core/djangoapps/user_authn/views/login.py untuk menjejak dan menambah bilangan log masuk dan pendaftaran apabila terdapat acara baharu.

Sekarang mari log masuk ke Open edX dan daftar dalam kursus. Seterusnya, mari pergi ke papan pemuka kami di AppSignal. Klik pada Tambah papan pemuka, kemudian Buat papan pemuka, dan beri nama dan penerangan.

Klik pada Tambah graf, masukkan Pengguna Aktif sebagai tajuk, pilih Tambah Metrik dan gunakan login_count:

Papan pemuka anda sepatutnya kelihatan seperti berikut:

Anda boleh mengikuti langkah yang sama untuk menambah graf bagi pendaftaran menggunakan metrik enrollment_count.

Memastikan Penggayaan Konsisten

Untuk memastikan penggayaan tapak kami kekal konsisten, mari tambah semakan masa operasi baharu untuk static/tailwind/css/lms-main-v1.css dan dapatkan pemberitahuan apabila URL rosak:

Penghantaran E-mel dan Pengendalian Ralat

Dalam bahagian Ralat pada papan pemuka, kami boleh melihat semua ralat, menyediakan pemberitahuan untuknya dan melakukan pembetulan secepat mungkin untuk mengelakkan pengguna daripada mendapat kesan negatif.

Kecekapan Kerja Latar Belakang untuk Penggredan

Dalam bahagian Pantau Saderi dan Redis artikel ini, kami melihat cara menggunakan Saderi dan Redis menggunakan AppSignal. Mari kita ikuti langkah yang sama untuk mendayakan AppSignal supaya kita dapat melihat tugasan yang digredkan. Dalam fail lms/djangoapps/grades/tasks.py, tambahkan baris berikut:

Kini kita sepatutnya melihat beberapa item untuk digredkan di bawah Prestasi -> Senarai isu.

Seperti yang anda lihat, pengiraan semula_subseksyen_gred_v3 (tugas penggredan Saderi utama kami) mengambil masa 212 milisaat. Untuk penggredan semula, lms.djangoapps.instructor_task.tasks.reset_problem_attempts dan lms.djangoapps.instructor_task.tasks.rescore_problem mengambil masa 1.77 saat.

Membungkus

Dalam siri dua bahagian ini, kami menyepadukan AppSignal dengan Open edX untuk memperkukuh keupayaan pemantauannya. Kami bermula dengan asas — menyediakan dan memahami tawaran asas AppSignal, termasuk penjejakan ralat dan pemantauan prestasi.

Dalam artikel ini, kami menangani cara menstrim log dengan cekap daripada pelbagai perkhidmatan Open edX ke AppSignal, memastikan semua maklumat yang berkaitan dipusatkan dan mudah diakses. Kami juga memantau tugas tak segerak penting yang dikendalikan oleh Celery dan Redis.

Akhir sekali, kami menangani beberapa cabaran dunia nyata, seperti respons tapak yang perlahan, kesesakan sumber semasa tempoh pendaftaran yang tinggi dan isu yang tidak dijangka seperti penggayaan yang rosak.

Sekarang, anda sepatutnya mempunyai pemahaman yang menyeluruh tentang cara memanfaatkan AppSignal untuk bukan sahaja memantau, tetapi juga meningkatkan dengan ketara, prestasi dan kebolehpercayaan platform Open edX anda.

Jika anda mempunyai sebarang pertanyaan tentang Open edX atau memerlukan bantuan lanjut, sila layari cubite.io atau hubungi saya terus di amir@cubite.io.

P.S. Jika anda ingin membaca siaran Python sebaik sahaja ia keluar dari akhbar, langgan surat berita Python Wizardry kami dan jangan sekali-kali terlepas satu pun siaran!

Atas ialah kandungan terperinci Pemantauan edX Terbuka Lanjutan dengan AppSignal untuk Python. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!