내가 직장 생활에서 자주 겪는 문제는 이미 생산에 들어간 응용 프로그램을 지원하는 것이다.프로덕션에서 서비스를 지원할 때 고객/엔드 유저가 영향을 받기 전에 문제가 발생한 곳과 이를 해결하는 방법을 파악하는 것이 중요합니다.
내가 생산 문제에 대한 통지를 받았을 때, 프로그램 로그는 보통 내가 먼저 검사하는 곳이다.쉬워 보이죠?파일을 열고 단어 '이상' 이나 '오류' 를 찾아서 거슬러 올라갑니다.유일한 문제는 오늘날 환경에서 이러한 고장 제거 방법은 지속가능하지 않다는 것이다. 왜냐하면 서비스는 분산되고 분포되며 응용 프로그램으로 구성될 수 있기 때문이다.
당신은 고장 제거 과정의 복잡화로 인한 인지적 부담을 증가시키지 않고 여러 서비스(즉 마이크로 서비스 체계 구조)를 어떻게 감시할 것입니까?

모니터링 및 쿠베르네트스

여러 가지 모니터링 방법이 있지만 이것은 사용자가 사용하는 플랫폼과 플랫폼(즉 GCP,Azure,AWS)에서 사용할 수 있는 도구에 달려 있지만 Kubernetes 그룹에서 모니터링을 어떻게 하는지 중점적으로 소개하겠습니다.
다행히도, Kubernetes 집단 환경에서 일할 때, 상당히 많은 소스 오픈 프로젝트가 서비스의 관찰성과 모니터링을 도울 수 있다.
사용하기 편리하도록 Linkerd를 사용하겠습니다.Linkedr는 쉽게 설정할 수 있는 서비스 격자입니다.이외에 링크드가 있으면 Prometheus와 Grafana 두 가지 버전을 무료로 받을 수 있습니다!

격자 서비스는 무엇입니까?

Kubernetes 집단의 상하문에서 서비스 격자는 응용 프로그램, 서비스, 사용자 정의 자원의 집합으로 집단의 응용 프로그램에 관찰성, 신축성, 탄력성을 제공한다.Linkerd는 서비스에 대한 API 호출을 에이전트하고 지표를 제공하는 Linkerd Proxy라는 pod sidecar를 사용합니다.이 지표들은 프로메테우스에게 보고될 것이다. 프로메테우스는 지표를 살펴보고 경보를 관리하는 도구이다.프로메테우스는 이러한 지표를 그래프 형태로 시각화해 지표를 쉽게 이해할 수 있도록 하는 지표를 그라파나에게 보고했다.
또한 Grafana는 로그를 Grafana에 제공하여 로그를 비교적 쉽게 검색할 수 있도록 하는 플러그인Loki이 있습니다.
응용 프로그램 메트릭의 프로세스는 다음과 같습니다.

또한 애플리케이션 로그 흐름은 다음과 같습니다.

Linkedr 설정

만약 당신이 Kubernetes 그룹을 모두 설정했다면, Linkerd를 설정하는 것은 비교적 간단할 것입니다.Linkerd는 Linkerd 관리를 단순화하는 명령줄 인터페이스(CLI) 도구를 제공합니다.
다음 CLIthese instructions를 설치합니다.

curl -sL https://run.linkerd.io/install | sh
# Add Linkerd to path
export PATH=$PATH:$HOME/.linkerd2/bin
# Deploy Linkerd to your cluster
linkerd install | kubectl apply -f -

여기서 Linkedr 대시보드에서Grafana에 액세스할 수 있습니다.

# Open a browser window to the linkerd dashboard
linkerd dashboard

Kubernetes 리소스는 배치 또는 네임스페이스에 대한 설명을 통해 Linkerd에 할당할 수 있습니다.

apiVersion: v1
kind: Namespace
metadata:
  linkerd.io/inject: enabled

apiVersion: apps/v1
kind: Deployment
metadata:
  linkerd.io/inject: enabled   

측정 조작원

Logging Operator는 Banzai Cloud에서 만든 프로젝트로 로그 검색을 수행하기 위해 FluentD와 FluentBit에서 지원합니다.
우선 로그 조작부호를 Kubernetes 그룹에 배치합니다.다행히도 키맵이 있어서 배치가 더욱 쉽다.

# Create a logging namespace
apiVersion: v1
kind: Namespace
metadata:
  name: logging

# Add the helm repo
helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
# Install the helm chart
helm upgrade --install --wait --create-namespace --namespace logging logging-operator banzaicloud-stable/logging-operator \
  --set createCustomResource=false"

로키를 배치하다

현재 로그 조작원은 우리의 각종 원본에 로그를 설정했습니다. 로키와Grafana를 설정할 때가 되었습니다.
Grafana 커뮤니티에 헬멧 그림이 만들어졌는데 이것은terraform을 사용하여 Loki 창고를 구축하는 데 도움이 될 것입니다.

resource "helm_release" "rel_logging_loki" {
  repository = "https://grafana.github.io/helm-charts"
  chart = "loki-stack"
  name = "loki"
  namespace = "logging"

  set {
    name = "pomtail.enabled"
    value = "true"
  }
  set {
    name = "loki.enabled"
    value = "true"
  }
}

Linkedr는 Grafana가 Loki와 대화할 수 있도록 업데이트해야 합니다.
설정을 위해, 새로운 Grafana 설정을 링크dr의 Grafana 실례에 수정할 수 있도록 내장된 Kubernetes 유틸리티 kustomize 를 사용합니다.
그라파나.yml

kind: ConfigMap
apiVersion: v1
metadata:
  name: linkerd-grafana-config
data:
  datasources.yaml: |-
    apiVersion: 1
    datasources:
    - name: prometheus
      type: prometheus
      access: proxy
      orgId: 1
      url: http://linkerd-prometheus.linkerd.svc.cluster.local:9090
      isDefault: false
      jsonData:
        timeInterval: "5s"
      version: 1
      editable: true
    - name: Loki
      type: loki
      access: proxy
      editable: false
      default: true
      url: http://loki.logging:3100
      maximumLines: "300"

kustomization을 만듭니다.yml:

resources:
- linkerd.yml
patchesStrategicMerge:
- grafana.yml

현재 Linkerd 설정을 저장하고 실행할 수 있습니다 kubectl kustomize. 이전 Grafana 설정을 Linkerd에 패치할 수 있습니다.

linkerd upgrade > linkerd.yml
kubectl kustomize | kubectl apply -f -

로그 운영자가 Loki로 스트리밍하도록 설정

마지막 단계는 Loki로 스트리밍할 로그 운영자를 설정하는 것입니다.
로그 운영자는 컨테이너를 모니터링하고 대상 대상으로 로그를 전송하는 데 사용할 다음과 같은 사용자 정의 리소스를 지정합니다.

로깅 - 로깅 소스 지정

출력 - 로그 출력의 대상을 지정합니다.클러스터 범위 내에서 Cluster Output

으로 리소스를 구축할 수도 있습니다.

흐름 - 로그 자원을 출력 자원에 연결하고 로그 항목을 분석하는 데 사용할 모드를 지정합니다.이런 자원도 집단 흐름으로 집단 범위 내에서 세울 수 있다.

Loki에 로그를 보낼 ClusterFlow를 지정합니다.

apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
  name: loki-output
  namespace: logging
spec:
  loki:
    url: http://loki:3100
    configure_kubernetes_labels: true
    buffer:
      timekey: 1m
      timekey_wait: 30s
      timekey_use_utc: true

모니터링할 각 Pod/배포에 대해 로깅 및 프로세스를 설정해야 합니다.

# Set up the Logging object
apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: files-logger
  namespace: files
spec:
  fluentd: {}
  fluentbit: {}
  controlNamespace: logging
---
# Set up the Flow object
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: files-flow
  namespace: files
spec:
  globalOutputRefs:
  - logging-index-output
  filters:
    - tag_normaliser: {}
    - parser:
        remove_key_name_field: true
        reserve_data: true
        parse:
          type: multi_format
          patterns:
            - format: regexp
              expression: '/^(?<time>[^\]]*) \[(?<level>[^ ]*)\] (?<source>[^\":]*): (?<message>.*)$/'
              time_key: logtime
              time_format: '%Y-%m-%dT%H:%M:%S.%LZ'
            - format: regexp
              expression: '/^time="(?<time>[^\]]*)" level=(?<level>[^ ]*) msg="(?<message>[^\"]*)"/'
              time_key: time
              time_format: '%Y-%m-%dT%H:%M:%SZ'
            - format: regexp
              expression: '/^level=(?<level>[^ ]*) ts=(?<time>[^\]]*) caller=(?<source>.*) msg="(?<message>[^\"]*)"/'
              time_key: time
              time_format: '%Y-%m-%dT%H:%M:%S.%LZ'
            - format: regexp
              expression: '^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$'
              time_key: time
              time_format: '%d/%b/%Y:%H:%M:%S %z'
  match:
  - select:
      labels:
        app: owncloud

ℹ The Flow object in this example uses FluentD expressions to parse log streams. The FluentD expressions can be evaluated/debugged using Fluentar

globalOutputRefs 부분은 흐르는 자원과 출력을 일치시킨다.출력은 로그 경로를 지정한 목적지로 가져옵니다.match 부분적으로 흐름 자원이 로그를 얻기 위해 어떤 Kubernetes 자원을 찾을지 지시합니다.이 예에서 Flow 리소스는 레이블app: owncloud이 있는 모든 크레인을 찾습니다.
모든 설정이 올바르면 Grafana에서 로그를 검색할 수 있습니다.

뭐가 남았죠?

지금까지 링크dr를 설정하고 로그 흐름을 Grafana로 전송하는 방법을 소개했습니다.이 설정의 개선 사항은 Slack과 PagerDuty 등 제3자 서비스를 통해 알림을 받을 수 있도록 PrometheusAlertManager를 배치하는 것입니다.

도구책

맞춤형 Linkerd 구성 - https://linkerd.io/2/tasks/customize-install/

로그 조작원 빠른 입문 안내서 - 로기 - https://banzaicloud.com/docs/one-eye/logging-operator/quickstarts/loki-nginx/

https://itnext.io/part-4-operations-and-the-cloud-native-stack-in-action-bb17d9f0ff5

지출하다

이 글은 내 가정 실험실에서 약 3개월간의 실험을 진행했다. 나는 최초로 엘라스틱 Stack, EFK Elasticsearch, FluentD, Kibana) 를 사용하여 로그 흐름을 미리 처리하려고 시도했다. Graphana와 Loki가 아니라.
저는 KeyClope을 신분 공급자로 사용하고 Kibana와 오픈 ID 연결(OIDC) 기반 신분 검증을 사용하여 초기 설정을 시도합니다.그러나 OIDC 플러그인은 Elastic의 플래티넘 레이어에서만 사용할 수 있습니다.xpack.security.enabled 설정을 해제하면 유연한 애플리케이션이 손상됩니다.
keycloak-kibana 플러그인을 사용하려고 해도 키바나가 시작할 수 없습니다.
Loki와Grafana가 있으면, 제 서비스에 접근할 수 있도록 OAUTH2 authentication Kubernetes 입구를 설정할 수 있습니다.