従来のオブザーバビリティが抱える高コストな課題
あるスタートアップのMVP開発で、フル構成のELK（Elasticsearch, Logstash, Kibana）スタックをデプロイしようとした時のことです。開始10分足らずでVPSの4GB RAMは限界に達し、カーネルのOOM（Out of Memory）キラーがプロセスを強制終了し始めました。Elasticsearchは強力ですが、Javaベースのアーキテクチャはリソースを大量に消費します。中小規模のインフラを管理する多くのチームにとって、午前2時のコンテナクラッシュをデバッグするためだけに、ペタバイト規模の検索エンジンは必要ありません。
そこで私が切り替えたのがOpenObserveです。半年間本番環境で運用してみて、モニタリングのコスト構造を根本から変えるものだと確信しました。Rustで書かれているため非常に高速で、メモリ使用量も極めてわずかです。ELKノードが8GB未満のRAMで苦労する一方で、OpenObserveはわずか512MBのメモリでも数百万件のレコードを余裕で処理できます。
なぜOpenObserveはELKスタックより優れているのか
OpenObserveは単なる軽量な代替品ではなく、統合されたオブザーバビリティプラットフォームです。その真髄はストレージエンジンにあります。常に手動調整が必要で壊れやすい複雑なインデックスを管理する代わりに、OpenObserveはデータをローカルファイルやMinIOのようなS3互換のオブジェクトストレージに保存します。このアプローチにより、従来のインデックス作成と比較してストレージコストを最大90%削減できます。
データのクエリも非常に簡単です。基本的なSQLが書ければ、すでにログの検索方法を知っていることになります。KQLやLuceneのような独自の構文を学ぶのに時間を無駄にする必要はありません。SELECT * FROM "logs" WHERE status='error' AND service='api-gateway' のようなシンプルなクエリが、期待通りに動作します。
私はこの構成を使って、3つの異なるツールを1つのDockerコンテナに置き換えました。スタックがシンプルになり、メンテナンスも驚くほど簡単になります。
マスターすべき主要コンセプト
インストールを始める前に、3つの基本的なアーキテクチャの柱を理解しておく必要があります。
- ストレージの柔軟性: スピード重視のローカルNVMeドライブを使用したステートフルモード、またはAWS S3にすべてを転送してほぼ無限かつ低コストに保存するステートレスモードのいずれでも実行可能です。
- ストリームベースの構成: ストリームをデータベースのテーブルのように考えます。
frontend_logs、db_metrics、auth_tracesのようにデータを分離して、ワークスペースを整理できます。 - ユニバーサルなデータ取り込み: 他のツールとの親和性も高いです。Fluentbit、OpenTelemetry (OTLP)、Vector、さらにはシンプルなHTTP POSTリクエストを使用してデータを送信できます。
実践：Docker Composeによるデプロイ
Docker Composeは、構成をバージョン管理するための最適な方法です。以下のテンプレートを使用すれば、本番環境に対応可能なスタンドアロンインスタンスを数秒でセットアップできます。
1. 環境の準備
mkdir openobserve && cd openobserve
mkdir data2. Docker Composeファイルの作成
docker-compose.yml ファイルを作成します。以下の環境変数は標準的なセットアップ向けに最適化されています。デフォルトのパスワードはすぐに変更するようにしてください。
services:
openobserve:
image: public.ecr.aws/zinclabs/openobserve:latest
container_name: openobserve
restart: always
environment:
- [email protected]
- ZO_ROOT_USER_PASSWORD=YourSecurePassword123
- ZO_DATA_DIR=/data
- ZO_HTTP_PORT=5080
ports:
- "5080:5080"
volumes:
- ./data:/data
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5080/healthz"]
interval: 30s
timeout: 10s
retries: 33. システムの起動
コンテナをバックグラウンドで起動します：
docker-compose up -dブラウザで http://your-server-ip:5080 にアクセスしてください。設定した認証情報を使用してダッシュボードにログインします。UIはクリーンでレスポンスが良く、モダンなデータプラットフォームに非常に近いと感じるはずです。
最初のログエントリを送信する
OpenObserveでは、事前にスキーマを定義することなくデータの取り込みを開始できます。curl を使用して、すぐにインジェストパイプラインをテストできます。これは、バックエンドアプリケーションがAPI経由でログを送信する方法と同じです。
curl http://localhost:5080/api/default/logs/_json \
-u "[email protected]:YourSecurePassword123" \
-H "Content-Type: application/json" \
-d '[{
"message": "ユーザーのログインに成功しました",
"user_id": 1024,
"level": "info",
"latency_ms": 45
}]'ダッシュボードの「Logs」タブを確認してください。default ストリームにエントリが表示されます。OpenObserveは latency_ms が数値であることを自動的に検出し、即座に高度な集計やグラフを作成できるようになります。
メトリクスとトレースの処理
ログだけでは全体像の半分しかわかりません。全体を把握するにはメトリクスとトレースが必要です。OpenObserveはPrometheusのリモートライト（remote write）プロトコルをサポートしています。アプリがすでにPrometheusメトリクスをエクスポートしている場合は、出力をOpenObserveに向けるだけでデータを集約できます。
分散トレースについては、完全にOTLPネイティブです。私は通常、Node.jsやPythonアプリを設定して、OpenObserveのエンドポイントに直接トレースを送信するようにしています。この構成により、JaegerやTempoが不要になり、クラスタ全体でさらに1GB〜2GBのRAMを節約できます。
実践的な最適化のヒント
いくつかのOpenObserveインスタンスを管理してきた経験から、システムを健全に保つための3つのプラクティスを推奨します。
シークレットの保護
パスワードをGitHubにコミットしないでください。.env ファイルを使用して ZO_ROOT_USER_PASSWORD を保存しましょう。OpenObserveは多数の設定フラグをサポートしており、専用の環境変数ファイルで管理することでアップグレードが非常にスムーズになります。
長期保存にはS3に切り替える
ローカルディスクはすぐに一杯になります。90日以上のログを保持する必要がある場合は、S3が最適です。ディスク容量の不足を心配することなく、大規模なスケーリングを実現できます。ComposeファイルのenvironmentセクションにS3バケットの認証情報を追加するだけです。
リテンションポリシーの自動化
すべてのログが同じ重要度ではありません。スペースを節約するために nginx_access ログは7日間だけ保持し、コンプライアンスのために audit_logs は1年間保持するといった設定が可能です。これらのルールは「Settings」メニューで設定できます。これにより、ストレージ使用量を予測可能かつコスト効率の高い状態に保てます。
切り替える価値はあるか？
肥大化したELKスタックからOpenObserveへの移行は、真夏に厚い冬のコートを脱ぎ捨てるような爽快感があります。膨大なインフラコストをかけることなく、高性能なオブザーバビリティを実現できます。モニタリングツールが、監視対象であるはずの実際のアプリケーションよりも多くのリソースを消費している状況にうんざりしているなら、OpenObserveこそが探していたソリューションです。
