- はじめに — 量がそのままコストであり、組み込まれなければ使われない
- スナップショット
- 計装 — ベンダーから切り離す
- 保存と参照
- 一式でまとめて受け取る選択肢
- ランタイム — eBPF が作った視野
- サプライチェーンとコード
- 導入前の確認
- リンク
はじめに — 量がそのままコストであり、組み込まれなければ使われない
オブザーバビリティとセキュリティは性質の異なる分野ですが、失敗の仕方はよく似ています。
観測の側では、データをすべて集めるとコストが賄えなくなり、減らすと肝心なときに残っていません。セキュリティの側では、ツールがどれほど正確でも、パイプラインに組み込まれていなければその結果を誰も見ません。だからどちらの領域でも、どこに差し込まれるか が機能と同じくらい重要になります。
以下は順位ではなく、担当する層ごとの地図です。
スナップショット
| プロジェクト | ライセンス(リポジトリでの宣言ベース) | スター | 最新プッシュ |
|---|---|---|---|
aquasecurity/trivy | Apache-2.0 | 37,369 | 2026-08-12 |
SigNoz/signoz | MIT(ただし ee/ と cmd/enterprise/ は別) | 31,822 | 2026-08-12 |
grafana/loki | AGPL-3.0 | 28,720 | 2026-08-12 |
gitleaks/gitleaks | MIT | 28,633 | 2026-07-29 |
openobserve/openobserve | AGPL-3.0 | 20,937 | 2026-08-12 |
VictoriaMetrics/VictoriaMetrics | Apache-2.0 | 17,519 | 2026-08-12 |
semgrep/semgrep | LGPL-2.1 | 16,190 | 2026-08-12 |
grafana/pyroscope | AGPL-3.0 | 11,624 | 2026-08-11 |
falcosecurity/falco | Apache-2.0 | 9,260 | 2026-08-03 |
open-telemetry/opentelemetry-collector | Apache-2.0 | 7,377 | 2026-08-12 |
sigstore/cosign | Apache-2.0 | 6,201 | 2026-08-11 |
cilium/tetragon | Apache-2.0 | 4,911 | 2026-08-12 |
すべて 2026-08-12 時点です。
計装 — ベンダーから切り離す
open-telemetry/opentelemetry-collector は、この分野で最も実用的な変化を生んだ部品です。アプリケーションは標準の形式で送り出し、コレクターがそれを受け取ってフィルタリングし、サンプリングして望みのバックエンドへ送ります。オブザーバビリティのツールを入れ替える作業が、アプリケーションの再デプロイから設定変更へと下りてきます。
スター数はこの一覧で最も低い部類ですが、それが重要度と無関係であることを示すよい例です。複数のリポジトリに分かれた組織構造のため、関心が分散しているだけです。この点があるからこそ、スター数で順位を付けてはいけません。
保存と参照
VictoriaMetrics/VictoriaMetrics は Prometheus 互換の時系列ストアで、同じデータをより少ない資源で保持することに焦点を置いています。すでに Prometheus を使っていて保持期間とコストで行き詰まっているなら、自然な次の一歩です。
grafana/loki は、ログを全文インデックスなしでラベル中心に保存してコストを下げます。その代わり、任意の文字列を全体から探す検索は得意ではありません。ラベルの設計を誤ると、その利点は消えます。
grafana/pyroscope は継続的プロファイリングを担当します。メトリクスとトレースでは絞り込めない資源使用の問題を、コードのレベルまで下りて見せてくれます。
三つのうち Loki と Pyroscope は AGPL-3.0 です。AGPL は OSI が承認したオープンソースですが、改変したコードをネットワークサービスとして提供する場合にまで公開義務が及ぶ、強いコピーレフトです。社内でそのまま運用することと、改変して外部の顧客にサービスとして提供することでは、検討の範囲が異なります。
一式でまとめて受け取る選択肢
SigNoz/signoz と openobserve/openobserve は、収集・保存・ダッシュボードを一つの製品にまとめ、セルフホストのオブザーバビリティスタックを素早く立ち上げたいチームを狙っています。
ライセンスの形はそれぞれ異なります。SigNoz は LICENSE ファイルで、ee/ と cmd/enterprise/ のディレクトリは別のライセンスに従い、それ以外は MIT だと宣言しています。OpenObserve は AGPL-3.0 です。どちらもソースを見ることはできますが条件は同じではないので、どの機能がどの条件に属するのかを確認してから導入してください。
ランタイム — eBPF が作った視野
falcosecurity/falco は、カーネルのイベントをルールで判定してコンテナ内の不審な動きを捕まえます。cilium/tetragon は同じ基盤の上で、観察だけでなくポリシーの強制までを狙います。
この系統はアプリケーションに手を入れずに計装できる点が強力ですが、カーネルのバージョンとデプロイ環境に敏感です。マネージド Kubernetes でノードイメージを自由に選べないなら、サポート範囲をまず確認する必要があります。そして、ルールを調整しないまま有効にすると、アラートが降り注いで誰も見ない状態になります。
サプライチェーンとコード
aquasecurity/trivy は、イメージ、ファイルシステム、リポジトリ、Kubernetes のリソースまでを一つのコマンドで走査します。脆弱性だけでなく、設定の誤りや漏れた秘密情報も併せて見ます。
# 例: デプロイ前にイメージとリポジトリをまとめて点検
trivy image --severity HIGH,CRITICAL registry.example.com/app:1.4.2
trivy fs --scanners vuln,secret,misconfig .
gitleaks/gitleaks はコミット履歴から認証情報を探します。すでに上がってしまった秘密情報は回収より破棄が答えなので、事後の点検よりもコミットフックと CI に置くほうが実効が大きくなります。
semgrep/semgrep は、コードのパターンに基づく静的解析を担当します。ルールをチームの慣習に合わせて自分で書けることが実質的な価値です。リポジトリのライセンスは LGPL-2.1 で、商用として提供される付加機能やルールは別の条件なので、区別して見てください。
sigstore/cosign は成果物に署名し、検証します。署名は作ることよりも 検証を強制すること が核心です。デプロイの段階で検証しなければ、署名は飾りです。
導入前の確認
ライセンスの全文を自分で直接確認し、商用での導入は法務のレビューを通してください。この記事は法律上の助言ではありません。
この領域でよくある失敗は、ツールを増やすことで問題を覆い隠してしまうことです。新しいツールを入れる前に、誰がその結果を見て何を決めるのかをまず決めてください。見る人のいないダッシュボードと、誰も直さないアラートは、コストだけを生みます。
リポジトリの情報(スター数・ライセンス・最近の活動)は、2026-08-12 に GitHub で直接確認した時点の値です。数値と状態は変わります。
リンク
シリーズ: 前の記事 — インフラとデータベース · 次の記事 — データと ML パイプライン
このブログの関連記事:
ツール: ハッシュ生成器 · HTTP ステータスコード
현재 단락 (1/43)
オブザーバビリティとセキュリティは性質の異なる分野ですが、失敗の仕方はよく似ています。