基本的网页操作，比如用户登录，我们希望能够搜集到用户登录的失败原因和次数，这样我们可以统计到用户登录的主要原因，以此发现我们网页哪部分对用户做的不够友好。
以登录来讲，像验证码输入错误这种前端就能验证的错误，还有密码错误这种到后端接口返回才能知道的错误，我们希望都能搜集到一张统计的日志表。
当我们修改登录流程的时候，通过对日志表的定时分析能够准确的知道这次修改对用户产生的实际影响；当我们换用验证码的时候，也能计算得到实际的效果变化。
不知道各位大大平时有没有类似的需求，这样的需求如何实现比较方便呢？
其实你这个需求在很多支付平台的登录、支付操作页面是很有必要的。
验证码这种也是属于后端验证吧。通过前端的ajax请求到后端程序校验用户填写的和实际验证码，这样应该也是在后端记录。要希望能把尽可能多的登录信息记录，就要细化正对你的登录业务流程来逐步记录。而且实现前后端统一日志，日志当然是全部在后端采集存储，所以前端采集的数据也是要想办法传到后端来存储记录的。
既然是流程，那么可以按照我们小时候写记叙文的方法来，时间、地点、人物、事件。
1.时间
或者说耗时，最能直接体现用户感受。这里的耗时有几种，前端可以记录页面加载时间，等用户登录的时候捎带数据。然后就是用户从打开页面到开始输入用户名，或用户开始输入用户名到最后提交的耗时，当然这里应该按照你的登录流程来分析，这几个时间都是前端可以采集到的，当然如果你们的流程比较复杂，时间点可以分的更细。最好在必要的后端交互操作时候把数据传输到后端记录。
2.地点
这个就是判断用户的“位置”了，比如：用户访问的页面完整路径；用户GET这个登录页面的浏览器信息、来源信息等。这些都是可以从http请求头里面得到。还有比如请求IP的归属地等等。
3.人物
当然没有登录前，我们不知道是哪个用户。最简单的记录也就是GET这个登录页面的IP地址了，这个应该是整个记录的开始，用请求IP作为一个登录流程的开始标记。然后具体再看你的业务流程。（插一句，还有些那种变态的细节，比如你是否要考虑通IP登录的问题，或者还有宽带运营商的NAT444处理的网络地址还需要记录端口。）
4.事件
就是你具体的登录事件了，按业务采集必要的操作，这里多是前端的吧。然后和后端交互的时候传递。
就先想到这些~
不需要单独记日志，让每次用户登录失败会有不同的apache访问日志，分析用户行为路径就可以得到你想要的结果