製品について
MotionBoard とは
【詳細はこちら】MotionBoardは様々なデータを集め、画面上で仮想統合ができるBIツールです。データを集め、データをビジュアライズすることに長けています。
※キャプチャはウイングアーク１ｓｔ社のホームページより抜粋
Dr.Sum とは
【詳細はこちら】Dr.Sumは10億件のデータを1秒台で集計できる超高速データベースツールです。
また、Dr.Sumは集計速度だけでなく、データベース構築経験の少ない方でもGUI操作でDBをつくったり、データを取り込んだりできます。
データベース周りにそこまで強くないぼくのような人間でも、気軽にデータハンドリングができるところが素敵です。
さて、Dr.Sumという製品は単純にデータベースがあるだけではなく、様々なオプション製品を加えることで、多様な使い方が可能です。
詳しくは公式ホームページをご参照いただきたいのですが、
✅ データを抜いて
✅ データを加工して
✅ データを貯めて
✅ データを高速集計する
ことが可能となります。
Dr.Sum Connect とは
【詳細はこちら】Dr.Sum Connectはデータを抽出・加工・取り込みをするETLツールです。
下図のように様々な環境からデータを取得して、加工して、Dr.Sumに投げ込むことのできるツールです。
エラーになったらログを吐いたり、メールを飛ばしたり、だいたいGUIで操作できるので、プログラムを書かずとも連携の仕組みを作ることができます。
基本的なスクリプトのつくり方についてはこちらの解説記事をお読みください。
Dr.Sum ConnectをつかったETLのスクリプトのつくり方
Dr.Sum ConnectはDataSpiderのOEM製品です。
以降の記事ではConnectと書きます。
最初に
MotionBoardを使いこなし、運用が軌道に乗ってくると、どんな人がどれだけMotionBoardを利用しているか気になってきます。
MotionBoardの機能で各ボードの足跡（PV数）がデータとして溜まっていますが、MotionBoardで貯めている各種ログをデータ分析できるようになると、さらに細かなユーザーの動向を把握することができます。
今回はMotionBoardで取得できる以下の４つのログをDr.Sumに貯める方法について解説します。
・通常ログ
・操作ログ
・パフォーマンスログ
・データアクセスログ
各種ログの説明はこちらを参照してください。
これらのログはCSV形式で出力できるんですが、せっかくだからダッシュボードで可視化したいですよね。
そんな訳で、毎日Dr.Sumにデータを貯める処理の作り方を解説します。
cURLコマンドを使ってみる
記事のメインはDataSpiderでの処理の解説です。
ここではまず、cURLコマンドでデータが取れるかを確認します。
MotionBoardのAPIをcURLコマンドで叩く方法については下記を参照してください。
curl -b "tenant=xxxxx" https://wa-up.motionboard.jp/motionboard/rest/log/download/operation -F "id=aaa" -F "pw=bbb" -F "logType=operation" -F "logLevel=INFO" -o C:\data\MotionBoard_Log\OperationLog.csv
上記はMotionBoard CloudのURLです。
MotonBoard Cloud for Salesforceは https://sfdc-up.variocloud.jp/motionboard/ でイケました。
詳細はこちらを参考にしてください。
上記は操作ログのデータ取得となります。
実行すると👆の感じで操作ログファイルが取得できます。
あとはDr.Sumのインポートタスクをつかったりすれば、とりあえずはデータを取り込めますね。
ただ、やはりバッチだとエラーハンドリングが大変ですし、エラー時の復旧なども手間です。
毎日の運用を考えると、これらはなるべく人の手を煩わせない処理にしたいです。そのためにはDataSpiderですね。
cURLでデータが取れるってことは、DataSpiderでも取れるはず、ということでやってみましょう。
DataSpiderで取得してみる
それではDataSpiderでデータを取得してみましょう。
グローバルリソースの設定
まずはDataSpiderのグローバルリソースでREST接続設定をします。
[URL]についてはcURLのところを参照してください。
MotionBoard Cloudならば
https://wa-up.motionboard.jp/motionboard
MotionBoard Cloud for Salesforceならば
https://sfdc-up.variocloud.jp/motionboard
となります。
スクリプトの設定
スクリプトはこのようにつくりました。
右上がメイン処理です。
その他の処理についてはログや異常時のメール送信です。
これらの処理が気になる方は下記の記事を参考にしてください。
４つのログを取得していますが、これらは同じ処理を使っていますので、今回は赤枠の部分のみ説明します。
その前の下準備として、Dr.Sumにテーブルを用意しましょうか。
各ログのCREATE TABLE文は下記に置いておきますので参照してください。
通常ログ
CREATE TABLE MB_Log_通常ログ (
ログ時刻 TIMESTAMP,
ログレベル VARCHAR,
ログカテゴリ VARCHAR,
デバッグメッセージ VARCHAR,
メッセージID VARCHAR,
メッセージ VARCHAR,
実行時間 VARCHAR,
トレースID VARCHAR,
テナントID VARCHAR,
ユーザーID VARCHAR,
セッションID VARCHAR,
アクセスID VARCHAR,
スレッド名 VARCHAR,
ノード名 VARCHAR,
IPアドレス VARCHAR);
ALTER TABLE MB_Log_通常ログ MODIFY COMMENT 'MBSFのログをWebAPIで連携 12ヶ月分';
操作ログ
CREATE TABLE MB_Log_操作ログ (
ログ時刻 TIMESTAMP,
操作内容 VARCHAR,
テナントID VARCHAR,
ユーザーID VARCHAR,
セッションID VARCHAR,
アクセスID VARCHAR,
ノード名 VARCHAR,
IPアドレス VARCHAR);
ALTER TABLE MB_Log_操作ログ MODIFY COMMENT 'MBSFのログをWebAPIで連携 12ヶ月分';
パフォーマンスログ
CREATE TABLE MB_Log_パフォーマンスログ (
ログ時刻 TIMESTAMP,
処理開始時間 TIMESTAMP,
ボードパス VARCHAR,
データソースパス VARCHAR,
実データ件数 VARCHAR,
サーバー抽出件数 VARCHAR,
クエリー処理時間 NUMERIC,
全体処理時間 NUMERIC,
キャッシュフラグ VARCHAR,
キャッシュ作成時刻 VARCHAR,
テナントID VARCHAR,
ユーザーID VARCHAR,
セッションID VARCHAR,
アクセスID VARCHAR,
ノード名 VARCHAR,
IPアドレス VARCHAR);
ALTER TABLE MB_Log_パフォーマンスログ MODIFY COMMENT 'MBSFのログをWebAPIで連携 12ヶ月分';
データアクセスログ
CREATE TABLE MB_Log_データアクセスログ (
ログ時刻 TIMESTAMP,
外部接続名 VARCHAR,
データソース情報 VARCHAR,
テーブル名 VARCHAR,
項目名リスト VARCHAR,
検索条件 VARCHAR,
ログインハンドル VARCHAR,
テナントID VARCHAR,
ユーザーID VARCHAR,
セッションID VARCHAR,
アクセスID VARCHAR,
ノード名 VARCHAR,
IPアドレス VARCHAR);
ALTER TABLE MB_Log_データアクセスログ MODIFY COMMENT 'MBSFのログをWebAPIで連携 12ヶ月分';
コンポーネントの紹介
日付格納
まずは日付格納コンポーネント、こちらはMAPPERを使います。
スクリプト変数を各種用意しておきまして、現在時刻からの引き算した「yyyy/MM/dd 00:00:00」か「yyyy/MM/dd 23:59:59」をスクリプト編集に入力します。
startDateとendDateは必須で必要となります。
各種ログをどの期間分を取得するかを決めるものです。今回の処理は「8日前から1日前のログを抽出する」としています。
「去年」「半年」「先月」「２年前」というスクリプトはテーブルにログデータをどれだけ貯めるかを考慮しています。
ログデータは膨大な量になりがちなので、１日あたりのテーブル件数を見て、ログデータの削除をおこないます。
操作ログ 定数入力
Web APIを実行するための定数を格納します。
出力先のlogLevel、startDate、endDateはこの後のREST接続の[マルチパートフォーム]を設定しなければ表示されません。
まずはREST設定をしてしまうことをオススメします。
MAPPERの中でlogLevelとスクリプト変数のstartDateとendDateを格納します。
logLevelは単一行文字列定数ロジックにして、"INFO"を入れます。
ここを"DEBUG"などに変えるとログの量が増え、より詳細な内容が把握できますが、データ量が多くなるので気をつけましょう。
操作ログ API実行
ここが今回の操作のメインとなるところです。
REST接続でMotionBoardからログをCSV形式でダウンロードします。
使用するコンポーネントは[REST]の[POST実行]です。
必須設定
ここからはPOST実行処理に必要な情報をタブ毎に記載します。
設定内容は下図となります。
接続先はグローバルリソースで作成した[REST接続設定]を選択します。
パスは操作ログの場合は
rest/log/download/operation
となります。
クエリパラメータにはMotionBoardへのログイン情報が入ります。
テナント・ユーザーID・パスワードですね。ぼくは事前にDataSpiderの環境変数に入れていますので、そちらを格納しています。
リクエスト設定
データ形式を[マルチパートフォーム]にして、
logLevel
startDate
endDate
を文字列で登録します。
こちらを設定すると、先ほどのMAPPING[操作ログ 定数入力]のOutput側に反映されます。
レスポンス設定
こちらはCSVファイルをどこに出力するかというところです。
任意のファイルパスをセットしましょう。
POST実行処理の設定は以上です。
操作ログ 削除（12ヶ月）
ここではテーブルに入っているデータ量を制御します。
ログデータは大量件数になりますので、いくらでもデータを貯めるわけには参りません。
今回は一律12ヶ月としていますが、大量ユーザーがMotionBoardを活用していたらもっと期間を減らしたり、別テーブルにデータを逃す処理などが必要となります。
日付格納MAPPINGでスクリプト変数を多く作っていたのはそのためです。
ログによってデータ保持期間を変更すると良いかと思います。
DELETE文はシンプルです。
今回は12ヶ月なので、変数は ${去年} としています。
操作ログ 削除
ここでは startDate から endDate までのデータを削除します。
APIも同じ範囲のCSVを持ってきています。同じ期間のデータをテーブルから削除するので、重複なく取り込まれるようになります。
ここで「なんで１日分のデータを入れないの？」と疑問に思う方もいらっしゃると思います。
この理由は 運用の手間をなくしたいから となります。
たとえば３日前にエラーが出てたんですが、自分が休みの日だったので気づかなかったとします。
おそらくエラーは毎日でますので、3日前、2日前、昨日はデータが取り込まれていないでしょう。
ここでエラー復旧させたとき、3日前から取り込み直さねばなりません。ましてや修正中にうっかりデータを入れちゃったら、「何日前を入れればいいんだ？」ってなって、考えるのがめんどくさいです。
今回の処理では startDateを8日前、endDateを1日前としています。
テーブル内の同じ期間を削除してから挿入しているので、データが余分に増えることはないのです。
エラー復旧後の処理も簡単ですよね。
余談ですが、エラー復旧はテンパるものです。開発者以外の人が運用している時はなおさらそうでしょう。
運用者に優しい設計を心掛けましょう。
操作ログ csv_read
あとはデータを取り込むだけです。
CSVをロードします。
API実行で出力したCSVを読み込みます。
ただ残念なことに、APIで出力したCSVには見出し行がついていません。
そのため、[列一覧]は手動で作る必要があります。（ここを回避したかったのですが、避けられなかった・・・）
さきほどのCREATE TABLE文やマニュアルを参考に、無心で登録してください。
通常ログ bulk_insert
最後にBulkInsertです。
読み込んだCSVをテーブルにInsertしましょう。
処理は以上です。
あとは操作ログ以外の取り込み処理を行いましょう。
最後に
今回はMotionBoardのログを効率的にデータベースに溜め込む処理について解説をしました。
これでデータベースにログ情報が貯まったことと思います。
このデータの活用方法については、情報をまとめ、記事にしていきたいと思います。
まずはデータを貯めた上で、オリジナルのダッシュボードを構築いただけますと幸いです。