記事公開日
最終更新日
Power Apps キャンバスアプリテンプレートを作る③ ログの管理
こんにちは。システムソリューション営業本部の吾妻です。
この記事は、私たちが今までに Power Platform サポート＆アプリカタログサービス をはじめとする Power Apps アプリ開発で得てきた経験をもとに、「アプリテンプレート」を作りながら、構成要素と考え方についてご紹介している連載の第3回目のものになります。
アプリテンプレートに含めたい事柄としては、
ログの出力先と内容
アプリケーションを運用していく中で何らかの想定外の挙動に遭遇した際に、原因を究明したり、修正方法を検討するために重要なのが、ログです。Power AppsやPower Automateに関連して取得しておきたいログの例として、以下のようなものが考えられます。| 出力先 | 内容 |
| ①画面内 | スプラッシュ画面や通知バーに、プログレスサークルとともに処理の進捗状況を表示することで、ユーザーを無意味に待たせない(体感速度を低下させない)ために使用 |
| ②コンソール |
処理の詳細な内容を確認したり、ユーザーの想定に反した挙動が生じた際に内部状態を確認したりするために使用 |
| ③Monitor | キャンバスアプリで発生したイベント（主にコネクタ経由でのAPI呼び出し）のログを格納するために使用 |
| ④Dataverse | アプリケーションログやアクセスログを格納するために使用 |
| ⑤フローの実行履歴 | 開発中などに一時的にデバッグログを出力して挙動を確認したい場合に使用 |
| ⑥Application Insights | スクラッチ開発のAzure App Serviceアプリと同じように、またはApp Serviceと横断的にログを確認したい場合に使用 |
Application Insights （も含めたAzure Monitorの概要）については、以下の記事でご紹介しています。
こうした様々な種類のログについて、出力されたログの「深刻度」や誰向けのログなのかを整理するために、統一したログレベルを定義しておきます。
ログレベルの定義として有名なのはsyslogのもので、RFC5424に定義されています。ただ、あまり詳細にログレベルを区分してもPower Platformの中で運用しにくい(Power Platform基盤側で想定されるようなemergencyレベルなどは一緒にすると煩雑になる)ため、ある程度絞り込んで、以下のようなものを用意しようと思います。下の行ほど重要度が高くなります。
| ログレベル | 閲覧する人 | 出力する目的 |
| debug | 開発者 | 開発中や問題発生時に処理の詳細な内容を確認させるため |
| info | 利用者/運用者 | 処理が正常に実行されていることを確認させるため |
| warning | 処理は継続できるものの、想定外の事態が発生していることを知らせるため | |
| error | システムのある機能が実行できないことを知らせるため | |
| critical | システム全体が実行できないことを知らせるため |
今回のデモでは、これらのログレベルのうち、「error」から「info」までのログは画面内とDataverseの双方に、「debug」レベルのログはDataverseのみに出力させることにします。
ログレベルも含め、ログのレコード（行）には以下のような項目を出力させることにします。画面内に表示したり、コンソールに出力したりといった文字数に制約がある状況では、必要に応じて優先度の低い項目は省略します。
| 項目 | 内容 |
| 発生日時 | ログが記録された日時 |
| ログレベル | ログの優先度を示すログレベル |
| 発生箇所 | ログが記録された場所 ・環境名(ID) ・ソリューション名(ID) ・アプリ名(ID) ・画面名 ・コントロール名 ・プロパティ名 ・フロー名(ID) ・アクション名 |
| ユーザー情報 | アプリ／フローを実行した利用者の情報 ・利用者のUPN(ユーザープリンシパル名) ・利用者のIPアドレス ・利用者のユーザーエージェント |
| ログメッセージ | 処理内容、処理結果、与えられた引数、アップロードされたファイルの名前、生成されたSQLクエリなどの詳細な情報 ※個人情報やパスワードは出力しない、もしくはマスクする |
| 対応方法 | エラー発生時の対応手順など |
アプリ実装例
デモアプリにログ出力機能を各種実装してみました。まずは、アプリ起動直後に表示するスプラッシュウィンドウのサンプルです。ログインユーザーの情報や、読み込んでいるデータソースの名前を表示してみました。
他にも、ネットワークの有効/無効を表示させたり、外部のREST APIを呼び出すアプリであればバージョン情報を返すエンドポイントを叩いてサービスの稼働状況を表示させたりするために利用できます。
次に、デバッグバー（コンソール）のサンプルです。画面の左下にデバッグバーを表示するための🐞アイコンを、画面の下半分にログを表示するためのラベルを置いています。スプラッシュウィンドウに出すような万人向けの情報ではあるものの、ユーザーが必要に応じて表示させること「も」できるようにしたい場合に利用できます。ブラウザの開発者ツールのように、ネットワークリソースの取得状況をグラフ化したり、変数などの内部状態を表示・変更させたりするために利用することも考えられます。
続いてフローの実行履歴にログを残す方法を実現するためのクラウドフローのサンプルです。ログインユーザーのUPNやIPアドレス、ユーザーエージェントといった情報はフローの triggerOutput() に含まれているので、アプリ側でフローを呼び出す際に指定する値とは別に、呼び出されたフロー側でも取得・保存することができます。
このサンプルでは最後に「作成」アクションでログデータを書き出すところで止めているので、フローの実行履歴からログデータを確認することになります。そのため、実行してから30日以上経ってしまうと、実行履歴そのものが消えてしまうので、ログデータも確認できなくなります。開発時・デバッグ時の一時的な動作確認用のログ出力であればこのままでほぼ問題ないかと思いますが、永続的に残す必要があるデータを出力する場合は、「作成」アクションからDataverseの「新しい行を追加する」アクションに変更することで、Dataverseテーブルに保管すると良いでしょう（ユーザーエージェント等の情報が不要であれば、キャンバスアプリから直接Patch関数で書き出す方が楽ですが…）。
まとめ
今回は、Power Platformでログを管理する方法についてご紹介しました。
アプリを開発している時点ではなかなか意識することのないログ出力ですが、運用フェーズになってから、特にトラブルが発生したタイミングになってから、必要性を実感することになるポイントかと思います。
QESの Power Platform サポート＆アプリカタログサービス は、アプリを開発するだけのサービスではなく、ログ管理、パフォーマンス改善のような、運用保守で重要になってくる技術サポートについても含まれるものになっています。まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
