1.3. 운영 문제 해결
이 섹션에서는 OpenShift에 표시되도록 3scale 감사 로깅을 구성하는 방법과 OpenShift에서 3scale 로그 및 작업 대기열에 액세스하는 방법을 설명합니다.
1.3.1. OpenShift에서 3scale 감사 로깅 구성
이를 통해 모든 로그가 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴에서 쿼리할 수 있습니다. 이러한 툴을 사용하면 3scale 구성의 변경 사항과 이러한 변경 사항을 언제 변경했는지 파악할 수 있습니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등의 변경 사항이 포함됩니다.
사전 요구 사항
- 3scale 2.10 배포.
절차
모든 애플리케이션 로그를 표준 OpenShift 포드 로그로 전달하도록 stdout
에 감사 로깅을 구성합니다.
몇 가지 고려 사항:
-
3scale이 온프레미스로 배포되면 기본적으로
stdout
에 대한 감사 로깅이 비활성화됩니다. 이 기능이 완전히 작동하도록 구성해야 합니다. -
stdout
에 대한 감사 로깅은 3scale 호스팅에서 사용할 수 없습니다.
1.3.2. 감사 로깅 활성화
3scale은 features.yml
구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout
에 감사 로깅을 활성화하려면 ConfigMap
에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.yml
에 종속되는 OpenShift 포드는 system-app
및 system-sidekiq
입니다.
사전 요구 사항
- OpenShift에서 클러스터 관리자 액세스 권한이 있어야 합니다.
절차
다음 명령을 입력하여 감사 로깅을
stdout
에 활성화합니다.oc patch configmap system -p '{"data": {"features.yml": "features: &default\n logging:\n audits_to_stdout: true\n\nproduction:\n <<: *default\n"}}'
다음 환경 변수를 내보냅니다.
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"}]}}}}'
업데이트된 배포 구성을 관련 OpenShift 포드에 적용하려면 다음 명령을 입력합니다.
oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES
1.3.3. EFK 로깅 구성
3scale 애플리케이션 로그를 OpenShift로 전달하기 위해 stdout
에 감사 로깅을 활성화한 경우 EFK 로깅 툴을 사용하여 3scale 애플리케이션을 모니터링할 수 있습니다.
OpenShift에서 EFK 로깅을 구성하는 방법에 대한 자세한 내용은 다음을 참조하십시오.
1.3.4. 로그 액세스
각 구성 요소의 배포 구성에는 액세스 및 예외에 대한 로그가 포함되어 있습니다. 배포에 문제가 발생하면 해당 로그에서 자세한 내용을 확인하십시오.
3scale의 로그에 액세스하려면 다음 단계를 따르십시오.
절차
로그를 수행할 Pod의 ID를 찾습니다.
oc get pods
oc logs
및 선택한 Pod의 ID를 입력합니다.oc logs <pod>
시스템 포드에는 각각 별도의 로그가 있는 두 개의 컨테이너가 있습니다. 컨테이너의 로그에 액세스하려면
system-provider 및
Pod를 사용하여system-
developer--container
매개변수를 지정합니다.oc logs <pod> --container=system-provider oc logs <pod> --container=system-developer
1.3.5. 작업 대기열 확인
작업 대기열에는 system-sidekiq
포드에서 전송된 정보의 로그가 포함되어 있습니다. 이 로그를 사용하여 클러스터가 데이터를 처리 중인지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다.
oc get jobs
oc logs <job>
1.3.6. 단일 성장 방지
monotonic 증가를 방지하기 위해 기본적으로 3scale 일정으로 다음 테이블을 자동으로 삭제합니다.
- user_sessions - clean up은 매주 한 번 트리거되고 2주가 지난 레코드를 삭제합니다.
- audits - clean up은 하루에 한 번 트리거되며 3개월이 지난 레코드를 삭제합니다.
- log_entries - 하루에 한 번 트리거되는 정리는 6개월이 지난 레코드를 삭제합니다.
- event_store_events - clean up은 매주 한 번 트리거되고 1주일 이상 레코드가 삭제됩니다.
위에 나열된 테이블을 제외하고 다음 테이블에는 데이터베이스 관리자가 수동으로 삭제해야 합니다.
- 경고
데이터베이스 유형 | 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; |
이 섹션에 지정되지 않은 다른 테이블의 경우 데이터베이스 관리자는 시스템이 자동으로 삭제되지 않는 테이블을 수동으로 정리해야 합니다.
추가 리소스
- OCP(Openshift Container Platform)에 대한 자세한 내용은 OCP 문서를 참조하십시오.
- 포드 자동 스케일링.
- 계산 노드 추가.
- 라우팅 최적화.