作者：Eddie Mitchell

歡迎閱讀 Elastic? Stack 和 Docker Compose 入門的第二部分。 在第一部分博客中，我們了解了 Docker Compose 的基礎(chǔ)知識(shí)以及如何將單節(jié)點(diǎn)集群建立為本地游樂場(chǎng)，其中包括 Elasticsearch?、Kibana?、Logstash?、Metricbeat 和 Filebeat。 如果你還沒有閱讀第一篇博客，你可能需要跳過去閱讀它，然后再繼續(xù)。

在本博客中，我們將在之前的集群之上進(jìn)行構(gòu)建，并實(shí)現(xiàn)額外的功能，例如艦隊(duì)、代理、APM 和演示應(yīng)用程序，讓你享受 POC 樂趣！ 請(qǐng)記住，即使集群規(guī)模較大，也不建議將 Docker Compose 用于生產(chǎn)。

當(dāng)然，如果你已經(jīng)熟悉并且只想編寫代碼，請(qǐng)隨時(shí)到 GitHub 存儲(chǔ)庫獲取這些文件。

讓我們開始吧！

Agent、Fleet、APM，天哪！

如果你不熟悉這些術(shù)語和產(chǎn)品，請(qǐng)不要擔(dān)心！ 首先，我們花幾分鐘時(shí)間來介紹這些功能是什么以及為什么它們可能對(duì)你有用。

在這個(gè)集群的原始架構(gòu)中，我們專注于一些監(jiān)控和文件攝取的基礎(chǔ)知識(shí)。 在這里你可以看到它的代表。

Elastic Agent：快速概述

讓我們從 Elastic Agent 及其附帶的一些附加術(shù)語開始。

Elastic Agent 提供了一種統(tǒng)一的方式來啟用主機(jī)對(duì)日志、指標(biāo)和其他數(shù)據(jù)等各種數(shù)據(jù)類型的監(jiān)控。 此外，它還提供安全威脅、操作系統(tǒng)數(shù)據(jù)查詢、遠(yuǎn)程服務(wù)或硬件數(shù)據(jù)轉(zhuǎn)發(fā)等保護(hù)。 代理簡(jiǎn)化并加速了整個(gè)基礎(chǔ)設(shè)施的監(jiān)控部署。 每個(gè)代理都與策略相關(guān)聯(lián)，這些策略可以更新以合并新數(shù)據(jù)源、安全措施和附加功能的集成。

Elastic Integrations 旨在讓你能夠快速、輕松地從外部源收集數(shù)據(jù)以獲得洞察。 這些集成通常使用預(yù)構(gòu)建的設(shè)置、儀表板、可視化和管道來幫助理解指標(biāo)、日志和事件。 集成頁面可以在你的本地 Kibana 實(shí)例中找到，從而可以輕松瀏覽、安裝和配置與 Elastic Agent 及其策略的集成。 你還可以在 Elastic 網(wǎng)站上查看可用集成的列表。

Policies (策略)?是定義 Elastic Agent 如何運(yùn)行的設(shè)置和集成的集合。 可以將多個(gè)集成分配給一個(gè)代理策略，從而允許代理能夠靈活地捕獲數(shù)據(jù)。 將 Elastic 代理策略分配給多個(gè)代理允許你使用 Fleet 更大規(guī)模地管理和配置許多代理。

Fleet 是 Kibana 中的用戶界面，允許集中管理 Elastic Agent 和相關(guān)策略。 此用戶界面使你能夠查看每個(gè)代理的運(yùn)行狀況、安裝的版本、上次簽入或活動(dòng)時(shí)間以及策略信息。 Fleet 通過 Fleet Server 促進(jìn)與每個(gè) Elastic 代理的通信。 這允許在簽入時(shí)遠(yuǎn)程推送新的策略更新以及升級(jí)代理二進(jìn)制文件或集成。

Fleet Server 是 Elastic Agent 的一個(gè)實(shí)例，作為 Fleet 與所有已部署的 Elastic Agent 之間通信的協(xié)調(diào)器運(yùn)行。

*哇*

查看 Elastic 的文檔，了解與 Agent 和 Fleet 相關(guān)的所有主題的更多信息。

我們將集成 Elastic Agent 和 Fleet，以演示如何收集日志和指標(biāo)以及管理策略。 讓我們將其添加到架構(gòu)圖中，看看它會(huì)是什么樣子。

Elastic APM 和自定義 Web 應(yīng)用程序

Elastic APM 是基于 Elastic Stack 構(gòu)建的應(yīng)用程序性能監(jiān)視器。 使用 Elastic APM 代理來檢測(cè)你的代碼可以通過收集指標(biāo)、跟蹤、日志、錯(cuò)誤和異常并將其傳送到 Elasticsearch 以便在 APM 用戶界面中查看來幫助簡(jiǎn)化故障排除和性能問題。

Elastic APM 可以在云端設(shè)置，也可以在本地自行管理。 管理 APM 的本地實(shí)例時(shí)，你可以選擇管理獨(dú)立的 APM Server 二進(jìn)制文件或通過 Elastic Agent 將 APM 用作集成。

對(duì)于我們本地的 POC，我們將實(shí)施由 Elastic Agent 和 Fleet 服務(wù)管理的 Elastic APM。

如果你沒有要監(jiān)控的應(yīng)用程序，那么監(jiān)控應(yīng)用程序性能的能力并沒有多大用處。 理想情況下，你已經(jīng)擁有一些想要使用我們的 APM 代理之一進(jìn)行檢測(cè)的代碼。 如果沒有，GitHub 存儲(chǔ)庫有一個(gè)小型 Python 應(yīng)用程序，我們將對(duì)其進(jìn)行一些基本測(cè)試。

新架構(gòu)

讓我們?cè)俅慰匆幌挛覀兊募軜?gòu)圖，看看一切是如何組合到位的。

在這里你可以看到我們有新的 Fleet-Server 容器，它正在運(yùn)行 Elastic Agent，充當(dāng)所有代理與 Elastic 集群通信的中央通信點(diǎn)。 Elastic Agent 正在運(yùn)行 Elastic APM 集成，以便從我們的自定義 Web 應(yīng)用程序和 Kibana 收集遙測(cè)信息。

通訊和訪問

一般來說，開始使用 Docker 時(shí)出現(xiàn)的許多常見挑戰(zhàn)是了解通信的工作原理。 有了前面提到的所有容器、端口、證書和 URL，讓我們退后一步，看看當(dāng)不同部分需要相互通信時(shí)，這種新架構(gòu)會(huì)是什么樣子。

在我們的 docker-compose.yml 文件中，你已經(jīng)看到了我們用來為不同容器生成證書的代碼。 它看起來像這樣：

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;

該代碼塊正在創(chuàng)建一個(gè)名為 instances.yml 的文件，該文件駐留在 “setup” 容器中，該文件是所有容器名稱及其 DNS 條目的列表，因?yàn)樗鼈冊(cè)?Docker 引擎中相互關(guān)聯(lián)。 我們將此文件與 elasticsearch-certutil 實(shí)用程序結(jié)合使用，為每個(gè)容器創(chuàng)建一個(gè)證書，以便在容器通信時(shí)以及你與容器通信時(shí)確保容器之間的通信安全。

我們所有的容器都使用我們?cè)?docker-compose.yml 中設(shè)置的默認(rèn)網(wǎng)絡(luò)相互通信，如下所示：

networks:
  default:
    name: elastic

該網(wǎng)絡(luò)位于 Docker 引擎內(nèi)部，允許所有容器相互通信并解析其他容器的名稱。 為了允許來自瀏覽器的流量到達(dá)容器，我們?cè)诿總€(gè)服務(wù)中公開必要的端口。 例如：

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，并且該文件將在你的計(jì)算機(jī)（主機(jī)）上打開。 第二個(gè) 9200 代表我們將主機(jī)映射到的容器上的端口。 這樣，當(dāng)你從瀏覽器訪問 https://localhost:9200 時(shí)，你的流量將被發(fā)送到 es01 容器。

默認(rèn)情況下，Elasticsearch 也會(huì)打開端口 9300 用于節(jié)點(diǎn)間通信。 雖然 Docker 引擎中的其他容器將能夠在必要時(shí)訪問該端口，但你將無法從主機(jī)訪問該端口，因?yàn)槲覀兩形垂_該端口。

如果我們嘗試使用新架構(gòu)來可視化這些概念，它可能如下所示：

在此圖中，容器 “metricbeat01” 能夠解析我們?yōu)?“es01” 和 “l(fā)ogstash01” 指定的名稱，甚至可以訪問 “l(fā)ogstash01” 上未公開的監(jiān)控端口 9600，因?yàn)樗鼈凂v留在同一 Docker 網(wǎng)絡(luò)中。

但是，我們可以看到，為了讓你訪問 9200 上的 Elasticsearch 和 5601 上的 Kibana，你需要訪問 “l(fā)ocalhost”，以便你的計(jì)算機(jī)可以將流量路由到 Docker 網(wǎng)絡(luò)和正確的容器。

最后，在引用這些服務(wù)之一時(shí)決定使用哪個(gè)地址可能很棘手。 要記住的關(guān)鍵是，當(dāng)你的一個(gè)容器正在訪問已配置 Elastic 網(wǎng)絡(luò)的另一個(gè)容器時(shí)，請(qǐng)使用正確的服務(wù)/容器名稱。 但是，如果來自主機(jī)的流量正在訪問其中一個(gè)容器，那么你將需要驗(yàn)證 docker-compose.yml 中是否公開了正確的端口，并通過 localhost 訪問該端口。

另請(qǐng)注意，這些配置是本地開發(fā)入門的方法，但不建議在生產(chǎn)環(huán)境中使用。

實(shí)施

那么，我們?nèi)绾螌?shí)現(xiàn)這一切呢？

首先，我們將快速回顧一下我們的基礎(chǔ)堆棧，并突出顯示一些更改，從我們的文件結(jié)構(gòu)、.env 文件和 docker-compose.yml 開始

文件結(jié)構(gòu)

對(duì)于我們的文件結(jié)構(gòu)，我們添加了 “app” 文件夾來保存自定義 Web 應(yīng)用程序的所有代碼和配置以及新的 kibana.yml，因?yàn)槲覀儗⑻砑优c Elastic Agent 和 APM 相關(guān)的更多具體設(shè)置。

.env

我們的 .env 文件（GitHub 鏈接）基本保持不變，除了 Fleet、APM 服務(wù)器和 APM 秘密令牌的新端口之外，如下所示。

稍后在我們的實(shí)施中將使用 secret token 來授權(quán)對(duì) APM 服務(wù)器的請(qǐng)求。 你可以在文檔中閱讀有關(guān)它們的更多信息。

# 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

請(qǐng)記住，本博客中列出的任何密碼或密鑰均用于演示目的，應(yīng)立即在你的環(huán)境中進(jìn)行更改。

docker-compose.yml

對(duì)于我們的 docker-compose.yml 文件，我們?cè)诨A(chǔ)堆棧中添加了一些內(nèi)容 - 即 “Fleet Server” 和 “webapp” 的容器，包括添加額外的卷以及將艦隊(duì)服務(wù)器添加到我們的服務(wù)器列表中以生成如上所述的證書 。

你可以在 GitHub 上找到整個(gè)文件，但我們將僅介紹其中的一些編輯內(nèi)容。

關(guān)于環(huán)境變量的說明

現(xiàn)有服務(wù)中有許多環(huán)境變量，其中已指定證書并將其傳遞到容器或其相應(yīng)的配置文件。

與我們的 .env 文件非常相似，docker-compose.yml 中的環(huán)境變量允許我們將變量傳遞給容器。 通過這種方式，我們將變量 “CA_CERT” 設(shè)置為容器上的證書路徑一次，然后在 metricbeat.yml 文件中，我們現(xiàn)在可以在需要的地方使用該變量。 例如，如果我們需要更新 CA_CERT，我們只需要在 docker-compose.yml 中更新一次路徑，然后重新部署 metricbeat 容器。

metricbeat01 容器和 metricbeat.yml 文件是傳遞 “CA_CERT” 環(huán)境變量并在 yml 文件中多次使用它的好示例。

閱讀有關(guān)設(shè)置和使用環(huán)境變量的更多信息。

docker-compose.yml（‘fleet-server’?容器）

將 “fleet-server” 容器添加到 docker-compose.yml 文件（GitHub 鏈接）中會(huì)產(chǎn)生一個(gè)額外的容器來拉取 Elastic Agent 映像。 代理映像用于邊緣數(shù)據(jù)收集，以及用于配置 fleet 管理服務(wù)器的基礎(chǔ)映像。

請(qǐng)記住，我們正在使用一些額外的標(biāo)志來減輕證書檢查的嚴(yán)格程度，因?yàn)檫@是本地 POC。 在生產(chǎn)環(huán)境中，你需要正確頒發(fā)和驗(yàn)證所有證書。

如上所述，我們公開兩個(gè)端口用于通信。

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

• “8220” 處理所有發(fā)往代理/艦隊(duì)通信的流量。
• “8200” 處理 APM 服務(wù)器將使用的所有流量，因?yàn)槲覀兊拇戆?APM 集成。

這里有幾個(gè)關(guān)鍵的環(huán)境配置：

注意：如果你還想配置和運(yùn)行綜合測(cè)試，則需要使用 Docker 鏡像 “docker.elastic.co/beats/elastic-agent-complete:${STACK_VERSION}”。 我們不會(huì)討論這一部分，但你可以在我們的文檔中閱讀更多相關(guān)信息。

docker-compose.yml（‘kibana’ 容器）

“kibana” 容器需要進(jìn)行兩處更改（GitHub 鏈接）。 第一個(gè)是 “volumes” 部分中 docker-compose.yml 和 kibana.yml 文件之間非常重要的連接。 此行告訴 Docker 將本地 kibana.yml 文件 “bind mount” 到容器中以供使用。

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

接下來，在環(huán)境變量的底部添加了一個(gè)簡(jiǎn)單的更改，這允許我們傳遞我們最初在 .env 文件中設(shè)置的 APM 秘密令牌。

- ELASTIC_APM_SECRET_TOKEN=${ELASTIC_APM_SECRET_TOKEN}

kibana.yml

我們添加了一個(gè)新的 yml 文件來配置 Kibana，以便合并 Fleet 和 Agent（GitHub 鏈接）。

值得注意的是，xpack.fleet.packages 允許我們指定包將自動(dòng)提取其資產(chǎn)：

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

而 xpack.fleet.agentPolicies 允許定義用于初始 fleet 和代理的基本策略：

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

你可以在我們的文檔中閱讀有關(guān)在沒有 UI 的情況下配置策略的更多信息。

我們還添加了一項(xiàng)政策來支持 Elastic APM 以及相關(guān)的 APM 包資產(chǎn)：

- 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}

我們?cè)O(shè)置服務(wù)器 URL 和 Secret_token 以確保我們的應(yīng)用程序可以正常通信。

一個(gè)好處是 telemetry.enabled: "true"，它允許我們針對(duì)我們自己的 Kibana 實(shí)例運(yùn)行 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

對(duì)于我們的示例 Web 應(yīng)用程序，我們使用 dockerfile 來幫助我們構(gòu)建應(yīng)用程序并在 Docker 中部署。

此容器配置嚴(yán)重依賴于 “context: app” 構(gòu)建命令。 Docker 假設(shè) “app” 是一個(gè)文件夾，該文件夾內(nèi)是我們的 Dockerfile。 這些屬性可以更具體，但就我們的目的而言，默認(rèn)假設(shè)完全沒問題。

當(dāng) Docker Compose 構(gòu)建此容器時(shí)，它將讀入 “app” 文件夾并獲取 dockerfile 以獲取有關(guān)如何構(gòu)建要在容器中使用的映像的說明。

我們還指定要公開端口 8000，并傳遞一些類似于 Metribeat 可用的 “volumes” 以監(jiān)控資源。

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 現(xiàn)在將使用 “python:3.9-slim-buster” 圖像作為拉取的基礎(chǔ)。 從那里，它將創(chuàng)建 /app 文件夾，從我們的位置復(fù)制 requests.txt 文件，然后通過 pip3 安裝需求。

之后，它將復(fù)制我們的 main.py 應(yīng)用程序，然后嘗試運(yùn)行在 main.py 中構(gòu)建的 Uvicorn 應(yīng)用程序。

注意：出于緩存目的，操作順序在 dockerfile 中很重要。 如果更改 docker 文件中調(diào)用的任何文件，則緩存將被丟棄，并且將發(fā)生新的文件拉取。 通常，你希望將最頻繁更改的文件稍后放置在 dockerfile 中，以便較慢或未更改的文件可以在構(gòu)建過程中保留緩存。

app/main.py

main.py 應(yīng)用程序 (GitHub) 是一個(gè)非常簡(jiǎn)單的應(yīng)用程序，結(jié)合了 FastAPI 和 NiceGUI。 主應(yīng)用程序已使用 Starlette Elastic APM 代理進(jìn)行檢測(cè)，并且有幾個(gè)按鈕允許進(jìn)行調(diào)用，從而有目的地在我們的 APM 環(huán)境中拋出錯(cuò)誤和消息。

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 :)"}

上面是代碼片段，我們可以看到我們正在導(dǎo)入 APM 庫，創(chuàng)建 APM 客戶端，并將中間件添加到 FastAPI 應(yīng)用程序中。

此應(yīng)用程序僅作為如何與 Elastic APM 交互的示例。

Docker Compose up

現(xiàn)在我們已經(jīng)配置好了一切，讓我們啟動(dòng)集群吧！

運(yùn)行命令 docker compose up 將啟動(dòng)所有容器，并允許你通過 https://localhost:5601 登錄 Kibana。 請(qǐng)記住，由于我們現(xiàn)在已經(jīng)為 Kibana 準(zhǔn)備了證書，因此我們必須使用 HTTPS，因此你可能必須單擊瀏覽器向你提供的任何證書警告。登錄后，你可以通過漢堡菜單 -> Management -> Fleet.。

到達(dá)那里后，你將在 “Agents”?菜單下看到一個(gè)主機(jī)。 你可以在此 “Fleet” 頁面中查看已注冊(cè)到集群中的所有代理。 你還可以創(chuàng)建或更改策略、注冊(cè)新代理以及更新任何全局隊(duì)列配置。

但是，你可能會(huì)注意到 CPU 和內(nèi)存使用情況字段并未更新。 同樣，如果你單擊 “Host” 鏈接，日志看起來也沒有被填充。 經(jīng)過進(jìn)一步調(diào)查，我們?cè)?fleet 服務(wù)器容器日志中看到類似于以下內(nèi)容的錯(cuò)誤：

{"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"}

這是因?yàn)?，默認(rèn)情況下，我們的 Elastic Agent 會(huì)嘗試將數(shù)據(jù)記錄到本地 Elasticsearch 實(shí)例，這對(duì)于我們的 Docker 環(huán)境來說是不正確的。

我們需要在 “Fleet” -> “Settings”?UI 中執(zhí)行一些更新才能解決此問題。

讓我們來看看。

重新配置輸出，添加證書

導(dǎo)航到 “fleet” -> “Settings”后，我們要查看 “Output”部分，然后單擊 “Actions” 標(biāo)題下的 “Edit” 按鈕：

這將為我們提供從界面右側(cè)滑出的功能，以便修改默認(rèn)輸出。

我們需要更改 “Hosts” 字段以及 “Elasticsearch CA trusted fingerprint” 字段，以及對(duì) “Advanced YAML configuration” 部分的更改。

但是，我們還沒有所有這些信息。 因此，讓我們跳入終端并獲取它。

首先，我們需要從集群中提取 CA 證書。 這與我們?cè)诘谝徊糠种惺褂玫拿钕嗤?/p>

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

注意：此命令將根據(jù)運(yùn)行 docker-compose.yml 文件的目錄或 .env 文件中指定的 COMPOSE_PROJECT_NAME 變量而有所不同。

接下來，我們需要獲取證書的指紋。 為此，我們可以使用 OpenSSL 命令：

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

這將產(chǎn)生類似于以下的值：

5A7464CEABC54FA60CAD3BDF16395E69243B827898F5CCC93E5A38B8F78D5E72

最后，我們需要將整個(gè)證書轉(zhuǎn)換為 yml 格式。 我們可以使用 “cat” 命令或僅通過在文本編輯器中打開證書來完成此操作：

獲得證書文本后，我們會(huì)將其添加為 yml 格式，并將所有這些信息輸入到之前的 “Fleet Setings” 屏幕中。

對(duì)于 “Hosts”，我們將使用 “https://es01:9200”。 這是因?yàn)橥泄?Fleet 服務(wù)器的容器了解如何與 es01 容器通信以發(fā)送數(shù)據(jù)。

輸入為 “Elasticsearch CA trusted fingerprint.” 字段生成的指紋。

最后，將證書文本添加到 “Advanced YAML configuration.”。 由于這是一個(gè) yml 配置，如果間隔不正確，它將拋出錯(cuò)誤。

從如下位置開始：

ssl:
certificate_authorities:
- |

然后粘貼證書文本，確?？s進(jìn)正確。

例子：

不要忘記單擊 “Save and Apply Settings” -> “Save and Deploy.”。

查看 Elastic Agent 數(shù)據(jù)

保存和部署完成后，返回代理選項(xiàng)卡，單擊代理名稱，你應(yīng)該會(huì)看到 CPU 和內(nèi)存利用率正確顯示，以及正在填充的日志。

從這里，你還可以單擊 “View more agent metrics” 以前往代理儀表板并查看其他數(shù)據(jù)。

查看文檔以獲取有關(guān)監(jiān)控代理的更多信息。

查看 Elastic APM 數(shù)據(jù)

導(dǎo)航至漢堡菜單 -> Observability -> Overview，你將能夠開始看到一些流入的 Elastic APM 指標(biāo)。

具體來說，導(dǎo)航到 APM -> Services，你將能夠看到 Kibana 和我們的演示應(yīng)用程序。

這將使你能夠深入了解服務(wù)并熟悉 Elastic APM 正在捕獲的信息類型。

使用 Elastic Stack 進(jìn)行故障排除和無縫擴(kuò)展

我們的 Elastic Stack 和 Docker Compose 入門系列的第二部分重點(diǎn)介紹了其他安全性和功能，例如 Elastic Agent、Fleet 和 Elastic APM。 通過 Dockerfile 添加自定義應(yīng)用程序也有助于說明 Elastic APM 的實(shí)現(xiàn)。

這提供了一個(gè)很棒的本地學(xué)習(xí)平臺(tái)來開發(fā)和測(cè)試功能。

使用 Elastic APM 代理來檢測(cè)你的應(yīng)用程序以監(jiān)控你的應(yīng)用程序?qū)O大地提高你增強(qiáng)應(yīng)用程序并排除應(yīng)用程序故障的能力。 利用 Elastic Agent 和 Fleet 服務(wù)將允許你輕松擴(kuò)展你的檢測(cè)。

請(qǐng)記住，雖然我們演示了 Elastic Agents 和 APM，但此設(shè)置還允許測(cè)試 OTel 配置！

當(dāng)你準(zhǔn)備好遷移到更適合生產(chǎn)的集群時(shí)，請(qǐng)查看 Elastic Cloud，將你在本地學(xué)到的知識(shí)無縫過渡到具有許多集成的生產(chǎn)就緒環(huán)境。

這里討論的所有文件都可以在 GitHub 上找到。 歡迎提出問題和請(qǐng)求！

本文中描述的任何特性或功能的發(fā)布和時(shí)間安排均由 Elastic 自行決定。 當(dāng)前不可用的任何特性或功能可能無法按時(shí)交付或根本無法交付。文章來源地址http://www.zghlxwxcb.cn/news/detail-724512.html

到了這里，關(guān)于Elastic Stack 和 Docker Compose 入門：第 2 部分的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！