みなさん、OpenObserve というソフトウェアもしくはクラウドサービスをご存知でしょうか？
ログ、メトリクス、トレースなどの監視を 1 つのプラットフォームでできる、フルスタックのオープンソースの監視ツール・サービスです。
最近（2023年6月上旬）ネット上の一部で話題となったのですが、そのうたい文句にはこうあります：
🚀 10x easier, 🚀 140x lower storage cost, 🚀 high performance, 🚀 petabyte scale – Elasticsearch/Splunk/Datadog alternative for 🚀 (logs, metrics, traces).
訳するとこんな感じでしょうか：
🚀 10 倍簡単、🚀 140 倍のストレージコスト効率、🚀 高パフォーマンス、🚀 ペタバイトスケール ― Elasticsearch / Splunk / Datadog の代替 🚀（ログ、メトリクス、トレースの収集）
これを見た私の最初の正直な感想は、「ずいぶんと大きく出たなぁ・・・」でした。
Elasticsearch や Splunk や Datadog というと、いずれも非常に幅広く利用されているソフトウェアもしくはクラウドサービスで、大量のデータを蓄積してそれを可視化したり分析したりアラートを設定したりできるものです。私たちソラコムも大変お世話になっています。
もし OpenObserve のうたい文句が（特に 140x lower storage cost の部分が）本当なら、これは革命的な出来事だぞ、とも思いました。
「でも、本当はお高いんでしょう？」と思いながら OpenObserve のサイトを確認すると、なんと Free プランでもデータを200GB まで入れられて最大15日間保持されるようです。（2023年6月時点）
200GBもあれば、ある程度の台数の IoT デバイスであってもログを保管するには十分すぎるのではないでしょうか。
しかし猜疑心の強い私は、「でも独自プロトコルを使う必要があったり使い方が面倒だったり何かしら制限があって、結局使いこなせないのでは？」と、まだ OpenObserve のことを信じきれていませんでした。
そこで、まずは OpenObserve にデータを送る（インジェストする）方法を調べてみました。
Log / Metrics / Traces それぞれでデータの特性が異なるためか、対応しているインジェスト方法が異なっています。
たとえば Log を送るためには以下のようなインジェスト方法がサポートされています。（この記事を書いた2023年6月時点）
Curl というのは HTTP のリクエストをコマンドラインで実行できるツールのことなので、これは HTTP で直接 Log データを送信できるということです。それ以外にも Filebeat、FluentBit、Fluentd、Vector、Kinesis Firehose に対応しています。いろいろ用意されているので、既存のシステムから簡単に乗り換えることもできそうですね。よく使われているプロトコルはだいたいカバーされていそうな気がしますが、他にも使われているものがあれば今後対応してくれることも期待できそうです。
Metrics は Prometheus / OTEL Collector / Telegraf に対応しています。いずれも有名どころという感じですね。
Traces は Open Telemetry のみです。
そしてこれを見たとき、私は「SORACOM Funnel は Kinesis Firehose へのデータ送信に対応しているから、それを使えばもしかしたら IoT デバイスから大量のログを Kinesis Firehose 経由で OpenObserve に送ることができるのではないだろうか？」と思いました。
思いついたらすぐに試したくなってしまい、その日のうちに OpenObserve にサインアップして試してみたところ、とても簡単にデータをインジェストして可視化・分析できるようになりましたので、この記事ではその方法をご紹介したいと思います。
概要
以下のブロック図で示すように、いくつかのコンポーネントの設定を順に行っていきます。また、OpenObserve、AWS、SORACOM の 3 つのアカウントが必要ですので事前に作成しておいてください。
データの流れとしては左から右なのですが、設定作業はデータの流れの下流の方から行っていくイメージです。
- OpenObserve のインジェスト先 (HTTP エンドポイント) の情報を取得
- Kinesis Firehose の Delivery stream（配信ストリーム）を作成
- 配信ストリームへ SORACOM Funnel からデータを送れるようにするための IAM ロールを作成
- SORACOM Funnel の設定
- デバイスから SORACOM Funnel 経由でデータを送信
- OpenObserve で可視化・分析
それでは、以下少し長くなってしまいますがお付き合い願います。
1．OpenObserve のインジェスト先 (HTTP エンドポイント) の情報を取得
概要のブロック図の①番の部分です。
このあと作成する Kinesis Firehose から OpenObserve にデータを送るときの送り先の情報を入手します。
OpenObserve にサインインします。（Google アカウントがあれば初回のサインアップ手続きも簡単に済みます。）
サインインすると以下のような画面になると思います。
日本語にも対応していてすごいですね。もし日本語で表示されていない場合は、画面上部中央の言語選択のドロップボックスから変更できます。
[データが取り込まれていません] と大きく書かれたカードの下部に、 [ログの取り込み方法を見る>>] というリンクがあるのでそこをクリックすると以下のような画面になります。
すでに OpenObserve にデータを取り込み済みで [データが取り込まれていません] と表示されていない方は、左のメニューから漏斗のような形のアイコン（カーソルを合わせると日本語なら [摂取] と書かれています）をクリックすると同じ画面になるはずです。
[摂取] というのは英語表記の [Ingestion] の直訳だと思います。
上の画面では、左のカラムで [Logs] が選択されています。真ん中のカラムでは [FluentBit] が選択されています。右のカラムには FluentBit を使ってインジェストする際に設定ファイルに書くべき内容が表示されています。
もしすでに FluentBit を使っているシステムがあるなら、これをコピー＆ペーストするだけで OpenObserve にデータを送り込むことができるという寸法です。
今回私たちが使いたいのは AWS の Kinesis Firehose です。というわけで一番下の [Kinesis Firehose] をクリックします。すると以下のような表示に変わると思います。
Kinesis Firehose を使う場合は設定項目がとても少ないですね。
この設定項目は次のステップで Kinesis Firehose からの送信先として設定しますので、コピーしてどこかにメモしておいてください。
2．Kinesis Firehose の Delivery stream（配信ストリーム）を作成する
続いては、概要のブロック図の②番の作業を行います。
AWS の管理コンソールにログインし、Kinesis Firehose のページを開きます。
[配信ストリームを作成] をクリックします。 次のような画面が開きます。
[ソース] は Direct PUT を選択します。
[送信先] は HTTP エンドポイント を選択します。
すると画面が以下のように変わります。
入力しなければならない項目がたくさんありますが、以下のように入力していきます。
[配信ストリーム名] : 最初からランダムな文字列が設定されていますが、そのままだと後でこの配信ストリームが何のためのものだったかが分からなくなるので、適切な名前に変更しましょう。例えば SORACOM-Funnel-to-OpenObserve のような名前にします。
[レコードを変換] : 変換は必要ないので、 [データ変換を有効にする] のチェックボックスはチェックを入れずに空欄のままとしておきます。
補足しておくと、この後の設定で SORACOM Funnel からのデータ送信形式として JSON 形式を選択します（デバイスからのログメッセージは JSON の payload フィールドに格納されます）。一方の OpenObserve は JSON 形式でログを投入されることを期待しています。したがって Kinesis Firehose でレコードを変換しなくてもそのまま送信できます。
[送信先の設定] : ここで先ほど①の手順で取得した [HTTP エンドポイント URL] と [アクセスキー] の情報を入力します。[HTTP エンドポイント名] は、OpenObserve のエンドポイントであることがわかるような名前（たとえば OpenObserve HTTP endpoint）を入力しておくとよいでしょう。それ以外の設定はそのままとしておきます。
[バックアップの設定] : [S3 バックアップバケット] に S3 のバケットの URI を入力します。[参照] ボタンを押して既存のバケットを選択するか、[作成] ボタンを押してバケットを作成します。[S3 バックアップバケットエラー出力プレフィックス] は必要に応じて指定してください。
[詳細設定] は、特に変更する必要はありません。
必要な情報をすべて入力したら、[配信ストリームを作成] をクリックします。
しばらく待つと配信ストリームが作成されます。
配信ストリームが作成されたら[配信ストリームの詳細] に記載されている [ARN] をコピーして、どこかにメモしておきます。この ARN は次のステップで IAM ロールを作成するときに利用します。
3．配信ストリームへ SORACOM Funnel からデータを送れるようにするための IAM ロールを作成
続いては、概要のブロック図の③番の作業を行います。
SORACOM Funnel という、読者の AWS アカウントにとっての第三者が、②で作成した配信ストリームへデータを投入することを許可するための IAM ロールを作成します。
AWS の管理コンソールで IAM のサービスページを開き [ロール] を選択します。
[ロールを作成] ボタンを押します。
ウィザードのステップ 1 が表示されます。
[信頼されたエンティティタイプ] は、AWS アカウント を選択します。
[AWS アカウント] は、 別の AWS アカウント を選択します。
[アカウント ID] には、以下のいずれかの値を入力します。
- 日本カバレッジの SIM 等からのデータを SORACOM Funnel 経由で OpenObserve に送りたい場合：
762707677580 - グローバルカバレッジの SIM 等からのデータを SORACOM Funnel 経由で OpenObserve に送りたい場合：
950858143650
[オプション] > [外部 ID を要求する] にチェックを入れます。
[外部 ID] には、任意の文字列を設定します。
ここで指定した外部 ID は次のステップで SORACOM Funnel の設定をするときに使いますので、どこかにメモしておいてください。
以上の設定を入力し終えたら、[次へ] を押します。ウィザードのステップ 2 が表示されます。
[ポリシーを作成] をクリックします。
別のウィンドウでポリシーの作成ウィザードが開きます。
[サービスを選択] の検索ボックスに、 Firehose と入力します。選択肢が [Firehose] だけになるのでそれをクリックします。
以下のように Firehose のアクション許可等を設定する項目が表示されます。
[アクション許可] の下の [書き込み] を開いて、 [PutRecordBatch] にチェックを入れます。
[リソース] の下の [ARN を追加] をクリックします。
以下のように [ARN を指定] というモーダル（ダイアログ）が開きます。
[テキスト] を選択し、その下のテキストボックスに先ほど②の作業の最後でコピーした配信ストリームの ARN を貼り付けます。
[ARN を追加] ボタンを押してモーダルを閉じます。
ウィザードに戻るので [次へ] をクリックします。
ポリシー作成ウィザードのステップ 2 の画面になります。
[ポリシー名] を入力し、 [ポリシーの作成] ボタンを押します。
ポリシーの作成が完了したら、 IAM ロールを作成していたウィザードのウィンドウに戻ります。
再読込ボタン 
先ほど作成したポリシーだけが表示される状態になると思うので、そのポリシーにチェックマークをつけて一番下の [次へ] を押します。
IAM ロール作成ウィザードのステップ 3 が表示されます。
[ロール名] に任意の名前を設定します。SORACOM Funnel からこのロールが利用されて Kinesis Firehose の配信ストリームにデータが書き込まれる、ということがわかるような名前をつけましょう。
[ロールを作成] ボタンを押します。
ロールの作成が完了すると、以下のように成功のメッセージとともに [ロールを表示] というボタンが表示されます。
[ロールを表示] を押して、今作成した IAM ロールを表示します。
表示されている [ARN] を次のステップで利用しますので、コピーしてどこかにメモしておきます。
4．SORACOM Funnel の設定
続いては、概要のブロック図の④番の作業を行います。
SORACOM Funnel の設定といっても、実際にはまず先ほど作成した IAM ロールにアクセスするための情報を「認証情報ストア」と呼ばれる場所に格納し、それからその認証情報を使って SORACOM Funnel の設定を行うという 2 段階の作業になります。
SORACOM User Console にサインインします。
[アカウントメニュー]（画面右上のメールアドレスもしくはユーザー名が書かれている箇所）> [セキュリティ] の順にクリックします。
[認証情報ストア] > [認証情報を登録] の順にクリックします。
以下のようなモーダルが表示されます。
[認証情報 ID] はこの認証情報の識別子です。任意のユニークな ID を付与します。この ID はこの後 SORACOM Funnel の設定をする時に利用します。
[概要] には、この認証情報の用途や登録者の情報など、後からこの認証情報がなんのためのものだったかを思い出せるような内容を書いておきましょう。
[種別] は、 AWS IAM ロール認証情報 を選択します。
[ロール ARN] には、さきほど③番の作業の一番最後にコピーした IAM ロールの ARN を指定します。
[外部 ID] も、先ほど③番の作業の途中で決めた外部IDの値を指定します。
必須項目をすべて入力したら、 [登録] ボタンを押します。
続いては、いよいよ SORACOM Funnel の設定をします。
すでに利用する SIM が決まっていてその SIM が SIM グループに所属している場合は、その SIM グループを開きます。
SIM が決まっていないか、SIM が SIM グループに所属していない場合は SIM グループを新規作成します。
左上のメインメニューから、 [SIM グループ] を選択します。
SIM 以外のデバイス（Sigfox デバイスや Inventory のデバイス）から Funnel にデータを送る場合は、それぞれのグループを作成してください。
グループを新規作成する場合は [+追加] ボタンを、既存のグループを利用する場合は検索ボックスにグループ名を入れて目的のグループを探します。
グループの編集画面になったら、 [SORACOM Funnel 設定] を開きます。
先頭のスイッチを [ON] にします。
[転送先サービス] は、 Amazon Kinesis Firehose を選択します。
[転送先 URL] は、以下のフォーマットで記入します。
<リージョン> は②番の作業で配信ストリームを作成したリージョン（東京リージョンなら ap-northeast-1）に置き換えます。<配信ストリーム名> は配信ストリームの名前を指定します。
[認証情報] は、先ほど作成した認証情報を選択します。
[送信データ形式] は、デフォルトでは JSON になっているはずです。JSON 以外になっていたら JSON に変更します。
それ以外の設定は変更せず、最後に忘れずに [保存] ボタンを押します。
今回新規にグループを作成した場合は、データを送る元になる SIM をこのグループに所属させるのを忘れないようにしましょう。
5．IoT デバイスから SORACOM Funnel 経由でログを送信する
さて、諸々準備が整いましたので、いよいよデバイスからログデータを送信します。
デバイスは皆さんのお手元にあるものでしたら何でも構いませんが、Unified endpoint に向けてデータを送信するように設定しましょう。
SORACOM Funnel のエンドポイントに直接データを投げることもできなくはないのですが、データがちゃんと送信できているかどうかを確かめたくなったら、SORACOM Harvest にも同じデータを送信したくなるかもしれませんし、デバイスから送信したデータを SORACOM Orbit で加工してから OpenObserve に渡したくなるかもしれません。それらが後からでもクラウド側の変更だけで対応できるようになりますので、基本的には Unified endpoint をお使いいただくことをオススメしています。
OpenObserve のログ画面を更新してみて、データが届いているようでしたら成功です！
もしデータが表示されない場合は、データ送信元（上流）からチェックしていきましょう。
- デバイスに何かエラーを示すログが残っていないか、設定間違いはないか
- データ送信先 URL やポート番号は正しいか、など
- SORACOM に何かエラーを示すログが残っていないか、設定間違いはないか
- ユーザーコンソールで [エラーログ] を表示してみる
- SORACOM Funnel の設定を見直したり、認証情報ストアに入れた認証情報を作り直したりしてみる
- SORACOM Peek を使ってデバイスと SORACOM 間の通信状況を確認してみる
- Kinesis Firehose に何かエラーを示すログが残っていないか、設定間違いはないか
- AWS 管理コンソールで配信ストリームのページを開き、[モニタリング] タブで受信や配信の各メトリクスを観察したり、[送信先エラーログ] タブでエラーログを確認したりして、どこに問題がありそうかを見極める
- まずそもそも SORACOM Funnel から受信できていない場合は、 IAM Role の設定などを見直す
- 受信はできているが配信に失敗している場合は、 HTTP エンドポイントの設定などを見直す
- AWS 管理コンソールで配信ストリームのページを開き、[モニタリング] タブで受信や配信の各メトリクスを観察したり、[送信先エラーログ] タブでエラーログを確認したりして、どこに問題がありそうかを見極める
6．OpenObserve で可視化・分析
OpenObserve にログデータが入ってくるようになったら、あとはそれを可視化したり分析したりできます。
Kibana や Datadog、Grafana などをすでに使っている方はなんとなく使い方がわかるのではないかと思いますが、簡単に説明します。
ログ件数の時間推移
デフォルトではヒストグラムが表示されている状態だと思いますので、どの時間帯にどのくらいの件数のログが送られてきたかということがひと目でわかります。
画面右上の方に [Past 15 Minutes] と表示されているところがありますので、そこをクリックするとログを見る時間の範囲を指定できます。
その隣の [0s] と表示されている部分は、自動更新の間隔です。0s (0 秒) は自動更新 Off です。
ログのクエリ
[Query Editor] には、目的とするログを見つけるためのクエリを書くことができます。
クエリの構文は直感的なもので、きっと読者の皆様もすぐに使いこなすことができると思います。詳細は [Syntax Guide] というボタンを押すと以下のように表示されますのでぜひ確認してみてください。
クエリは SQL の構文で書くこともできます。
[SQL モード] というトグルスイッチをオンにします。
FROM 節に指定している “default” は [ストリーム] の名前です。Kinesis Firehose からの送り先として指定した HTTP エンドポイントの URL の中ほどに default という文字列が含まれていますが、これがストリームの名前です。この HTTP エンドポイントのストリーム名部分を別の文字列に変更してインジェストすると、 OpenObserve 側でストリームが自動的に生成されてそのストリームにログが記録されるようになります。
したがって、異なるシステムからのログが混在していると困る（ログが見づらくなる）場合は、それぞれのシステムからのログを別々のストリーム名を指定してインジェストするとよいと思います。
ログのフィルタ
上の図で赤く囲った部分がフィルタです。
default と表示されているドロップダウンリストはストリームの選択です。
その下に _timestamp とか credentialsid とか書かれている部分は、 OpenObserve が受信した JSON のフィールド名です。
JSON がネストしている場合は、フィールド名が _ で連結されてフラットになっていますので、もしデバイス自体が JSON 形式でログを送信した場合は、 SORACOM Funnel はその JSON を payloads フィールドに入れますので、 payloads_xxx という形で現れているはずです。
ちなみに timestamp が 2 つあるように見えますが、名前の先頭にアンダースコアがついている _timestamp は、 OpenObserve が自動的に付与したタイムスタンプ、ついていない timestamp は SORACOM Funnel が付与したタイムスタンプです。
話がそれてしまいましたが、各フィールド名をクリックすると、その時点で表示されているログのそのフィールドの値のリストが表示されます。
上の図では、imsi フィールドを展開
フィールドの値の右側には○で囲まれた = や ≠ という記号が並んでいます。
= を押すと、その値が含まれるログのみ表示するようになります。
≠ を押すと、その値が含まれるログを表示しないようになります。
特定の IMSI のログだけを確認したい場合などに便利ですね。
おわりに
以上、IoT デバイスから SORACOM Funnel を使って OpenObserve にログデータを送る方法をご説明いたしましたが、OpenObserve にはまだまだたくさんの機能があります。
個人的には、今回ご紹介したログの他にメトリクスも投入してみてダッシュボードを作るなどしています。トレースの機能はまだ試せていませんが、これらが一つのプラットフォームで完結するという点にはとても大きな可能性を感じます。
生まれたてのプロダクトなので、 UI がまだちょっと垢抜けてない部分があるなという印象はありますし、この記事を書きながらいろいろ試している最中にサーバーサイドのエラーが発生したり、 UI のエラーが発生したりして思うような操作ができなくなり、ブラウザーの再読み込みボタンを押したら解決した、なんてことが何度かありました。安定性という面では、いきなり商用環境に組み込むのはまだ控えたほうが良さそうという感触を持ちましたが、今後の発展に期待したいところですね。
みなさんもぜひ活用してみてください！
― ソラコム 小熊 (@ogu)