メインコンテンツまでスキップ

Customize your dedicated server image at runtime

Last updated on August 18, 2026

注釈:本資料はAI技術を用いて翻訳されています。

概要

AMS Watchdogは、アップロードプロセスを変更することなく、実行時に専用サーバーイメージをカスタマイズする2つのオプション手段をサポートしています。追加のaptパッケージのインストールと、専用サーバー(DS)と並行したコンパニオンプロセスの実行です。どちらも、アップロードするフォルダーのルートに特定のファイルを追加することで有効になります。

実行時に追加のaptパッケージをインストールする

専用サーバービルドが、AMS Watchdogのベースコンテナに含まれていない共有ライブラリ(グラフィックスライブラリやオーディオライブラリなど)に依存している場合があります。これらのライブラリを起動時にコンテナイメージへ追加したい場合は、DSの起動前にWatchdogが自動的にインストールする追加のDebian/Ubuntu(apt)パッケージを指定できます。

そのためには、アップロードするフォルダーのルートに apt-packages.txt という名前のファイルを追加し、1行につき1つのパッケージ名を記載します。空行および # で始まる行は無視されます。

# Graphics libraries needed by our DS
libgl1-mesa-glx
libvulkan1

# Audio support
libopenal1
注記

各パッケージ名は、Debianのパッケージ命名規則(^[a-z0-9][a-z0-9.+\-]*(:[a-z0-9]+)?$)に一致している必要があります。この規則では、libexample:amd64 のようなアーキテクチャ修飾子を任意で付加することもできます。パッケージ名がこのパターンに一致しない場合、またはパッケージのインストールに失敗した場合、DSは起動しません。

Watchdogは、イメージをダウンロードして展開する際に apt-packages.txt の有無を確認します。ファイルが存在する場合は、そのイメージからDSプロセスを起動する前に apt-get update を実行し、続いて記載されたパッケージを apt-get install でインストールします。パッケージは、AMS Watchdogのベースイメージに設定されているデフォルトのDebian/Ubuntuリポジトリからインストールされます。このインストールは、イメージのダウンロード1回につき1度だけ実行されます。たとえばオンデマンドモードのように、キャッシュされた同じイメージから複数のDSプロセスが起動される場合でも、パッケージがインストールされるのは最初の1回のみです。

専用サーバーと並行してコンパニオンプロセスを実行する

専用サーバービルドには、WatchdogがDSと並行して起動し、実行し続けるコンパニオンスクリプトをオプションで含めることができます。たとえば、AMS自体の組み込みモニタリングとは独立して、独自のテレメトリを独自のオブザーバビリティバックエンドに送信するエージェントなどです。

そのためには、アップロードするフォルダーのルートに demon.sh という名前のファイルを追加します。Watchdogはこれをシェルで実行するため、実行可能属性を付与する必要はありません。Watchdogはこれを自動的に起動し、終了した場合はバックオフ遅延を設けて再起動します。このコンパニオンプロセスは、Watchdogとの間でハンドシェイクやプロトコルを実装する必要はありません。Watchdogは、それが実行中かどうかのみを確認します。

注記

このコンパニオンプロセスの状態は、専用サーバーには影響しません。このプロセスが何度終了またはクラッシュしても、DSプロセスは通常どおり起動および実行を続けます。

注記

これは現在、開発フリートではサポートされていません。

利用可能な環境変数

Watchdogは、demon.sh 用に次の環境変数を設定します。

変数説明
DS_LOG_DIR専用サーバーのログファイルを格納するディレクトリ
ARTIFACT_COREDUMPS_PATH設定されている場合、コアダンプアーティファクトを格納するディレクトリ
WD_ID, WD_REGION, WD_FLEET_ID, WD_NAMESPACE現在のWatchdogインスタンスを識別する情報

Watchdogはまた、専用サーバーと共有する基盤のプロセスランナーから継承された PATHDS_ID 変数も設定します。DS_ID の値は demon.sh にとって意味を持たないため、何にも依存すべきではありません。

ノード上ですでに使用されているポート

AMSは、フリートインフラストラクチャの内部モニタリングのために、各Watchdogと並行して独自のオブザーバビリティコレクターを実行しています。これは、ほとんどのオブザーバビリティエージェントが使用するのと同じデフォルトポートをリッスンします。

ポートプロトコル
8125statsd (UDP)
4317OTLP gRPC
4318OTLP HTTP

コンパニオンプロセスのエージェントがデフォルトでこれらのポートのいずれかをリッスンする場合、バインドに失敗します。代わりに、エージェントが別のポート(たとえば、以下の例で使用されている 181251431714318)をリッスンするように設定してください。

注記

これらのポートを変更する場合は、専用サーバー自体のメトリクスおよびトレースのエクスポーターも、同じ非デフォルトポートに向けてください。多くのstatsdおよびOTLPクライアントライブラリは、デフォルトで上記の標準ポートを使用します。コンパニオンプロセスのレシーバーをデフォルトポートから移動した後もDSがデフォルトポートへのエクスポートを続けている場合、コンパニオンプロセスはそのトラフィックを一切受信できません。それにもかかわらず、エラーなく起動してしまいます。

例: DSのログ、メトリクス、トレースをオブザーバビリティエージェントで転送する

demon.sh の一般的な使用方法は、$DS_LOG_DIR を監視(tail)し、専用サーバーのログ、メトリクス、トレースを独自のバックエンドに転送するエージェントを実行することです。以下は、3つの人気エージェントの出発点であり、それぞれログ、メトリクス、トレース、およびノードのホストレベルのメトリクス(CPU、メモリ、ディスク、ネットワーク)をカバーしています。パイプラインや設定は、それぞれの環境に合わせて調整してください。

OpenTelemetry Collector — アップロードに otelcol-contrib バイナリ(プレーンな otelcol ビルドではありません。以下の file_log および statsd レシーバーはcontrib限定です)と設定ファイルを含めます。

otel-config.yaml
receivers:
file_log:
include: ["${env:DS_LOG_DIR}/*.log"]
start_at: beginning
statsd:
endpoint: "0.0.0.0:18125"
aggregation_interval: 60s
otlp:
protocols:
grpc:
endpoint: "0.0.0.0:14317"
http:
endpoint: "0.0.0.0:14318"
host_metrics:
collection_interval: 60s
scrapers:
cpu:
memory:
disk:
filesystem:
load:
network:
exporters:
debug:
verbosity: detailed
processors:
memory_limiter:
check_interval: 1s
limit_percentage: 80
spike_limit_percentage: 15
batch:
send_batch_size: 10000
timeout: 30s
service:
pipelines:
logs:
receivers: [file_log]
processors: [memory_limiter, batch]
exporters: [debug]
metrics:
receivers: [statsd, otlp, host_metrics]
processors: [memory_limiter, batch]
exporters: [debug]
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [debug]
demon.sh
#!/bin/sh
export GOMEMLIMIT=128MiB
exec ./otelcol-contrib --config ./otel-config.yaml
ヒント

GOMEMLIMIT を設定すると、コレクターのGoランタイムのメモリ使用量が制限されます。demon.sh はWatchdogが実行されている間ずっと動作し続けるため、apt-packages.txt がトリガーする一度限りのインストールとは異なり、長時間実行されるGoベースのエージェントであればこの設定を行う価値があります。

Grafana Alloy — アップロードに alloy-linux-amd64 バイナリとRiver設定を含めます。

config.alloy
local.file_match "ds_logs" {
path_targets = [{"__path__" = sys.env("DS_LOG_DIR") + "/*.log"}]
}

loki.source.file "ds_logs" {
targets = local.file_match.ds_logs.targets
forward_to = [loki.write.default.receiver]
}

loki.write "default" {
endpoint {
url = "https://<your-loki-endpoint>/loki/api/v1/push"
}
}

prometheus.exporter.statsd "ds_metrics" {
listen_udp = "0.0.0.0:18125"
}

prometheus.scrape "ds_metrics" {
targets = prometheus.exporter.statsd.ds_metrics.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

prometheus.exporter.unix "host" {
}

prometheus.scrape "host_metrics" {
targets = prometheus.exporter.unix.host.targets
forward_to = [otelcol.receiver.prometheus.default.receiver]
}

otelcol.receiver.prometheus "default" {
output {
metrics = [otelcol.exporter.debug.default.input]
}
}

otelcol.receiver.otlp "ds_traces" {
grpc {
endpoint = "0.0.0.0:14317"
}
http {
endpoint = "0.0.0.0:14318"
}

output {
traces = [otelcol.exporter.debug.default.input]
}
}

otelcol.exporter.debug "default" {
}
demon.sh
#!/bin/sh
exec ./alloy-linux-amd64 run ./config.alloy --stability.level experimental
注記

この設定のメトリクスおよびトレース用のデバッグ出力(otelcol.exporter.debug)は実験的なAlloyコンポーネントであるため、Alloyがこの設定で起動するには --stability.level experimental が必要です。Alloyの loki.write コンポーネントには、ログ用のコンソール/デバッグに相当するものがなく、常に実際のLoki互換エンドポイントに送信します。そのため、上記の url は実際のLokiインスタンスを指すようにして、ログ出力を確認してください。

Vector — アップロードに vector バイナリと設定ファイルを含めます。

vector.yaml
data_dir: "./vector-data"

sources:
ds_logs:
type: file
include:
- "${DS_LOG_DIR}/*.log"
read_from: beginning

ds_metrics:
type: statsd
mode: udp
address: "0.0.0.0:18125"

ds_traces:
type: opentelemetry
grpc:
address: "0.0.0.0:14317"
http:
address: "0.0.0.0:14318"

ds_host_metrics:
type: host_metrics
scrape_interval_secs: 60
collectors: [cpu, memory, disk, filesystem, load, network]

sinks:
console:
type: console
inputs: [ds_logs, ds_metrics, ds_traces.traces, ds_host_metrics]
encoding:
codec: json
demon.sh
#!/bin/sh
mkdir -p vector-data
exec ./vector --config ./vector.yaml
注記

Vectorの data_dir は起動前に存在している必要があります。上記の demon.sh がこれを作成します。