10.4. Elasticsearch 로그 저장소 구성
Elasticsearch 6을 사용하여 로그 데이터를 저장하고 구성할 수 있습니다.
다음을 포함하여 로그 저장소를 수정할 수 있습니다.
- Elasticsearch 클러스터의 스토리지
- 전체 복제에서 복제 없음까지 클러스터의 데이터 노드 간 shard 복제
- Elasticsearch 데이터에 대한 외부 액세스
10.4.1. 로그 스토리지 구성
ClusterLogging
사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 스토리지 유형을 구성할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator와 LokiStack 또는 Elasticsearch인 내부 로그 저장소를 설치했습니다.
-
ClusterLogging
CR을 생성했습니다.
로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.
프로세스
ClusterLogging
CRlogStore
사양을 수정합니다.ClusterLogging
CR 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... logStore: type: <log_store_type> 1 elasticsearch: 2 nodeCount: <integer> resources: {} storage: {} redundancyPolicy: <redundancy_type> 3 lokistack: 4 name: {} # ...
LokiStack을 로그 저장소로 지정하는
ClusterLogging
CR의 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: managementState: Managed logStore: type: lokistack lokistack: name: logging-loki # ...
다음 명령을 실행하여
ClusterLogging
CR을 적용합니다.$ oc apply -f <filename>.yaml
10.4.2. 감사 로그를 로그 저장소로 전달
로깅 배포에서 컨테이너 및 인프라 로그는 기본적으로 ClusterLogging
사용자 정의 리소스(CR)에 정의된 내부 로그 저장소로 전달됩니다.
감사 로그는 보안 스토리지를 제공하지 않기 때문에 기본적으로 내부 로그 저장소로 전달되지 않습니다. 감사 로그를 전달하는 시스템이 조직 및 정부 규정을 준수하고 올바르게 보호되도록 할 책임이 있습니다.
이 기본 구성이 요구 사항을 충족하는 경우 ClusterLogForwarder
CR을 구성할 필요가 없습니다. ClusterLogForwarder
CR이 있는 경우 기본
출력이 포함된 파이프라인을 정의하지 않는 한 로그는 내부 로그 저장소로 전달되지 않습니다.
프로세스
Log Forward API를 사용하여 감사 로그를 내부 Elasticsearch 인스턴스로 전달하려면 다음을 수행합니다.
ClusterLogForwarder
CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다.모든 로그 유형을 내부 Elasticsearch 인스턴스로 보내는 CR을 생성합니다. 다음 예제를 변경하지 않고 그대로 사용할 수 있습니다.
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: pipelines: 1 - name: all-to-default inputRefs: - infrastructure - application - audit outputRefs: - default
- 1
- 파이프라인은 지정된 출력을 사용하여 전달할 로그 유형을 정의합니다. 기본 출력은 로그를 내부 Elasticsearch 인스턴스로 전달합니다.
참고파이프라인에서 애플리케이션, 인프라 및 감사의 세 가지 유형의 로그를 모두 지정해야 합니다. 로그 유형을 지정하지 않으면 해당 로그가 저장되지 않고 손실됩니다.
기존
ClusterLogForwarder
CR이 있는 경우 감사 로그의 기본 출력에 파이프라인을 추가합니다. 기본 출력을 정의할 필요가 없습니다. 예를 들면 다음과 같습니다.apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: elasticsearch-insecure type: "elasticsearch" url: http://elasticsearch-insecure.messaging.svc.cluster.local insecure: true - name: elasticsearch-secure type: "elasticsearch" url: https://elasticsearch-secure.messaging.svc.cluster.local secret: name: es-audit - name: secureforward-offcluster type: "fluentdForward" url: https://secureforward.offcluster.com:24224 secret: name: secureforward pipelines: - name: container-logs inputRefs: - application outputRefs: - secureforward-offcluster - name: infra-logs inputRefs: - infrastructure outputRefs: - elasticsearch-insecure - name: audit-logs inputRefs: - audit outputRefs: - elasticsearch-secure - default 1
- 1
- 이 파이프라인은 외부 인스턴스와 함께 내부 Elasticsearch 인스턴스로 감사 로그를 보냅니다.
추가 리소스
10.4.3. 로그 보존 시간 구성
기본 Elastic검색 로그 저장소가 인프라 로그, 응용 프로그램 로그 및 감사 로그의 세 가지 로그 원본 각각에 대한 인덱스를 보관하는 기간을 지정하는 보존 정책을 구성할 수 있습니다.
보존 정책을 구성하려면 ClusterLogging
사용자 정의 리소스(CR)에서 각 로그 소스에 대해 maxAge
매개변수를 설정합니다. CR은 Elasticsearch 롤오버 스케줄에 이러한 값을 적용하여 Elasticsearch가 롤오버된 인덱스를 삭제하는 시기를 결정합니다.
인덱스가 다음 조건 중 하나와 일치하면 Elasticsearch는 현재 인덱스를 이동하고 새 인덱스를 생성하여 인덱스를 롤오버합니다.
-
인덱스가
Elasticsearch
h CR의rollover.maxAge
값보다 오래되었습니다. - 인덱스 크기가 40GB × 기본 shard 수보다 큽니다.
- 인덱스 문서 수가 40960KB × 기본 shard 수보다 큽니다.
Elasticsearch는 구성한 보존 정책에 따라 롤오버된 인덱스를 삭제합니다. 로그 소스에 대한 보존 정책을 생성하지 않으면 기본적으로 7일 후에 로그가 삭제됩니다.
사전 요구 사항
- Red Hat OpenShift Logging Operator 및 OpenShift Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
로그 보존 시간을 구성하려면 다음을 수행합니다.
retentionPolicy
매개변수를 추가하거나 수정하려면ClusterLogging
CR을 편집합니다.apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" ... spec: managementState: "Managed" logStore: type: "elasticsearch" retentionPolicy: 1 application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 ...
- 1
- Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 1일은
1d
입니다.maxAge
보다 오래된 로그는 삭제됩니다. 기본적으로 로그는 7일 동안 유지됩니다.
Elasticsearch
사용자 정의 리소스(CR)에서 설정을 확인할 수 있습니다.예를 들어 Red Hat OpenShift Logging Operator가 8시간마다 인프라 로그의 활성 인덱스를 롤오버하는 설정이 포함된 보존 정책을 구성하기 위해 다음
Elasticsearch
CR을 업데이트했고, 롤오버된 인덱스는 롤오버 후 7일이 지나면 삭제됩니다. OpenShift Container Platform은 15분마다 인덱스를 롤오버해야 하는지 확인합니다.apiVersion: "logging.openshift.io/v1" kind: "Elasticsearch" metadata: name: "elasticsearch" spec: ... indexManagement: policies: 1 - name: infra-policy phases: delete: minAge: 7d 2 hot: actions: rollover: maxAge: 8h 3 pollInterval: 15m 4 ...
- 1
- 보존 정책은 각 로그 소스에 대해 해당 소스의 로그를 삭제하고 롤오버할 시기를 나타냅니다.
- 2
- OpenShift Container Platform이 롤오버된 인덱스를 삭제하는 경우 이 설정은
ClusterLogging
CR에서 설정한maxAge
입니다. - 3
- 인덱스를 롤오버할 때 고려해야 할 OpenShift Container Platform의 인덱스 수명입니다. 이 값은
ClusterLogging
CR에서 설정한maxAge
에서 결정됩니다. - 4
- OpenShift Container Platform에서 인덱스를 롤오버해야 하는지 확인하는 경우 이 설정은 기본값이며 변경할 수 없습니다.
참고Elasticsearch
CR 수정은 지원되지 않습니다. 보존 정책에 대한 모든 변경은ClusterLogging
CR에서 수행해야 합니다.OpenShift Elasticsearch Operator는 Cron 작업을 배포하고
pollInterval
로 예약한 정의된 정책에 따라 각 매핑의 인덱스를 갱신합니다.$ oc get cronjob
출력 예
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE elasticsearch-im-app */15 * * * * False 0 <none> 4s elasticsearch-im-audit */15 * * * * False 0 <none> 4s elasticsearch-im-infra */15 * * * * False 0 <none> 4s
10.4.4. 로그 저장소에 대한 CPU 및 메모리 요청 구성
각 구성 요소 사양을 통해 CPU 및 메모리 요청을 조정할 수 있습니다. OpenShift Elasticsearch Operator가 해당 환경에 알맞은 값을 설정하므로 이러한 값을 수동으로 조정할 필요는 없습니다.
대규모 클러스터에서 Elasticsearch 프록시 컨테이너의 기본 메모리 제한으로 충분하지 않을 수 있으므로 프록시 컨테이너가 OOMKilled로 됩니다. 이 문제가 발생하면 Elasticsearch 프록시에 대한 메모리 요청 및 제한을 늘립니다.
각 Elasticsearch 노드는 더 낮은 메모리 설정으로 작동할 수 있지만 프로덕션 배포에는 권장되지 않습니다. 프로덕션 용도의 경우 각 Pod에 기본 16Gi 이상이 할당되어 있어야 합니다. 가급적 Pod당 최대 64Gi를 할당해야 합니다.
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ oc edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch:1 resources: limits: 2 memory: "32Gi" requests: 3 cpu: "1" memory: "16Gi" proxy: 4 resources: limits: memory: 100Mi requests: memory: 100Mi
- 1
- 필요에 따라 Elasticsearch에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시
16Gi
이고 CPU 요청 시1
입니다. - 2
- Pod에서 사용할 수 있는 최대 리소스 양입니다.
- 3
- Pod를 예약하는 데 필요한 최소 리소스입니다.
- 4
- 필요에 따라 Elasticsearch 프록시에 대한 CPU 및 메모리 요청을 지정합니다. 이러한 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값을 설정합니다. 기본값은 메모리 요청 시
256Mi
이고 CPU 요청 시100m
입니다.
Elasticsearch 메모리 양을 조정할 때 요청과
제한
모두에 동일한 값을 사용해야 합니다.
예를 들면 다음과 같습니다.
resources: limits: 1 memory: "32Gi" requests: 2 cpu: "8" memory: "32Gi"
쿠버네티스는 일반적으로 노드 구성을 준수하며 Elasticsearch가 지정된 제한을 사용하도록 허용하지 않습니다. requests
및 limits
에 대해 동일한 값을 설정하면 노드에 사용 가능한 메모리가 있다고 가정하고 Elasticsearch가 원하는 메모리를 사용할 수 있습니다.
10.4.5. 로그 저장소에 대한 복제 정책 구성
Elasticsearch shard가 클러스터의 데이터 노드에 복제되는 방법을 정의할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ oc edit clusterlogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" .... spec: logStore: type: "elasticsearch" elasticsearch: redundancyPolicy: "SingleRedundancy" 1
- 1
- shard에 대한 중복 정책을 지정합니다. 변경 사항을 저장하면 변경 사항이 적용됩니다.
- FullRedundancy. Elasticsearch는 각 인덱스의 기본 shard를 모든 데이터 노드에 완전히 복제합니다. 이 방법은 안전성이 가장 높지만 필요한 디스크 양이 가장 많고 성능이 가장 낮습니다.
- MultipleRedundancy. Elasticsearch는 각 인덱스의 기본 shard를 데이터 노드의 절반으로 완전히 복제합니다. 이 방법은 안전성과 성능 사이의 균형이 우수합니다.
- SingleRedundancy. Elasticsearch는 각 인덱스에 대해 기본 shard의 사본 하나를 만듭니다. 두 개 이상의 데이터 노드가 존재하는 한 항상 로그를 사용할 수 있고 복구할 수 있습니다. 5개 이상의 노드를 사용하는 경우 MultipleRedundancy보다 성능이 향상됩니다. 단일 Elasticsearch 노드 배포에는 이 정책을 적용할 수 없습니다.
- ZeroRedundancy. Elasticsearch는 기본 shard의 사본을 만들지 않습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다. 안전보다 성능이 더 중요하거나 자체 디스크/PVC 백업/복원 전략을 구현한 경우 이 모드를 사용합니다.
인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.
10.4.6. Elasticsearch Pod 축소
클러스터에서 Elasticsearch Pod 수를 줄이면 데이터 손실 또는 Elasticsearch 성능 저하가 발생할 수 있습니다.
축소하는 경우 Pod를 한 번에 하나씩 축소하고 클러스터에서 shard와 복제본의 균형을 다시 조정할 수 있어야 합니다. Elasticsearch 상태가 green
으로 돌아가면 다른 Pod에서 축소할 수 있습니다.
Elasticsearch 클러스터가 ZeroRedundancy
로 설정된 경우 Elasticsearch Pod를 축소해서는 안 됩니다.
10.4.7. 로그 저장소에 대한 영구 스토리지 구성
Elasticsearch에는 영구 스토리지가 필요합니다. 스토리지가 빠를수록 Elasticsearch 성능이 빨라집니다.
Lucene은 NFS가 제공하지 않는 파일 시스템 동작을 사용하므로 Elasticsearch 스토리지에서는 NFS 스토리지를 볼륨 또는 영구 볼륨(또는 Gluster와 같은 NAS를 통해)으로 사용할 수 없습니다. 데이터 손상 및 기타 문제가 발생할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
ClusterLogging
CR을 편집하여 클러스터의 각 데이터 노드가 영구 볼륨 클레임에 바인딩되도록 지정합니다.apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" # ... spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
이 예에서는 클러스터의 각 데이터 노드가 AWS General Purpose SSD(gp2) 스토리지 "200G"를 요청하는 영구 볼륨 클레임에 바인딩되도록 지정합니다.
영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume
개체에서 volumeMode: block
에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.
10.4.8. emptyDir 스토리지에 대한 로그 저장소 구성
emptyDir을 로그 저장소와 함께 사용하면 임시 배포가 생성되고 재시작 시 Pod의 모든 데이터가 손실됩니다.
emptyDir을 사용할 때 로그 스토리지가 다시 시작되거나 재배포되면 데이터가 손실됩니다.
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
emptyDir을 지정하려면
ClusterLogging
CR을 편집합니다.spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
10.4.9. Elasticsearch 롤링 클러스터 재시작 수행
elasticsearch
구성 맵 또는 elasticsearch-*
배포 구성을 변경할 때 롤링 재시작을 수행합니다.
또한 Elasticsearch Pod가 실행되는 노드를 재부팅해야 하는 경우에도 롤링 재시작이 권장됩니다.
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
프로세스
클러스터를 롤링 재시작하려면 다음을 수행합니다.
openshift-loggin
프로젝트로 변경합니다.$ oc project openshift-logging
Elasticsearch pod의 이름을 가져옵니다.
$ oc get pods -l component=elasticsearch
수집기 Pod를 축소하여 Elasticsearch로 새 로그 전송을 중지합니다.
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'
OpenShift Container Platform es_util 툴을 사용하여 shard 동기화 플러시를 수행하여 종료하기 전에 디스크에 쓰기 대기 중인 작업이 없는지 확인하십시오.
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST
예를 들면 다음과 같습니다.
$ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_flush/synced" -XPOST
출력 예
{"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}
OpenShift Container Platform es_util 도구를 사용하여 의도적으로 노드를 중단할 때 shard 밸런싱을 방지합니다.
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
예를 들면 다음과 같습니다.
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
출력 예
{"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":
명령이 완료되면 ES 클러스터의 각 배포에 대해 다음을 수행합니다.
기본적으로 OpenShift Container Platform Elasticsearch 클러스터는 노드에 대한 롤아웃을 차단합니다. 다음 명령을 사용하여 롤아웃을 허용하고 Pod가 변경 사항을 선택하도록 합니다.
$ oc rollout resume deployment/<deployment-name>
예를 들면 다음과 같습니다.
$ oc rollout resume deployment/elasticsearch-cdm-0-1
출력 예
deployment.extensions/elasticsearch-cdm-0-1 resumed
새 Pod가 배포되었습니다. Pod에 컨테이너가 준비되면 다음 배포로 이동할 수 있습니다.
$ oc get pods -l component=elasticsearch-
출력 예
NAME READY STATUS RESTARTS AGE elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7 2/2 Running 0 22h elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr 2/2 Running 0 22h
배포가 완료되면 롤아웃을 허용하지 않도록 Pod를 재설정합니다.
$ oc rollout pause deployment/<deployment-name>
예를 들면 다음과 같습니다.
$ oc rollout pause deployment/elasticsearch-cdm-0-1
출력 예
deployment.extensions/elasticsearch-cdm-0-1 paused
Elasticsearch 클러스터가
green
또는yellow
상태인지 확인하십시오.$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
참고이전 명령에서 사용한 Elasticsearch Pod에서 롤아웃을 수행한 경우 그 Pod는 더 이상 존재하지 않으며 여기에 새 Pod 이름이 필요합니다.
예를 들면 다음과 같습니다.
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
{ "cluster_name" : "elasticsearch", "status" : "yellow", 1 "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 3, "active_primary_shards" : 8, "active_shards" : 16, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 1, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 }
- 1
- 계속하기 전에 이 매개변수 값이
green
또는yellow
인지 확인하십시오.
- Elasticsearch ConfigMap을 변경한 경우 각 Elasticsearch Pod에 대해 이 단계를 반복합니다.
클러스터의 모든 배포가 롤아웃되면 shard 밸런싱을 다시 활성화합니다.
$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
예를 들면 다음과 같습니다.
$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
출력 예
{ "acknowledged" : true, "persistent" : { }, "transient" : { "cluster" : { "routing" : { "allocation" : { "enable" : "all" } } } } }
수집기 Pod를 확장하여 Elasticsearch에 새 로그를 보냅니다.
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'
10.4.10. 로그 저장소 서비스를 경로로 노출
기본적으로 로깅과 함께 배포된 로그 저장소는 로깅 클러스터 외부에서 액세스할 수 없습니다. 데이터에 액세스하는 도구의 로그 저장소 서비스에 대한 외부 액세스를 위해 재암호화 종료로 경로를 활성화할 수 있습니다.
외부에서는 재암호화 경로, OpenShift Container Platform 토큰 및 설치된 로그 저장소 CA 인증서를 생성하여 로그 저장소에 액세스할 수 있습니다. 그런 후 다음을 포함하는 cURL 요청으로 로그 저장소 서비스를 호스팅하는 노드에 액세스합니다.
-
Authorization: Bearer ${token}
- Elasticsearch 재암호화 경로 및 Elasticsearch API 요청
내부에서는 다음 명령 중 하나로 얻을 수 있는 로그 저장소 클러스터 IP를 사용하여 로그 저장소 서비스에 액세스할 수 있습니다.
$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging
출력 예
172.30.183.229
$ oc get service elasticsearch -n openshift-logging
출력 예
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE elasticsearch ClusterIP 172.30.183.229 <none> 9200/TCP 22h
다음과 유사한 명령을 사용하여 클러스터 IP 주소를 확인할 수 있습니다.
$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"
출력 예
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 29 100 29 0 0 108 0 --:--:-- --:--:-- --:--:-- 108
사전 요구 사항
- Red Hat OpenShift Logging 및 Elasticsearch Operator가 설치되어 있어야 합니다.
- 로그에 액세스하려면 프로젝트에 액세스할 수 있어야 합니다.
프로세스
로그 저장소를 외부에 노출하려면 다음을 수행합니다.
openshift-loggin
프로젝트로 변경합니다.$ oc project openshift-logging
로그 저장소에서 CA 인증서를 추출하고 admin-ca 파일에 씁니다.
$ oc extract secret/elasticsearch --to=. --keys=admin-ca
출력 예
admin-ca
로그 저장소 서비스의 경로를 YAML 파일로 생성합니다.
다음을 사용하여 YAML 파일을 생성합니다.
apiVersion: route.openshift.io/v1 kind: Route metadata: name: elasticsearch namespace: openshift-logging spec: host: to: kind: Service name: elasticsearch tls: termination: reencrypt destinationCACertificate: | 1
- 1
- 로그 저장소 CA 인증서를 추가하거나 다음 단계에서 명령을 사용합니다. 일부 재암호화 경로에 필요한
spec.tls.key
,spec.tls.certificate
및spec.tls.caCertificate
매개변수를 설정할 필요는 없습니다.
다음 명령을 실행하여 이전 단계에서 생성한 경로 YAML에 로그 저장소 CA 인증서를 추가합니다.
$ cat ./admin-ca | sed -e "s/^/ /" >> <file-name>.yaml
경로를 생성합니다.
$ oc create -f <file-name>.yaml
출력 예
route.route.openshift.io/elasticsearch created
Elasticsearch 서비스가 노출되어 있는지 확인합니다.
요청에 사용할 이 서비스 계정의 토큰을 가져옵니다.
$ token=$(oc whoami -t)
생성한 elasticsearch 경로를 환경 변수로 설정합니다.
$ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`
경로가 성공적으로 생성되었는지 확인하려면 노출된 경로를 통해 Elasticsearch에 액세스하는 다음 명령을 실행합니다.
curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"
응답은 다음과 유사하게 나타납니다.
출력 예
{ "name" : "elasticsearch-cdm-i40ktba0-1", "cluster_name" : "elasticsearch", "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ", "version" : { "number" : "6.8.1", "build_flavor" : "oss", "build_type" : "zip", "build_hash" : "Unknown", "build_date" : "Unknown", "build_snapshot" : true, "lucene_version" : "7.7.0", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "<tagline>" : "<for search>" }
10.4.11. 기본 Elasticsearch 로그 저장소를 사용하지 않는 경우 사용되지 않은 구성 요소 제거
관리자로서 로그를 타사 로그 저장소로 전달하고 기본 Elasticsearch 로그 저장소를 사용하지 않는 경우 로깅 클러스터에서 사용하지 않는 여러 구성 요소를 제거할 수 있습니다.
즉, 기본 Elasticsearch 로그 저장소를 사용하지 않는 경우 ClusterLogging
사용자 정의 리소스(CR)에서 내부 Elasticsearch logStore
, Kibana visualization
구성 요소를 제거할 수 있습니다. 이러한 구성 요소를 제거하는 것은 선택 사항이지만 리소스를 절약할 수 있습니다.
사전 요구 사항
로그 전달자가 로그 데이터를 기본 내부 Elasticsearch 클러스터로 전송하지 않는지 확인합니다. 로그 전달을 구성하는 데 사용한
ClusterLogForwarder
CR YAML 파일을 검사합니다.default
를 지정하는outputRefs
요소가 없는지 확인합니다. 예를 들면 다음과 같습니다.outputRefs: - default
ClusterLogForwarder
CR은 로그 데이터를 내부 Elasticsearch 클러스터로 전달하고 ClusterLogging
CR에서 logStore
구성 요소를 제거합니다. 이 경우 로그 데이터를 저장할 내부 Elasticsearch 클러스터가 표시되지 않습니다. 이 경우 데이터 손실이 발생할 수 있습니다.
프로세스
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ oc edit ClusterLogging instance
-
ClusterLogging
CR에서logStore
,visualization
스탠자를 제거하십시오. ClusterLogging
CR의collection
스탠자를 유지합니다. 결과는 다음 예와 유사해야 합니다.apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" collection: type: "fluentd" fluentd: {}
수집기 Pod가 재배포되었는지 확인합니다.
$ oc get pods -l component=collector -n openshift-logging