1.3. Logging 6.0으로 업그레이드

로깅 v6.0은 이전 릴리스에서 중요한 업그레이드로, 클러스터 로깅의 여러 장기 목표를 달성합니다.

로깅 구성 요소(예: 수집기, 스토리지, 시각화)를 관리하기 위한 별도의 운영자 소개.
Elastic 제품(예: Elasticsearch, Kibana)을 기반으로 관리형 로그 스토리지 및 시각화에 대한 지원 제거
Fluentd 로그 수집기 구현의 사용 중단
ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io 리소스에 대한 지원 제거

참고

cluster-logging-operator 는 자동 업그레이드 프로세스를 제공하지 않습니다.

로그 수집, 전달 및 스토리지에 대한 다양한 구성이 제공되어 cluster-logging-operator 에서 자동 업그레이드가 제공되지 않습니다. 이 문서는 관리자가 기존 ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io 사양을 새 API로 변환하는 데 도움이 됩니다. 일반적인 사용 사례에 대한 마이그레이션된 ClusterLogForwarder.observability.openshift.io 리소스의 예가 포함되어 있습니다.

1.3.1. `oc explain` 명령 사용

oc explain 명령은 OpenShift CLI oc 의 사용자 정의 리소스(CR) 내의 필드에 대한 자세한 설명을 제공하는 필수 툴입니다. 이 명령은 OpenShift 클러스터에서 리소스를 구성하거나 문제를 해결하는 관리자 및 개발자에게 매우 중요합니다.

1.3.1.1. 리소스 설명

oc explain 은 특정 오브젝트와 관련된 모든 필드에 대한 심층적인 설명을 제공합니다. 여기에는 Pod 및 서비스와 같은 표준 리소스뿐만 아니라 상태 저장 세트 및 Operator에서 정의한 사용자 정의 리소스와 같은 더 복잡한 엔티티가 포함됩니다.

ClusterLogForwarder 사용자 정의 리소스의 outputs 필드에 대한 문서를 보려면 다음을 사용합니다.

$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs

참고

clusterlogforwarder 대신 단축 형식을 사용할 수 있습니다.

그러면 유형, 기본값 및 관련 하위 필드를 포함하여 이러한 필드에 대한 자세한 정보가 표시됩니다.

1.3.1.2. 계층 구조 구조

명령은 리소스 필드의 구조를 계층 구조로 표시하여 다양한 구성 옵션 간의 관계를 명확히 합니다.

예를 들어 LokiStack 사용자 정의 리소스의 스토리지 구성을 드릴다운하는 방법은 다음과 같습니다.

$ oc explain lokistacks.loki.grafana.com
$ oc explain lokistacks.loki.grafana.com.spec
$ oc explain lokistacks.loki.grafana.com.spec.storage
$ oc explain lokistacks.loki.grafana.com.spec.storage.schemas

각 명령은 리소스 사양의 깊은 수준을 표시하여 구조를 지웁니다.

1.3.1.3. 유형 정보

oc explain 은 각 필드의 유형(예: 문자열, 정수 또는 부울)을 나타내며 리소스 정의가 올바른 데이터 유형을 사용하는지 확인할 수 있습니다.

예를 들면 다음과 같습니다.

$ oc explain lokistacks.loki.grafana.com.spec.size

이 경우 정수 값을 사용하여 크기를 정의해야 합니다.

1.3.1.4. 기본값

해당하는 경우 명령은 필드의 기본값을 표시하여 명시적으로 지정되지 않은 경우 사용할 값에 대한 통찰력을 제공합니다.

lokistacks.loki.grafana.com 을 예제로 다시 사용합니다.

$ oc explain lokistacks.spec.template.distributor.replicas

출력 예

GROUP:      loki.grafana.com
KIND:       LokiStack
VERSION:    v1

FIELD: replicas <integer>

DESCRIPTION:
    Replicas defines the number of replica pods of the component.

1.3.2. 로그 스토리지

이 릴리스에서 사용할 수 있는 유일한 관리형 로그 스토리지 솔루션은 loki-operator 에서 관리하는 Lokistack입니다. 이전에 관리형 Elasticsearch 오퍼링의 대안으로 사용 가능한 이 솔루션은 배포 프로세스에서 변경되지 않은 상태로 유지됩니다.

중요

elasticsearch-operator 에서 제공하는 기존 Red Hat 관리 Elasticsearch 또는 Kibana 배포를 계속 사용하려면 동일한 네임스페이스에서 ClusterLogging이라는 ClusterLogging 리소스를 제거하기 전에 elasticsearch elasticsearch 라는 Elasticsearch 리소스와 openshift-logging 네임스페이스의 kibana 라는 Kibana 리소스를 제거합니다.

임시로 ClusterLogging 을 Unmanaged상태로 설정

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge

Elasticsearch 리소스에서 ClusterLogging ownerReferences 제거
다음 명령은 ClusterLogging 이 더 이상 Elasticsearch 리소스를 소유하지 않도록 합니다. ClusterLogging 리소스의 logStore 필드에 대한 업데이트는 더 이상 Elasticsearch 리소스에 영향을 미치지 않습니다.
```
$ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
Kibana 리소스에서 ClusterLogging ownerReferences 제거
다음 명령은 ClusterLogging 이 더 이상 Kibana 리소스를 소유하지 않도록 합니다. ClusterLogging 리소스의 시각화 필드에 대한 업데이트는 더 이상 Kibana 리소스에 영향을 미치지 않습니다.
```
$ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
ClusterLogging 을 state Managed로 설정

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge

1.3.3. 로그 시각화

로그 시각화를 위한 OpenShift 콘솔 UI 플러그인이 cluster-logging-operator 에서 cluster-observability-operator 로 이동되었습니다.

1.3.4. 로그 수집 및 전달

이제 observability.openshift.io API 그룹의 일부인 새 API 아래에 로그 수집 및 전달 구성이 지정됩니다. 다음 섹션에서는 이전 API 리소스의 차이점을 설명합니다.

참고

벡터는 지원되는 유일한 수집기 구현입니다.

1.3.5. 관리, 리소스 할당 및 워크로드 스케줄링

관리 상태(예: Managed, Unmanaged)에 대한 구성(예: Managed, Unmanaged), 리소스 요청 및 제한, 허용 오차 및 노드 선택이 이제 새 ClusterLogForwarder API의 일부입니다.

이전 설정

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
  managementState: "Managed"
  collection:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

현재 설정

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  managementState: Managed
  collector:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

1.3.6. 입력 사양

입력 사양은 ClusterLogForwarder 사양의 선택적 부분입니다. 관리자는 계속해서 애플리케이션,인프라 및 감사 의 사전 정의된 값을 사용하여 이러한 소스를 수집할 수 있습니다.

1.3.6.1. 애플리케이션 입력

네임스페이스 및 컨테이너 포함 및 제외가 단일 필드에 통합되었습니다.

5.9 네임스페이스 및 컨테이너가 포함된 애플리케이션 입력 및 제외

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       namespaces:
       - foo
       - bar
       includes:
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

6.0 애플리케이션 입력 네임스페이스 및 컨테이너 포함 및 제외

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       includes:
       - namespace: foo
       - namespace: bar
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

참고

애플리케이션,인프라, 감사 는 예약된 단어로, 입력을 정의할 때 이름으로 사용할 수 없습니다.

1.3.6.2. 입력 수신자

입력 수신자에 대한 변경 사항은 다음과 같습니다.

수신기 수준에서 유형의 명시적 구성입니다.
포트 설정이 수신자 수준으로 이동했습니다.

5.9 입력 수신자

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    receiver:
      http:
        port: 8443
        format: kubeAPIAudit
  - name: a-syslog
    receiver:
      type: syslog
      syslog:
        port: 9442

6.0 입력 수신자

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    type: receiver
    receiver:
      type: http
      port: 8443
      http:
        format: kubeAPIAudit
  - name: a-syslog
    type: receiver
    receiver:
      type: syslog
      port: 9442

1.3.7. 출력 사양

출력 사양에 대한 높은 수준의 변경 사항은 다음과 같습니다.

URL 설정은 각 출력 유형 사양으로 이동했습니다.
튜닝 매개변수는 각 출력 유형 사양으로 이동했습니다.
TLS 구성을 인증과 분리합니다.
TLS 및 인증을 위한 키 및 시크릿/구성 맵에 대한 명시적 구성입니다.

1.3.8. 보안 및 TLS 구성

보안 및 TLS 구성은 각 출력에 대한 인증 및 TLS 구성으로 구분됩니다. 관리자가 인식된 키로 시크릿을 정의하는 대신 사양에 명시적으로 정의해야 합니다. TLS 및 권한 부여 구성을 업그레이드하려면 관리자가 기존 보안을 계속 사용하려면 이전에 인식된 키를 이해해야 합니다. 다음 섹션의 예제에서는 기존 Red Hat 관리 로그 스토리지 솔루션으로 전달하도록 ClusterLogForwarder 시크릿을 구성하는 방법에 대한 세부 정보를 제공합니다.

1.3.9. Red Hat Managed Elasticsearch

v5.9 Red Hat Managed Elasticsearch로 전달

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: elasticsearch

v6.0, Red Hat Managed Elasticsearch로 전달

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-elasticsearch
    type: elasticsearch
    elasticsearch:
      url: https://elasticsearch:9200
      version: 6
      index: <log_type>-write-{+yyyy.MM.dd}
    tls:
      ca:
        key: ca-bundle.crt
        secretName: collector
      certificate:
        key: tls.crt
        secretName: collector
      key:
        key: tls.key
        secretName: collector
  pipelines:
  - outputRefs:
    - default-elasticsearch
  - inputRefs:
    - application
    - infrastructure

참고

이 예에서는 애플리케이션 로그가 app-write 대신 application-write alias/index에 기록됩니다.

1.3.10. Red Hat Managed LokiStack

v5.9 Red Hat Managed LokiStack으로 전달

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: lokistack
    lokistack:
      name: lokistack-dev

v6.0, Red Hat Managed LokiStack으로 전달

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: lokistack-dev
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - outputRefs:
    - default-lokistack
  - inputRefs:
    - application
    - infrastructure

1.3.11. 필터 및 파이프라인 구성

이제 파이프라인 구성이 필요한 변환을 필터로 별도로 구성하여 출력 대상에 대한 입력 소스의 라우팅만 정의합니다. 이전 릴리스의 파이프라인의 모든 속성이 이 릴리스의 필터로 변환되었습니다. 개별 필터는 필터 사양에 정의되어 파이프라인에서 참조합니다.

5.9 필터

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
spec:
  pipelines:
   - name: application-logs
     parse: json
     labels:
       foo: bar
     detectMultilineErrors: true

6.0 필터 설정

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
spec:
  filters:
  - name: detectexception
    type: detectMultilineException
  - name: parse-json
    type: parse
  - name: labels
    type: openshiftLabels
    openshiftLabels:
      foo: bar
  pipelines:
  - name: application-logs
    filterRefs:
    - detectexception
    - labels
    - parse-json

1.3.12. 검증 및 상태

대부분의 검증은 리소스가 생성 또는 업데이트되어 즉각적인 피드백을 제공할 때 적용됩니다. 이는 이전 릴리스의 전환으로, 유효성 검사가 생성 후 수행되었으며 리소스 상태를 검사해야 합니다. 일부 검증은 생성 또는 업데이트 시 유효성을 검사할 수 없는 경우 생성 후 계속 수행됩니다.

ClusterLogForwarder.observability.openshift.io 의 인스턴스는 Operator가 로그 수집기를 배포하기 전에 다음과 같은 조건을 충족해야 합니다: Authorized, Valid, Ready. 이러한 조건의 예는 다음과 같습니다.

6.0 상태 조건

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
status:
  conditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: 'permitted to collect log types: [application]'
    reason: ClusterRolesExist
    status: "True"
    type: observability.openshift.io/Authorized
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/Valid
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ReconciliationComplete
    status: "True"
    type: Ready
  filterConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "detectexception" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-detectexception
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "parse-json" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-parse-json
  inputConditions:
  - lastTransitionTime: "2024-09-13T12:23:03Z"
    message: input "application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidInput-application1
  outputConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: output "default-lokistack-application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidOutput-default-lokistack-application1
  pipelineConditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: pipeline "default-before" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidPipeline-default-before

참고

충족되고 적용 가능한 조건은 "True"의 "상태" 값이 있습니다. "True" 이외의 상태가 있는 조건은 이유 및 문제를 설명하는 메시지를 제공합니다.

1.3. Logging 6.0으로 업그레이드

1.3.1. `oc explain` 명령 사용

1.3.1.1. 리소스 설명

1.3.1.2. 계층 구조 구조

1.3.1.3. 유형 정보

1.3.1.4. 기본값

1.3.2. 로그 스토리지

1.3.3. 로그 시각화

1.3.4. 로그 수집 및 전달

1.3.5. 관리, 리소스 할당 및 워크로드 스케줄링

1.3.6. 입력 사양

1.3.6.1. 애플리케이션 입력

1.3.6.2. 입력 수신자

1.3.7. 출력 사양

1.3.8. 보안 및 TLS 구성

1.3.9. Red Hat Managed Elasticsearch

1.3.10. Red Hat Managed LokiStack

1.3.11. 필터 및 파이프라인 구성

1.3.12. 검증 및 상태

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links

1.3. Logging 6.0으로 업그레이드

1.3.1. oc explain 명령 사용

1.3.1.1. 리소스 설명

1.3.1.2. 계층 구조 구조

1.3.1.3. 유형 정보

1.3.1.4. 기본값

1.3.2. 로그 스토리지

1.3.3. 로그 시각화

1.3.4. 로그 수집 및 전달

1.3.5. 관리, 리소스 할당 및 워크로드 스케줄링

1.3.6. 입력 사양

1.3.6.1. 애플리케이션 입력

1.3.6.2. 입력 수신자

1.3.7. 출력 사양

1.3.8. 보안 및 TLS 구성

1.3.9. Red Hat Managed Elasticsearch

1.3.10. Red Hat Managed LokiStack

1.3.11. 필터 및 파이프라인 구성

1.3.12. 검증 및 상태

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links

1.3.1. `oc explain` 명령 사용