GitHub Actions OpenTelemetryというGitHub Actionを作っています。GitHub Actionsのワークフロー実行データをOpenTelemetryのトレースとメトリクスとして出力するActionです。 このActionにE2Eテストを入れたので、そのテスト設計について書きます。やっていることは単純で、ActionがOTLPエンドポイントに送ったトレースとメトリクスのJSONをまるっとキャプチャして、期待値と比較しています。 ユニットテストだけだと何が怖いか E2Eテストの全体設計 JSONで丸ごと比較する Collectorでデータをキャプチャする jqで動的な値を正規化する 期待値JSONをgitで管理する まとめ ユニットテストだけだと何が怖いか このActionはGitHub APIからワークフローの実行データを取ってきて、そこからトレースとメト
はじめに 突然ですが、Dress Code 株式会社ではつい先日コードレビューの負荷軽減を目的として Greptile を導入しました。 Graphベースでコードのコンテキストを持ってくれているのでそれなりに精度が高く、学習させることで継続的に改善できる点が気に入っています。 ただ、一つだけ困った点があって、使用量を制限する仕組みがないんです。 Greptileの料金体系はざっくり以下のようになっています。 月に1ユーザーあたり 50レビューまでが基本料金に含まれる 超過分は 1レビューあたり$1の従量課金 つまり、誰かがガンガンPRを出してレビューを回すと、知らないうちにコストが膨らむ可能性があるわけです。 Greptile側にユーザーごとの上限設定やアラート機能があればいいんですが、現時点ではそういった機能は提供されていません。 「じゃあ自分たちで計測してアラート出せるようにするか」と
これはOpenTelemetry Advent Calendar 2025 2日目のエントリです。2週間に1回欠かさずOpenTelemetery Collectorのアップデートを追っている身として、「意外と知られていないのでは?」と個人的に思っているネタを取り上げます。 Batch Processorの利用推奨について OpenTelemetry Collectorをお使いのみなさん。Batch Processorを利用していますか? Batch Processorは複数のテレメトリーデータを1つのbatchにまとめる役割を果たします。受け取った・生成されたテレメトリーを即時にexportする手法と比較して、オブザーバビリティバックエンドにデータを送信するときの接続数が減らせたり、データの圧縮がより効くようになったりして、結果データ転送が最適化されます。 さて、OpenTelemetr
こんにちは、技術戦略部CTOブロックの塩崎です。 当社ZOZOには1人あたり月額200ドルの基準のもと、Claude CodeやGemini CLIをはじめとした各種AI開発ツールを利用可能にする制度を2025年7月にスタートさせました。 corp.zozo.com 現在ではこの制度を用いて数百名という非常に多くの社員がClaude Codeを利用しています。このような中で組織全体のAI活用を推進するためには、それぞれの社員や部署のClaude Codeの利用状況をモニタリングすることが重要です。そのためにClaude CodeのOpenTelemetry機能を利用して、全社員のClaude Code利用状況を収集したので、本記事ではその手法を紹介します。 ccusageを使った利用情報の収集の課題 Claude CodeのOTel機能の紹介 作ったものの全体像紹介 利用情報を送信する部分
Claude Code には OpenTelemety(以下 Otel) 形式でメトリクスを出力できる機能が備わっています。 今回はそのメトリクスを New Relic へ転送してみます。 他のプラットフォームも同じ要領で転送できると思うので試してみてください。 Claude Code のモニタリング設定 まず初めに Claude Code からメトリクスが出力できるように設定します。 今回はてっとり早いので環境変数でやりますが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く