Python용 AppSignal을 사용한 고급 Open edX 모니터링
- Susan Sarandon원래의
- 2024-11-29 19:54:12951검색
이 시리즈의 첫 번째 부분에서는 AppSignal이 어떻게 Open edX 플랫폼의 견고성을 크게 향상시킬 수 있는지 살펴보았습니다. Open edX가 확장되면서 직면하는 과제와 실시간 성능 모니터링 및 자동화된 오류 추적을 포함한 AppSignal의 기능이 어떻게 DevOps 팀에 필수 도구를 제공하는지 확인했습니다. 우리의 연습에서는 AppSignal과 Open edX의 초기 설정 및 통합을 다루면서 이 강력한 관찰 프레임워크의 즉각적인 이점을 강조했습니다.
이 두 번째 게시물에서는 AppSignal이 제공하는 고급 모니터링 기능에 대해 더 자세히 살펴보겠습니다. 여기에는 Open edX에서 AppSignal로 로그 스트리밍, Celery를 사용하여 백그라운드 작업자 모니터링, Redis 쿼리 추적이 포함됩니다. 이러한 기능을 활용하여 특정 운영 문제를 해결하고 다양한 상황에서도 학습 플랫폼이 안전하게 유지되도록 하는 방법을 보여드리겠습니다.
이 기사를 마치면 Open edX 플랫폼의 성능과 안정성을 유지하고 개선하기 위해 AppSignal을 최대한 활용하는 방법을 알게 될 것입니다.
AppSignal로 로그 스트리밍
AppSignal의 가장 강력한 기능 중 하나는 중앙 집중식 로그 관리입니다.
Open edX에서는 일반적으로 지원팀이 사이트 문제를 보고하고 엔지니어는 즉시 서버에 SSH를 통해 Nginx, Mongo, MySQL 및 Open edX 애플리케이션 로그를 확인할 수 있습니다.
서버에 SSH로 연결할 필요 없이 로그를 보관하는 중앙 집중식 저장소는 정말 강력한 기능입니다. 문제의 심각도에 따라 알림을 설정할 수도 있습니다.
이제 Open edX에서 AppSignal로 로그를 스트리밍하는 방법을 살펴보겠습니다.
소스 생성
로깅 섹션에서 소스 관리를 클릭하고 플랫폼으로 HTTP, JSON을 사용하여 새 소스를 만듭니다. 형식. 소스를 생성한 후 AppSignal은 로그를 POST
할 수 있는 엔드포인트와 API 키를 제공합니다.로그 전송을 더 효과적으로 제어하기 위해 로컬 Open edX에서 로그를 읽고 사전 처리한 다음 중요한 로그를 AppSignal로 이동하는 간단한 Python 스크립트를 작성할 수 있습니다. 예를 들어, 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) 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.")
스크립트 작동 방식은 다음과 같습니다.
- 로그 파일 관리: 교사는 모든 로그를 /root/.local/share/tutor/data/lms/logs/all.log 파일에 저장합니다. 이 파일에는 MySQL, LMS, CMS, Caddy, Celery 및 기타 서비스가 포함되어 있습니다. 스크립트는 마지막으로 처리된 라인을 추적하는 포인터 /root/.local/share/tutor/data/lms/logs/processed.log 파일을 사용합니다. 이렇게 하면 각 로그가 한 번만 처리됩니다.
- 오류 필터링: 앞서 언급했듯이 AppSignal에는 ERROR 로그만 전송됩니다.
- 데이터 구문 분석 및 형식화: 각 오류 로그를 구문 분석하여 타임스탬프 및 오류 메시지와 같은 주요 정보를 추출합니다. 스크립트는 이 데이터를 전송에 적합한 JSON 구조로 형식화합니다.
- 로그 전송: 포맷된 로그 데이터가 HTTP POST 요청을 사용하여 AppSignal로 전송됩니다.
중요: 개인 식별 정보를 엔드포인트로 보내지 않도록 하세요.
이제 이 스크립트를 실행하면 ERROR 로그가 AppSignal로 이동됩니다.
ERROR와 같은 특정 이벤트가 발생하는 즉시 알림을 보내는 새 트리거를 생성할 수도 있습니다.
AppSignal을 사용하여 Celery 및 Redis 모니터링
Celery(분산 작업 대기열)는 채점, 인증서 생성, 대량 이메일 발송과 같은 백그라운드 작업 관리를 담당하는 Open edX의 필수 구성 요소입니다. Redis는 작업 대기열을 관리하는 Celery의 브로커 역할을 하는 경우가 많습니다. 두 시스템 모두 비동기 처리에 필수적이며 사용량이 많은 기간에는 병목 현상이 발생할 수 있습니다. AppSignal을 사용하여 이러한 서비스를 모니터링하면 작업 실행 및 대기열 상태에 대한 귀중한 통찰력을 얻을 수 있어 잠재적인 문제를 선제적으로 해결하는 데 도움이 됩니다. Celery와 Redis를 모니터링하는 방법을 살펴보겠습니다.
먼저 필요한 패키지를 설치하세요. .local/share/tutor/config.yml 파일의 OPENEDX_EXTRA_PIP_REQUIREMENTS 변수에 다음을 추가하세요.
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.")
다음과 같아야 합니다.
- opentelemetry-instrumentation-celery==0.45b0 - opentelemetry-instrumentation-redis==0.45b0
보시다시피 Celery 및 Redis용 opentelemetry 패키지를 설치하고 있습니다.
이제 작업자_process_init를 사용하여 Celery를 계측하여 해당 지표를 AppSignal에 보고할 수 있습니다.
AppSignal의 대시보드로 돌아가면 성능 섹션에서 네임스페이스가 배경인 Celery 및 Redis 보고서를 볼 수 있습니다.
Redis 쿼리의 경우 느린 쿼리를 클릭하세요.
실제 모니터링: AppSignal을 통해 Open edX 강화
이 섹션에서는 이 시리즈의 1부에서 설명한 초기 문제를 다시 살펴보고 실용적인 AppSignal 모니터링 솔루션을 적용하여 Open edX 플랫폼이 강력하고 안정적으로 유지되도록 하겠습니다. 분석 내용은 다음과 같습니다.
사이트 성능 개선
먼저 전반적인 사이트 성능을 평가해 보겠습니다. 성능 섹션의 문제 목록에서 방문한 모든 URL에 대한 주요 측정항목을 확인할 수 있습니다.
- 응답 시간: 요청을 처리하고 응답하는 데 걸리는 시간을 측정하여 사용자 경험을 직접적으로 반영합니다. 이에 영향을 미치는 요소에는 데이터베이스 쿼리 및 미들웨어 작업이 포함됩니다.
- 처리량: 특정 기간 내에 처리된 요청 수를 나타냅니다.
- 평균 응답 시간: 특정 엔드포인트에 대한 모든 요청의 평균 응답 시간을 제공합니다. 1초가 넘는 평균 응답 시간은 잠재적인 문제이며 최적화가 필요한 영역을 강조합니다.
- 90번째 백분위수 응답 시간: 예를 들어 GET store/의 90번째 백분위수 응답 시간이 7ms라는 것은 요청의 90%가 7ms 이내에 완료된다는 것을 의미합니다.
이제 평균을 기준으로 모든 작업의 순서를 지정해 보겠습니다. 1초보다 긴 항목은 위험 신호로 간주되어야 합니다.
보시다시피 학생 시도 점수를 다시 매기고 재설정하는 Celery 작업, 강좌 콘텐츠 표시를 위한 LMS 요청, 일부 API는 1초 이상 걸립니다. 또한 이는 한 명의 활성 사용자에게만 해당된다는 점에 유의해야 합니다. 동시 사용자가 더 많으면 이 응답 시간이 늘어납니다. 첫 번째 해결책은 서버에 더 많은 리소스(CPU 및 메모리)를 추가하고 또 다른 성능 테스트를 수행하는 것입니다.
평균 응답 시간이 1초를 초과하는 작업을 식별한 후 다음과 같은 성능 최적화 전략을 고려하세요.
- JavaScript 실행 최소화
- 정적 콘텐츠에 CDN 사용
- 캐싱 기술 구현
서버 리소스 모니터링
이전 글에서 이상 감지와 호스트 모니터링에 대해 이야기했습니다. 다음 항목에 대한 트리거를 추가해 보겠습니다.
- CPU 사용량
- 디스크 사용량
- 메모리 사용량
- 네트워크 트래픽
- 오류율
맞춤 측정항목
저희 플랫폼에서 매우 중요한 두 가지 지표는 활성 사용자 수와 등록자 수입니다. AppSignal을 사용하여 이러한 지표를 어떻게 측정할 수 있는지 살펴보겠습니다.
먼저 common/djangoapps/student/views/management.py 및 opensx/core/djangoapps/user_authn/views/login.py에 increment_counter를 추가하여 새 이벤트가 있을 때 로그인 및 등록 수를 추적하고 증가시킵니다.
이제 Open edX에 로그인하여 강좌를 등록해 보겠습니다. 다음으로 AppSignal의 대시보드로 이동하겠습니다. 대시보드 추가를 클릭한 다음 대시보드 만들기를 클릭하고 이름과 설명을 지정합니다.
그래프 추가를 클릭하고 제목으로 활성 사용자를 입력하고 측정항목 추가를 선택한 다음 login_count:
를 사용합니다.
대시보드는 다음과 같아야 합니다.
동일한 단계에 따라 Registration_count 지표를 사용하여 등록 그래프를 추가할 수 있습니다.
일관된 스타일 보장
사이트 스타일의 일관성을 유지하기 위해 static/tailwind/css/lms-main-v1.css에 대한 새로운 가동 시간 확인을 추가하고 URL이 깨졌을 때 알림을 받으세요.
이메일 전달 및 오류 처리
대시보드의 오류 섹션에서는 모든 오류를 확인하고, 이에 대한 알림을 설정하고, 사용자가 부정적인 영향을 받지 않도록 가능한 한 빨리 수정 작업을 수행할 수 있습니다.
채점을 위한 백그라운드 작업 효율성
이 기사의 Celery 및 Redis 모니터링 섹션에서는 AppSignal을 사용하여 Celery 및 Redis를 계측하는 방법을 살펴보았습니다. 동일한 단계에 따라 AppSignal을 활성화하면 등급이 지정된 작업을 볼 수 있습니다. lms/djangoapps/grades/tasks.py 파일에 다음 줄을 추가합니다.
이제 성능 ->에서 채점할 항목이 몇 개 표시됩니다. 이슈 목록.
보시다시피 recalculate_subsection_grade_v3(기본 채점 Celery 작업)에는 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로 직접 문의하세요.
P.S. Python 게시물이 보도되자마자 읽고 싶다면 Python Wizardry 뉴스레터를 구독하고 게시물 하나도 놓치지 마세요!
위 내용은 Python용 AppSignal을 사용한 고급 Open edX 모니터링의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!