sardine で mackerel-plugin の出力をサービスメトリックとして投稿する

全国三千万 Mackerel ユーザーの皆様こんにちは。

mackerel-plugin で生成した値を、サービスメトリックとして投稿したいと思ったことはないでしょうか。ありますよね。でも mackerel-agent ではホストメトリックしか投稿できません。

ということで、拙作の sardine に Mackerel のサービスメトリックとして投稿する機能を追加しました。(Thanks for @jet_zousan)

sardine についてはこちらをご覧ください。

sfujiwara.hatenablog.com github.com

mackerel-plugin 互換の出力を CloudWatch のメトリックとして投稿する agent です。 おもにコンテナ環境で、mackerel-agent を全部に立てたくはないけど使い慣れた mackerel-plugin で収集した値を集約して把握することを目的としています。Go で書かれていてバイナリ1つで動作するため、コンテナに同梱して動かすのも簡単です。

以下のような設定ファイルで起動すると

[plugin.metrics.ping]
command = "mackerel-plugin-ping -count 2 -host 8.8.8.8,8.8.4.4"
service = "Home"
destination = "Mackerel"

サービスメトリックを投稿して

$ sudo MACKEREL_APIKEY="XXX" sardine -config test.conf -debug
2018/03/27 13:05:36 [plugin.servicemetrics.ping] starting
2018/03/27 13:05:38 putToMackerel: {"Service":"Home","MetricValues":[{"name":"ping.rtt.8_8_8_8","time":1522123536,"value":3.379283},{"name":"ping.rtt.8_8_4_4","time":1522123536,"value":2.739579}]}
2018/03/27 13:06:38 putToMackerel: {"Service":"Home","MetricValues":[{"name":"ping.rtt.8_8_8_8","time":1522123596,"value":2.716042},{"name":"ping.rtt.8_8_4_4","time":1522123596,"value":3.67368}]}

こんな感じにグラフができます。便利ですね。

f:id:sfujiwara:20180327131535p:plain

また、interval という設定で実行間隔を制御できるため、毎分取るほどでもない値を任意の間隔で投稿することもできます。(mackerel-agent では metric plugin の実行間隔は 1分で固定になっていて、現状変更できません)

どうぞご利用ください。

ECS のデプロイツール ecspresso と、環境変数を展開して YAML/JSON/TOML を読み込む go-config について

OSS紹介 Advent Calendar 2017 - Qiita 18日目の記事です。(一週間遅れ)

Amazon ECS へのデプロイツール ecspresso と、そこで使っている環境変数を展開しつつ複数の YAML/JSON/TOML を読み込む config loader である go-config の紹介をします。

ecspresso

github.com

エスプレッソ」と読みます。Go で書かれた Amazon ECS 用のデプロイツールです。以下の3つのファイルを用いて ECS へのサービス、タスク定義作成、入れ換えを行います。

  • YAML の設定ファイル
  • タスク定義のための JSON (aws ecs describe-task-definition 出力と互換)
  • サービス定義のための JSON (オプション。aws ecs describe-services 出力の services セクションと互換`)
region: ap-northeast-1
cluster: default
service: app
task_definition: taskdef.json
service_definition: service.json
timeout: 10m

create (サービス作成)、deploy (新しいタスク定義を作成しサービスに対して入れ換える)、status (deployments, events をみる)、rollback (一つ前のタスク定義に差し替えてデプロイすることでロールバックする) の機能があります。

元々 aws-cli を shell script から叩いていたデプロイ script を実装し直したもので (一番最初のバージョンは Go から aws-cli をコマンド起動するものでした)、「それ ○○ (他の ECS に対応したデプロイツール)とどう違うの」といわれると答えに窮する代物ですが…

無理矢理特徴を挙げると

  • Go で実装してあるのでシングルバイナリで環境依存少なく動作する
  • タスクとサービスの定義ファイルには後述の go-config による、環境変数展開機能がある

ぐらいでしょうか。

go-config

github.com

こちらは、複数の YAML / JSON / TOML をマージしつつ、Go の text/template の記法で環境変数を展開して読み込むことができるパッケージです。もともと社内のとあるアプリケーションで使用するために開発されたものですが、ecspresso で使いたいがために (便利なので) 公開しました。

コンテナでアプリケーションやミドルウェアを動作させる場合、設定ファイル自体はコンテナに同梱しておくが、その中の値は環境変数で指定したい、というニーズがあります。ファイルにハードコードされていると設定値を書き換えるたびにコンテナのビルドが必要になりますが、環境変数であればコンテナの起動時に動的に指定することができるため、便利になりますね。

foo: {{ env "FOO" "default_foo" }}

このような YAML を、環境変数 FOObar が設定されている状態で読み込むと

foo: bar

となりますし、FOO が未設定であればデフォルト値として

foo: default_foo

として読み込まれます。

また、環境変数が設定されていなければ panic することで、読みこみ時に確実に設定されていることを強要する {{ must_env "FOO" }} という記法もあります。

やっていることは単純で、先に Go の text/template環境変数を展開した上で YAML / JSON / TOML のパーサを通しているだけなので、ファイル自体が各フォーマットとして不正であっても展開後に正しい状態であれば、問題なく読み込むことができます。

とはいえエディタでの編集時にそれぞれのフォーマットとして正しく扱えてくれた方が楽なので、" " でクォートされた内部に展開する場合は、template の記法の方でバッククォートを用いるのがお薦めです。

{
  "foo": "{{ env `FOO` `default_foo` }}"
}

先述の ecspresso では、タスクとサービスの定義ファイル (JSON) の読みこみ時に go-config による環境変数展開が行われます。

{
  "taskDefinition": {
    "containerDefinitions": [
      {
         "image": "example.com/myapp:{{ must_env `IMAGE_TAG` }}",
         "environment": [
           {
             "name": "APP_SECRET",
             "value": "{{ must_env `APP_SECRET` }}"
           },
           {
             "name": "ENDPOINT",
             "value": "{{ env `ENDPOINT` `example.com` }}"
           }
         ]
      }
    ]
  }
}

典型的には、以下のような値を展開することを想定しています。

  • デプロイごとに変わる可能性が高い値
    • Docker イメージのタグなど
  • リポジトリには生で入れたくないクレデンシャルの類

特にクレデンシャル類は、direnv 等で使用される .envrc というファイルに記述した上で暗号化してリポジトリに保存し、デプロイ時に復号、環境変数に設定した上でデプロイを行うと便利に扱えると思います。

# .envrc
export APP_TOKEN="raw_value_of_token"

AWS KMS で暗号化した値を .envrc.encrypted として出力、リポジトリにはこれをコミット。

$ aws kms encrypt --key-id mykey \
       --plaintext fileb://.envrc \
       --output text --query CiphertextBlob \
       --output text \
    | base64 --decode > .envrc.encrypted

デプロイ直前に KMS で .envrc を復号し、環境変数に設定してデプロイ。

$ aws kms decrypt --ciphertext-blob fileb://.envrc.encrypted \
        --output text
        --query Plaintext \
     | base64 --decode > .envrc
$ source .envrc
$ ecspresso --config app.yaml deploy

まとめ

  • Amazon ECS 用のデプロイツール ecspresso を書きました
  • go-config は実行時に環境変数を展開しつつ設定ファイルを読み込めて便利です

sardine - mackerel plugin のメトリクスを CloudWatch で集約する agent を書いた

OSS紹介 Advent Calendar 2017 - Qiita 22日目の記事です。

f:id:sfujiwara:20171222113112j:plain

最近、監視を Zabbix から Mackerel に切り替えていっています。それと並行して、新規プロジェクトは Amazon ECS でコンテナで運用するようにもしていっています。そこで考えどころなのが、コンテナで動作するプロセスのモニタリングをどうするかです。

たとえば、コンテナで動作する nginx を mackerel-plugin-nginx で監視する場合、普通にやるとこんな感じになるのですが…

  • nginx と mackerel-agent を同一タスク (ECS用語) に定義する
  • mackerel-agent.conf で cloud_platform = "none"設定をして、コンテナがホストの EC2 とは切り離された状態でホストとして認識されるようにする

すべてのタスクを Mackerel 上のホストとして認識させることになると、いくつか困ることがあります。

  • 課金対象が増える
    • タスクは EC2 のホストなどよりかなり多くなるため、インパクトが大きい
    • 今後の Fargate 化を考えると、Fargate は最大4コアなので、多数のタスクを配置することになり EC2 で大きなインスタンスを動作させるよりもかなり数が増えそう
  • タスクはデプロイごとに入れ替わるので、ホストの入れ替わりイベントが大量に発生する
    • 自動退役すればみなくてよいとはいえ…

複数コンテナのメトリクスは、集約した状態で一つの値がみられれば用が足りることが多いため、何らかの形で集約メトリクスを実現したかったのですが、現状の Mackerel では同一時刻に登録したサービスメトリックの値は上書きされてしまいます。

そこで、CloudWatch で集約することを考えました。

CloudWatch では同一時刻に複数回送信した値を、合計、最大、最低、平均などの統計(statistics)を指定して取得することができるため、nginx でいうと RequestCount の合計なら単位時間内の総クエスト数、平均なら1コンテナあたりの平均リクエスト数、のように、目的に合わせて値を読み取れます。

sardine

github.com

mackerel-plugin (互換) のコマンドを実行し、得たメトリクスを CloudWatch へ投稿する agent として、sardine を書きました。 Go で実装されたシンプルな agent です。

命名は、mackerel(鯖)より小さいのが群れているので sardine(鰯) ということで。

[plugin.metrics.nginx]
command = "mackerel-plugin-nginx --host nginx --port 80 --path /nginx_status"
dimensions = ["Service=staging", "Service=staging,Task=app"]

このような、mackerel-agent.conf に類似した設定ファイルで定義をします。各 ECS タスクに同梱して動作させる想定です。

デフォルトでは60秒ごとにプラグインをコマンドとして実行し、たとえば得られた出力が以下だった場合に

nginx.requests.requests 123.0 1512057958

CloudWatch のメトリクスとしては以下の値を投稿します。

  • Namespace: nginx/requests
  • MetricName: requests
  • Value: 123.0
  • Timestamp: 2017-12-01T16:05:58Z

これで複数の同一種類のコンテナ、タスクから投稿された値を、大づかみにして把握できます。

f:id:sfujiwara:20171222121835p:plain

この集約されたメトリクスを、Fluentd を用いて (plugin-cloudwatch + plugin-macakrel) Mackerel に値を持っていくことで、Mackerel 上でグラフを並べてみることもできます。

f:id:sfujiwara:20171222121956p:plain

まとめ

  • コンテナ、タスク単位で Mackerel にホストを作らず、集約メトリクスを実現するために sardine を作りました
  • Mackerel 本体だけで、このような集約メトリクスが実現できると嬉しいです

Amazon CloudSearch にドキュメントを取りこむ Lambda 関数 s32cs のご紹介

このエントリは OSS紹介 Advent Calendar 2017 - Qiita 16日目の記事です。穴が空いていたので拙作の紹介で穴埋めを。

s32cs という Amazon CloudSearch に対して S3 からのイベントドリブンでドキュメントを投入する Lambda を書いたのでご紹介します。

github.com


3行で

  • Amazon CloudSearch にドキュメントを登録する Lambda を作った
  • アプリケーションからは Fluentd にログを送るだけ
  • Kinesis Firehose + S3 を利用することで、ストリームデータを 一定時間/一定サイズ に区切っての継続的なバッチ処理が容易かつ堅牢に

基礎知識

Amazon CloudSearch は AWS が提供している、フルマネージドな検索エンジンです。ドキュメント数が多くなったりすると勝手にスケール (アップ|アウト) してくれるので、キャパシティプランニングにそれほど気を遣うことなく全文検索を実装できます。

業務では数億(5より大きい)レコードを投入しているものもありますが、おおむね元気に動いてくれています。

CloudSearch へのデータの投入方法あれこれ

Amazon CloudSearch ドメインにデータをアップロード - Amazon CloudSearch

ここがちょっと癖があるところで、逐次レコードを登録するような、いわゆるストリーミングアップロード的なことはできず、投入するレコードが複数まとまった 5MBまでの JSON / XML ファイル (SDF) を用意してバッチ的に投げ込む API になっています。

素朴な方法

最初はものすごく素朴に、「5分ごとに DB から直近 5分のレコードを取得し、JSON に加工した上でアップロードする cron 処理」などで投入していました。

しかし、このような頻度が高い定期処理は、いろいろ面倒なことがあるのでできれば避けたいものです。

  • 前回の処理が何らかの原因で終わってない場合の排他処理
    • 特に流量が多くなると、並列処理で分散させるのが面倒になります
  • 失敗した場合のリカバリ
    • 前回処理が終わった最後のレコードを覚えていないといけない

また、レコードが削除されたというドキュメントも CloudSearch 側に反映しないといけないため、DBから物理削除してしまうと何らかの削除済みフラグを他に保存しておく必要があり、処理が複雑になります。

ken39arg/fluent-plugin-cloudsearch

そこで同僚の ken39arg が開発したのが fluent-plugin-cloudsearch です。Fluentd の output plugin として動作し、指定した時間/サイズごとにバッファを CloudSearch にアップロードするものです。

github.com

これによって、アプリケーションからはドキュメントの情報をログとして Fluentd に送信するだけでインデックスの更新ができるようになりました。ストリーミング処理ですね!

ただ、これもいくつか問題がありました。

  • 複数台で動作させると、ある1レコードの作成と削除が別々の Fluentd のバッファに保存される可能性がある
    • バッファのフラッシュタイミングによっては、作成→削除 ではなく 削除(空振り)→作成 という順で処理され、削除されたはずのレコードが消えてくれない
  • Fluentd のホストがダウンすると、バッファが失われる可能性がある
    • コンテナで動作させると、落ちた瞬間に失われるのでロストするリスクが大
  • 投入した SDF はどこにも保存されずに消えてしまうので、問題があった場合のリカバリが難しい

s32cs

ということで開発したのが s32cs です。名前はまったくいいキラキラネームが思いつかなかったので、「S3 to CloudSearch」という意味です。 Go + Apex で実装されています。

S3 にオブジェクトが配置された時のトリガで Lambda を実行し、

  • S3 からオブジェクトを取得
  • 以下のような 1行 1レコードの JSON をアップロード用の SDF 形式に加工
{"id":"123","type":"add","fields":{"foo":"bar","bar":["A","B"]}}
{"id":"123","type":"delete"}

[
  {"id":"123","type":"add","fields":{"foo":"bar","bar":["A","B"]}},
  {"id":"123","type":"delete"}
]
  • CloudSearch にアップロード

という動作を行います。

S3 に JSON を配置するときに fluent-plugin-s3 で行うと、fluent-plugin-cloudsearch 同様に作成と削除が入れ替わる可能性があるため、Firehose を経由することでレコードの発生順序を(できるだけ)直列化するのがお薦めです。

  1. アプリケーションは Fluentd に送信
  2. Fluentd は Kinesis Firehose に逐次送信
  3. Firehose は 5分 / 5MB 単位などで S3 にオブジェクトを保存
  4. s32cs が S3 のオブジェクトを加工してアップロード

これによって、fluent-plugin-cloudsearch であったいくつかの問題も解消しました。

  • 複数台で動作させると、ある1レコードの作成と削除が別々の Fluentd のバッファに保存される可能性がある
    • → Firehose へなるべく間隔をおかずに送信することでイベントの順序を保つ
  • Fluentd のホストがダウンすると、バッファが失われる可能性がある
    • → 短時間で Firehose へ送り出されるので、ダウン時の影響が小さい
  • 投入した SDF はどこにも保存されずに消えてしまうので、問題があった場合のリカバリが難しい
    • → S3 に元データが残っているので、再度別の箇所に投入したり、内容を確認することが容易

まとめ

Kinesis Firehose + S3 を利用することで、ストリームデータを 一定時間/一定サイズ に区切っての継続的なバッチ処理が Lambda で容易かつ堅牢に行えるようになります。

使いでのあるアーキテクチャパターンなので、今後も多用していきたいと思います。

fluent-logger-golang の実戦的な使いかたまとめ

OSS紹介アドベントカレンダー の14日目の記事です。

Fluentd の 公式 Go 版 Logger である fluent-logger-golang はこのように使うのがよさそう、という使い方をまとめてみました。 元々社内で書いておいたドキュメントを編集したものです。

github.com

前提のユースケース

Webアプリケーション(APIサーバ) を Go で書いていて、そこから何らかのログを Fluentd に送信したい。

config のお勧めオプション

  • Timeout : Connect に対するタイムアウト。デフォルト3秒なのでそのままでよさそう
  • WriteTimeout : 書き込みのタイムアウト。デフォルトだとずっと待ってしまうので 3 秒とか?
  • BufferLimit : デフォルト 8MB これを超えると捨てられてしまう。送る流量によって調整が必要
  • MaxRetry : この回数だけリトライして失敗すると panic する。Exponential back off でリトライ間隔が延び続ける(上限なし)ので、リトライを繰り返し続けると間隔が広がりすぎてつらいが、panic されるよりはマシなので大きめに設定しておく
  • AsyncConnect : fluent.New() するときに connect できなくても error を返さず、裏でリトライする。 起動時に接続先の Fluentd がちゃんと動いてない場合に気がつけない可能性があるので、false (default) がよさそう

fluent.New() 時に接続できない場合

  • 特にコンテナで動作させる場合など、アプリケーション起動時に Fluentd がまだ Listen できていない状態があり得る。 fluent.New() 時に接続できないと error が返るので、そこで失敗扱いにしてしまうとアプリケーションの起動が失敗することになる
  • config.AsyncConnect = true にすると、設定ミスなどで Fluentd がいつまでも起動してこない場合に困る

アプリケーションで、適切にリトライ処理を行うほうがよい。

import "github.com/Songmu/Retry"

var client FluentClient
err := retry.Retry(3, time.Second, func() (err error) { // 3回試行。失敗したら1秒待つ
    client, err = fluent.New(fluent.Config{})
    return err
})

Post() がエラーを返してきたらどうすべきか

Post()net.Conn.Write() が正常に返ってくれば成功するので、この時点で Fluentd へ接続しているソケットに書き込みは成功している。本当に受け取れているかはまだ分からない。

error が返ってくるのは以下の場合。

  • オンメモリバッファが溢れた → ログは捨てられてしまう
  • 再接続試行中 errors.New("fluent#send: can't send logs, client is reconnecting")
  • net.Conn.Write() が error を返した
    • 自動的に net.Conn.Close() が行われ、再接続が裏 (別 goroutine) で走る

error が返ってきたとしてもバッファが溢れない限りは積まれて再送されるが、その再送が最終的に成功するかどうかは不明なため、この時点で対処する方がよい。

また、バッファが溢れた場合はその時点で対処しないとリカバリする方法はない。

ごくごく単純に書くとこう。

if err := logger.Post(tag, x); err != nil {
    log.Println(tag, x) // stderr にだしちゃう
}

実際はリカバリを考えて、再処理しやすい format で別の場所に書き出しましょう。

struct を投げるときの留意点

struct については何もしなくても msgpack でエンコードしてくれるが、public field が大文字はじまりなのでログの key も大文字になってしまう。

msgp を使って struct に対して MarshalMsg() を生成しておくと、それが使われる。

import "github.com/tinylib/msgp/msgp"

//go:generate msgp
type Foo struct {
    Foo int    `msg:"foo"`
    Bar string `msg:"bar"`
}

アプリケーションを shutdown する処理を書くときの留意点

Close() を呼ぶと、その時点で内部に持っているバッファがあればそれは送信を試みた上で終了する。ただし、そこで失敗した場合にリカバリする方法はない。 (バッファ自体は private なので、アプリケーションから触ることができない)

Post() で送信失敗してバッファに積まれるということは接続先が落ちている状況なので、その状況で Close() を呼んだとしても、再送に成功する可能性は高くない。

そのため、ロストしては困るログについては、Post() 失敗時点で他の箇所に書き込むなどの対応が必須。そうしていれば Close() は必ずしも呼ぶ必要はない。 (呼んで困ることはないので呼べるなら呼びましょう)


この元の文書を書いた時点では、go-fluent-client は同期書き込み (ソケットに書き込めてからアプリケーションに処理を戻す) がサポートされていなかったため、要件に合わずに採用しませんでしたが、最近同期モードもサポートされたようなので、go-fluent-logger も検討してみたいですね。

medium.com

aswrap - ~/.aws/(config|credentials) で定義した AssumeRole 定義から一時キーを取得してコマンドを起動してくれる wrapper を書いた

業務では多数の AWS アカウントを運用しています (現時点でアクティブなのは100行かないぐらい)。

AWS アカウントごとに利用者それぞれに IAM User や IAM key を発行するのは権限管理が煩雑になるため、以下のようなアカウント運用をしています。

  1. ログインを集約する専用の AWS アカウントを用意 (account A とします)
    • このアカウントに IAM User を作成し、IAM key を発行する
  2. 各案件用の AWS アカウント(account B) に IAM Role を定義し、Assume Role によって権限を付与

(最近 AWS Organization が Single Sign On に対応したので、今後は不要になるのかもしれませんが…)

こうしておくことで、AWS console には account A でログインした上で、各アカウントにロールの切り替えで遷移することができます。

また、aws-cli では以下のような定義を ~/.aws/credentials 等に記述しておくことで、aws --profile service1 ... として実行すれば自動的に一時キーを取得して account B に対してアクセスすることができます。

# account A
[kayac-iam]
aws_access_key_id=XXXXXXX
aws_secret_access_key=YYYYYYY

# account B
[service1]
role_arn=arn:aws:iam::9999999999:role/InfraTeam
source_profile=kayac-iam

dev.classmethod.jp

aws-cli 以外での問題

Terraform 等、aws-cli ではない AWS SDK を利用したアプリケーションを実行する際には、上記の記述での一時キー解決が動作しません。

そのため、Insntance Profile が付与された EC2 上で実行するか、IAM User を account B に作成してそのキーを使う必要がありました。 しかし、各アカウントで個別に IAM User を作成してしまうと管理が面倒ですし、キーを複数人で共有したりする問題が起きやすくなります。

ということで、思い立って aswrap という wrapper コマンドを書きました。

github.com

このコマンドは、~/.aws/(config|credentials) に定義されてる profile を元に aws sts assume-role で一時キーを取得し、それを環境変数 AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN に設定した上で引数に渡したコマンドを exec する、というものです。

$ AWS_PROFILE=service1 aswrap terraform plan

(terraform plan を一時キー環境変数設定済みの状態で実行する)

また、引数なしで起動すると環境変数を export する shell command を出力するので、eval することで現在の shell に環境変数を設定できます。

$ eval "$(AWS_PROFILE=service1 aswrap)"
$ aws sts get-caller-identity   # service1 の credential で実行される

ということで、aswrap を利用すると、aws-cli と同様の profile 管理で多数のコマンドが実行できるようになります。便利!

Perl 製ですが、fatpack してあるので 5.14.0 以降(または JSON::PP がインストールされていればそれ以下でも) なら、特に依存はなくファイル単体で利用できるはずです。

alp と Plack::Middleware::QueryCounter を合わせて使うと捗る

OSS紹介 Advent Calendar 2017 - Qiita 4日目の記事です。

@tkuchiki 氏が作っている alp (Access Log Profiler) は、もはや ISUCON 競技者必須ツールとなった、LTSV 形式のアクセスログをいい感じに集計してくれるツールです。 github.com

通常は alp では reqtime, apptime など、リクエストの処理に要した時間を集計するこのでパフォーマンスチューニングするのですが、実は集計対象は引数 --apptime-label を指定することで、集計時に自由に決めることができます。パフォーマンスに影響するなんらかの数値をログに出力しておけば、それを key にして集計できるということですね。

そこでもうひとつ、@acidlemon 氏作の便利 Plack::Middleware を組み合わせてみました。

metacpan.org

Plack::Middleware::QueryCounter::DBI は enable するだけで、DBIx::Tracer を使ってそのリクエスト中の DBI でのクエリ発行数を計測し、レスポンスヘッダに出力してくれます。

    log_format ltsv 'host:$remote_addr\t'
    # (snip)
                    'query_total:$upstream_http_x_querylog_total\t'
                    'query_read:$upstream_http_x_querylog_read\t'
                    'query_write:$upstream_http_x_querylog_write\t'
                    'query_other:$upstream_http_x_querylog_other\t'

ということで、nginx ではそのヘッダを LTSV 形式でログに残すようにすれば…

$ alp -r --avg --apptime-label="query_total" < access.log
+-------+--------+---------+----------+--------+-----------+-----------+------------+-----------+--------+-------------------------------------------------------+
| COUNT |  MIN   |   MAX   |   SUM    |  AVG   | MAX(BODY) | MIN(BODY) | SUM(BODY)  | AVG(BODY) | METHOD |                          URI                          |
+-------+--------+---------+----------+--------+-----------+-----------+------------+-----------+--------+-------------------------------------------------------+
| 5     | 35.000 |  35.000 |  175.000 | 35.000 |  2119.000 |  2430.000 |  11479.000 |  2295.800 | POST   | /api/xxxxxxx/top                                      |
| 51    |  6.000 | 474.000 | 1765.000 | 34.608 |    38.000 |   656.000 |   3741.000 |    73.353 | POST   | /api/yyyyyy/action                                    |
| 1     | 19.000 |  19.000 |   19.000 | 19.000 |  2825.000 |  2825.000 |   2825.000 |  2825.000 | GET    | /api/user                                             |
| 5     | 17.000 |  18.000 |   87.000 | 17.400 |  1527.000 |  1588.000 |   7807.000 |  1561.400 | POST   | /api/zzzzzz/info                                 |
....

どこの path の処理中にクエリを大量に発行しているのかが一目瞭然ですね。

ベンチマーク中に大変便利だったのでご紹介でした。