Mackerel APMとは｜OpenTelemetryでトレースを送る手順とスパン課金の見積もり

Mackerel APMは、はてなのサーバー監視サービス「Mackerel」に2025年5月1日に正式リリースされたアプリケーション性能監視の機能です。アプリケーションからOpenTelemetry形式のトレースを受け取り、リクエスト数・エラー率・レイテンシーのグラフ、エンドポイント別やSQL別の統計、エラーの集約までを1つのサービス画面にまとめます。課金はホスト数ではなくスパン数で、スタンダードプランは月5Mスパンまで無料、超過分は1Mスパンあたり330円（税込）です。

この記事では、画面で何が見えるか、トレースをどの経路で送るか、Pythonアプリをコード変更なしで計装する手順、月額の見積もり方とサンプリングの落とし穴を、2026年10月時点の公式ドキュメントと手元での実行結果をもとに整理します。mackerel-agentによるサーバー監視そのものはMackerelでサーバーを監視する手順｜agent導入から料金試算と採用判断までで扱っています。

まとめ：Mackerel APMの機能・料金・導入手順の要点

• 見えるもの：サマリー（REDメトリック）・トレース・HTTPサーバー・データベース・課題・サービスマップの6タブ。トレースの保持は最大2週間です。
• 送り方：OpenTelemetryで計装し、Mackerel OpenTelemetryコレクター経由（本番の推奨）か、https://otlp-vaxila.mackerelio.com/v1/traces への直接送信を選びます。直接送信はOTLP/HTTPで、2026年10月6日からJSON形式も受け付けています。
• 計装：Pythonなら opentelemetry-distro を入れて opentelemetry-instrument 経由で起動するだけで、Flaskのリクエストとcursor経由のSQLがスパンになります。
• 料金：スタンダードプランは月5Mスパン無料、超過は1Mごと切り上げで330円（税込）。課金対象機能の合計には最低利用料金2,180円（税込）が適用されます。月額は「秒間リクエスト数×1リクエストのスパン数×259万2,000秒」で桁が出ます。
• 注意点：エラーと遅いトレースだけを全数残すテイルベースサンプリングは、画面のエラー率とレイテンシーを実態より悪く見せます。偏りを避けるなら処理結果によらない一定確率のヘッドベースを使い、SLOの判定はサンプリングに依存しないメトリクスで行います。

Mackerel APMで見える6タブとサーバー監視との境界

Mackerel APMの画面は、OpenTelemetryの service.name ごとに作られるサービス詳細画面が中心です。何をどのタブで見るかを先に押さえておくと、計装で何を送ればよいかが決まります。

サマリーからサービスマップまで各タブが集計する属性

公式ドキュメントの「短期検証による可視化分析」では、サービス詳細画面を次の6タブで説明しています。HTTPサーバーとデータベースのタブは、スパンに特定の属性が無いと一覧に出ません。

HTTPサーバータブのエラー率は、ステータスコード500番台の件数をリクエスト総数で割った値です。4xxはエラーに数えません。P95も「近似値」と明記されており、SLOの判定に使う厳密な値は別途メトリクスで取る必要があります。ルート名は http.route を最優先し、無ければ url.path、http.target、http.url の順で拾います。旧仕様の http.method や http.status_code も代替として読み取るため、計装ライブラリが古いセマンティック規約で属性を出していても一覧には載ります。

REDの3指標を何に使うかという一般論はREDメソッドとは？マイクロサービス監視の3指標（流量・失敗・所要時間）と実装手順を解説にまとめています。

データベースタブの計測範囲とクエリ改善事例

データベースタブの数字は、アプリケーションがSQLを発行してから結果を受け取るまでの時間です。DBサーバー側の統計とは測る位置が違います。はてなのWebマンガビューワ「GigaViewer」の導入事例（GigaViewerにおけるMackerel APM導入の裏側、2025年5月28日の発表）では、それまで見ていたAuroraのPerformance InsightsをDBサーバー上の所要時間、APMのデータベースタブをクライアントアプリケーション上の所要時間と整理しています。

このチームはデータベースタブで、DBセッションの設定に使う SET クエリが毎回3本発行されていることに気づきました。3本を1本のクエリにまとめた結果、全リクエストが1ミリ秒程度速くなったと報告しています。1本あたりは軽く、サーバー側の統計では上位に出にくいクエリでも、回数と合計時間で並べると目に付きます。事例のコレクターはECSのサイドカーに置いて設定を最低限にし、PerlのバックエンドはX-Ray Receiver経由、自動計装やミドルウェアはOTLPで送る構成でした。発表者は「OpenTelemetry、簡単ではない」として、計装とコレクターの導入は簡単ではなく、仕様と実装が一致しない場合もあると述べています。

従来のMackerelの「サービス」とは別物になるAPMのサービス

既存のMackerel利用者が最初に戸惑うのが用語です。Mackerel APMの「サービス」はOpenTelemetryの service.name の値で、ホストをまとめる従来のMackerelのサービスとは無関係です。画面も分かれており、公式ドキュメントは「サーバー側のリソース状況はホストの詳細画面で、アプリケーション内部の処理フローはAPMの画面で」と使い分けを案内しています。

2つをつなぐ導線はトレース詳細画面にあります。スパンに host.id か host.name が入っていれば「メトリック」リンクが表示され、発生時刻の前後に絞ったメトリックエクスプローラーへ移れます。レイテンシー悪化の原因がアプリかインフラかを切り分けたいなら、リソース属性にホスト情報を載せておくのが前提になります。Mackerel OpenTelemetryコレクターは resourcedetection プロセッサーを同梱しており、ホスト名などをコレクター側で付与できます。

2025年5月の正式リリース以降に追加された主な機能

正式リリース後も週次のアップデートで機能が追加されています。主な更新は次のとおりで、直接送信のJSON形式対応のように送信設定に関わる変更も含みます。

トレースをMackerelへ送る2つの経路と計装方式の選び方

トレースの届け方（コレクターを挟むか直接送るか）と計装の方式は、独立に決められます。

直接送信とMackerel OpenTelemetryコレクター経由の違い

直接送信では、送信先を https://otlp-vaxila.mackerelio.com/v1/traces にし、HTTPヘッダー Mackerel-Api-Key にWrite権限のあるAPIキーを付けます。受け付けるのはOTLP/HTTPで、2026年10月6日まではBinary Protobuf（http/protobuf）のみでした。現在はJSON形式も受け付けるため、Cloudflare WorkersのようにJSONしか出せない環境でも変換用のコレクターが不要になりました。送信側のSDKがJSONに対応していることが前提で、対応SDKなら OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="http/json" を指定します。2026年10月29日公開のPython SDK 1.45.2でこの値を指定すると、Unsupported OTLP protocol 'http/json' is configured の例外でSDKの構成が失敗しました。アプリ本体はそのまま起動するため、エラーログを見落とすとトレースが1本も届かない状態に気づけません。Pythonは引き続き http/protobuf を使います。

コレクター経由では、アプリはlocalhostの4318番（HTTP）か4317番（gRPC）へ送り、コレクターがMackerelへ転送します。Mackerel OpenTelemetryコレクター（MDOT Collector）は公式Collectorをベースにしたディストリビューションで、環境変数 MACKEREL_APIKEY を渡すだけで設定ファイルなしに起動します。2026年10月31日時点の最新は、10月28日公開のv0.16.1です（GitHubのリリース一覧で確認）。10月22日公開のv0.16.0でログの送信先が otlp.mackerelio.com に変わっているため、ログも送る構成では更新しておきます。

コレクターはLinuxとDocker向けのみで、Windows版はありません。Windowsでは公式の otelcol-contrib を使い、エクスポーターに otlp_http を置いて送信先とAPIキーを自分で書きます。このときトレースの送信先は https://otlp-vaxila.mackerelio.com、メトリックの送信先は otlp.mackerelio.com:4317（gRPC）と、シグナルで宛先が異なる点に注意が要ります。Collector自体の構成はOpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違いとOpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distroで解説しています。

ブラウザやモバイルアプリからトレースを送る場合、APIキーを埋め込むのは危険です。2026年3月に追加されたクライアントトークンはトレース投稿だけに権限を絞ったトークンで、ヘッダーは X-Mackerel-Client-Token を使います。

ゼロコード計装・ライブラリ計装・コードベース計装の使い分け

公式ドキュメントの推奨順は、ゼロコード計装で始め、細かい制御が要ればライブラリ計装、業務固有の情報を残したくなったらコードベース計装を足す、という段階導入です。

• ゼロコード計装：Javaエージェント、Pythonの opentelemetry-instrument、Node.jsの --require、PHP拡張など、起動方法の変更だけで済みます。取れる範囲は対応ライブラリ次第です。
• ライブラリ計装：SDKと計装ライブラリを入れ、初期化コードを書きます。RailsならGemを追加して use_all を呼ぶ形です。
• コードベース計装：注文IDや金額などをスパン属性に載せる手書きの計装です。調査で「どの条件のときだけ遅いか」を絞る材料になります。

このほか、LinuxのeBPFでカーネル側から通信を観測するOBI（OpenTelemetry eBPF Instrumentation）も案内されています。SDKを入れられないミドルウェアや他チームのサービスもサービスマップに載せられる一方、Linux限定です。eBPFの仕組みはeBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワークでできることを参照してください。Mackerel向けの言語別ガイドは、Go・Node.js・PHP・Python・Ruby（Rails）・.NET・Java（Java Agent／Spring Boot）・ブラウザがあります。

Pythonアプリをゼロコード計装でMackerelへ送る手順

ここでは公式のPythonガイドの手順を、Flaskアプリで実際に動かした結果とあわせて示します。公式ガイドの動作要件は「Python 3.9以上」ですが、PyPIのopentelemetry-sdkは2026年5月19日公開の1.42.0からPython 3.10以上を要求しています。3.9のままpipで入れるとSDKは1.41.1で止まり、以降の修正が入りません。新しく計装するなら3.10以上で始めてください。

パッケージ導入とopentelemetry-instrumentでの起動

まず opentelemetry-distro とOTLPエクスポーターを入れ、opentelemetry-bootstrap で環境にあるライブラリ（Flask、requests、psycopg2など）に対応する計装ライブラリを自動で追加します。ライブラリを後から増やしたら、bootstrapを再実行します。

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

直接送信するなら、APIキーを環境変数に入れて次のように起動します。公式ガイドの例で、メトリクスとログのエクスポーターは止めてトレースだけを送ります。

opentelemetry-instrument \
    --traces_exporter otlp \
    --metrics_exporter none \
    --logs_exporter none \
    --service_name my-sample-app \
    --exporter_otlp_traces_endpoint https://otlp-vaxila.mackerelio.com/v1/traces \
    --exporter_otlp_traces_headers "Mackerel-Api-Key=${MACKEREL_APIKEY},Accept='*/*'" \
    --exporter_otlp_traces_protocol http/protobuf \
    python myapp.py

送信後は、メニューの「APM」からサービス名を選び、「トレース」タブで届いたトレースを確認できます。

コレクター経由に切り替える環境変数とリソース属性

本番では、コレクターを起動してOTLP/HTTPの4318番ポートで受信できることを確認してから、以下のアプリ側設定に切り替えます。同一ホストまたはネットワーク名前空間を共有するサイドカー構成ではlocalhostを使えます。APIキーはコレクター側に設定します。

export OTEL_SERVICE_NAME="my-python-app"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_RESOURCE_ATTRIBUTES="service.version=1.4.2,deployment.environment.name=production"
opentelemetry-instrument --traces_exporter otlp --metrics_exporter none --logs_exporter none gunicorn myapp:app

公式ドキュメントは、リソース属性として最低限 service.name・service.version・deployment.environment.name を設定するよう案内しています。バージョンを入れておくと、デプロイ前後でレイテンシーを比べられます。環境名を入れずにステージングと本番を同じ service.name で送ると、サマリーのグラフが混ざって判断材料になりません。特定の計装を止めたいときは OTEL_PYTHON_DISABLED_INSTRUMENTATIONS=redis,requests のように指定し、スパン数も減らせます。

手元の実行結果で分かったDBタブに出ないクエリ

2026年10月31日に、Python 3.12.13・opentelemetry-distro 0.66b2（SDK 1.45.2）・Flask 3.1.3の環境で、エクスポーターを console にして出力されるスパンを数えました（10月7日にSDK 1.41.1で測った結果と同じでした）。アプリは、cursor経由でSQLiteへ2回問い合わせるルート、接続オブジェクトの execute で1回問い合わせるルート、例外を投げるルートを持つ最小構成です。以下はcursor経由のルートの抜粋で、実行にはFlaskアプリの初期化とusersテーブルの事前作成が必要です。

@app.route("/users/<int:uid>")
def user(uid):
    c = sqlite3.connect("demo.db")
    cur = c.cursor()
    row = cur.execute("SELECT id, name FROM users WHERE id = ?", (uid,)).fetchone()
    cur.execute("SELECT count(*) FROM users").fetchone()
    cur.close()
    c.close()
    return jsonify({"user": row})

接続オブジェクトの簡略メソッド c.execute(...) で問い合わせたルートでは、SQLのスパンが1本も出ませんでした。c.cursor() を経由したルートでは、db.statement 属性付きのCLIENTスパンがSQLごとに1本ずつ、計2本出ました。Mackerelのデータベースタブは db.statement か db.query.text が無いスパンを表示しないため、簡略メソッドを多用するコードではタブが空のままになります。ゼロコード計装を入れたらまず console で出力を見て、期待した処理がスパンになっているかを確かめてください。

例外を投げたルートでは、スパンのステータスがERRORになり、exception.type・exception.message・exception.stacktrace を持つイベントが付きました。Mackerelの課題タブはこのイベントの exception.message を課題名にして同種エラーをまとめます。SDKによっては例外を自動で記録しないものがあり、その場合はフレームワークのエラーハンドラーで recordException 系の関数を呼ぶ必要があります。また、このFlask計装は属性を http.method・http.status_code という旧名で出していましたが、前述のとおりHTTPサーバータブは旧名も読むため集計に支障はありません。

スパン課金の見積もり方とコストを抑える設定

Mackerel APMの費用はスパン数だけで決まります。ホスト課金のサーバー監視とは別の軸で増えるため、有効化の前に桁を出しておきます。

スタンダード・フリー・トライアルのスパン枠

2026年10月31日時点のMackerelの料金ページに記載された枠です。

見落としやすいのが最低利用料金です。スタンダードプランで無料枠を超えたスパン投稿などの課金対象機能を使うと、合計が2,180円（税込）に満たなくても2,180円に切り上げられます。月6Mスパンで超過が1Mだけでも、請求は330円ではなく2,180円です。スパンの課金対象月は、スパンを受信した時刻で決まります。

1リクエストあたりのスパン数から月額を出す計算

公式の見積もり手順は「1リクエストあたりのスパン数」を起点にします。トレース詳細画面でサービスごとのスパン数が見えるので、代表的なリクエストを数件開いて平均を取ります。月のスパン数は、24時間稼働なら次の式で出ます。

月間スパン数 = 平均秒間リクエスト数 × 1リクエストのスパン数 × 2,592,000（30日の秒数）

平均10リクエスト／秒、1リクエスト5スパンのAPIなら、月1億2,960万スパンです。無料枠5Mを引いた1億2,460万スパンを1M単位に切り上げると125M、月41,250円（税込）になります。同じAPIで10％のヘッドベースサンプリングをかけると月1,296万スパン、超過8Mで2,640円です。一定確率のサンプリングでは期待スパン数は抽出率に比例しますが、請求額には無料枠・1M単位の切り上げ・最低利用料金が影響します。有効化前に候補となる抽出率ごとの月額を計算してください。

運用中の監視には、2026年3月から投稿されているスパン概算使用量のメトリックが使えます。メトリックエクスプローラーで service.name に __mackerelio.system を指定すると表示され、クエリによる監視で閾値アラートも張れます。このメトリック自体にメトリック利用料はかかりません。

ヘルスチェック除外とテイルベースサンプリングの設定

Mackerel OpenTelemetryコレクターには filter・tail_sampling・probabilistic_sampler の各プロセッサーが組み込まれています。単純な確率サンプリングなら、設定ファイルを書かずに環境変数 OTELCOL_MACKEREL_SAMPLING_PERCENTAGE=10 で済みます。条件付きで残したい場合は、公式ドキュメントの例を基に次のような config.yaml を書きます。

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  filter/healthcheck:
    error_mode: ignore
    traces:
      span:
        - 'attributes["http.route"] == "/healthz"'
        - 'attributes["http.route"] == "/readyz"'
  tail_sampling:
    decision_wait: 10s
    num_traces: 100000
    policies:
      - name: errors-policy
        type: status_code
        status_code:
          status_codes:
            - ERROR
      - name: slow-traces-policy
        type: latency
        latency:
          threshold_ms: 1000
      - name: normal-sampling
        type: probabilistic
        probabilistic:
          sampling_percentage: 10
exporters:
  mackerel_otlp:
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, filter/healthcheck, tail_sampling]
      exporters: [mackerel_otlp]

この設定は、判定時にERRORまたは遅延条件を満たすトレースを採用し、それ以外を確率10％で採用します。ただし、最初のスパン受信から10秒後に判定するため、遅れて届くスパンのエラー情報などが判定に反映されない場合があります。保持上限の100,000トレースを超えた場合も判定前に破棄され得るため、全数保持は保証されません。ポリシーはOR評価です。filter はスパン単位で落とすため、複数スパンからなるトレースでは条件に合ったスパンだけが抜け、残りは送られます。プロセッサーの並びは memory_limiter、filter、tail_sampling の順にします。メモリ上限を先に確認し、不要なスパンを落としてから間引くためです。サンプリング方式の比較はトレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説【2026年版】で詳しく扱っています。

テイルベースでREDの数字が実態より悪く見える偏り

上の設定には代償があります。Mackerel APMのサマリーとHTTPサーバータブは、サンプリング後に届いたデータで集計されます。エラーを全数・正常を10％だけ残すと、画面のリクエスト数は実際より少なく、エラー率は実際より高く、レイテンシーの分布は遅い側に寄ります。公式ドキュメントの「フィルタリングとサンプリングによるデータ量・コストの最適化」もこの偏りを明記しています。

週次報告で傾向を見るなら、処理結果によらない一定確率のサンプリングを使い、標本数と抽出率を併記してください。SLOの判定には、トレースの間引きに依存しないメトリクスを使います。エラーや遅いトレースを障害調査用に優先して残したいなら、判定待ち時間・バッファ容量・同一トレースの集約先を設計したうえでテイルベースを選び、そのかわりAPM画面の率や分布を「実数」として報告しないとチームで決めておきます。結果に応じて抽出率を変えたデータを、補正せず全体の統計として報告すると判断を誤ります。

アラートの組み立て：課題のSlack通知とクエリによる監視の分担

Mackerel APMで通知に直結するのは「課題」です。exceptionイベントを含むエラーが同種ごとに課題としてまとまり、課題一覧画面の「Slack通知連携」でSlackのIncoming Webhookへ通知できます。同じ課題が繰り返し通知される場合は、課題詳細の「スヌーズ」で一時停止できます（2026年3月追加）。

一方、「P95が500msを超えたら通知」のようなレイテンシーやエラー率の閾値監視を、APMのサマリー画面から直接作る手順は2026年10月時点の公式ドキュメントに見当たりません。閾値で見張るなら、アプリからOpenTelemetryのメトリクス（たとえば http.server.request.duration）も送ってラベル付きメトリックとして投稿し、「クエリによる監視」でPromQLの式に閾値を設定します。クエリによる監視は監視間隔1分、評価範囲は常に20分間で、監視ルール名に {{http.route}} のようなラベルのテンプレートを埋め込めます。メトリクスはスパンとは別課金で、料金ページでは毎分1か月投稿した系列を1メトリックと数え、1メトリック11円（税込）です。系列数も見積もりに含めてください。

トレースは原因調査、メトリクスは閾値の判定と役割を分けると、通知が二重に鳴る設計を避けられます。メトリクス側の計器の選び方はOpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計、通知の量の抑え方はアラート疲れとは｜原因と対策を監視の実装視点で解説【2026年時点】が参考になります。

Mackerel APMを選ぶ条件と他のAPMへ寄せる場面

Mackerel APMが合うのは、すでにMackerelでサーバーを監視していて、アプリの遅延をホストのメトリクスと同じアカウントで突き合わせたいチームです。計装はOpenTelemetryそのものなので、将来ほかのバックエンドへ移るときも計装コードはそのまま使えます。2026年11月1日からはログ機能も正式版になり、公式の告知によれば、OpenTelemetry準拠のメトリック・トレース・ログの3シグナルが正式版として揃います。ログはスタンダードプランで1GBあたり70円（税抜）、無料枠なし、保存30日です。計装の設計から監視の定着までを外部に任せたい場合は、保守運用・内製化支援で相談を受け付けています。

逆に、次の条件に当たるなら他のAPMを比較してください。

• 2週間より前のトレースを掘る運用：トレースの保持は最大2週間です。月次の傾向分析はメトリクスで残す設計にするか、保持期間を選べる製品を検討します。
• トレースを送らないサービスも依存関係に載せたい：サービスマップに出るのはMackerelへスパンを送っているサービス同士だけです。OBIで補えるのはLinux上のサービスに限られます。
• Windowsサーバー中心の構成：Mackerel OpenTelemetryコレクターはWindows版が無く、公式の otelcol-contrib を自分で設定する前提になります。

APMの選び方の全体像はAPM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説、他社製品の導入手順はDatadog APM導入の実装手順｜dd-trace自動計装からサンプリング設計までとNew Relicとは｜APM・インフラ監視の構成とデータ量課金の設計を実装目線で解説で比較できます。

よくある質問

Mackerel APMは無料で使えますか？

フリープランで月5Mスパンまで無料で使えます。上限に達すると翌月まで投稿できなくなります。スタンダードプランも月5Mスパンまでは無料で、超過分が1Mスパンごとに330円（税込）です。新規オーガニゼーションの2週間トライアルでは100Mスパンまで無料です。

Mackerel APMを使うのにmackerel-agentは必要ですか？

必要ありません。トレースはOpenTelemetryのSDKやゼロコード計装から、直接またはOpenTelemetryコレクター経由で送ります。mackerel-agentはホストのメトリクスを送るためのもので、トレースの経路には入りません。ホストのメトリクスとトレースを突き合わせたい場合は、両方を入れます。

Mackerel APMはどの言語に対応していますか？

OpenTelemetryのSDKがある言語なら送れます。公式の導入ガイドがあるのは、Go・Node.js・PHP・Python・Ruby（Rails）・.NET・Java（Java Agent／Spring Boot）とブラウザです。ガイドの無い言語も、送信先・ヘッダー・リソース属性の3点を設定すれば送れると公式ドキュメントが説明しています。

トレースデータはどれくらいの期間見られますか？

最大2週間です。画面の期間選択も最大2週間までです。それ以上前の傾向を見たい場合は、OpenTelemetryのメトリクスを別途送ってラベル付きメトリックとして残します。

ブラウザやスマートフォンアプリからトレースを送れますか？

送れます。2026年3月に追加されたクライアントトークンを使います。トレース投稿だけに権限を限定したトークンで、ヘッダーは X-Mackerel-Client-Token です。作成にはオーガニゼーションのオーナーまたは管理者権限が要ります。APIキーをフロントエンドのコードに埋め込むのは避けてください。

関連記事

• Mackerelでサーバーを監視する手順｜agent導入から料金試算と採用判断まで
• APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説
• トレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説【2026年版】
• OpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違い
• REDメソッドとは？マイクロサービス監視の3指標（流量・失敗・所要時間）と実装手順を解説