Elastic StackとDocker Composeを使いはじめる：パート2

著者

Eddie Mitchell

2023年10月13日

「Elastic^® StackとDocker Composeを使いはじめる」のパート2にようこそ。パート1のブログでは、Docker Composeの基本と、単一ノードクラスターにElasticsearch^®、Kibana^®、Logstash^®、Metricbeat、Filebeatを含めてローカルのプレイグラウンドとして立ち上げる方法を確認しました。まだ読んでいない場合は、この記事に進む前にお読みください。

このブログでは、前に説明したクラスターに、Fleet、Agent、APM、デモアプリケーションなどの追加機能を実装します。快適なPOC環境を構築しましょう。なお、Docker Composeは、たとえクラスターサイズが大きくても本番環境には推奨されていないことにご注意ください。

もちろん、すでに使い慣れていてコードを知りたいだけの場合は、GitHubレポジトリで手早くファイルを入手できます。

それでは早速始めましょう。

Agentから、Fleet、APMまで

これらの用語や製品に詳しくなくても問題ありません。最初にこれらの機能の内容や、これらが役立つ理由を手短かにご説明します。

このクラスターの元のアーキテクチャーは、監視とファイルインジェスチョンの基本に注目したものでした。それを表現したのがこちらです。

Elastic Agent：簡単な概要

まずはElastic Agentといくつかの関連用語からご紹介します。

Elastic Agentは、ログやメトリックなど、さまざまな種類のデータの一元的なホスト監視を実現します。また、セキュリティ脅威からの保護、オペレーティングシステムデータの照会、リモートサービス、ハードウェアデータ転送などの機能も提供します。Elastic Agentはインフラ全体で監視機能のデプロイを合理化して高速化します。各エージェントはポリシーに関連付けられており、そのポリシーは、新しいデータソース、セキュリティ対策、追加機能の統合を組み込むための更新が可能です。

Elastic統合機能群は、外部ソースからデータを迅速かつ簡単に収集してインサイトを獲得できるように設計されています。多くの場合、これらの統合機能群では、事前構築済みの設定、ダッシュボード、視覚化機能、パイプラインを使用して、メトリックや、ログ、イベントの解釈に役立てることができます。統合のページはローカルのKibanaインスタンス内にあり、Elastic Agentやそのポリシーと組み合わせて統合機能群の参照、インストール、設定を簡単に行うことができます。利用可能な統合のリストはElastic Webサイトでも確認できます。

ポリシーは、Elastic Agentがどのように機能するかを定義する設定と統合の総称です。Elastic Agentポリシーには複数の統合を割り当てることができるため、エージェントで何のデータをキャプチャするかを柔軟に設定できます。Elastic Agentポリシーを複数のエージェントに割り当てると、Fleetを使用して多くのエージェントをさらに大規模に管理および設定できます。

Fleetは、Elastic Agentと関連ポリシーを一元管理するためのKibana内のユーザーインターフェースです。このユーザーインターフェースを使用すると、各エージェントのヘルス、インストールされているバージョン、最新のチェックイン時刻またはアクティビティの時刻、ポリシー情報を確認できます。各Elasticエージェントへの通信は、Fleet Serverを介してFleetで管理されます。これにより、チェックイン時にポリシーの新しい更新をリモートでプッシュしたり、エージェントのバイナリや統合をアップグレードしたりすることができます。

Fleet Serverは、Fleetと、デプロイされたすべてのElasticエージェント間の通信のコーディネーターとして実行される、Elastic Agentのインスタンスです。

*基本的な用語の説明は以上です。*

AgentとFleetに関するすべてのトピックの詳細については、Elasticのドキュメントをご確認ください。

Elastic AgentをFleetと組み合わせてログやメトリックを収集し、ポリシーを管理する方法をご紹介します。アーキテクチャーを示した以下の図をご覧ください。

Elastic APMとカスタムWebアプリ

Elastic APMは、Elastic Stack上に構築されたアプリケーションパフォーマンス監視機能です。Elastic APM Agentを使用してコードをインストルメントすると、メトリック、トレース、ログ、エラー、例外を収集し、それらをElasticsearchに送信してAPMユーザーインターフェースで表示することができ、トラブルシューティングやパフォーマンスに関する疑問を軽減できます。

Elastic APMは、クラウドでも、ローカルでのセルフマネージドでも設定可能です。APMのローカルインスタンスを管理する場合、スタンドアロンのAPM Serverバイナリを管理するか、APMを統合機能としてElastic Agentを通じて使用するかを選択できます。

今回のローカルPOCでは、Elastic AgentとFleetサービスで管理されたEastic APMを使用しています。

監視対象となるアプリケーションがなければ、アプリケーションのパフォーマンスを監視する機能はあまり役に立ちません。いずれかのElastic APM Agentを使用してインストルメントしたいコードがすでにあるのが理想です。まだない場合は、GitHubレポジトリに格納されている小さなPythonアプリケーションを使用して基本的なテストを実行することができます。

新しいアーキテクチャー

再びアーキテクチャー図を見て、配置を確認しましょう。

新しいFleet-Serverコンテナーがあることがわかります。このコンテナーはElastic Agentを実行することで、Elastic AgentをすべてのエージェントとElasticクラスターの中央通信ポイントとして機能させています。Elastic Agentは、カスタムWebアプリケーションと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;

このコードのブロックにより、instances.ymlというファイルが作成されます。このファイルは"setup"コンテナー内に、Docker Engine内のすべてのコンテナー名とそのDNSエントリーのリストとともに配置されます。このファイルを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:"セクションに注目します。これは、"host:container"の形式で指定されたポートをマッピングするようにDocker Composeに指示しています。この例では"${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などがあります。

ファイル構造

Elastic AgentとAPMの両方に、より具体的な設定を追加できるようにするため、ファイル構造に新しいkibana.ymlとともにカスタムWebアプリのすべてのコードと設定を保持するための"app"フォルダーが追加されました。

.env

.envファイル（GitHubリンクはこちら）での変更点はほとんどありません。以下に示すとおり、Fleet、APM Server、APMシークレットトークン用の新しいポートのみが例外的に変更されています。

シークレットトークンは、後で行う実装時にAPM Serverへのリクエストを承認するために使用されます。詳しくは、ドキュメントでご確認ください。

# 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"と"webapp"用のコンテナーに、ボリュームの追加や、前述の証明書生成用サーバーリストへのfleet-serverの追加などが行われました。

ファイルの全容はGitHubで確認できますが、その一部をここで説明します。

環境変数に関する注意

既存のサービスでは、証明書が指定された環境変数がコンテナーまたは対応する設定ファイルに渡される場合もあります。

.envファイルと同様に、docker-compose.ymlの環境変数を使用すると、コンテナーに変数を渡せるようになります。この方法で、コンテナー上で変数"CA_CERT"を証明書パスと同等のものとして一度設定すると、その変数を必要に応じてmetricbeat.ymlファイルのどこでも使用できるようになります。たとえば、CA_CERTを更新する必要がある場合、docker-compose.ymlでパスを1度更新してから、metricbeatコンテナーを再デプロイするだけで済みます。

metricbeat01コンテナーとmetricbeat.ymlファイルは、"CA_CERT"環境変数を渡してymlファイルで複数回使用する好例です。

環境変数の設定と使用について詳しくは、こちらをご覧ください。

docker-compose.yml（"fleet-server"コンテナー）

"fleet-server"コンテナーをdocker-compose.ymlファイル（GitHubリンクはこちら）に追加することで、Elastic Agentのイメージをプルする追加のコンテナが起動します。エージェントのイメージは、エッジデータの収集と、Fleet管理サーバーの設定に使用されるベースイメージの両方に使用されます。

これはローカルPOCであるため、証明書のチェックの厳格さを緩和するために、追加フラグをいくつか使用していることに注意してください。本番環境では、すべての証明書を適切に発行して検証する必要があります。

前述のように、通信用に2つのポートを公開しています。

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

"8220"は、Agent/Fleetの通信宛てのすべてのトラフィックを処理します。
"8200"は、APMサーバーに使用されるすべてのトラフィックを処理します。これはAgentがAPM統合機能を取り込んでいるためです。

主な環境設定の一部をここに示します。

注：シンセティックテストも設定して実行する場合は、代わりに"docker.elastic.co/beats/elastic-agent-complete:${STACK_VERSION}"のDockerイメージを使用する必要があります。これについて本記事では説明しませんが、詳しくはElasticのドキュメントでご確認ください。

docker-compose.yml（"kibana"コンテナー）

"kibana"コンテナーには2点の変更が必要です（GitHubリンクはこちら）。1つ目は"volumes"セクションの、docker-compose.ymlファイルとkibana.ymlファイルの間の非常に重要な接続です。この行は、ローカルのkibana.ymlファイルをDockerに"バインドマウント"して使用するように指示しています。

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

次に、環境変数の一番下に簡単な変更が追加され、もともと.envファイルに設定されていたAPMシークレットトークンを通過できるようになっています。

- ELASTIC_APM_SECRET_TOKEN=${ELASTIC_APM_SECRET_TOKEN}

kibana.yml

新しいymlファイルが追加され、FleetとAgentを含めてKibanaを設定できるようになりました（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のドキュメントでご確認ください。

また、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

ElasticのサンプルWebアプリでは、Dockerを使用したアプリケーションの構築とデプロイを支援するため、dockerfileを使用しています。

このコンテナー設定は、"context: app"ビルドコマンドに大きく依存しています。Dockerでは、"app"がフォルダーであり、そのフォルダー内にDockerfileがあることが前提とされています。これらの属性はより具体的にすることもできますが、今回の目的を考えると、デフォルトの前提のままでまったく問題ありません。

Docker Composeは、このコンテナーをビルドする際、"app"フォルダーを読み取り、コンテナーで使用されるイメージをビルドする方法の指示が記述されたdockerfileを取得します。

また、ポート8000を公開するように指定し、Metribeatでリソースの監視に使用されているものと類似するいくつかの"ボリューム"を渡します。

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を組み合わせた非常にシンプルなアプリケーションです。mainアプリケーションは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］（エージェント）メニューの下に1つのホストが表示されます。［Fleet］ページでは、クラスターに登録したすべてのエージェントを詳しく確認できます。また、ポリシーを作成または変更したり、新しいエージェントを登録したり、グローバル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がデフォルトでローカルのElasticsearchインスタンスにデータをロギングしようと試みていたことが原因であり、Docker環境としては正しい状態ではありません。

これ解決するには、［Fleet］ > ［Settings］（設定）のUIで、いくつかの更新を行う必要があります。

では、見てみましょう。

出力の再構成と証明書の追加

［Fleet］ > ［Settings］（設定）に移動したら、［Outputs］（出力）セクションを確認して、［Actions］（アクション）ヘッダーの下にある［Edit］（編集）ボタンをクリックします。

これにより、インターフェースの右側からスライドアウトが表示され、デフォルトの出力を変更できるようになります。

［Hosts］（ホスト）フィールドと［Elasticsearch CA trusted fingerprint］（Elasticsearch CAの信頼されたフィンガープリント）フィールドを変更し、［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設定画面に入力します。

［Hosts］（ホスト）には「https://es01:9200」と入力します。Fleetサーバーをホストするコンテナーが、es01コンテナーと通信してデータを送信するしくみを理解しているためです。

［Elasticsearch CA trusted fingerprint］（Elasticsearch CAの信頼されたフィンガープリント）フィールドに、生成されたフィンガープリントを入力します。

最後に、［Advanced YAML configuration］（高度なYAML設定）に証明書のテキストを追加します。これはyml設定であるため、スペースが正しく使用されていないとエラーがスローされます。

冒頭は以下のようになります。

ssl:
certificate_authorities:
- |

次に、証明書のテキストをペーストします。インデントが正しいことを確認してください。

例：

［Save and Apply Settings］（設定を保存して適用） > ［Save and Deploy］（保存してデプロイ）を必ずクリックしてください。

Elastic Agentデータの確認

保存とデプロイが完了した後、エージェントタブに戻り、エージェント名をクリックすると、CPUとメモリーの使用率が適切に表示され、ログも作成されていることを確認できます。

ここから、［View more agent metrics］（エージェントメトリックをさらに表示）をクリックしてエージェントダッシュボードに移動し、追加のデータを確認することもできます。

Agentの監視に関する情報について詳しくは、ドキュメントを確認してください。

Elastic APMデータの確認

ハンバーガーメニュー > ［Observability］（オブザーバビリティ） > ［Overview］（概要）に移動すると、流入してくるElastic APMメトリックの一部も確認できるようになります。

特に、［APM］ > ［Services］（サービス）に移動すると、Kibanaとデモアプリケーションの両方を確認できます。

これで、サービスをドリルダウンして、Elastic APMがキャプチャしている情報の種類を理解できるようになります。

Elastic Stackによるトラブルシューティングとシームレスな拡張

「Elastic StackとDocker Composeを使いはじめる」シリーズのパート2では、さらなるセキュリティと、Elastic Agent、Fleet、Elastic APMなどの機能に注目しました。Elastic APMの実装時にも、Dockerfileを介したカスタムアプリケーションの追加が行われます。

こうすることで、機能の開発とテストのためのローカル学習プラットフォームが実現します。

Elastic APM Agentを組み込んでアプリケーションを監視すれば、今後のアプリケーションの機能強化とトラブルシューティングが大幅にしやすくなります。Elastic AgentとFleetサービスを使用することで、インストルメンテーションを簡単に拡張できるようになるのです。

今回実施したのはElastic AgentとElastic APMでしたが、この設定はOTelの設定にも役立つことを覚えておいてください。

より本番環境に対応したクラスターへ移行する準備ができたら、Elastic Cloudの機能を確認して、多くの統合を備えた本番環境にローカルで学習した内容をシームレスに移行する方法を確認してください。

本記事で説明したすべてのファイルはGitHubで入手できます。質問やプルリクエストもお気軽にどうぞ。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

検索AI企業

生成AI

検索

セキュリティ

オブザーバビリティ

ソリューション別

業界

Elastic StackとDocker Composeを使いはじめる：パート2

Agentから、Fleet、APMまで

Elastic Agent：簡単な概要

Elastic APMとカスタムWebアプリ

新しいアーキテクチャー

通信とアクセス

実装

ファイル構造

.env

docker-compose.yml

docker-compose.yml（"fleet-server"コンテナー）

docker-compose.yml（"kibana"コンテナー）

kibana.yml

docker-compose.yml（"webapp"コンテナー）

app/dockerfile

app/main.py

Docker Compose up

出力の再構成と証明書の追加

Elastic Agentデータの確認

Elastic APMデータの確認

Elastic Stackによるトラブルシューティングとシームレスな拡張

シェアする

Elastic Cloudの無料トライアルに登録

SNSリンク

会社概要

参加する

パートナー

信頼とセキュリティ

投資家向け情報

Excellence Awards