2.3. 운영 문제 해결

이 섹션에서는 OpenShift에 표시되도록 3scale 감사 로깅을 구성하는 방법과 OpenShift에서 3scale 로그 및 작업 대기열에 액세스하는 방법을 설명합니다.

2.3.1. OpenShift에서 3scale 감사 로깅 구성

이를 통해 모든 로그가 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴에서 쿼리할 수 있습니다. 이러한 툴을 사용하면 3scale 구성의 변경 사항과 이러한 변경 사항을 언제 변경했는지 파악할 수 있습니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등의 변경 사항이 포함됩니다.

사전 요구 사항

  • 3scale 2.11 배포.

절차

모든 애플리케이션 로그를 표준 OpenShift 포드 로그로 전달하도록 stdout 에 감사 로깅을 구성합니다.

몇 가지 고려 사항:

  • 3scale이 온프레미스로 배포되면 기본적으로 stdout 에 대한 감사 로깅이 비활성화됩니다. 이 기능이 완전히 작동하도록 구성해야 합니다.
  • stdout 에 대한 감사 로깅은 3scale 호스팅에서 사용할 수 없습니다.

2.3.2. 감사 로깅 활성화

3scale은 features.yml 구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout 에 감사 로깅을 활성화하려면 ConfigMap 에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.yml 에 의존하는 OpenShift 포드는 system-app 및 system-sidekiq 입니다.

사전 요구 사항

  • OpenShift에서 클러스터 관리자 액세스 권한이 있어야 합니다.

절차

  1. 다음 명령을 입력하여 감사 로깅을 stdout 에 활성화합니다. 

    oc patch configmap system -p '{"data": {"features.yml": "features: &default\n  logging:\n    audits_to_stdout: true\n\nproduction:\n  <<: *default\n"}}'

  2. 다음 환경 변수를 내보냅니다. 

    export PATCH_SYSTEM_VOLUMES='{"spec":{"template":{"spec":{"volumes":[{"emptyDir":{"medium":"Memory"},"name":"system-tmp"},{"configMap":{"items":[{"key":"zync.yml","path":"zync.yml"},{"key":"rolling_updates.yml","path":"rolling_updates.yml"},{"key":"service_discovery.yml","path":"service_discovery.yml"},{"key":"features.yml","path":"features.yml"}],"name":"system"},"name":"system-config"}]}}}}'

  3. 업데이트된 배포 구성을 관련 OpenShift 포드에 적용하려면 다음 명령을 입력합니다. 

    oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES
oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES

2.3.3. EFK 로깅 구성

3scale 애플리케이션 로그를 OpenShift로 전달하기 위해 stdout 에 감사 로깅을 활성화한 경우 EFK 로깅 툴을 사용하여 3scale 애플리케이션을 모니터링할 수 있습니다.

OpenShift에서 EFK 로깅을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

2.3.4. 로그 액세스

각 구성 요소의 배포 구성에는 액세스 및 예외에 대한 로그가 포함되어 있습니다. 배포에 문제가 발생하면 해당 로그에서 자세한 내용을 확인하십시오.

3scale의 로그에 액세스하려면 다음 단계를 따르십시오.

절차

  1. 로그를 수행할 Pod의 ID를 찾습니다. 

    oc get pods

  2. oc logs 및 선택한 Pod의 ID를 입력합니다. 

    oc logs <pod>

    시스템 포드에는 각각 별도의 로그가 있는 두 개의 컨테이너가 있습니다. 컨테이너의 로그에 액세스하려면 system-provider 및 system- developer Pod를 사용하여 --container 매개변수를 지정합니다. 

    oc logs <pod> --container=system-provider
oc logs <pod> --container=system-developer

2.3.5. 작업 대기열 확인

작업 대기열에는 system-sidekiq 포드에서 전송된 정보의 로그가 포함되어 있습니다. 이 로그를 사용하여 클러스터가 데이터를 처리 중인지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다. 

oc get jobs
oc logs <job>

2.3.6. 단일 성장 방지

monotonic 증가를 방지하기 위해 기본적으로 3scale 일정으로 다음 테이블을 자동으로 삭제합니다.

  • user_sessions - clean up은 매주 한 번 트리거되고 2주가 지난 레코드를 삭제합니다.
  • audits - clean up은 하루에 한 번 트리거되며 3개월이 지난 레코드를 삭제합니다.
  • log_entries - 하루에 한 번 트리거되는 정리는 6개월이 지난 레코드를 삭제합니다.
  • event_store_events - clean up은 매주 한 번 트리거되고 1주일 이상 레코드가 삭제됩니다.

위에 나열된 테이블을 제외하고 다음 테이블에는 데이터베이스 관리자가 수동으로 삭제해야 합니다.

  • 경고

표 2.1. SQL 제거 명령

데이터베이스 유형SQL 명령

MySQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL 14 DAY;

PostgreSQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL '14 day';

Oracle 

DELETE FROM alerts WHERE timestamp <= TRUNC(SYSDATE) - 14;

이 섹션에 지정되지 않은 다른 테이블의 경우 데이터베이스 관리자는 시스템이 자동으로 삭제되지 않는 테이블을 수동으로 정리해야 합니다.

추가 리소스