UiPathのログ管理に困った話

UiPathのログを見ないとエラー発生時に対応できないけどめんどくさい!ログを分析しないと、どんなワークフローが何件実行されて、どんな結果だったのか、どれくらいの削減工数になったのか、管理できない!!…かといってOrchestratorも高いから導入してもらえない、どうしよう…。

と悩んでいませんか?

悩んでいるとしたら、次のような環境でUiPathを運用しているんじゃないですか?

  • UiPathを導入しているけどOrchestratorは導入していない、できない
  • RPAの開発ライセンスと実行ライセンスを合わせて5つ程度の規模
  • 専用の実行マシン(複数)でワークフローを実行している

このような環境で、UiPathのログ管理に課題を抱えているなら、続きをぜひお読みください。この記事では、

  • 僕が困ったUiPathログ管理
  • 僕の解決方法

を書いています。それでは、どうぞ!

この記事を書いた人
この記事を書いた人
こさい
こさい

(株)完全自動化研究所代表のこさいです。

1) エンジニア歴25年超。RPA開発および支援8年超
2) RPA関連の書籍を5冊出版。現在はGPT×PADの書籍を執筆中!
3)当サイトのプレミアム会員募集中!無限回答、動画見放題。詳しくはこちら

僕が困ったUiPathのログ管理

UiPathのログは実行マシンのローカルフォルダーに作成されます。

開発機と実行マシンが同じパソコン端末であるときは問題がないのですが、実行マシンが増えてくると管理が本当に面倒になってきますよね…。

まとめて絵にかいてみました。

シナリオのログ管理や分析が大変

UiPathの開発・運用には色々な立場の人が関わっているので、「運用者」「開発者」「管理者」という3つの立場から解説しますね。

僕自身もこれら3つの立場でかかわっているので、その苦労を書いてみます。

この3つの立場を兼任したり、そもそもはっきり分けて認識してなかったりするでしょう。開発者がそのまま運用したり、管理者も兼ねてたり…。でも、客観的に観察してみると3つの立場に分類できることがわかるでしょう。

運用者の立場

まず、運用者がUiPathの運用に関わるのは実行マシンでエラーが発生したとき。このとき、運用者は「どんな内容のエラーなのか?」を調べますね。

でも、Orchestratorを導入していないとWebブラウザー上でエラー内容を確認することができないので、UiPathワークフローが実行されている実行マシンを見に行かないとダメなわけです…。

エラーが発生するたびに実行マシンにアクセスし、ローカルのログをテキストエディタで開き、エラー箇所を探すのは大きな工数と大きなストレスです。

開発者の立場

開発者としての立場でも「エラー対応のためにログが見たい」ことが多いですね。

そこにワークフロー改修のために必要な情報があるから。

開発者もまた、実行マシンにアクセスする、という手間がかかります。

僕は、運用者とバッティングしてしまうので「運用者にログを送付してもらう」という手順を踏んでいました。

管理者の立場

UiPathの実行ログは実行マシンの中にあるので、実行マシンが3台あったら、3つのログが存在している状態になります。

管理者としては、これらのログを一元管理したいですね。一元管理して分析したい、というニーズがあるからです。

  • ワークフローを何件実行している?
  • エラーは何件発生している?
  • どれくらいの時間利用しているの?

こういったことが分析できないと、管理者として困りますね。どう困るかというと、

  • 実行ライセンスの数は足りているのか余っていないのか、わからない
  • エラー頻度が把握できない
  • 削減工数を集計・報告できない

と、いったこと。

Orchestratorも入れずに、これをやれている会社って少ないんじゃないかな?

やってなくても大きな問題は起きないかもしれないんだけど、いざ『やろうとしてもできない』ってのは問題かも。

僕の解決方法

僕も『ログ管理のめんどくささ』には困ってました。エラーの度にワークフローの実行マシンにリモートでアクセスしてログを取ってくるのにはうんざり。

で、どうしたかというと、、自分でソフトウェアを開発しました(笑)

ざっくり説明すると、こんな感じ。

  • 複数の実行マシンにエージェントアプリを入れて、サーバーにログを定期的に送信する
  • サーバー側でログを分析してデータベースに格納
  • マネージャーアプリで分析結果を閲覧できる

これで、いちいち実行マシンにログを取りに行く必要もなくなったし、人間にとって読みにくいログを苦労して読む必要もなくなった!

エラーがあったら、そのジョブは赤色で示してわかりやすくしているし、ダブルクリックするとエラー内容がポップアップ表示されるようにしています。

ワークフローごとに「手作業でやってたときの工数」を入力しておけば、実際にワークフロー実行でかかった時間との差分を「削減工数」として算出するから、効果も見えるんです。

削減工数 = 手作業工数 – ワークフロー実行時間

ついでに

  • ワークフローの重要度
  • 業務に対する貢献度

も入れられるようにして、総合的な評価から『健康指数』を算出するようにしました。

感覚的にどの実行マシン、どのワークフローが健康か不健康かってことがつかめるわけです!

健康指数が高くなるようにメンテナンスしていけば、おのずと運用は安定化していくという感じですね。

RPAというのは『継続的に育てていく』ことがなにより大事!

そのためには『ログを管理すること』が基本中の基本なんです。

このソフトウェアについて、もっと詳しく知りたいなぁと思ったら、次の記事も読んでみてください。