導入事例：scarf.sh導入によるOSSの利用動向分析

クリアコードではログデータ収集ソフトウェアの1つである Fluentdの継続的な開発に参加しています。その成果の1つとして、Fluentdのエンタープライズにおける長期運用に適したLTS版のパッケージ（Fluent Package）の提供を主導しています。

本記事では、配布しているパッケージの利用動向に関して、scarf.shを導入して簡単に把握できるようにする方法について紹介します。

scarf.sh導入の背景

かつてFluentdに各種プラグインを統合したオールインワンパッケージとして提供されていたのがTD Agentです。これをリブランディングして提供を開始したのがFluent Packageです。リリース体制等も刷新した最初のリリースはFluent Package v5.0.0で2023年8月のことでした。

それから、v6.0.0へのメジャーバージョンアップを経て現在もv6のLTSの提供を続けています。

Fluentdをとりまく状況はFluent Package提供開始時点から大きく変化しています。 v7で対応するディストリビューションの選定を含め、今後のFluent Packageの提供方針を検討するうえで、利用動向の分析は欠かせません。しかし、開発者側で適度な粒度の利用動向の情報を得られるしくみは整っていませんでした。

幸いFluentdはCNCF傘下のプロジェクトであり、scarf.shからCNCF枠としてスポンサー利用できることがわかったため、 CNCFに申請して導入をしてみることとしました。

利用が多いディストリビューションやバージョンのサポートを優先したり、EOLを判断したりする際の参考になることを期待しています。計測するのは、Scarfを経由したパッケージやリポジトリメタデータへのアクセスです。稼働中の環境数を直接示すものではありませんが、ディストリビューションやバージョンごとの利用動向を推測する材料として活用します。

導入前後のFluent Package配布のしくみ

導入前の状況は次のとおりでした。

docs.fluentd.orgのインストール手順において、インストール用の簡易スクリプトを案内している
deb、rpm、msiなどのパッケージをCNCFによるCloudflare R2リソースを利用して提供している
しかし該当Cloudflare R2に関するアナリティクスデータへのアクセス権限はFluentd開発者にはない
サブドメイン追加などの権限はfluentd.orgに関して与えられている

導入後の構成は次のとおりとしました。

docs.fluentd.orgのインストール手順において、インストール用の簡易スクリプトを案内（参照するURLを https://packages.fluentd.org に変更し、新規インストールはこのドメインを利用するようにした）
実際のパッケージについてはCNCF提供のCloudflare R2からインストールしてもらうのは変更なし
Cloudflare R2の前段にscarf.shを導入
直接scarf.shを見せるのではなく、 https://packages.fluentd.org をNetlifyで提供し、Edge Functionsでリダイレクト先を切り替える。IPv4の場合は https://fluentd.gateway.scarf.sh へとリダイレクトし、IPv6の場合は直接 https://fluentd.cdn.cncf.io へとリダイレクトする
scarf.shのカスタムドメイン機能（scarf.shのサブドメインに独自ドメインを割り当てる機能）は利用せず、fluentd.gateway.scarf.shからのリダイレクト先をfluentd.cdn.cncf.ioにしている

IPv4とIPv6のときの流れを示したものが次の図です。（なぜこのような分岐が必要だったかについては「scarf.shでの注意事項」で後述します。）

このようにすることで、仮に今後scarf.shが利用できなくなることがあったとしても、影響を最小限にすることができます。（scarf.shで障害が起きた場合は、Netlify Edge Functionsのリダイレクト先をfluentd.cdn.cncf.ioへ変更し、利用者側の設定を変えずにCDNへ直接つなぐよう切り替えられます。ただし、切り替えが終わるまでは、packages.fluentd.orgを利用したインストールも更新も失敗します。その間は fluentd.cdn.cncf.io を直接使えば回避できます）

上記変更にともない、ご利用環境によっては、明示的に以下のサイトへのアクセスが許可されている必要があります。

packages.fluentd.org (新規)
fluentd.gateway.scarf.sh (新規)
fluentd.cdn.cncf.io

scarf.shではどのような設定をすればよいのか

scarf.shにはさまざまな機能が提供されていますが、Fluent Packageでの利用目的はパッケージがどのくらい実際に利用されているのかを把握することです。¹

そのため、次のような方針としました。

Fluent Packageは通常版とLTS版の2系統があるので、Fluent Package（通常版）とFluent Package（LTS版）、検証用の3つのscarf.shのFileパッケージを作成（scarf.shではパッケージ単位で設定を管理します）
各パッケージにリダイレクトさせるためのrouteを複数定義して、scarf.shでトラッキングしつつ、リクエストをCloudflare R2へとリダイレクトする

scarf.shでは例えば次のようにリダイレクトのためのrouteを定義します。（一部抜粋。検証環境の事例）

Desired path format:
/test/experimental/{release}/{distro}/{distro_version}/{arch}/repodata/{+path}
File location:
https://fluentd.cdn.cncf.io/test/experimental/{release}/{distro}/{distro_version}/{arch}/repodata/{+path}

Desired path format:
/test/experimental/{release}/{distro}/{distro_version}/{arch}/fluent-package-{version}-{revision}.el{distro_version}.{arch}.rpm
File location:
https://fluentd.cdn.cncf.io/test/experimental/{release}/{distro}/{distro_version}/{arch}/fluent-package-{version}-{revision}.el{distro_version}.{arch}.rpm

Desired path format:
/test/experimental/{release}/{distro}/{distro_version}/pool/contrib/f/fluent-package/fluent-package_{version}-{revision}_{arch}.deb
File location:
https://fluentd.cdn.cncf.io/test/experimental/{release}/{distro}/{distro_version}/pool/contrib/f/fluent-package/fluent-package_{version}-{revision}_{arch}.deb

Desired path formatがユーザーからのリクエストで、File locationでファイルの提供元にマッピングしてリダイレクトさせます。

上記で抜粋したのはRPMのメタデータや、RPM、DEBファイルへのリクエストをCloudflare R2側にリダイレクトさせる設定です。 {release}や{distro}といった任意の変数を定義することができます。

このように変数を定義すると、たとえば、/test/experimental/6/redhat/10/x86_64/repodata/...(省略)のようなリクエストがあったときに、 {release}が6、{distro}にredhatといったように、分析の軸となる単位で集計できるようになります。

{+path}だけ特殊で、いわゆるワイルドカードでマッチさせるための変数です。 repodataの場合はリポジトリのメタデータを更新するたびにパスが変わるため、固定のパスを設定しなくてすむメリットがあります。（{+path}を使わずに固定パスでrouteを定義していた場合、メタデータを更新したときにマッチしなくなり、メタデータを正常に取得できない不具合が発生することになります。）

scarf.shで集計するとどうなるか（サンプルデータ）

以下はscarf.shの動作確認用にFileパッケージを作成してみたときのサンプルデータでの例です。

Fluent Packageの場合はURLに利用動向分析の軸となる情報が含まれているため、debやrpmのリポジトリに対して導入すると、利用動向の分析と非常に相性がよいということがわかります。

scarf.shでの注意事項

Fileパッケージに適宜リダイレクトのためのルールを定義すれば、簡単に利用動向を分析するプラットフォームとしてscarf.shを使えて便利です。しかし、いくつか利用時の注意点があります。

routeの定義はパッケージごとに行うが、他のパッケージの定義と干渉することがある

パッケージAとパッケージBでどちらかに幅広くマッチしてしまうルールが存在していると、もう一方のルールが期待通りに動作しません。その場合には、Desired path format:で重複してマッチしないようにルールを工夫する必要があります。

Fluent Packageの場合は、インストールスクリプトでそのようなケースがありました。例えば、次のようなパターンだと問題があります。

fluent packageパッケージの定義

Desired path format:
/sh/install-{target}.sh
File location:
https://fluentd.cdn.cncf.io/sh/install-{target}.sh

fluent package LTSパッケージの定義

Desired path format:
/sh/install-{target}-lts.sh
File location:
https://fluentd.cdn.cncf.io/sh/install-{target}-lts.sh

Desired path format:が/sh/install-{target}.shだと、LTS側を想定したリクエストにもマッチしてしまいます。そのため、/sh/install-{target}-std.shというように区別するための識別子を付与して、実際のファイル（https://fluentd.cdn.cncf.io/sh/install-{target}.sh）へリダイレクトするルールにする必要がありました。

パッケージのメトリクスをリセットする方法がない

事前にある程度検証したうえで、本番稼働しようとしたとき、テストで収集されたメトリクスデータをリセットしてやりなおしたくなることがあります。

しかし、scarf.shにはそのような機能はない（2026年10月時点）ため、パッケージにひもづいたメトリクスをリセットするにはパッケージをいったん削除するしか方法がありません。

再度設定するのは面倒と思うかもしれませんが、幸いAPIが提供されているので、route定義を事前にバックアップしておけば、新規に作り直すことも容易にはなっています。

例えば、次のようなスクリプトを用意すれば、fluentd organizationの各パッケージごとのroute定義をバックアップできます。（package一覧とroute定義はどちらもページングに注意してください。次の例は1ページ目を取得するもので、route定義はper_page=30にしているため30件を超えると取りこぼします）

YYYYMMDD=$(date +'%Y%m%d')
for entry in $(curl --silent --header "Authorization: Bearer ${SCARF_API_TOKEN}" \
                              https://api.scarf.sh/v2/packages/fluentd | \
                             jq --raw-output '.results[] | "\(.id),\(.name)"'); do
  package_id=$(echo "$entry" | cut -d',' -f1)
  package_name=$(echo "$entry" | cut -d',' -f2)
  curl --silent --header "Authorization: Bearer ${SCARF_API_TOKEN}" \
       "https://api.scarf.sh/v2/packages/fluentd/${package_id}/routes?per_page=30" > ${package_name}.${YYYYMMDD}.json
done

その後Fileパッケージを作り直した後、次のようにrouteを追加するAPIを呼び出すことで、以前と同様のFileパッケージを再構築できます。（incoming_pathとoutgoing_urlをあらかじめバックアップしていたファイルから適宜埋める）

curl --silent --show-error --request POST \
                        --header "Authorization: Bearer ${SCARF_API_TOKEN}" \
                        --header "Content-Type: application/json" \
                        --data "{ \
                               \"type\": \"uri-template\", \
                               \"incoming_path\": \"${incoming}\", \
                               \"outgoing_url\": \"${outgoing}\" \
                        }" \
                        "https://api.scarf.sh/v2/packages/fluentd/${package_id}/routes"

IPv6 はサポートされない

2026年10月現在、scarf.shはIPv6をサポートしていません。また直近でサポートする予定もないとされています。

したがって、IPv6で接続する場合もIPv4と同じ手順でインストールできるようにするには、サブドメインのCNAMEを利用してカスタムドメインをFileパッケージに適用するのは推奨されません。疎通できない環境ができてしまうためです。

利用動向の把握と、利便性のバランスをとるため、Fluent PackageではIPv6のみの環境についてはscarf.shの利用はしないことに決めました。将来的にscarf.shがサポートしたら対応予定です。

IPv4/IPv6で同じインストール手順とするために、packages.fluentd.org では、IPv4およびIPv6でのアクセスかを判定する処理をはさむことにしました。 IPv4の場合は scarf.shへリダイレクトし、IPv6の場合はscarf.shにアクセスさせず直接 fluentd.cdn.cncf.ioへとリダイレクトする構成です。

すでにFluentdのウェブサイト等でNetlifyを利用しているので、packages.fluentd.orgのプロジェクトを作成し、NetlifyのEdge Functionsを利用して振り分けるようにしました。

IPv4のときと、IPv6のときの挙動の違いは次のようにして確認できます。

$ curl -6 -I https://packages.fluentd.org/6/index.html
HTTP/2 302 
cache-control: no-store
date: Thu, 22 Oct 2026 03:00:17 GMT
location: https://fluentd.cdn.cncf.io/6/index.html
server: Netlify
strict-transport-security: max-age=31536000
x-nf-request-id: 01M5GRTQTR46Z73A79HS7W1YBS
content-length: 0

$ curl -4 -I https://packages.fluentd.org/6/index.html
HTTP/2 302 
cache-control: no-store
date: Thu, 22 Oct 2026 03:00:20 GMT
location: https://fluentd.gateway.scarf.sh/6/index.html
server: Netlify
strict-transport-security: max-age=31536000
x-nf-request-id: 01M5GRTTPTJQ1JS74YP9Y8T5MJ
content-length: 0

さいごに

本記事では、配布しているパッケージの利用動向に関して、scarf.shを導入してOSSの利用動向を簡単に把握できるようにする方法を紹介しました。

ここまでの説明は、新規にFluent Packageを導入するケースを計測するためのものでした。すでにパッケージをインストール済みの環境を捕捉することはできません。既存の導入済み環境も測定できるようにするには、別途参照するリポジトリを更新するためのパッケージ（Fluent Packageの場合はすでにfluent-lts-releaseやfluent-lts-apt-sourceを配布している）を更新するなどの手立てが必要です。

その点に関しては、近々Fluent Package v6.1.0をリリースするので、その際にリポジトリを参照できるようにするパッケージもあわせて更新して集計の対象に加えることを計画しています。ユーザーが集計の対象外としたい場合には、直接fluentd.cdn.cncf.ioを参照させることで回避できます。fluentd.cdn.cncf.ioを直接参照する手段自体は廃止の予定はありません。

切り替えに関してはv6.1.0のリリースアナウンスでも改めて告知予定です。

アクセスしてきたaptやdnfクライアントや、アクセス元の国に関してはFluentdの開発者がscarf.shの管理画面で閲覧できるようになっていますが、IPアドレスは開示されないようになっています。 https://about.scarf.sh/privacy-policy/ ↩

ククログ