1.3. 작업 문제 해결


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

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

이를 통해 Elasticsearch, Fluentd 및 Kibana(EFK) 로깅 툴을 통해 모든 로그를 쿼리할 수 있습니다. 이러한 툴은 3scale 구성 변경 사항, 이러한 변경을 수행한 사용자 및 시기에 대한 가시성을 향상시킵니다. 예를 들어 청구, 애플리케이션 계획, API 구성 등에 대한 변경 사항이 포함됩니다.

사전 요구 사항

  • 3scale 2.7 배포

절차

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

몇 가지 고려 사항:

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

1.3.2. 감사 로깅 활성화

3scale은 features.xml 구성 파일을 사용하여 일부 글로벌 기능을 활성화합니다. stdout 에 대한 감사 로깅을 활성화하려면 ConfigMap 에서 이 파일을 마운트하여 기본 파일을 교체해야 합니다. features.xml 을 사용하는 OpenShift pod는 system-appsystem-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

1.3.3. EFK 로깅 구성

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

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

1.3.4. 로그 액세스

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

다음 단계에 따라 3scale의 로그에 액세스합니다.

절차

  1. 로그를 원하는 Pod의 ID를 찾습니다.

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

    oc logs <pod>

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

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

1.3.5. 작업 대기열 확인

작업 큐에는 system-sidekiq Pod에서 보낸 정보 로그가 포함됩니다. 이러한 로그를 사용하여 클러스터가 데이터를 처리하고 있는지 확인합니다. OpenShift CLI를 사용하여 로그를 쿼리할 수 있습니다.

oc get jobs
oc logs <job>

1.3.6. 단조적 성장 방지

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

  • user_sessions - 정리가 일주일에 한 번 트리거되고 2주 이상 오래된 레코드를 삭제합니다.
  • 감사 - 정리는 하루에 한 번 트리거되고 3개월 이상 오래된 레코드를 삭제합니다.
  • log_entries - 하루에 한 번 트리거하여 6개월 이상 오래된 레코드를 삭제합니다.
  • event_store_events - 정리가 일주일에 한 번 트리거되고 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;

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.