在分析日志中识别测试机 [英] Identifying test machines in analytics logs

问题描述

我们刚刚开始将分析添加到我们的SaaS应用程序中，以开始(除其他事项外)根据使用情况为客户计费.我们遇到的问题是，在某些情况下，我们的支持团队将模拟登录到生产环境，以尝试使用客户端的配置来重现报告的问题.当他们登录时，将在他们的特定帐户已登录的我们的分析日志中输入一个条目，我们将使用该条目来计算账单.

我们必须解决的一些想法:

1)我们为登录的每台PC记录IP地址和机器密钥-我们可以过滤掉属于支持的已知IP地址和/或机器密钥.缺点是我们必须手动维护密钥/地址列表.

2)如果支持人员(或内部任何其他人员)以调试模式(而不是发行版)运行我们的应用程序，则它将不报告分析.只要支持人员/其他任何人都记得切换到调试模式，就可以了.

3)包括在配置生产系统以发送分析时需要设置的某种注册表项/类似设置.同样，只要我们的基础架构团队记得设置注册表项或设置即可.

所有这些方法都需要某种程度的人为参与，我们都知道这充其量是无稽之谈.有人遇到过类似情况吗?是否有自动化的方法来解决此问题?

(PS>当然，我们不应该在生产中进行测试，但是有一些一次性设置的客户设置实例，如果没有在生产中登录它们，我们就无法复制它们.这是我们唯一的一次这样做，这就是我在这个问题中谈论的情况.)

We''re just beginning to add analytics to our SaaS application, to begin (among other things) billing clients based on usage. The problem we''re running into is there''s a few circumstances where our support team will simulate a log in into production to try to reproduce reported issues with a client''s configuration. When they log in, an entry will be made into our analytics logs that their specific account has logged in, which we use to calculate billing.

A few ideas we had to solve this:

1) We log IP addresses as well as machine keys for each PC that logs in - we could filter out known IP addresses and/or machine keys belonging to support. The drawback is we have to maintain a list of keys / addresses manually.

2) If support (or anyone else internal) runs our application in debug mode (as opposed to release), it will not report analytics. This is fine, as long as support / anyone else remembers to switch to debug mode.

3) Include some sort of reg key / similar setting required to be set when configuring a production system in order to send analytics. Again, fine, as long as our infrastructure team remembers to set the reg key or setting.

All of these approaches require some sort of human involvement, which we all know can be iffy at best. Has anyone run into a similar situation? Is there an automated approach to this problem?

(PS> Of course, we shouldn''t be testing in production, but there are a few one-off instances with customer set up that we can''t reproduce without logging in as them in production. This is the only time we do so, and this is the case I''m talking about in this question.)

推荐答案

有一些用于禁用GA的浏览器加载项.您的支持团队可以使用它们.

http://techie-buzz.com/how-to/how-to- disable-google-analytics.html [ ^ ]

选项1是我认为最好的.过滤应该不会太困难，因为您的内部IP应该很容易识别，是您是在私有地址空间上运行还是所有内部寻址都通过一个共享的NAT网关地址在应用程序内部出现.

选项2也是一个选项，仅需要对支持团队进行培训，以确保它成为测试程序的一部分，并且让他们动脑子进行切换

选择3，我会避免涉及更多设置(尤其是那些可以由客户找到并关闭的设置).

There are browser add-ons for disabling GA. your support team could use them.

http://techie-buzz.com/how-to/how-to-disable-google-analytics.html[^]

Option 1 is the best I think. the filtering shouldn''t be too difficult as your internal IPs should be easy to identify if you are running on private address space or all addressing internally appear on the application from a single Shared NAT gateway address.

Option 2 is also an option, and the support team just need to be educated to make sure it is part of the test procedures and they get it into their heads to switch

Option 3, i would avoid, involving more settings (particularly those that could be found and turned off by the customer).

这篇关于在分析日志中识别测试机的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！