モニタリングスイートチュートリアル

[更新: 2026年7月23日]

このチュートリアルでは、さくらのクラウド上に作成したサーバへ nginx と sacloud-otel-collector をインストールし、サーバメトリクスおよび nginx のアクセスログをモニタリングスイートへ送信します。

構築後は、モニタリングスイートで以下を行えるようになります。

nginx のアクセスログの検索・分析
CPU、メモリ、ディスクなどのサーバメトリクスの可視化
メトリクスに基づくアラートルールの設定
異常発生時のメール通知の受信

前提条件 

事前にさくらのクラウド会員IDの登録やプロジェクトの作成など、さくらのクラウドの利用準備が完了していること。
さくらのクラウドの利用開始方法は「さくらのクラウド ご利用開始手順」をご確認ください。

本手順は以下のバージョンのソフトウェアを利用して検証しています。

項目	バージョン
OS	Ubuntu Server 26.04 LTS 64bit
sacloud-otel-collector	0.7.0
nginx	1.28.3 (Ubuntu)

手順1 さくらのクラウドのサーバの作成 

さくらのクラウドでサーバを作成します。サーバの作成手順については、「サーバの作成・削除」をご確認ください。

nginx のアクセスログを利用するため、サーバ作成後に nginx をインストールします。

$ sudo apt install nginx -y

手順2 ログストレージ・メトリクスストレージの作成 

コントロールパネルから、ログとメトリクスの保存先となるモニタリングスイートのストレージを作成します。

手順2-1 ログストレージ・アクセスキーの作成 

左側メニュー「モニタリングスイート」カテゴリ内にある「ログストレージ」を選択します。作成済みのログストレージがある場合は一覧表示されます。

初めてご利用の場合は「一括作成」をクリックします。

一括作成の操作により、「ユーザ領域」「システム領域」のログストレージが1つずつ作成されます。ユーザ領域には、お客様が設定した任意のログが蓄積されます。システム領域には、さくらのクラウドの各サービスから自動で連携されるログが蓄積されます。本チュートリアルではユーザ領域のログストレージを利用します。

新しいログストレージを作成する場合は右上の「追加」をクリックし、任意の名前を入力してユーザ領域のログストレージを作成します。

エージェントからログストレージにログを書き込むには、事前にアクセスキーを作成しておく必要があります。作成したユーザ領域のログストレージをクリックし、詳細画面を表示します。

「アクセスキー」タブから「追加」をクリックし、新規アクセスキーを追加します。

アクセスキーを追加すると、アクセスキーの一覧に追加したアクセスキーが表示されます。

作成したアクセスキーをクリックし、詳細画面を表示します。詳細画面で表示されるエンドポイントや認証情報は後の手順で利用します。

手順2-2 メトリクスストレージ・アクセスキーの作成 

左側メニュー「モニタリングスイート」カテゴリ内にある「メトリクスストレージ」を選択します。作成済みのメトリクスストレージがある場合は一覧表示されます。

初めてご利用の場合は「一括作成」をクリックします。

一括作成の操作により、「ユーザ領域」「システム領域」のメトリクスストレージが1つずつ作成されます。ユーザ領域には、お客様が設定した任意のメトリクスが蓄積されます。システム領域には、さくらのクラウドの各サービスから自動で連携されるメトリクスが蓄積されます。本チュートリアルではユーザ領域のメトリクスストレージを利用します。

新しいメトリクスストレージを作成する場合は右上の「追加」をクリックし、任意の名前を入力してユーザ領域のメトリクスストレージを作成します。

エージェントからメトリクスストレージにメトリクスを書き込むには、事前にアクセスキーを作成しておく必要があります。作成したユーザ領域のメトリクスストレージをクリックし、詳細画面を表示します。

「アクセスキー」タブから「追加」をクリックし、新規アクセスキーを追加します。

アクセスキーを追加すると、アクセスキーの一覧に追加したアクセスキーが表示されます。

作成したアクセスキーをクリックし、詳細画面を表示します。詳細画面で表示されるエンドポイントや認証情報は後の手順で利用します。

手順3 sacloud-otel-collector のセットアップ 

モニタリングスイートでは、ログ収集エージェントとして Fluent Bit や OpenTelemetry Collector、メトリクス収集エージェントとして Prometheus や OpenTelemetry Collector などをサポートしています。これらのエージェントを利用する場合の設定例は各エージェントの設定例を参照してください。

また、さくらのクラウドでは OpenTelemetry Collector をベースにした OSS の sacloud-otel-collector を提供しています。

sacloud-otel-collector には、モニタリングスイートへの送信設定が簡単に行える機能に加え、ホストの基本的なメトリクスを収集するための設定や systemd のサービスファイルがあらかじめ含まれています。そのため、標準の OpenTelemetry Collector よりも手軽に、メトリクス・ログ・トレースをモニタリングスイートへ送信できます。本チュートリアルでは、sacloud-otel-collector を利用します。

手順3-1 パッケージのインストール 

リリースページから利用環境に応じたパッケージを取得し、インストールします。

さくらのクラウドのサーバ（Ubuntu Server 26.04 LTS 64bit）環境でのインストール手順は以下の通りです。

$ wget https://github.com/sacloud/sacloud-otel-collector/releases/download/v0.7.0/sacloud-otel-collector_0.7.0_linux_amd64.deb
$ sudo dpkg -i sacloud-otel-collector_0.7.0_linux_amd64.deb

手順3-2 設定ファイルの編集 

設定ファイル /etc/sacloud-otel-collector/config.yaml を編集します。

$ sudo vi /etc/sacloud-otel-collector/config.yaml

本チュートリアルでは、nginx のアクセスログを収集できるよう filelog receiver の include に /var/log/nginx/access.log を追加し、利用しない設定は削除します。

設定例の全体は以下の通りです。

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      cpu:
        metrics:
          system.cpu.utilization:
            enabled: true
      memory:
        metrics:
          system.memory.utilization:
            enabled: true
      disk:
      filesystem:
        metrics:
          system.filesystem.utilization:
            enabled: true
      network:
      paging:
        metrics:
          system.paging.utilization:
            enabled: true
  filelog:
    start_at: end
    exclude: []
    include:
      - /var/log/nginx/access.log

processors:
  resourcedetection:
    detectors: [system]
    system:
      hostname_sources: [os]

# You should set environment variables SACLOUD_*
exporters:
  debug:
  sacloud:
    metrics:
      endpoint: "${SACLOUD_METRICS_ENDPOINT}"
      token: "${SACLOUD_METRICS_TOKEN}"
    logs:
      endpoint: "${SACLOUD_LOGS_ENDPOINT}"
      token: "${SACLOUD_LOGS_TOKEN}"

service:
  pipelines:
    metrics:
      receivers:
        - hostmetrics
      processors:
        - resourcedetection
      exporters:
        - sacloud
        - debug
    logs:
      receivers:
        - filelog
      processors:
        - resourcedetection
      exporters:
        - sacloud
        - debug

手順3-3 認証情報の設定 

モニタリングスイートへの認証に使用するアクセスキーは、sacloud-otel-collector サービスの起動時に読み込まれる環境変数ファイル /etc/default/sacloud-otel-collector に設定します。

$ sudo vi /etc/default/sacloud-otel-collector

アクセスキーの詳細ページの情報に基づき、以下の情報を設定します。

SACLOUD_METRICS_ENDPOINT=123456789012
SACLOUD_METRICS_TOKEN=met-xxxx
SACLOUD_LOGS_ENDPOINT=123456789012
SACLOUD_LOGS_TOKEN=log-xxxx

手順3-4 sacloud-otelcol ユーザーの権限設定 

sacloud-otel-collector のプロセスは sacloud-otelcol ユーザーとして実行されます。そのため、filelog receiver でログファイルを収集する場合は、 sacloud-otelcol ユーザーに対象ファイルの読み取り権限が必要です。

ここでは setfacl を利用して、 sacloud-otelcol ユーザーに nginx のアクセスログの読み取り権限を付与します。 logrotate などでログファイルがローテーションされる場合に備え、ディレクトリに対してデフォルトの ACL も設定しておきます。

$ sudo apt install acl -y
$ sudo setfacl -m u:sacloud-otelcol:rx /var/log/nginx/access.log
$ sudo setfacl -m d:u:sacloud-otelcol:r /var/log/nginx

手順3-5 サービスの起動 

サービスを有効化し、起動します。

$ sudo systemctl enable sacloud-otel-collector
$ sudo systemctl start sacloud-otel-collector

# エラーが発生していないか確認する場合は、以下のコマンドでログを確認します。
$ journalctl -f -u sacloud-otel-collector

必要に応じて設定を変更した場合は、サービスを再起動してください。

$ sudo systemctl restart sacloud-otel-collector

手順4 ログの確認 

手順4-1 nginx アクセスログの生成 

nginx を起動したサーバ上で、以下のコマンドを複数回実行し、nginx のアクセスログを生成します。

$ curl http://localhost/
$ curl http://localhost/
$ curl http://localhost/
...

$ curl http://localhost/notfound.html
$ curl http://localhost/notfound.html
...

手順4-2 ログ閲覧 

コントロールパネルの「モニタリングスイート」カテゴリ内にある「ログストレージ」を選択し、作成したユーザ領域のログストレージをクリックします。

「情報」タブにある「内容を閲覧」をクリックします。

モニタリングスイート専用Web UIのログ閲覧画面に遷移します。

「検索」をクリックすると、デフォルトで直近3時間分のログを表示します。

各ログ行をクリックすると、ログの詳細が表示されます。

手順4-3 ログの検索 

nginx のアクセスログは、デフォルトでは非構造化ログとして送信されます。非構造化ログは text_payload フィールドに元のログの内容が格納されます。

text_payload フィールドに含まれる文字列を検索するには「Search words」にキーワードを入力して、「検索」を実行します。

例として notfound.html を検索すると、notfound.html が含まれるアクセスログが検索結果として表示されます。

手順5 ログの構造化 

ログを構造化して特定のフィールドに値を格納して送信することで、UI 上でログが見やすくなり、検索やフィルタリングも簡単に行えるようになります。

手順5-1 nginx のログを構造化する 

nginx のアクセスログを構造化ログとして出力するため、nginx の設定ファイルの http セクションに log_format ディレクティブを追加し JSON 形式のログを出力するように設定します。

$ sudo vi /etc/nginx/nginx.conf

log_format および access_log の設定例は以下の通りです。検索やフィルタリングを簡単に行うために「ログの構造化」に準拠した送信フィールド名で出力する必要があります。

...

http {

    ...

        ##
        # Logging Settings
        ##
        log_format json escape=json '{'
                '"time":"$time_iso8601",'
                '"http_remote_addr":"$remote_addr",'
                '"http_request_method":"$request_method",'
                '"http_request_url":"$request_uri",'
                '"http_status":$status,'
                '"http_response_size":$body_bytes_sent,'
                '"http_latency_sec":$request_time,'
                '"http_referer":"$http_referer",'
                '"http_user_agent":"$http_user_agent"'
        '}';

        # access_log /var/log/nginx/access.log;
        access_log /var/log/nginx/access.log json;


    ...
}

設定変更後は、nginx サービスを再起動してください。

$ sudo systemctl restart nginx

再起動後、nginx のアクセスログが JSON 形式で出力されるようになります。

$ curl http://localhost/
$ tail -1 /var/log/nginx/access.log
{"time":"2026-07-07T17:20:25+09:00","http_remote_addr":"::1","http_request_method":"GET","http_request_url":"/","http_status":200,"http_response_size":615,"http_latency_sec":0.000,"http_referer":"","http_user_agent":"curl/8.18.0"}

手順5-2 sacloud-otel-collector で構造化ログを送信する 

ログを構造化してモニタリングスイートに送信するために、JSON 形式のログをエージェント側で事前にパースする必要があります。

sacloud-otel-collector の設定ファイルの filelog receiver に json_parser operator を追加します。

$ sudo vi /etc/sacloud-otel-collector/config.yaml

json_parser の主な設定項目は以下の通りです。

parse_from

JSON 形式の文字列のパース対象のフィールドです。filelog receiver で読み込んだログは body に格納されるため、今回の例では body を指定します。
parse_to

パース結果を格納するフィールドです。body を指定することで、body の中身が map 型で上書きされます。
parse_ints

デフォルト（false）では、パースされた数値は整数も含めてすべて double 型になります。 true にすると、整数値を int 型として扱います。モニタリングスイートの http_status, http_request_size などのフィールドは int 型として送る必要があるため、true に設定します。利用可能なフィールドの一覧と対応する型は「ログの構造化」をご確認ください。

json_parser を含めた設定例の全体は以下の通りです。

receivers:
  hostmetrics:
    collection_interval: 10s
    scrapers:
      cpu:
        metrics:
          system.cpu.utilization:
            enabled: true
      memory:
        metrics:
          system.memory.utilization:
            enabled: true
      disk:
      filesystem:
        metrics:
          system.filesystem.utilization:
            enabled: true
      network:
      paging:
        metrics:
          system.paging.utilization:
            enabled: true
  filelog:
    start_at: end
    exclude: []
    include:
      - /var/log/nginx/access.log
    operators:
      - id: parse_json
        type: json_parser
        parse_from: body
        parse_to: body
        parse_ints: true

processors:
  resourcedetection:
    detectors: [system]
    system:
      hostname_sources: [os]

# You should set environment variables SACLOUD_*
exporters:
  debug:
  sacloud:
    metrics:
      endpoint: "${SACLOUD_METRICS_ENDPOINT}"
      token: "${SACLOUD_METRICS_TOKEN}"
    logs:
      endpoint: "${SACLOUD_LOGS_ENDPOINT}"
      token: "${SACLOUD_LOGS_TOKEN}"

service:
  pipelines:
    metrics:
      receivers:
        - hostmetrics
      processors:
        - resourcedetection
      exporters:
        - sacloud
        - debug
    logs:
      receivers:
        - filelog
      processors:
        - resourcedetection
      exporters:
        - sacloud
        - debug

設定変更後は、sacloud-otel-collector サービスを再起動してください。

$ sudo systemctl restart sacloud-otel-collector

手順5-3 構造化ログの検索 

再度、nginx のアクセスログを生成するため、以下のコマンドを複数回実行します。

$ curl http://localhost/
$ curl http://localhost/
$ curl http://localhost/
...

$ curl http://localhost/notfound.html
$ curl http://localhost/notfound.html
...

モニタリングスイートの専用Web UIで最新のログを検索すると、これまで text_payload フィールドに格納されていたものが、各フィールドに分解されて格納されるようになります。明示的に送信しない一部のフィールドにはデフォルト値（0 や false）が設定されます。

左ペインでは特定のフィールドに対して値のパターンとマッチするログの行数が表示されます。チェックボックスを使って、検索結果を絞り込むことも可能です。

例えば左ペイン上の http_status をクリックして開くと、http_status の種類と各ステータスコードごとのログの件数が表示されます。 200 にチェックをつけて「検索」をクリックすると、ステータスコード 200 のログに絞って検索できます。

また、Query 機能を利用すると、各フィールドに対して詳細な条件を指定した検索が可能です。

http_status のチェックボックス指定を外し、Query 入力欄に http_response_size >= 100 and http_request_url = "/notfound.html" を入力して「検索」をクリックすると、「レスポンスサイズが 100 バイト以上」かつ「"/notfound.html" へのリクエスト」のログを検索できます。

Query に指定できるフィールドや演算子についての詳細は「Query機能」をご確認ください。

手順6 メトリクスの確認 

手順6-1 メトリクス閲覧 

コントロールパネルの「モニタリングスイート」カテゴリ内にある「メトリクスストレージ」を選択し、作成したユーザ領域のメトリクスストレージをクリックします。

「情報」タブにある「内容を閲覧」をクリックします。

モニタリングスイート専用Web UIのメトリクス閲覧画面に遷移します。

送信されているメトリクスの一覧が表示されます。 hostmetrics receiver で収集した、CPU 使用率・メモリ使用率・ディスク使用率などのメトリクスが確認できます。

確認したいメトリクスをクリックするか、メトリクス名を入力すると、メトリクスの値がグラフで表示されます。

PromQL（Prometheus Query Language）を利用して、メトリクスをフィルタリングしたり、統計値を算出することも可能です。

例えば、idle 以外の CPU 使用率を算出したい場合は、以下の PromQL を入力します。

100 * (1 - avg(system_cpu_utilization_ratio{state="idle"}))

PromQL については、さくらのナレッジの次の記事で解説しているので参考にしてください。

（参考） Prometheusのクエリ機能とアラート機能 | さくらのナレッジ

手順7 アラートルールの設定 

アラートルールを利用すると、メトリクスが指定したしきい値を超えた際にアラートを発生させることができます。発生したアラートは、「シンプル通知」や「EventBus」へ通知できます。

この手順では、サーバの CPU 使用率が一定値を超えた際にアラートを発生させるアラートルールを作成し、シンプル通知を利用してメールで通知を受け取る方法を説明します。

手順7-1 シンプル通知のリソース作成 

モニタリングスイートのアラートをシンプル通知で受け取るには、シンプル通知の以下のリソースを作成する必要があります。

本チュートリアルではアラート通知方法としてメールを利用するため、メールの通知先を作成します。

通知先アドレスに入力したアドレス宛に本登録手続き用の通知メールが送信されます。「本登録URL」のリンクをクリックして、本登録を実施して下さい。

その後、作成した通知先を含む通知先グループを作成します。

作成した通知先グループがモニタリングスイートからの通知を受け取るように通知先ルーティングを作成します。

手順7-2 アラートプロジェクトの作成 

アラートルールや通知先の設定を管理するための「アラートプロジェクト」を作成します。

コントロールパネルの「モニタリングスイート」カテゴリにある「アラートプロジェクト」を選択し、「追加」をクリックします。

名前などのフィールドを入力し、「作成」をクリックします。

作成したアラートプロジェクトの詳細画面を開いて、「ルールの確認」をクリックします。

モニタリングスイート専用Web UIのアラートプロジェクトの管理画面に遷移します。

手順7-3 アラートプロジェクトの通知先設定 

シンプル通知と連携するため、アラートプロジェクトの通知先としてシンプル通知を設定します。

アラートプロジェクトの管理画面で「通知先」をクリックします。

通知先設定画面で「シンプル通知への通知送信を設定する」をクリックします。

これでシンプル通知への通知が有効になります。

手順7-4 アラートプロジェクトの通知ルーティング設定 

モニタリングスイートで発生したアラートは、アラートプロジェクトの「通知ルーティング」で設定した条件に基づき、異なる通知先へ振り分けることができます。

通知ルーティングを複数設定した場合は、優先度の高いルーティングから順に評価されます。条件に一致した最初のルーティングの通知先にのみ通知が送信されます。

この手順では、すべてのアラートをシンプル通知へ送信する通知ルーティングを1つ設定します。アラートプロジェクトの管理画面から、「通知ルーティング」をクリックします。

「ルーティング追加」をクリックします。

シンプル通知を通知先として設定し、条件は空のまま「保存」をクリックします。

この通知ルーティングの設定で、すべてのアラートがシンプル通知に送信されるようになります。

手順7-5 アラートルールの作成 

アラートルールを作成します。

ここでは例として、CPU 使用率が 70% を超えた状態を検知するアラートルールを作成します。

アラートプロジェクトの管理画面から、「アラートルール」をクリックします。

「ルール追加」をクリックします。

以下の項目を入力し、「保存」をクリックします。

メトリクスストレージ : 作成したメトリクスストレージを選択
ルール名 : （例）CPU使用率監視
Query : 100 * (1 - avg(system_cpu_utilization_ratio{state="idle"}))
しきい値
- Warning : 有効
- 条件 : >=
- 値 : 70
- 継続時間（秒） : 60s （デフォルト値のまま）

手順8 アラートの確認 

アラートルール作成後、対象サーバで CPU 負荷を発生させ、シンプル通知からアラート通知メールが届くことを確認します。

負荷を発生させるために、stress コマンドをインストールします。

$ sudo apt install -y stress

stress コマンドを利用して、CPU 負荷を一定時間かけます。

$ stress --cpu 2 --timeout 180

上記コマンドの実行中、CPU 使用率がしきい値を超えた状態が 60 秒以上継続するとアラートが発生し、シンプル通知からメールが送信されます。必要に応じて --cpu の値をサーバの vCPU 数に合わせて調整してください。

発生したアラートは、アラートプロジェクト管理画面の下部にある履歴にも表示されます。

履歴一覧からアラートの ID をクリックすると、アラート履歴の画面が表示されます。アラート履歴画面では、アラート発生時のメトリクスの推移など、アラートの詳細情報を確認できます。

しきい値を下回るとアラートは自動的に解消され、シンプル通知からメールが送信されます。

アラート履歴の画面でも、アラートが解消されたことを確認できます。

まとめ 

このチュートリアルでは、モニタリングスイートを利用して以下を実施しました。

nginx のアクセスログの検索・分析
CPU、メモリ、ディスクなどのサーバメトリクスの可視化
メトリクスに基づくアラートルールの設定
異常発生時のメール通知の受信

これで、モニタリングスイートによる基本的なサーバ監視環境の構築は完了です。実際の運用では、収集対象のログやメトリクスの追加、ダッシュボードを利用した可視化、ログ計測ルールを利用したログのメトリクス化およびログ監視、トレースデータを活用したアプリケーションのパフォーマンス分析、通知ルーティングを利用した複数の通知先へのアラート振り分けなどを行うことで、より高度な監視環境を構築できます。

モニタリングスイート チュートリアル

モニタリングスイートチュートリアル