本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「監視ツール「OpenObserve」に IoT データをためる ― SORACOM Funnel でノーコード実装」を再編集したものです。
目次
概要1.OpenObserveのインジェスト先 (HTTPエンドポイント) の情報を取得
2.Kinesis FirehoseのDelivery stream(配信ストリーム)を作成する
3.配信ストリームへSORACOM Funnelからデータを送れるようにするためのIAMロールを作成
4.SORACOM Funnelの設定
5.IoTデバイスからSORACOM Funnel経由でログを送信する
6.OpenObserveで可視化・分析
おわりに
みなさん、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つのアカウントが必要ですので事前に作成しておいてください。
データの流れとしては左から右なのですが、設定作業はデータの流れの下流の方から行っていくイメージです。
- 1.OpenObserveのインジェスト先 (HTTPエンドポイント) の情報を取得
- 2.Kinesis FirehoseのDelivery stream(配信ストリーム)を作成
- 3.配信ストリームへSORACOM Funnelからデータを送れるようにするためのIAMロールを作成
- 4.SORACOM Funnelの設定
- 5.デバイスからSORACOM Funnel経由でデータを送信
- 6.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ロールを作成していたウィザードのウィンドウに戻ります。
再読込ボタン を押し、検索ボックスに先ほど作成したポリシーのポリシー名を入力しEnterを押します。
先ほど作成したポリシーだけが表示される状態になると思うので、そのポリシーにチェックマークをつけて一番下の [次へ] を押します。
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)
投稿 監視ツール「OpenObserve」に IoT データをためる ― SORACOM Funnel でノーコード実装 は SORACOM公式ブログ に最初に表示されました。
この連載の記事
-
第478回
デジタル
コープさっぽろが、クラウド型カメラ「ソラカメ」を全店舗で導入、現場主導の改善を実現、サーバールームの異常な温度上昇を通知する新規掲載レシピ takuyaのほぼ週刊ソラコム 11/16-11/29 -
第476回
デジタル
WebRTCとMedia over QUIC Transportの性能比較 -
第475回
デジタル
SORACOM Lagoon 3 の [Math] 機能で、複数データを組み合わせた通知の手順 -
第474回
デジタル
SORACOM Flux の AI アクションに Amazon Bedrock – Anthropic Claude 3.5 Haiku を追加、Teltonika RUT240 の価格を改訂 takuyaのほぼ週刊ソラコム 11/02-11/15 -
第473回
デジタル
IoTセキュリティの基本知識と実践をご紹介 ― 10/31開催:SORACOMユーザー向けオンラインセミナー開催レポート -
第472回
デジタル
SORACOM Flux に追加された Incoming Webhook をつかってインタラクティブな Flux アプリを作る -
第471回
デジタル
サーバールームの異常な温度上昇を通知する新規掲載レシピのご紹介 -
第470回
デジタル
Virtual Private Gateway (VPG) Type-F2 が正式リリースになりました! -
第469回
デジタル
暗号化非対応のTCPクライアントでもNapterまでの通信を暗号化する方法 -
第468回
デジタル
SORACOM Beam や SORACOM Flux の開発・デバッグに使える HTTP モックサーバーを素早く作る方法