uzullaがブログスマートフォン用の表示で見るuzullaがブログuzullaがブログです。先日「JSが『なんか』うまくうごかない」というクレームが来て調査しており、開発者ツールをみればわかることでも手元のPCで再現せず、その人のPCをみないとわからんな〜〜ということがありました。いうのむずかしいですよね、エラーがあらゆる所でランダムに発生する(と主張されている)場合には問題が発生しているユーザーにデベロッパーツールを開きっぱなしにしてもらうのか?という問題もあります。...と言う気分でTwitterになにか無いかとボヤいたら、JSのプロのmizchiさんにレスをもらいました。いうPaaS合った気がする。2018ということで速やかにLogRocket、使ってみました。結果としてはとても役立ちましたね。happen"というワードが実に良い。結論からいって、解決に役立ちました。十分な情報が得られます。だれが、どの画面で、いつ、どういうエラーがでていたのかが一目瞭然でした。一部環境以外ではエラーがでていないことも確認できました。LogRocketとはJSのエラーが発生していないかあるユーザのブラウザにどのように表示されていたか(動画のように表示される)勿論エラー発生前後の画面の様子も見れるどういったHTTPリクエストがあったのか(所謂Networkパネル、ヘッダーも見れる)ユーザーはどういったブラウザ・OS環境なのかさらっとかきましたが、これ本当にすごいです。JSのエラー確認まず、何が良いってエラーをまとめてもらえることです。このサービスのJSエラーはあらかた潰してあったので「エラーが多くてみつからない!」という事はなかったのですが、そういうこともあるでしょう。発生頻度が集計済みなのも便利です。このエラーはLogRocketの中で「チケット」的な扱いになっていて、解決!とすると、同じエラーをまとめて非表示に出来ます。対応してないエラーに集中できてよいですね。(なお、放置すると設定期間で自動的に処分され、空気読んどるな?という感じはありますねw)詳細を開くと具体的なエラーログなどが確認出来ます。開発者ツールのConsoleくらいの情報量はあるので十分です。(一応、エラーの行情報からソースコードを表示してくれるのですが、無名関数だとおかしい場所が指し示されてしまうなどはあります。(こういうのが多いと、無駄でも無名関数はへらさんといかんなあという気分にもなる))やはりユーザーの画面で「どのような時に」エラーになったかを再生することができるのがよいですね。どこをクリックしたとか、どういう遷移できたとか、そういうのが相手の苦痛なくヒアリング無しでわかるので大変に!!助かります。公開できる情報じゃないんで皆さんにみせられないのが残念なんですが、本当にすごいので皆さんためしてみてほしい。操作している画面がそのまま見れるそんなことが実現可能なのかとおもっていましたけど、本当にできていましたね、どういう理屈なんだ。Videoみたいなもの以外はアニメーションもちゃんとレンダリングされているようです(Gifアニメ、JSによるフェードアウトなど)、スマホももちろん対応です。〜〜非常にわかりやすい...クレーム対応でなくてとも、何人もみていると「ああ、ここで迷うんだな」ということがよく分かる。ロードが遅くてマウスをくるくるまわすのもわかる。(ただ、私の(ここでの)立場はあくまでも実装エンジニアで、仕様策定者に「こうなっているらしいですよ」「へー、きょうみないや」みたいな感じなので活用できていないのだが...)このレコード機能はどうやって実装してるんだ?思いましたが、録画とかではないです。プレイヤーのiframeの中に元のサイトが改変ミラーされていて...みたいな感じになっていて、なるほど...?となれます、すごい...。Liveも見れるなお、レコーダーの再生は「リアルタイム」にも対応しています。YoutubeのLive再生みたいな感じで録画再生が終わったらLiveに移行できます。これもユーザーサポートでは非常に便利ですね。表示でもいいんだけど。Cookieみたいな感じです。課金単位はこのセッション数です。重要なのは、SPAでない普通のページ遷移を伴う場合も1セッションとして扱われることでしょうか。いわずもがなこれは非常に重要ですし、よくできてるな〜〜ポイントですよね。「便利だから!」てサイト全部に影響する所でトラックJSを埋め込むと、1セッションが長すぎて確認のための早送りが大変になります(まあ、サービスによるでしょうが)。ある程度タグを埋め込む箇所は調整したほうが良いと私は思います。セッション検索は結構豊富なメタデータで検索出来ます。これを組み込むことでクレームがくるか?これ結構心配していましたが(なにかが破滅したり、やばいくらい遅くなるとか)今の所そういった問題はなさそうです(もちろん帯域は無駄に消費しちゃっているのでしょうが)。今回はユーザー数が多くないBなサービスなので、サンプル数が足りないかもしれませんけど。サービスが(検閲削除)向けなものなので、ロード速度の悪化具合とかまではちゃんとチェックはしていないです。どれくらいインストールに手間か?サインアップはすぐにできて、あとはタグをサイトに貼り付ければ記録出来ます。UIから該当のユーザーを調べることが可能になります。エラーが発生しているユーザーアカウントをCS経由で問い合わせなくて良くなるので最高!!!最終的には、タグは以下みたいな感じになりました。}}</script>調べながらやったんですが、まあ30分〜1時間あれば使い始められますね。プライバシー(?)等について画面をログするので、プライバシーみたいなものが気になると思います。ここまでログできると、正当な業務であっても難色を示す人はいそうです。(「保存ボタンを押す前の下書き」まで見えるわけですからね)一応、HTMLのクラスなどに特殊な指定をすることで、録画しないように出来ます。(つまり、かんがえられてはいるということです)それ以前(?)に、一般向けへのサービスだとプライバシーポリシーやGDPR周りで苦労がありそうですが、まあ、このあたりは色々考えていくしかないかな〜という感じですね。やっていってはいるようだが、自分のところでユーザーにどうやるか、という話は別問題。便利なロガーはこのあたりの問題をどうやっても抱えるので、各自(法務と一緒に)なんとかしていきましょう。まとめエラーが発生「した」ことがわかるツールは現状把握には重要だと思いますが、そのエラーを再現させるための情報収集で大量のprintデバッグが必要になりがち。そのあたり、LogRocketだとどういう操作をしたか(XHRでどういうリクエストを飛ばそうとしたか含む)などがわかるので実に簡便。LogRocket非常に良いですね。追伸アクセス数の多いサイトや、何でもかんでもログする!だとめちゃめちゃ高くなるかも。プライス表は、ログインした後にもう少し細かいものがあります。サーバー側で「このユーザーIDや、環境や、(サービスの保守)契約プランならJSを読み込ませる」とかしないと無理そう。(そうすれば、大抵1万セッションくらいには収まるのでは...?)例えばですけど、「IEだけタグを出すようにする」と、もはやシェアが減りつつあるIEのJSの互換性チェックできますね...便利!!ただ、エラーはすべてを確保しておくのが迅速な解決につながるし、状況に応じてかな〜。NewRelicみたいにオープン初期は金を積む!とかもよいかもしれないですね。JSエラーの検知だけは別の安価なツールで検知して、必要に応じてこいつを差し込めるように...、くらいがよいのかもわからん。(CDNはいってるとちょっと面倒かな...)あ、セッション数が溢れた後の挙動はまだわかってないです、使い切っていない(後で追記するかも)簡単でしたが、こちらからは以上です。#01」に参加してきました。»プロフィールid:uzullauzullaがブログです。参加してきました!月別アーカイブ参加グループWindows開発者はてなブログをはじめよう!uzullaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。