مانیتورینگ edX پیشرفته با AppSignal برای پایتون

Summarize this content to 400 words in Persian Lang
در قسمت اول این مجموعه، بررسی کردیم که چگونه AppSignal می تواند به طور قابل توجهی استحکام پلتفرم های Open edX را افزایش دهد. ما شاهد چالش‌هایی بودیم که Open edX در حین بزرگ‌تر شدن با آن مواجه است و چگونه ویژگی‌های AppSignal – از جمله نظارت بر عملکرد در زمان واقعی و ردیابی خودکار خطاها – ابزارهای ضروری را برای تیم‌های DevOps فراهم می‌کند. راه‌اندازی اولیه و ادغام AppSignal با Open edX را پوشش می‌دهیم و مزایای فوری این چارچوب قابل مشاهده قدرتمند را برجسته می‌کند.

در این پست دوم، ما عمیق‌تر به قابلیت‌های نظارتی پیشرفته‌ای که AppSignal ارائه می‌دهد خواهیم پرداخت. این شامل استریم گزارش‌ها از Open edX به AppSignal، نظارت بر کارگران پس‌زمینه با Celery، و ردیابی درخواست‌های Redis است. ما نشان خواهیم داد که چگونه می‌توان از این ویژگی‌ها برای رسیدگی به چالش‌های عملیاتی خاص استفاده کرد و اطمینان حاصل کرد که پلت فرم یادگیری ما تحت شرایط مختلف ایمن باقی می‌ماند.

در پایان این مقاله، می‌دانید که چگونه از AppSignal با پتانسیل کامل آن در حفظ و بهبود عملکرد و قابلیت اطمینان پلتفرم Open edX خود استفاده کنید.

استریم لاگ به AppSignal

یکی از قوی ترین ویژگی های AppSignal مدیریت متمرکز گزارش است.

معمولاً در Open edX، تیم پشتیبانی مشکلی را در سایت گزارش می‌کند و یک مهندس می‌تواند فوراً به سرور SSH کند تا گزارش‌های Nginx، Mongo، MySQL و Open edX Application را بررسی کند.

یک مکان ذخیره سازی متمرکز که لاگ ها را بدون نیاز به SSH در سرور نگهداری می کند، یک ویژگی واقعا قدرتمند است. همچنین می‌توانیم اعلان‌ها را بر اساس شدت یک مشکل تنظیم کنیم.

حالا بیایید ببینیم چگونه می توانیم گزارش های خود را از Open edX به AppSignal استریم کنیم.

یک منبع ایجاد کنید

زیر ورود به سیستم بخش، روی آن کلیک کنید مدیریت منابع و ایجاد یک منبع جدید، با HTTP به عنوان پلت فرم و JSON به عنوان قالب پس از ایجاد منبع، AppSignal یک نقطه پایانی و کلید API ارائه می دهد که ما می توانیم ارسال کنید سیاهههای مربوط به.

برای اینکه کنترل بیشتری بر انتقال گزارش داشته باشیم، می‌توانیم یک اسکریپت ساده پایتون بنویسیم که گزارش‌ها را از Open edX محلی ما بخواند، آنها را از قبل پردازش کند و موارد مهم را به AppSignal منتقل کند. برای مثال من اسکریپت زیر را فقط برای جابجایی نوشتم ERROR به AppSignal وارد می شود (پرش INFO و WARNING سیاههها):

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) <= 50:
attributes[key] = value
# Format the timestamp
formatted_timestamp = datetime.strptime(timestamp, ‘%Y-%m-%d %H:%M:%S,%f’).isoformat()[:-3] + ‘Z’
# Add the message and attributes to the log structure
json_data = {
“timestamp”: formatted_timestamp,
“group”: “openedx”,
“severity”: “error”,
“hostname”: “tutor”,
“message”: message,
}
json_data.update(attributes) # Add the attributes directly to the json_data dictionary
return json_data

def post_logs(json_data):
headers = {‘Content-Type’: ‘application/json’}
response = requests.post(url, json=json_data, headers=headers)
logging.info(f”Posted log to server; HTTP status code: {response.status_code}, Response: {response.content}”)
return response.status_code

def process_logs():
last_processed = read_last_processed()
with open(log_file, ‘r’) as file:
for i, line in enumerate(file, 1):
if i > 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.”)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در اینجا نحوه کار اسکریپت آمده است:

مدیریت فایل لاگ: Tutor همه گزارش‌های موجود در را ذخیره می‌کند /root/.local/share/tutor/data/lms/logs/all.log فایل این فایل شامل MySQL، LMS، CMS، Caddy، Celery و سایر خدمات می باشد. اسکریپت از یک اشاره گر استفاده می کند /root/.local/share/tutor/data/lms/logs/processed.log فایلی که آخرین خط پردازش شده را ردیابی می کند. این تضمین می کند که هر گزارش فقط یک بار پردازش می شود.

خطا در فیلتر کردن: همانطور که گفته شد ما فقط ارسال می کنیم ERROR به AppSignal وارد می شود.

تجزیه و قالب بندی داده ها: هر گزارش خطا برای استخراج قطعات کلیدی اطلاعات، مانند مهر زمان و پیام خطا، تجزیه می شود. اسکریپت این داده ها را در یک ساختار JSON مناسب برای انتقال قالب بندی می کند.

انتقال ورود به سیستم: داده های گزارش فرمت شده با استفاده از درخواست HTTP POST به AppSignal ارسال می شود.

مهم: لطفاً مطمئن شوید که هیچ اطلاعات شناسایی شخصی را به نقطه پایانی ارسال نکنید.

حالا این اسکریپت را اجرا کنید و باید حرکت کند ERROR ورود به AppSignal:

همچنین می توانید یک ماشه جدید ایجاد کنید تا به محض وقوع یک رویداد خاص به شما اطلاع دهد ERROR اتفاق می افتد:

Celery و Redis را با استفاده از AppSignal مانیتور کنید

Celery (یک صف وظایف توزیع شده) یک جزء حیاتی Open edX است که مسئول مدیریت کارهای پس زمینه مانند درجه بندی، تولید گواهی و ارسال ایمیل انبوه است. Redis اغلب به عنوان واسطه برای Celery عمل می کند و صف های وظایف را مدیریت می کند. هر دو سیستم برای پردازش ناهمزمان ضروری هستند و می توانند در طول دوره های استفاده زیاد به گلوگاه تبدیل شوند. نظارت بر این سرویس‌ها با AppSignal بینش‌های ارزشمندی را در مورد اجرای کار و سلامت صف ارائه می‌کند و به شما کمک می‌کند تا پیشگیرانه به مشکلات احتمالی رسیدگی کنید. بیایید ببینیم چگونه می توانیم سلری و ردیس را زیر نظر داشته باشیم.

ابتدا پکیج های لازم را نصب کنید. موارد زیر را به OPENEDX_EXTRA_PIP_REQUIREMENTS متغیر در .local/share/tutor/config.yml فایل:

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

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

باید به شکل زیر باشد:

OPENEDX_EXTRA_PIP_REQUIREMENTS:
– appsignal==1.3.0
– opentelemetry-instrumentation-django==0.45b0
– opentelemetry-instrumentation-celery==0.45b0
– opentelemetry-instrumentation-redis==0.45b0

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

همانطور که می بینید ما در حال نصب هستیم opentelemetry بسته های کرفس و ردیس.

حالا می توانیم کرفس را با آن ساز بزنیم worker_process_init برای گزارش معیارهای آن به AppSignal.

با بازگشت به داشبورد خود در AppSignal، باید گزارش‌های Celery و Redis را در آن ببینیم عملکرد بخش، با پس زمینه به عنوان فضای نام

برای پرس و جوهای Redis، می توانید روی آن کلیک کنید پرس و جوهای آهسته:

نظارت عملی: بهبود Open edX با AppSignal

در این بخش، مسائل اولیه را که در قسمت اول این مجموعه بیان شد، دوباره بررسی می‌کنیم و راه‌حل‌های نظارتی کاربردی AppSignal را به کار می‌گیریم تا اطمینان حاصل کنیم که پلتفرم Open edX ما قوی و قابل اعتماد باقی می‌ماند. اینجا یک خرابی است.

بهبود عملکرد سایت

بیایید با ارزیابی عملکرد کلی سایت شروع کنیم. در عملکرد بخش، زیر لیست مسائل، می توانیم معیارهای کلیدی را برای همه URL های بازدید شده ببینیم:

زمان پاسخگویی: به طور مستقیم تجربه کاربر را با اندازه گیری زمان پردازش و پاسخ به درخواست ها منعکس می کند. عوامل مؤثر بر این امر عبارتند از پرس و جوهای پایگاه داده و عملیات میان افزار.

توان عملیاتی: نشان دهنده تعداد درخواست هایی است که در یک بازه زمانی معین انجام شده است.

میانگین زمان پاسخگویی: میانگین زمان پاسخگویی را در تمام درخواست‌ها به یک نقطه پایانی خاص ارائه می‌کند. هر میانگین زمان پاسخگویی بیش از 1 ثانیه یک نگرانی بالقوه است و مناطقی را که نیاز به بهینه سازی دارند برجسته می کند.

زمان پاسخ دهی صدک 90: به عنوان مثال، زمان پاسخ دهی صدک 90 ms 7 برای GET store/ نشان می دهد که 90٪ درخواست ها در 7 میلی ثانیه یا کمتر تکمیل می شوند.

اکنون بیایید همه اقدامات را بر اساس میانگین ترتیب دهیم. هر مورد بالاتر از 1 ثانیه باید به عنوان پرچم قرمز در نظر گرفته شود:

همانطور که می‌بینیم، وظایف Celery برای امتیازدهی مجدد و بازنشانی تلاش‌های دانش‌آموز، درخواست‌های LMS برای نمایش محتوای دوره، و برخی APIها بیش از 1 ثانیه طول می‌کشد. همچنین باید توجه داشته باشیم که این فقط برای یک کاربر فعال است. اگر کاربران همزمان بیشتری داشته باشیم، این زمان پاسخگویی بالا می رود. اولین راه حل ما اضافه کردن منابع بیشتر به سرور (CPU و حافظه) و انجام یک تست عملکرد دیگر است.

پس از شناسایی اقدامات با میانگین زمان پاسخ بیش از 1 ثانیه، استراتژی های بهینه سازی عملکرد مانند:

به حداقل رساندن اجرای جاوا اسکریپت
استفاده از CDN برای محتوای استاتیک
پیاده سازی تکنیک های کش

نظارت بر منابع سرور

در مقاله قبلی در مورد تشخیص ناهنجاری و نظارت بر میزبان صحبت کردیم. بیایید برای موارد زیر ماشه اضافه کنیم:

استفاده از CPU
استفاده از دیسک
استفاده از حافظه
ترافیک شبکه
میزان خطا

معیارهای سفارشی

دو معیار بسیار مهم برای پلتفرم ما تعداد کاربران فعال و ثبت نام‌های ما است. بیایید ببینیم چگونه می توانیم این معیارها را با استفاده از AppSignal اندازه گیری کنیم.

ابتدا اضافه کنید increment_counter به common/djangoapps/student/views/management.py و openedx/core/djangoapps/user_authn/views/login.py برای ردیابی و افزایش تعداد ورود و ثبت نام در صورت وجود رویداد جدید.

حالا بیایید وارد Open edX شویم و در یک دوره ثبت نام کنیم. بعد، بیایید به داشبورد خود در AppSignal برویم. را کلیک کنید داشبورد را اضافه کنید، سپس داشبورد ایجاد کنید، و نام و شرح آن را بدهید.

را کلیک کنید اضافه کردن نمودار، وارد کنید کاربران فعال به عنوان عنوان، انتخاب کنید متریک را اضافه کنید و استفاده کنید login_count:

داشبورد شما باید به شکل زیر باشد:

می توانید همین مراحل را برای افزودن نمودار برای ثبت نام با استفاده از یک دنبال کنید enrollment_count متریک

اطمینان از یک استایل ثابت

برای اطمینان از ثابت ماندن استایل سایت ما، بیایید یک بررسی آپتایم جدید اضافه کنیم static/tailwind/css/lms-main-v1.css و در صورت خراب شدن یک URL مطلع شوید:

تحویل ایمیل و رسیدگی به خطا

در خطا در بخش داشبورد، می‌توانیم همه خطاها را مشاهده کنیم، اعلان‌ها را برای آن‌ها تنظیم کنیم، و در اسرع وقت روی رفع آنها کار کنیم تا از تأثیر منفی کاربران جلوگیری کنیم.

کارایی شغلی پیش زمینه برای درجه بندی

در کرفس و ردیس را زیر نظر بگیرید در بخش این مقاله، نحوه ساخت Celery و Redis با استفاده از AppSignal را دیدیم. بیایید همان مراحل را دنبال کنیم تا AppSignal را فعال کنیم تا بتوانیم وظایف درجه بندی شده را ببینیم. در lms/djangoapps/grades/tasks.py فایل، خطوط زیر را اضافه کنید:

اکنون باید چند مورد را ببینیم که زیر آن درجه بندی کنیم عملکرد -> لیست مسائل.

همانطور که می بینید، recalculate_subsection_grade_v3 (کار درجه بندی اصلی کرفس ما) 212 میلی ثانیه طول می کشد. برای تجدید رتبه، lms.djangoapps.instructor_task.tasks.reset_problem_attempts و lms.djangoapps.instructor_task.tasks.rescore_problem 1.77 ثانیه طول بکشد.

بسته بندی

در این سری دو قسمتی، ما AppSignal را با Open edX ادغام کردیم تا قابلیت‌های نظارتی آن را تقویت کنیم. ما با اصول اولیه شروع کردیم – راه اندازی و درک پیشنهادات اساسی AppSignal، از جمله ردیابی خطا و نظارت بر عملکرد.

در این مقاله، نحوه استریم کارآمد گزارش‌ها از سرویس‌های Open edX مختلف به AppSignal را بررسی کردیم، تا اطمینان حاصل کنیم که تمام اطلاعات مرتبط متمرکز و به راحتی قابل دسترسی هستند. ما همچنین وظایف ناهمزمان حیاتی که توسط Celery و Redis انجام می شد را زیر نظر گرفتیم.

در نهایت، به برخی از چالش‌های دنیای واقعی، مانند پاسخ‌های کند سایت، تنگناهای منابع در طول دوره‌های ثبت‌نام بالا، و مسائل غیرمنتظره مانند استایل شکسته پرداختیم.

در حال حاضر، شما باید درک جامعی از نحوه استفاده از AppSignal نه تنها برای نظارت، بلکه به طور قابل توجهی بهبود عملکرد و قابلیت اطمینان پلت فرم Open edX خود داشته باشید.

اگر در مورد Open edX سؤالی دارید یا به کمک بیشتری نیاز دارید، به راحتی به cubite.io مراجعه کنید یا مستقیماً با من در amir@cubite.io تماس بگیرید.

PS اگر می‌خواهید پست‌های پایتون را به‌محض انتشار مطبوعات بخوانید، در خبرنامه Python Wizardry مشترک شوید و هیچ پستی را از دست ندهید!

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) <= 50:
                    attributes[key] = value
        # Format the timestamp
        formatted_timestamp = datetime.strptime(timestamp, '%Y-%m-%d %H:%M:%S,%f').isoformat()[:-3] + 'Z'
        # Add the message and attributes to the log structure
        json_data = {
            "timestamp": formatted_timestamp,
            "group": "openedx",
            "severity": "error",
            "hostname": "tutor",
            "message": message,
        }
        json_data.update(attributes)  # Add the attributes directly to the json_data dictionary
        return json_data

def post_logs(json_data):
    headers = {'Content-Type': 'application/json'}
    response = requests.post(url, json=json_data, headers=headers)
    logging.info(f"Posted log to server; HTTP status code: {response.status_code}, Response: {response.content}")
    return response.status_code

def process_logs():
    last_processed = read_last_processed()
    with open(log_file, 'r') as file:
        for i, line in enumerate(file, 1):
            if i > 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.")

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

OPENEDX_EXTRA_PIP_REQUIREMENTS:
  - appsignal==1.3.0
  - opentelemetry-instrumentation-django==0.45b0
  - opentelemetry-instrumentation-celery==0.45b0
  - opentelemetry-instrumentation-redis==0.45b0