febc技術メモ

なぜ作ったの?

=== 2024/04/01 : WHYを書いてなかったので追記

OpenTelemetry Collectorもエスクポート時のエラーくらいは表示してくれているのですが、例えば以下のような表示でどのようなエラーかは表示してくれずでした。

otel-collector-1  | 2025-03-31T01:39:13.094Z error   exporterhelper/retry_sender.go:145  Exporting failed. The error is not retryable. Dropping data.    {"kind": "exporter", "data_type": "logs", "name": "otlphttp", "error": "Permanent error: error exporting items, request to (バックエンドのURL)/v1/logs responded with HTTP Status Code 500", "dropped_items": 1}

上記の場合実はバックエンド側で↓のようなエラーが出ている状況だったのですがここから気づくのは無理ゲーでした... (以下の出力はotlp-http-spyからの出力)

=== Forwarded Response Headers ===

HTTP/2.0 500 Internal Server Error
Content-Length: 57
Content-Type: text/plain; charset=UTF-8
Date: Mon, 31 Mar 2025 01:39:13 GMT
(中略)

=== Raw Response ===

Unknown error: Timestamp is too old. 1970-01-01T00:00:00Z

OpenTelemetry Collectorが詳細なエラー出力をしてくれれば良いのですが、現時点ではOTLP/HTTPエクスポーターはエクスポーターがどのようなリクエスト/レスポンスをやりとりしたのかを出力する術を持っていないようでした。最初はOTLP/HTTPエクスポーターのHTTPクライアントのTransportにリクエスト/レスポンスをダンプするようなRoundTripperを噛ませようとしたのですが、OTLP/HTTPエクスポーターのコードに手を入れるよりは別途プロキシを作った方が楽という判断でした。

=== 2024/04/01追記ここまで

OpenTelemetry Collectorとの連携例

otlp-http-spy を OTLP/HTTPを受け付けるバックエンドの前段に挟むことで、バックエンドに送られる前のOTLP/HTTPリクエストやレスポンスを可視化できます。

[アプリケーション]
       |
       v
[OpenTelemetry Collector]
       |
       v
[otlp-http-spy]  ←★ リクエストをログにダンプ
       |
       v
[モニタリングスイートなどのOTLP/HTTPを受け付けるバックエンド]

この構成では、アプリケーションは OTLP/gRPCなどでOpenTelemetry Collectorにエクスポートし、OpenTelemetry Collectorがotlp-http-spy に対しOTLP/HTTP でエクスポート、otlp-http-spy はそのリクエストをダンプしつつバックエンドにフォワードします。

Collectorの設定例

Collector 側では、通常の otlp receiver を使い、Exporter に otlp-http-spy を示すために otlphttp/spy というエイリアス名を使うと分かりやすくなります。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:

exporters:
  debug:
    verbosity: detailed
  otlphttp/spy:
    endpoint: http://localhost:4318
    compression: none

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [debug, otlphttp/spy]

    metrics:
      receivers: [otlp]
      processors: []
      exporters: [debug, otlphttp/spy]

    logs:
      receivers: [otlp]
      processors: []
      exporters: [debug, otlphttp/spy]

インストールと実行方法

Dockerを使用する場合

docker run --rm -p 4318:4318 -e ENDPOINT=https://your-otlp-http-backend ghcr.io/yamamoto-febc/otlp-http-spy:latest

GitHub Releasesからダウンロードする場合

以下から任意のプラットフォーム向けの実行ファイルをダウンロード

ENDPOINT=https://your-otlp-http-backend  otlp-http-spy

go installする場合

go install github.com/yamamoto-febc/otlp-http-spy@latest

ENDPOINT=https://your-otlp-http-backend  otlp-http-spy

ログ出力例

===> Received OTLP request:  /v1/logs

=== HTTP Request Headers ===
POST /v1/logs HTTP/1.1
Host: localhost:4318
Content-Type: application/x-protobuf

=== OTLP Message (Request) ===

{
  "resourceLogs": [
    ...
  ]
}

=== Forwarded Response Headers ===
HTTP/1.1 200 OK
Content-Type: application/x-protobuf

=== OTLP Message (Response) ===

{
  "partialSuccess": {
    "rejectedLogRecords": 0
  }
}

おわりに

otlp-http-spyは、OTLP/HTTP通信の内容を詳細に確認し、OpenTelemetryのデバッグを効率化するためのツールです。OTLP/HTTPでの通信を人が読める形でダンプすることでOpenTelemetry Collectorやバックエンドが受け取る前のリクエストやレスポンスを直接観察できます。開発中のプロジェクトではありますが、実用性のある最小限の機能がすでに利用可能です。

ぜひ試してみて、フィードバックなどお寄せください！

入門 OpenTelemetry ―現代的なオブザーバビリティシステムの構築と運用

作者:Ted Young,Austin Parker
オーム社

実践 OpenTelemetry ―オープンなオブザーバビリティ標準を組織に導入する

ファシリテーション・グラフィック[新版]　議論を「見える化」する技法 (日本経済新聞出版)

2024-11-27

ウェブアクセラレータのアクセスログをSQLで集計してみた(clickhouse-local編)

ウェブアクセラレータでアクセスログのアップロード機能が提供開始されました。

www.sakura.ad.jp

これはウェブアクセラレータのアクセスログをさくらのクラウドのオブジェクトストレージにアップロードしてくれる機能です。

オブジェクトストレージにファイルがあれば clickhouse-localなどを用いてSQLが投げれるはず、ということで早速試してみました。

(※ 免責: 掲載内容は私自身の個人的な見解であり、必ずしも所属する企業や組織の立場、意見を代表するものではありません)

準備1: オブジェクトストレージへアクセスログをアップロードするための設定

まずはマニュアルに従ってオブジェクトストレージとウェブアクセラレータの設定を行います。

manual.sakura.ad.jp

設定したらログがアップロードされるまでしばらく待ちます。 (現在の仕様だと1時間ごとにアップロードされるようです)

準備2: SQLを投げるための準備(clickhouse-local)

今回は clickhouse-localを用います。

clickhouse.com

認証情報の準備(AWSプロファイル)

認証のために~/.aws配下にconfigとcredentialを登録しておきます。

$ vi ~/.aws/config

[default]
region = jp-north-1
output = json
endpoint_url = https://s3.isk01.sakurastorage.jp

$ vi ~/.aws/credentials

[default]
aws_access_key_id = {発行したオブジェクトストレージへのアクセスキーID}
aws_secret_access_key = {発行したオブジェクトストレージのシークレットアクセスキー}

clickhouse-localの実行

今回はdockerで実行します。

$ docker run -it --rm -v $HOME:/root/ clickhouse/clickhouse-server:latest clickhouse-local -m

SQLを投げてみる

以下のようなSQLでアクセスログにクエリすることができます。

SELECT *
    FROM s3(
        'https://{バケット名}.s3.isk01.sakurastorage.jp/アクセスログのオブジェクトのパス',
        'JSONEachRow'
    ) ;

バケット名がexample、アクセスログのオブジェクトへのパスが sakura-webaccelerator/example.user.webaccel.jp/2024/11/27/access-20241127T13.log.gzの場合は以下のようになります。

SELECT *
    FROM s3(
        'https://example.s3.isk01.sakurastorage.jp/sakura-webaccelerator/example.user.webaccel.jp/2024/11/27/access-20241127T13.log.gz',
        'JSONEachRow'
    ) ;

なおバケット内にアクセスログしか置いていないなら以下のようにしてもOKです。

SELECT *
    FROM s3(
        'https://{バケット名}.s3.isk01.sakurastorage.jp/**.gz',
        'JSONEachRow'
    ) ;

利用できるワイルドカードについてはこちらを参照ください。

clickhouse.com

結果確認

私の環境だと以下のような結果となりました(一部情報を加工してマスクしてます)

   ┌─time──────────────────────┬─http_host─────────────────┬─scheme─┬─remote_addr───┬─remote_port─┬─remote_user─┬─request───────────────────┬─status─┬─bytes_sent─┬─body_bytes_sent─┬─referer───────────────────────────┬─x_cache─┬─msec───────────┬─request_id───────────────────────┬─user_agent────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
1. │ 2024-11-27T13:28:34+09:00 │ xxx.user.webaccel.jp      │ http   │ 192.0.2.1     │ 46145       │             │ GET / HTTP/1.1            │ 200    │ 3590       │ 3068            │                                   │ MISS    │ 1732681714.282 │ xxx                              │ Mozilla/5.0 ...                                                                                                       │
2. │ 2024-11-27T13:28:34+09:00 │ xxx.user.webaccel.jp      │ http   │ 192.0.2.1     │ 46145       │             │ GET /index.html  HTTP/1.1 │ 200    │ 1376       │ 855             │ http://example.user.webaccel.jp/  │ MISS    │ 1732681714.518 │ xxx                              │ Mozilla/5.0 ...                                                                                                       │
3. │ 2024-11-27T13:28:35+09:00 │ xxx.user.webaccel.jp      │ http   │ 192.0.2.1     │ 46145       │             │ GET / HTTP/1.1            │ 200    │ 3590       │ 3068            │                                   │ MISS    │ 1732681715.550 │ xxx                              │ Mozilla/5.0 ...                                                                                                       │
4. │ 2024-11-27T13:28:35+09:00 │ xxx.user.webaccel.jp      │ http   │ 192.0.2.1     │ 46145       │             │ GET /style.css HTTP/1.1   │ 200    │ 1376       │ 855             │ http://example.user.webaccel.jp/  │ MISS    │ 1732681715.659 │ xxx                              │ Mozilla/5.0 ...                                                                                                       │
   └───────────────────────────┴───────────────────────────┴────────┴───────────────┴─────────────┴─────────────┴───────────────────────────┴────────┴────────────┴─────────────────┴───────────────────────────────────┴─────────┴────────────────┴──────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

DESCRIBEした結果はこんな感じでした。

    ┌─name────────────┬─type─────────────┬─default_type─┬─default_expression─┬─comment─┬─codec_expression─┬─ttl_expression─┐
 1. │ time            │ Nullable(String) │              │                    │         │                  │                │
 2. │ http_host       │ Nullable(String) │              │                    │         │                  │                │
 3. │ scheme          │ Nullable(String) │              │                    │         │                  │                │
 4. │ remote_addr     │ Nullable(String) │              │                    │         │                  │                │
 5. │ remote_port     │ Nullable(String) │              │                    │         │                  │                │
 6. │ remote_user     │ Nullable(String) │              │                    │         │                  │                │
 7. │ request         │ Nullable(String) │              │                    │         │                  │                │
 8. │ status          │ Nullable(String) │              │                    │         │                  │                │
 9. │ bytes_sent      │ Nullable(String) │              │                    │         │                  │                │
10. │ body_bytes_sent │ Nullable(String) │              │                    │         │                  │                │
11. │ referer         │ Nullable(String) │              │                    │         │                  │                │
12. │ x_cache         │ Nullable(String) │              │                    │         │                  │                │
13. │ msec            │ Nullable(String) │              │                    │         │                  │                │
14. │ request_id      │ Nullable(String) │              │                    │         │                  │                │
15. │ user_agent      │ Nullable(String) │              │                    │         │                  │                │
    └─────────────────┴──────────────────┴──────────────┴────────────────────┴─────────┴──────────────────┴────────────────┘

項目の詳細は以下にドキュメントがありますのでこれを見ながら色々すれば良さそうです。

manual.sakura.ad.jp

これを使えばアクセス数ランキングを出したり、キャッシュにヒットしなかったリクエストの割合を数えたりと色々できそうです。

アクセス数集計の例:

SELECT COUNT(*) as count, request
    FROM s3(
        'https://{バケット名}.s3.isk01.sakurastorage.jp/**.gz',
        'JSONEachRow'
    ) 
GROUP BY request
ORDER BY count DESC
;


   ┌─count─┬─request───────────────────┐
1. │     2 │ GET / HTTP/1.1            │
2. │     2 │ GET /news/sp.php HTTP/1.1 │
   └───────┴───────────────────────────┘

終わりに

ということでウェブアクセラレータのアクセスログをオブジェクトストレージにアップロードしつつSQLを投げてみました。
今回は以上です。

2023-12-05

Working Backwards - プレスリリースから始める社内勉強会

さくらインターネット Advent Calendar

この記事はさくらインターネット Advent Calendar 2023 5日目の記事です。

こんにちは、さくらインターネットの山本です。去年に引き続きSRE室という部署で働いています。

今回の記事について

今回はチーム運営支援の一環としてファシリテーション/ファシリテーショングラフィックについての社内勉強会を企画した時にWorking Backwardsという考え方を取り入れてみたのでその体験談を投稿いたします。

「Working Backwards」とは

Working Backwardsとはこちらの記事によると

Working Backwardsでは「お客様は誰ですか？」から始まる5つの質問を通じて、本当に必要なサービスを企画・開発していく。
具体的にはプレスリリースを書くことでこれからつくるプロダクトやサービスを明確にし、FAQを作成することでより具体的な体験として考えるための手法である。
(引用元: Amazonのイノベーションを支える「Working Backwards」とは？)

とのことです。

ファシリテーション勉強会を開催するにあたり@zembutsuさんに相談したところこの手法を使ってみてはどうか？とアドバイスいただいたため早速使ってみることにしました。

「プレスリリース」と「FAQ」を通じて企画を考える

今回は社内勉強会のため実際にプレスリリースを出すわけではないですが、参加者を募る際には勉強会についてのアナウンスを行いますのでそれをプレスリリースと見なすことにしました。

まずはじめにお客様を「全社員のうちファシリテーションを学びたい方々」とし、「望ましい顧客体験とは何か？」というところから考えてみました。

「望ましい顧客体験」を考えてみる

せっかく参加するなら1人で読書するだけでは得られないものが欲しいな、とか今感じている問題を解決できたら嬉しいな、すぐに業務に役に立つ/業務が改善できるものだと嬉しいな、などと考えた結果以下2つを望ましい顧客体験と定義しました。

座学だけではなく体験や実践ができること
業務に直接役立つ学びがあること

「望ましい顧客体験」から逆算して詳細を考えてみる

次に定義した望ましい顧客体験を実現するために必要な要素を考えてみました。

座学だけではなく体験や実践ができること

教師−生徒という関係だと座学みたいになりそうだから「学びたい人たちが集まって自分たちで学ぶ」ようにしよう
なるべく一人一人がたくさんの体験/実践を出来るように少人数のグループ制にしよう

業務に直接役立つ学びがあること

何を目指す勉強会なのか明確にしよう
ファシリテーションが役に立つようなシチュエーションを詳細にイメージできるようにしよう
具体的なツールの使い方についても学べる/体験できるようにしよう

「FAQ」を考えて詳細を詰める

次に「自分が勉強会に参加するのであれば何が気になるか？」という視点からFAQを考えて詳細を詰めることにしました。ここではオーソドックスに5W1Hの視点を用いました。

Why: なぜ？

Q: この勉強会はどんな勉強会ですか？
- A: ファシリテーションについて学ぶ、実践する、マインドセットやスキル、ツールの活用方法などを習得する

What：何を？

Q: この勉強会に参加すると何を得られるのですか？
- A: 以下の習得を目指す
  - ファシリテーターとしてのマインドセット
  - ファシリテーション・グラフィックをはじめとしたファシリテーションのスキル
  - Miroなどのオンラインホワイトボードの使い方

When: いつ？

Q: どれくらいの期間なのか？
- A: 毎週1回/全8回を想定
Q: どのくらいの時間を使うのか？
- A: 勉強会が毎回1時間とすると全8回で8時間、事前に教材を読む時間として2時間程度、合計10時間程度

Where: どこで？

Q: この勉強会はどこで開催されるのですか？
- A: 弊社ではリモートワークを前提とした働き方を採用しているためこれに合わせフルリモートで開催

Who：だれが？

Q: 参加するためにどのような資格(役職/職位)が必要ですか？
- A: ファシリテーションに興味があれば誰でもOK
  - 会議/MTGをより実り多いものにしたい方
  - チームメンバーにもっと積極的に会議/MTGに参加してほしいと感じているチームリーダー
  - 会議/MTGで発言しにくさを感じているチームメンバー

How：どのように？

Q: 具体的にどのような進め方をするのですか？イメージができないと不安/怖いです
- A: 全8回を想定、人数としては5〜20人程度を想定しており、5人程度に分かれてグループワークする
Q: 事前に何か準備が必要ですか？
- A: 事前に書籍を購入する
Q: 教材はどのように買えば良いですか？費用負担は誰がしますか？
- A: 各自で購入 & 費用は会社負担(各自で経費精算する)
Q: 読書は業務時間内に行っても良いですか？
- A: OK、ただし上長とは相談しておくこと

これらを盛り込んでプレスリリースを作成

次にここまでに考えた望ましい顧客体験やその詳細、FAQを元にプレスリリースの文面を作成しました。

【告知】ファシリテーション勉強会の開催について

# 概要と目的

  ミーティング/会議に参加していてこのような問題を感じたことはありませんか？

    - 司会者が一方的に話すだけ、静かで居心地が悪い
    - 発言があっても質疑応答のみになっている
    - 一部の人だけが発言している
    - 自分が参加する意義を感じられない
    - 議論はしているが議題があちこちに飛んでしまい、今何を議論しているのかわからなくなることがある

  この勉強会では上記のような問題の解決を目指すために、ファシリテーションについて学び、実践し、
  ファシリテーターとしてのマインドセットやスキル、ツールの活用方法などを習得することを目指します。

# この勉強会で学べること

  - ファシリテーションのマインドセット
  - ファシリテーション・グラフィックをはじめとしたファシリテーションのスキル
  - Miroなどのオンラインホワイトボードの使い方

# 想定参加者

  どなたでもご参加いただけます。役職や職位、所属部門などの制限はありません。
  
  - 会議をより実り多いものにしたい方
  - チームメンバーにもっと積極的に会議/MTGに参加してほしいと感じているチームリーダー/マネージャー
  - 会議で発言しにくさを感じているチームメンバー
  
  人数は5~20人程度を想定しています。1グループ5人程度に分かれてワークを行う予定です。

# 参加方法

  - 次のURLからご参加ください。 https://example.com/xxx
  - 連絡用にSlackの #xxx にご参加ください。
  - 当日はZoomでご参加ください。
  - 不明点があれば@xxxまたは@yyyまでお問い合わせください。
  
# 教材と教材費について

  教材として以下を利用します。  
    - ファシリテーション・グラフィック[新版] 議論を「見える化」する技法 (堀公俊, 加藤彰)
  各自で購入して経費精算してください。
  経費精算時の予算コードはxxxをご利用ください。

# 勉強会の進め方

  毎週1回/全8回を予定しています。各回は1時間の予定です。
  
  - 第1回: オリエンテーション    
  - 第2回: 読書会 & 共有会  (1周目)
  - 第3回: 実践会(1周目) 
  - 第4回: ふりかえり会(1周目)    
  - 第5回: 読書会 & 共有会(2周目)
  - 第6回: 実践会(2周目) 
  - 第7回: ふりかえり会(2周目)    
  - 第8回: 全体のふりかえり会    
  
# その他注意点

  - この勉強会は講習(先生−生徒の関係)ではありません。各自が自分自身で学ぶことを重視します。
  - この勉強会は学んだことの共有/議論/実践の場です。
  - 読書は上長と相談の上で業務時間中に行なってください。

募集開始〜開催

作成したプレスリリースを用いて実際に参加者を募集をしてみました。

当初は10人くらい集まれば十分かなと思っていたのですが、予想に反し上限の20人を超える参加申し込みがありました。

想定参加者や目指す姿を書いておいたからか参加者の熱量は高く、とても充実した勉強会を開催できました。

ふりかえり

勉強会を開催しようとした当初は毎週集まって輪読会をする、くらいのぼんやりとしたイメージしか持てていなかったのですが、プレスリリースやFAQを作成することを通じて半強制的に具体的なイメージを持てました。

例えばグループ分けについて当初は考え至っていなかったのですが、参加者目線で「座学だけではなく体験や実践ができること」を実現するために何が必要か考えたところ大人数ではファシリテーターをやる機会がなかなか回ってこないという問題に気付き少人数のグループ制にするというアイディアを思いつきました。

今回はあまり関係なかったですが、参加者目線から考えることで企画者がやりたいことと参加者の求めることのギャップにも気付けるというあたりはアジャイルなプロダクト開発ととても相性が良さそうに感じました。

おわりに

社内勉強会にWorking Backwardsという考え方を取り入れてみた体験談をお届けしました。
何かの参考になれば幸いです。

今回は以上です。お読みいただきありがとうございました。

参考文献

作者:堀公俊,加藤彰
日経BP

2023-10-30

opentelemetry-go: exec.Commandで外部コマンドを呼ぶ時にトレースコンテキストを伝搬させる

OpenTelemetry Observability

exec.Commandで外部コマンドを起動する時にトレースコンテキストを伝搬させてみました

今回のコード例

環境変数+propagation.TraceContextを利用することで伝搬させてみました。

解説

httpやgRPCの場合のコンテキスト伝搬

こちらの記事にあるように、呼び出す側/呼び出される側の両方で以下のようにPropagatorを設定した上でotelhttpやotelgrpcなどのインターセプターを利用します。

otel.SetTextMapPropagator(
        propagation.NewCompositeTextMapPropagator(
                propagation.TraceContext{},
                propagation.Baggage{},
        ),
)

exec.Commandで外部コマンドを起動する時にはotelhttpやotelgrpcのようなインターセプターがありませんので自前でInject/Extractする必要があります。

どうやってトレースコンテキストを渡す?

W3C TraceContextのような仕様がないか探したのですが、いくつかの実装はあるものの仕様としてはまだない模様でした。

そこで参考としてequinix-labs/otel-cliでの環境変数経由でトレースコンテキストを参照する部分の実装をみたところ、

環境変数名としてtraceparentを用いる
値のフォーマットはW3C TraceContextを利用

となっていました。

これならpropagation.TraceContextの実装が使えるのでは?

上記の仕様で渡すのであればpropagation.TraceContextが使えそうです。
propagation.TraceContextは引数で渡されたpropagation.TextMapCarrierに対して読み書きを行います。

環境変数をなんらかの形でラップしてpropagation.TextMapCarrierの形にした上でInject/Extractを呼べばなんとかできそうです。

やってみた

改めて今回のコード例はこちらに置いています。

christina04.hatenablog.com blog.cybozu.io www.w3.org github.com

親コマンド側では以下のようにotel.GetTextMapPropagator().Inject()した上で環境変数を組み立てています。 https://github.com/yamamoto-febc/otel-env-context/blob/6db0d50cbf473c8c3095413657da234a57c63ddb/cmd/otel-parent/main.go#L47-L51

// 親コマンド側

// Propagatorに指定されているpropagation.TraceContextを用いてトレースコンテキストをenvCarrierに書き出し
envCarrier := propagation.MapCarrier{}
otel.GetTextMapPropagator().Inject(ctx, envCarrier)

// 書き出したトレースコンテキストを環境変数に設定
for _, key := range envCarrier.Keys() {
    cmd.Env = append(cmd.Env, key+"="+envCarrier.Get(key))
}

子コマンド側ではotel.GetTextMapPropagator().Extract()してあげます。 https://github.com/yamamoto-febc/otel-env-context/blob/4f30a8c453d64b567eecae2301226327114f1a5e/cmd/otel-child/main.go#L27-L33

// 子コマンド側

envCarrier := propagation.MapCarrier{
    "traceparent": os.Getenv("traceparent"),
    "tracestate":  os.Getenv("tracestate"),
}
// 環境変数からトレースコンテキストを抽出
parentCtx := otel.GetTextMapPropagator().Extract(context.Background(), envCarrier)

// トレース開始
ctx, span := otel.Tracer(instrumentationName).Start(parentCtx, "child")

これでいい感じにトレースコンテキストの伝搬ができてるはずです。

終わりに

もっといいやり方があれば是非教えてください。

以上です。

参考にしたサイト

オブザーバビリティ・エンジニアリング

作者:Charity Majors,Liz Fong-Jones,George Miranda
オーム社

2023-09-28

オープンソースAPMのSigNoz + さくらのクラウドオブジェクトストレージ

Observability SigNoz

はじめに

最近お仕事でSigNozを使ってみました。
その中でSigNoz(が使っているClickHouse)のCold Storageとしてさくらのクラウドオブジェクトストレージを使ってみましたので利用手順などのメモを残しておきます。

SigNozとは

オープンソースのAPM & オブザーバビリティツールとのことです。

signoz.io

GitHub リポジトリのdescriptionには以下のように書かれています。

SigNoz is an open-source APM.
It helps developers monitor their applications & troubleshoot problems,
an open-source alternative to DataDog, NewRelic, etc. 🔥 🖥.
👉 Open source Application Performance Monitoring (APM) & Observability tool

DataDogやNewRelicの代替という位置付けを狙っているようですね。
OpenTelemetryに対応しており、メトリクス・トレース・ログをまとめて見ることが出来ます。

GIGAZINEでも紹介されていました。

gigazine.net

類似のプロダクトとしてはhyperdxやuptraceなどがあります。
(uptraceはgo言語向けのORMであるBunを開発しているところです)

hyperdx: http://hyperdx.io
uptrace: http://uptrace.dev

なおSigNoz CloudというSaaS形態での利用も可能ですが、今回は手元にインストールして利用するOSS版を利用しました。

SigNozのシステム構成

SigNozのドキュメントによると以下のような構成とのことです。

SigNoz Otel Collectorに送信されたデータをClickHouseに書き込むという構成です。
ClickHouseのディスクとしてS3(互換含む)を用いることも可能です。

参考: SigNoz docs: Retension Period

今回はS3の代わりにさくらのクラウドオブジェクトストレージを使ってみました。

SigNoz + さくらのクラウドオブジェクトストレージ

利用までの手順

SigNoz + ClickHouseのディスクとしてさくらのクラウドオブジェクトストレージを使うための手順は以下の通りです。

さくらのクラウドオブジェクトストレージ側の準備
- バケットの作成
- パーミッションの作成
SigNozのインストール/セットアップ(今回はdocker composeを利用)
- ClickHouseの設定(設定ファイルの編集)
SigNozダッシュボード上から保存期間(Retention Period)を設定

さくらのクラウドオブジェクトストレージ側の準備

バケット & 各種操作をするためのパーミッションを作成します

詳細はさくらのクラウドオブジェクトストレージのドキュメントを参照してください。

参考: https://manual.sakura.ad.jp/cloud/objectstorage/about.html#id8

パーミッション作成時に表示される「アクセスキーID」と「シークレットアクセスキー」を控えておいてください。
後ほどClickHouseの設定時に利用します。

SigNozのインストール/セットアップ(docker compose)

SigNozのセットアップを行います。今回はdocker composeを使います。
以下のドキュメントに従いSigNozのリポジトリをクローン、設定ファイルを編集した上でdocker compose upを実行という流れです。

参考: https://signoz.io/docs/install/docker/

クローン

# クローン
git clone -b main https://github.com/SigNoz/signoz.git && cd signoz/deploy/docker/clickhouse-setup

ClickHouseの設定(設定ファイルの編集)

ClickHouseの設定ファイルを編集しさくらのクラウドオブジェクトストレージを使えるようにします。
カレントディレクトリであるclickhouse-setup配下にclickhouse-storage.xmlというファイルがありますので以下のように編集します。

{バケット名}と{アクセスキーID}、{シークレットアクセスキー}は置き換えてください。

<?xml version="1.0"?>
<clickhouse>
<storage_configuration>
    <disks>
        <default>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </default>
        <s3>
            <type>s3</type>
            <endpoint>https://s3.isk01.sakurastorage.jp/{バケット名}//</endpoint>
            <access_key_id>{アクセスキーID}</access_key_id>
            <secret_access_key>{シークレットアクセスキー}</secret_access_key>
            <region>jp-north-1</region>
            <no_sign_request>false</no_sign_request>
        </s3>
   </disks>
   <policies>
       <tiered>
           <volumes>
                <default>
                    <disk>default</disk>
                </default>
                <s3>
                    <disk>s3</disk>
                    <perform_ttl_move_on_insert>0</perform_ttl_move_on_insert>
                </s3>
            </volumes>
        </tiered>
    </policies>
</storage_configuration>
</clickhouse>

次にdocker-compose.yamlを編集し、volume指定部分でのclickhouse-storage.xmlのところのコメントアウトを解除します。

@@ -107,7 +107,7 @@ services:
       - ./clickhouse-users.xml:/etc/clickhouse-server/users.xml
       - ./custom-function.xml:/etc/clickhouse-server/custom-function.xml
       - ./clickhouse-cluster.xml:/etc/clickhouse-server/config.d/cluster.xml
-      # - ./clickhouse-storage.xml:/etc/clickhouse-server/config.d/storage.xml
+      - ./clickhouse-storage.xml:/etc/clickhouse-server/config.d/storage.xml
       - ./data/clickhouse/:/var/lib/clickhouse/
       - ./user_scripts:/var/lib/clickhouse/user_scripts/

SigNozの起動

あとはDocker Composeで起動します。

docker compose up -d

起動したらhttp://localhost:3301でダッシュボードにアクセスできるはずです。

SigNozダッシュボード上から保存期間(Retention Period)を設定

あとはどれくらいの期間がすぎたらS3に移動させるかを設定します。ダッシュボードからSettings(localhost:3301であれば http://localhost:3301/settings )を開いて設定します。

この例ではトータルの保存期間を21日、14日をすぎたらS3に移動させるという設定になっています。

これでSigNoz + さくらのクラウドオブジェクトストレージが使えるようになりました。

終わりに

SigNozはメトリクス・トレース・ログを一箇所で見える環境を手軽に作れるというあたりが魅力的だと思います。
気になるのはデータ量についてですが、オブジェクトストレージをCold Storageとして活用することでコストを押さえつつデータの増加にも耐えられそうです。

これからもう少し使い込んでみようと思います。

以上です。

オブザーバビリティ・エンジニアリング

2023-02-07

Mailosaurでメール送信のE2Eテスト

最近MailosaurというSaaSを使ってメール送信機能をテストしてみましたので、備忘がてら紹介メモを残しておきます。

Mailosaurとは?

Mailosaurとは Email and SMS testing platformだそうです。

メールがちゃんと送れているか?だとかメール本文/添付ファイルなどは意図通りか?をテストするのに便利な機能が提供されています。

Mailosaurってなんて読むの?

以下の動画をみたところ、カタカナだと「メイラソー」のように呼ばれていました。

www.youtube.com

どんなことができるの?

EメールやSMS関連のテストを行うための様々な便利機能が提供されています。
詳細は以下のドキュメントに記載されています。

例えばEメール関連ですと以下のような機能が提供されています。(上位プランのみの機能も含まれます)

テスト用メールボックスの提供

任意の名前@サーバID.mailosaur.netのようなメールアドレスが提供されます。このアドレス向けにテストしたいメールを送ることで、送信できているかや内容が正しいかなどをコードから確認することが可能です。

API経由でのメール送信/転送/返信

APIを用いて送信/転送/返信が行えます。
これによりユーザーからのメールを契機にスタートするようなプロセスなどもE2Eテストが行えます。
単純なテキストだけでなく添付ファイルなどにも対応しており、多彩なシナリオに対応できそうです。

プレビュー生成機能

様々なメールクライアント上でメールがどのように表示されるかをプレビューする機能です。以下のように様々な環境がサポートされています。

その他

そのほかにもPOP3/SMTPサーバも提供されていたりします。

類似/競合サービス

類似/競合サービスとしては以下のようなものもあります。

機能面、価格面、各言語向けSDK/ライブラリの充実状況、法人利用ができるライセンスか?などを考慮した結果、今回はMailosaurを選択しました。

自前でメールサーバを建ててもよかったのですが、$9~で手軽にAPIからメール操作ができるというのは非常に嬉しいところでした。
また、MailosaurはGo言語向けのSDK/ライブラリを提供しているのもポイント高かったです。
(テストしたいアプリケーションがGoで書かれていたため)

なお、Mailosaurは以下の言語/プラットフォームに対応しています。

Node.js
Python
Java
.NET
Ruby
PHP
Go

使い方

以下に各言語/プラットフォーム向けのドキュメントが用意されています。

例えばGoだと以下のようなコードでMailosaurで発行したメールアドレスに対して送信したメールを確認できます。
(このコードでは受信したメールのサブジェクトをfmt.Printlnしています)

package emailtests

import (
  "fmt"
  "testing"
  "github.com/mailosaur/mailosaur-go"
)

func TestExample(t *testing.T) {
  // Available in the API tab of a server
  apiKey := "YOUR_API_KEY";
  serverId := "SERVER_ID";
  serverDomain := "SERVER_DOMAIN";

  m := mailosaur.New(apiKey);

  params := &mailosaur.MessageSearchParams {
    Server: serverId,
  }

  criteria := &mailosaur.SearchCriteria {
    SentTo: "anything@" + serverDomain,
  }

  email, err := m.Messages.Get(params, criteria)

  if (err != nil) {
    t.Error(err)
  }

  // If we have an email, print the subject
  fmt.Println("Subject: " + email.Subject)
}

上記コードでは宛先メールアドレスを条件に受信メールを検索していますが、そのほかにも様々な条件が指定可能です。
(詳細は以下のAPIドキュメントを参照)