Elastic Stack 및 Docker Compose 시작하기: 제2부

Eddie Mitchell

2023년 10월 13일

Elastic^® Stack 및 Docker Compose 시작하기 제2부에 오신 것을 환영합니다. 제1부 블로그에서는 Docker Compose의 기본 사항과 Elasticsearch^®, Kibana^®, Logstash^®, Metricbeat 및 Filebeat가 포함되는 단일 노드 클러스터를 로컬 놀이터로 설정하는 방법을 살펴보았습니다. 아직 첫 번째 블로그를 읽지 않으셨다면, 제2부를 계속 읽기 전에 먼저 제1부를 읽어보세요.

이 블로그에서는, 이전 클러스터를 기반으로 빌드하며 Fleet, Agent, APM 및 만족스러운 개념 증명(POC)을 위한 데모 애플리케이션과 같은 추가 기능을 구현하겠습니다! 클러스터 크기가 더 크더라도 Docker Compose는 프로덕션에 권장되지 않습니다.

물론, 이미 익숙하고 코딩만 하고 싶다면, TL;DR의 GitHub 리포지토리에 가셔서 파일을 가져오세요.

그럼 시작해 보겠습니다!

Agent, Fleet, APM이라니!

이러한 용어와 제품에 익숙하지 않더라도 걱정하지 마세요! 먼저 몇 분 동안 이러한 기능이 무엇인지, 그리고 이러한 기능이 왜 유용한지 살펴보겠습니다.

이 클러스터의 원래 아키텍처에서는 일부 모니터링 및 파일 수집을 통해 기본 사항에 중점을 두었습니다. 여기에서 그 표현을 보실 수 있습니다.

Elastic Agent: 빠른 개요

Elastic Agent와 함께 제공되는 몇 가지 추가 용어부터 시작하겠습니다.

Elastic Agent는 로그, 메트릭, 기타 데이터 등 다양한 데이터 유형에 대한 호스트 모니터링을 지원하는 통합 방법을 제공합니다. 또한 보안 위협, 운영 체제 데이터 쿼리, 원격 서비스 또는 하드웨어 데이터 전달 등으로부터 보호 기능을 제공합니다. 에이전트는 인프라 전체에 걸쳐 모니터링 배포를 간소화하고 가속화합니다. 각 에이전트는 새로운 데이터 소스, 보안 조치 및 추가 기능에 대한 통합을 결합하기 위해 업데이트할 수 있는 정책과 연결됩니다.

Elastic Integrations는 외부 소스에서 데이터를 빠르고 쉽게 수집하여 인사이트를 얻을 수 있도록 설계되었습니다. 이러한 통합에서는 매트릭, 로그 및 이벤트를 이해하는 데 도움이 되는 미리 빌드된 설정, 대시보드, 시각화 및 파이프라인을 사용하는 경우가 많습니다. 통합 페이지는 로컬 Kibana 인스턴스에서 찾을 수 있으므로 Elastic Agent 및 해당 정책과 함께 통합을 쉽게 찾아보고, 설치하고, 구성할 수 있습니다. 또한 Elastic 웹사이트에서 사용 가능한 통합 목록을 확인하실 수도 있습니다.

정책은 Elastic Agent의 작동 방식을 정의하는 설정 및 통합 모음입니다. 여러 통합을 에이전트 정책에 할당하여 데이터 에이전트가 캡처할 수 있는 데이터를 유연하게 지정할 수 있습니다. Elastic Agent 정책을 여러 에이전트에 할당하면 Fleet을 사용하여 더 큰 규모로 많은 에이전트를 관리하고 구성할 수 있습니다.

Fleet은 Elastic Agent 및 관련 정책을 중앙 집중식으로 관리할 수 있는 Kibana 내의 사용자 인터페이스입니다. 이 사용자 인터페이스를 사용하면 각 에이전트의 상태, 설치된 버전, 마지막 체크인 또는 활동 시간, 정책 정보를 볼 수 있습니다. 각 Elastic Agent와의 통신은 Fleet Server를 통한 Fleet으로 손쉽게 이루어집니다. 이를 통해 체크인 시 새 정책 업데이트를 원격으로 푸시하고 에이전트 바이너리 또는 통합을 업그레이드할 수 있습니다.

Fleet Server는 Fleet과 배포된 모든 Elastic Agent 간의 통신 조정자로 실행되는 Elastic Agent의 인스턴스입니다.

*휴우*

Elastic의 설명서를 살펴보고 Agent 및 Fleet과 관련된 모든 주제에 대해 자세히 알아보세요.

Elastic Agent와 Fleet을 통합하여 정책 관리와 함께 로그 및 메트릭을 수집하는 방법을 시연할 예정입니다. 아키텍처 다이어그램에 추가하여 이것이 어떻게 보일지 살펴보겠습니다.

Elastic APM 및 사용자 정의 웹 앱

Elastic APM은 Elastic Stack을 기반으로 빌드된 애플리케이션 성능 모니터입니다. Elastic APM Agent를 사용하여 코드를 계측하면, APM 사용자 인터페이스의 가시성을 위해 메트릭, 추적, 로그, 오류 및 예외를 수집하고 이를 Elasticsearch로 전송하여 문제 해결 및 성능 질문을 단순화하는 데 도움이 될 수 있습니다.

Elastic APM은 클라우드에서 설정하거나 로컬에서 자체 관리할 수 있습니다. APM의 로컬 인스턴스를 관리할 때, 독립형 APM 서버 바이너리를 관리하거나 Elastic Agent를 통한 통합으로 APM을 활용하도록 선택할 수 있습니다.

로컬 POC의 경우, Elastic Agent 및 Fleet 서비스로 관리되는 Elastic APM을 구현하겠습니다.

애플리케이션 성능 모니터링 기능은 모니터링할 애플리케이션이 없으면 별 소용이 없습니다. 이상적으로는, Elastic의 APM Agent 중 하나를 사용하여 계측하려는 코드가 이미 있습니다. 그렇지 않다면, GitHub 리포지토리에 몇 가지 기본적인 테스트를 수행할 수 있는 작은 Python 애플리케이션이 있습니다.

새로운 아키텍처

아키텍처 다이어그램을 다시 살펴보고 모든 것이 어떻게 제자리에 들어맞는지 살펴보겠습니다.

여기서 새로운 Fleet-Server 컨테이너가 있는 것을 볼 수 있는데, 이 컨테이너에서 Elastic 클러스터와의 모든 에이전트 통신용 중앙 통신 지점 역할을 하는 Elastic Agent가 실행됩니다. Elastic Agent는 맞춤형 웹 애플리케이션과 Kibana 양쪽 모두에서 원격 측정 정보를 수집하기 위해 Elastic APM 통합을 실행하고 있습니다.

통신 및 액세스

일반적으로 Docker를 시작할 때 흔히 겪는 어려움은 어떻게 통신이 작동하는지를 이해하는 것입니다. 언급된 모든 컨테이너, 포트, 인증서 및 URL을 사용하여, 한 걸음 물러서서 서로 다른 부분이 서로 통신해야 할 때 이 새로운 아키텍처가 어떻게 보이는지 살펴보겠습니다.

docker-compose.yml 파일에서 다양한 컨테이너를 위한 인증서를 생성하는 데 사용하는 코드를 확인하실 수 있습니다. 이렇게 보일 것입니다.

echo "Creating certs";
echo -ne \
"instances:\n"\
"  - name: es01\n"\
"    dns:\n"\
"       - es01\n"\
"       - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: kibana\n"\
"    dns:\n"\
"      - kibana\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
"  - name: fleet-server\n"\
"    dns:\n"\
"      - fleet-server\n"\
"      - localhost\n"\
"    ip:\n"\
"      - 127.0.0.1\n"\
> config/certs/instances.yml;

이 코드 블록은 Docker 엔진 내의 DNS 항목과 함께 모든 컨테이너 이름의 목록인 "setup" 컨테이너에 있는 instances.yml이라는 파일을 생성합니다. 우리는 이 파일을 elasticsearch-certutil 유틸리티와 함께 사용하여, 컨테이너가 통신하고 여러분이 컨테이너와 통신할 때 컨테이너 간 통신을 보호하기 위해 각 컨테이너에 대한 인증서를 생성합니다.

모든 컨테이너는 다음과 같이 docker-compose.yml에서 설정한 기본 네트워크를 사용하여 서로 통신합니다.

networks:
  default:
    name: elastic

이 네트워크는 Docker Engine의 내부이며 모든 컨테이너가 서로 통신하고 다른 컨테이너의 이름을 확인할 수 있도록 합니다. 여러분의 브라우저의 트래픽이 컨테이너에 도달할 수 있도록, 우리는 각 서비스에 필요한 포트를 노출합니다. 예를 들면, 다음과 같습니다.

es01:
  depends_on:
    setup:
      condition: service_healthy
  image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
  labels:
    co.elastic.logs/module: elasticsearch
  volumes:
    - certs:/usr/share/elasticsearch/config/certs
    - esdata01:/usr/share/elasticsearch/data
  ports:
    - ${ES_PORT}:9200
  environment:
    - node.name=es01
    - cluster.name=${CLUSTER_NAME}
    - discovery.type=single-node
  ...

구체적으로 “ports:” 섹션을 살펴보겠습니다. 이는 Docker Compose에게 "host:container" 형식으로 지정된 포트를 매핑하도록 지시합니다. 이 예에서, `${ES_PORT}`는 .env 파일의 9200으로 대체되고 이는 여러분의 컴퓨터(호스트)에서 열리게 됩니다. 두 번째 9200은 호스트를 매핑하는 컨테이너의 포트를 나타냅니다. 이런 방식으로, 브라우저에서 https://localhost:9200에 액세스하면 트래픽이 es01 컨테이너로 전송됩니다.

Elasticsearch는 기본적으로 노드 간 통신을 위해 포트 9300도 엽니다. Docker 엔진의 다른 컨테이너는 필요한 경우 해당 포트에 액세스할 수 있지만, 우리가 해당 포트를 노출하지 않았기 때문에 여러분의 호스트에서는 액세스할 수 없게 됩니다.

새 아키텍처를 사용하여 이러한 개념을 시각화하려고 하면, 다음과 같이 보일 수 있습니다.

이 그래픽에서, 'metricbeat01' 컨테이너는 “es01” 및 “logstash01”에 지정한 이름을 확인할 수 있으며 동일한 Docker 네트워크에 있기 때문에 “logstash01”의 노출되지 않은 모니터링 포트 9600에도 액세스할 수 있습니다.

그러나 9200의 Elasticsearch와 5601의 Kibana에 연결하려면, 여러분의 컴퓨터가 트래픽을 Docker 네트워크와 올바른 컨테이너로 라우팅할 수 있도록 “localhost”에 액세스해야 한다는 것을 알 수 있습니다.

마지막으로, 이러한 서비스 중 하나를 참조할 때 사용할 주소를 결정하는 것은 까다로울 수 있습니다. 기억해야 할 핵심 사항은 컨테이너 중 하나가 Elastic 네트워크로 구성된 다른 컨테이너에 액세스할 때 적절한 서비스/컨테이너 이름을 사용한다는 것입니다. 그러나 호스트 시스템에서 발생하는 트래픽이 컨테이너 중 하나에 액세스하는 경우, docker-compose.yml과 localhost를 통한 해당 포트에 대한 액세스에 올바른 포트가 노출되어 있는지 확인해야 합니다.

또한 이러한 구성은 로컬 개발을 시작하는 방법이지만 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.

구현

그럼 이 모든 것을 어떻게 구현할까요?

먼저, 기본 스택을 빠르게 검토하고 파일 구조인 .env 파일 및 docker-compose.yml부터 시작하여 몇 가지 변경 사항을 소개하겠습니다.

파일 구조

파일 구조의 경우, 새로운 kibana.yml과 함께 맞춤형 웹 앱에 대한 모든 코드와 구성을 보관할 “app” 폴더를 추가했습니다. Elastic Agent 및 APM과 관련된 보다 구체적인 설정을 추가할 것이기 때문입니다.

.env

.env 파일(GitHub 링크)은 대부분 변경되지 않은 상태로 유지됩니다. 아래에 표시된 것처럼 Fleet, APM Server 및 APM 비밀 토큰을 위한 새로운 포트는 예외입니다.

비밀 토큰은 나중에 구현 시 APM 서버에 대한 요청을 승인하는 데 사용됩니다. 자세한 내용은 설명서에서 읽어보세요.

# Port to expose Fleet to the host
FLEET_PORT=8220


# Port to expose APM to the host
APMSERVER_PORT=8200


# APM Secret Token for POC environments only
ELASTIC_APM_SECRET_TOKEN=supersecrettoken

이 블로그에 나열된 모든 비밀번호나 키는 데모용이므로 사용자 환경에서 즉시 변경해야 한다는 점을 기억하세요.

docker-compose.yml

docker-compose.yml 파일의 경우, 기본 스택에 몇 가지 추가 항목이 있습니다. 즉, 위에서 언급한 것처럼 추가 볼륨을 추가하고 인증서 생성을 위해 서버 목록에 Fleet-server를 추가하는 것을 포함한 “Fleet Server” 및 “webapp”을 위한 컨테이너입니다.

GitHub에서 전체 파일을 찾아보실 수 있지만, 몇 가지 수정 사항만 다루겠습니다.

환경 변수에 대한 참고사항

기존 서비스에는 인증서가 지정되어 컨테이너 또는 해당 구성 파일에 전달되는 환경 변수가 많이 있습니다.

.env 파일과 마찬가지로 docker-compose.yml의 환경 변수를 사용하면 컨테이너에 변수를 전달할 수 있습니다. 이러한 방식으로, `CA_CERT` 변수를 컨테이너에서 인증서 경로와 동일하게 설정한 다음 metricbeat.yml 파일 내에서 필요할 때마다 해당 변수를 사용할 수 있습니다. 예를 들어, CA_CERT를 업데이트해야 하는 경우, docker-compose.yml에서 경로를 한 번만 업데이트한 다음 metricbeat 컨테이너를 다시 배포하면 됩니다.

metricbeat01 컨테이너와 metricbeat.yml 파일은 `CA_CERT` 환경 변수를 전달하고 이를 yml 파일에서 여러 번 사용하는 좋은 예입니다.

환경 변수 설정 및 사용에 대해 자세히 알아보세요.

docker-compose.yml(‘fleet-server’ 컨테이너)

docker-compose.yml 파일(GitHub 링크)에 `fleet-server` 컨테이너를 추가하면 Elastic Agent 이미지를 가져오는 추가 컨테이너가 시작됩니다. 에이전트 이미지는 엣지 데이터 수집과 Fleet 관리 서버 구성에 사용되는 기본 이미지 양쪽 모두에 사용됩니다.

이것은 로컬 POC이므로 인증서 확인의 엄격한 정도를 줄이기 위해 몇 가지 추가 플래그를 사용하고 있다는 점을 기억하세요. 프로덕션 환경에서는 모든 인증서가 적절하게 발급되고 확인되기를 원할 것입니다.

위에서 언급했듯이 통신을 위해 두 개의 포트를 노출합니다.

ports:
  - ${FLEET_PORT}:8220
  - ${APMSERVER_PORT}:8200

'8220'은 에이전트/장비 통신을 위한 모든 트래픽을 처리합니다.
'8200'은 에이전트가 APM 통합을 수용하므로 APM 서버에서 활용할 모든 트래픽을 처리합니다.

몇 가지 주요 환경 구성은 다음과 같습니다.

참고: 가상 테스트도 구성하고 실행하려면 대신 `docker.elastic.co/beats/elastic-agent-complete:${STACK_VERSION}`의 Docker 이미지를 사용해야 합니다. 이 부분은 다루지 않지만, Elastic 설명서에서 자세한 내용을 읽어보실 수 있습니다.

docker-compose.yml('kibana' 컨테이너)

'kibana' 컨테이너(GitHub 링크)에 두 가지 변경이 필요합니다. 첫 번째는 docker-compose.yml과 ‘volumes’ 섹션의 kibana.yml 파일 사이의 매우 중요한 연결입니다. 이 줄은 Docker에게 로컬 kibana.yml 파일을 활용할 컨테이너에 '바인딩 마운트'하도록 지시합니다.

- ./kibana.yml:/usr/share/kibana/config/kibana.yml:ro

다음으로, 환경 변수 하단에 간단한 변경 사항이 추가되었습니다. 이를 통해 원래 .env 파일에 설정한 APM 비밀 토큰을 전달할 수 있습니다.

- ELASTIC_APM_SECRET_TOKEN=${ELASTIC_APM_SECRET_TOKEN}

kibana.yml

Fleet과 Agent를 통합하기 위해 Kibana를 구성하기 위한 새로운 yml 파일을 추가하고 있습니다(GitHub 링크).

특히, xpack.fleet.packages를 사용하면 패키지가 해당 자산에서 자동으로 가져오도록 지정할 수 있습니다.

xpack.fleet.packages:
  - name: fleet_server
    version: latest
  - name: system
...

xpack.fleet.agentPolicies에서는 초기 Fleet 및 Agent에 사용할 기본 정책 정의를 허용합니다.

xpack.fleet.agentPolicies:
  - name: Fleet-Server-Policy
    id: fleet-server-policy
    namespace: default
    monitoring_enabled: 
      - logs
      - metrics
...

설명서에서 UI 없이 정책을 구성하는 것에 대해 자세히 알아보실 수 있습니다.

또한 Elastic APM 및 관련 APM 패키지 자산을 지원하는 정책을 추가하고 있습니다.

- name: apm-1
        package:
          name: apm
        inputs:
        - type: apm
          enabled: true
          vars:
          - name: host
            value: 0.0.0.0:8200
          - name: secret_token
            value: ${ELASTIC_APM_SECRET_TOKEN}

애플리케이션이 제대로 통신할 수 있도록 서버 URL과 secret_token을 설정합니다.

한 가지 보너스는 telemetry.enabled: "true"입니다. 이를 통해 자체 Kibana 인스턴스에 대해 Elastic APM을 실행하여 APM이 작동하는 방법에 대한 추가 사용을 확인할 수 있습니다.

docker-compose.yml(‘webapp’ 컨테이너)

 webapp:
    build:
      context: app
    volumes:
      - "/var/lib/docker/containers:/var/lib/docker/containers:ro"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "/sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro"
      - "/proc:/hostfs/proc:ro"
      - "/:/hostfs:ro"
    ports:
      - 8000:8000

샘플 웹 앱의 경우, 애플리케이션을 빌드하고 Docker에 배포하는 데 도움이 되는 dockerfile을 사용하고 있습니다.

이 컨테이너 구성은 `context: app` 빌드 명령어에 크게 의존합니다. Docker는 "app"이 폴더이고 해당 폴더 안에 Dockerfile이 있다고 가정합니다. 이러한 속성은 더 구체적일 수 있지만 우리의 목적에 대해서는 기본 가정이 완벽합니다.

Docker Compose는 이 컨테이너를 빌드할 때 “app” 폴더를 읽고 컨테이너에서 사용할 이미지를 빌드하는 방법에 대한 지침을 제공하는 dockerfile을 가져옵니다.

또한 포트 8000을 노출하고 리소스를 모니터링하기 위해 Metribeat에서 사용할 수 있는 것과 유사한 일부 “volumes”를 전달하도록 지정하고 있습니다.

app/dockerfile

# syntax=docker/dockerfile:1


FROM python:3.9-slim-buster


WORKDIR /app


COPY requirements.txt requirements.txt


RUN pip3 install -r requirements.txt


COPY main.py main.py


CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--log-level", "info", "--workers", "1"]

이제 dockerfile은 가져올 기반으로 “python:3.9-slim-buster” 이미지를 사용합니다. 거기에서 /app 폴더를 생성하고 우리 위치에서 requirements.txt 파일을 복사한 다음 pip3을 통해 요건을 설치합니다.

그리고 나서 main.py 애플리케이션을 복사한 다음 main.py에 내장된 Uvicorn 애플리케이션 실행을 시도합니다.

참고: 캐싱 목적으로 dockerfile에서 작업 순서가 중요합니다. docker 파일에서 호출된 파일을 변경하면 캐시가 삭제되고 파일을 새로 가져옵니다. 일반적으로, 가장 자주 변경되는 파일을 dockerfile의 뒷부분에 배치하여 느리거나 변경되지 않는 파일을 빌드 프로세스 동안 캐시된 상태로 유지할 수 있습니다.

app/main.py

main.py 애플리케이션(GitHub)은 FastAPI 및 NiceGUI를 결합한 매우 간단한 애플리케이션입니다. 기본 애플리케이션은 Starlette Elastic APM Agent로 계측되었으며 몇 개의 버튼을 사용하면 APM 환경에서 의도적으로 오류와 메시지를 발생시키는 호출을 할 수 있습니다.

Python:

from elasticapm.contrib.starlette import ElasticAPM, make_apm_client

apm = make_apm_client({
      'SERVICE_NAME': 'my_python_service',
      'SECRET_TOKEN': 'supersecrettoken',
      'SERVER_URL': 'http://fleet-server:8200',
      'ENVIRONMENT': 'development'
  })

app = FastAPI()
app.add_middleware(ElasticAPM, client=apm)

apm.capture_message(f"Custom Message: {message}")

@app.get("/error")
async def throw_error():
    try:
        1 / 0
    except Exception as e:
        apm.capture_exception()
    return {"message": "Failed Successfully :)"}

위는 APM 라이브러리를 가져오고, APM 클라이언트를 생성하고, FastAPI 애플리케이션에 미들웨어를 추가하는 것을 볼 수 있는 코드 스니펫입니다.

이 애플리케이션은 Elastic APM과 상호 작용하는 방법의 샘플로만 사용됩니다.

Docker Compose up

이제 모든 구성이 완료되었으므로 클러스터를 불러오겠습니다!

docker compose up 명령을 실행하면 모든 컨테이너가 표시되고 https://localhost:5601에서 Kibana에 로그인할 수 있습니다. 현재 Kibana에 대한 인증서가 있으므로 HTTPS를 사용해야 합니다. 따라서 브라우저에서 표시하는 인증서 경고를 클릭해야 할 수도 있습니다.
로그인하면 햄버거 메뉴 -> Management(관리) -> Fleet을 통해 Fleet으로 이동할 수 있습니다.

여기서 Agents 메뉴 아래에 단일 Host가 표시됩니다. 이 Fleet 페이지에서는 클러스터에 등록한 모든 Agent를 체크인할 수 있습니다. 또한 정책을 생성 또는 변경하고, 새 Agent를 등록하고, 글로벌 Fleet 구성을 업데이트할 수도 있습니다.

그러나 CPU 및 메모리 사용량 필드는 업데이트되지 않는 것을 볼 수 있습니다. 마찬가지로 Host 링크를 클릭하면 로그도 채워지지 않는 것처럼 보입니다. 추가 조사 결과, Fleet-server 컨테이너 로그에 다음과 유사한 오류가 발견되었습니다.

{"log.level":"info","message":"Attempting to reconnect to backoff(elasticsearch(http://localhost:9200)) with 17 reconnect attempt(s)","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"log.origin":{"file.line":139,"file.name":"pipeline/client_worker.go"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"publisher_pipeline_output","ecs.version":"1.6.0"}
{"log.level":"error","message":"Error dialing dial tcp 127.0.0.1:9200: connect: connection refused","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"esclientleg","log.origin":{"file.line":38,"file.name":"transport/logging.go"},"network":"tcp","address":"localhost:9200","ecs.version":"1.6.0"}

이는 기본적으로 Elastic Agent가 Docker 환경에 적합하지 않은 로컬 Elasticsearch 인스턴스에 데이터를 기록하려고 시도하기 때문입니다.

이 문제를 해결하려면 Fleet -> Settings UI(설정 UI)에서 몇 가지 업데이트를 수행해야 합니다.

한번 살펴보겠습니다.

출력 재구성, 인증서 추가

Fleet -> Settings(설정)로 이동한 후 Outputs(출력) 섹션을 살펴보고 Actions 헤더 아래에 있는 Edit(편집) 버튼을 클릭합니다.

기본 출력을 수정하기 위해 인터페이스 오른쪽에서 슬라이드 아웃이 제공됩니다.

“Elasticsearch CA trusted fingerprint(Elasticsearch CA 신뢰할 수 있는 지문)” 필드와 함께 “Hosts(호스트)” 필드를 변경하고 “Advanced YAML configuration(고급 YAML 구성)” 섹션을 변경하려고 합니다.

그러나 아직 모든 정보가 없습니다. 그럼 터미널로 가서 가져오겠습니다.

먼저 클러스터에서 CA 인증서를 가져와야 합니다. 이는 1부에서 사용한 것과 동일한 명령입니다.

docker cp es-cluster-es01-1:/usr/share/elasticsearch/config/certs/ca/ca.crt /tmp/.

참고: 이 명령은 docker-compose.yml 파일을 실행 중인 디렉터리나 .env 파일에 지정된 COMPOSE_PROJECT_NAME 변수에 따라 다릅니다.

다음으로, 인증서의 지문을 가져와야 합니다. 이를 위해 OpenSSL 명령을 사용할 수 있습니다.

openssl x509 -fingerprint -sha256 -noout -in /tmp/ca.crt | awk -F"=" {' print $2 '} | sed s/://g

이렇게 하면 다음과 유사한 값이 생성됩니다.

5A7464CEABC54FA60CAD3BDF16395E69243B827898F5CCC93E5A38B8F78D5E72

마지막으로, 전체 인증서를 yml 형식으로 가져와야 합니다. `cat` 명령을 사용하거나 텍스트 편집기에서 인증서를 열어 이 작업을 수행할 수 있습니다.

cat /tmp/ca.crt

인증서 텍스트가 있으면 이를 yml 형식에 추가하고 이 모든 정보를 이전의 Fleet Settings 화면에 입력합니다.

“Hosts”에는 “https://es01:9200”을 사용하려고 합니다. 이는 Fleet 서버를 호스팅하는 컨테이너가 es01 컨테이너와 통신하여 데이터를 보내는 방법을 이해하기 때문입니다.

“Elasticsearch CA trusted fingerprint” 필드에 생성된 지문을 입력하세요.

마지막으로 “Advanced YAML configuration”에 인증서 텍스트를 추가합니다. 이는 yml 구성이므로 간격이 올바르게 지정되지 않으면 오류가 발생합니다.

다음으로 시작합니다.

ssl:
certificate_authorities:
- |

그런 다음 인증서 텍스트를 붙여넣고 들여쓰기가 올바른지 확인하세요.

예시:

"Save and Apply Settings(설정 저장 및 적용)" -> "Save and Deploy(저장 및 배포)"를 클릭하는 것을 잊지 마세요.

Elastic Agent 데이터 검토

저장 및 배포가 완료되면 Agent 탭으로 돌아가서 에이전트 이름을 클릭하면 CPU 및 메모리 사용률이 올바르게 표시되고 로그가 채워지는 것을 볼 수 있습니다.

여기에서, View more agent metrics(더 많은 에이전트 메트릭 보기)를 클릭하여 Agent 대시보드로 이동하여 추가 데이터를 볼 수도 있습니다.

Agent 모니터링에 대한 추가 정보에 대한 자세한 내용은 문서를 살펴보세요.

Elastic APM 데이터 검토

햄버거 메뉴 -> Observability -> Overview(개요)로 이동하면 일부 Elastic APM 메트릭도 유입되는 것을 확인할 수 있습니다.

구체적으로 APM -> Services(서비스)로 이동하면 Kibana와 데모 애플리케이션을 모두 볼 수 있습니다.

이를 통해 서비스를 자세히 살펴보고 Elastic APM이 캡처하는 정보 유형을 익힐 수 있습니다.

Elastic Stack으로 원활하게 문제를 해결하고 확장하세요

Elastic Stack 및 Docker Compose 시작하기 시리즈의 제2부에서는 Elastic Agent, Fleet, Elastic APM과 같은 추가 보안 및 기능에 중점을 둡니다. Dockerfile을 통해 사용자 정의 애플리케이션을 추가하는 것도 Elastic APM 구현을 설명하는 데 도움이 됩니다.

이를 통해 훌륭한 로컬 학습 플랫폼에서 기능을 개발하고 테스트할 수 있습니다.

Elastic APM Agent로 애플리케이션을 계측하여 애플리케이션을 모니터링하면 앞으로 애플리케이션을 개선하고 문제를 해결하는 능력이 크게 향상됩니다. Elastic Agent 및 Fleet 서비스를 활용하면 계측을 쉽게 확장할 수 있습니다.

Elastic Agent와 APM을 시연했지만 이 설정을 사용하면 OTel 구성 테스트도 가능하다는 점을 잊지 마세요!

프로덕션에 더욱 적합한 클러스터로 이동할 준비가 되면, Elastic Cloud를 확인하여 여러분이 로컬에서 배우신 것을 수많은 통합을 통해 프로덕션 준비가 완료된 환경으로 원활하게 이전할 수 있는 방법을 찾아보세요.

여기서 논의된 모든 파일은 GitHub에서이용하실 수 있습니다. 질문과 풀 리퀘스트를 환영합니다!

이 포스팅에 설명된 기능의 릴리즈 및 시기는 Elastic의 단독 재량에 따릅니다. 현재 이용할 수 없는 기능은 정시에 또는 전혀 제공되지 않을 수 있습니다.

Elasticsearch Platform

ELK Stack

Observability

Security

Search

산업별

솔루션별