App引擎中的记录器实体

发布于 2024-12-03 01:32:21 字数 257 浏览 1 评论 0原文

在应用程序引擎中使用记录器实体来写入日志是否可行?我将有一个大约 1500req/sec 的应用程序,并且正在考虑使用任务队列来完成它。每当我收到请求时,我都会创建一个任务并将其放入队列中以向日志实体写入内容(具有日期和字符串属性)。

我需要这个,因为我必须将统计数据放入网站中,我认为这样做并稍后使用后端读取日志可以解决问题。如果我能够以编程方式访问应用程序引擎日志(通过日志记录),那就太棒了,但由于这是不可用的,我看不到任何其他方法可以做到这一点。

非常欢迎反馈

Is it viable to have a logger entity in app engine for writing logs? I'll have an app with ~1500req/sec and am thinking about doing it with a taskqueue. Whenever I receive a request, I would create a task and put it in a queue to write something to a log entity (with a date and string properties).

I need this because I have to put statistics in the site that I think that doing it this way and reading the logs with a backend later would solve the problem. Would rock if I had programmatic access to the app engine logs (from logging), but since that's unavailable, I dont see any other way to do it..

Feedback is much welcome

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

彩虹直至黑白 2024-12-10 01:32:21

有几种方法可以做到这一点:

  1. 累积日志并将其写入请求末尾的单个数据存储中。这是延迟最高的选项,但只有一点点 - 数据存储放置相当快。该解决方案也是所有选项中消耗最少资源的。
  2. 累积日志并使用它们将任务队列任务排入队列,这会将它们写入数据存储(或对它们执行任何您想要的操作)。这稍微快一些(任务队列排队往往很快),但稍微复杂一些,并且数据限制为 100kb(希望这不应该成为限制)。
  3. 将数据放入拉取任务队列,并让常规推送任务或后端使用队列并批量插入到数据存储中。这比选项 2 更复杂,但也更高效。
  4. 运行一个累积和写入日志的后端,并对其进行 URLFetch 调用以存储日志。 urlfetch 处理程序可以将数据写入后端内存并异步返回,这在增加用户延迟方面是最快的(urlfetch 调用不到 1 毫秒)!不过,这需要等待 Python 2.7,因为您需要多线程来异步处理日志条目。

您可能还想查看 Prospective Search API,它可以让您对日志数据进行一些过滤和预处理。

There are a few ways to do this:

  1. Accumulate logs and write them in a single datastore put at the end of the request. This is the highest latency option, but only slightly - datastore puts are fairly fast. This solution also consumes the least resources of all the options.
  2. Accumulate logs and enqueue a task queue task with them, which writes them to the datastore (or does whatever else you want with them). This is slightly faster (task queue enqueues tend to be quick), but it's slightly more complicated, and limited to 100kb of data (which hopefully shouldn't be a limitation).
  3. Enqueue a pull task with the data, and have a regular push task or a backend consume the queue and batch-and-insert into the datastore. This is more complicated than option 2, but also more efficient.
  4. Run a backend that accumulates and writes logs, and make URLFetch calls to it to store logs. The urlfetch handler can write the data to the backend's memory and return asynchronously, making this the fastest in terms of added user latency (less than 1ms for a urlfetch call)! This will require waiting for Python 2.7, though, since you'll need multi-threading to process the log entries asynchronously.

You might also want to take a look at the Prospective Search API, which may allow you to do some filtering and pre-processing on the log data.

梦里泪两行 2024-12-10 01:32:21

如何保留请求信息的 Memcache 数据结构(在请求到达时进行记录),然后每 5 分钟(或更快)运行一次 cron 作业,该作业处理来自 memcache 的最后 5 分钟请求的统计信息,并将这些统计信息记录在该 5 分钟间隔的数据存储。然后,相同(或不同)的 cron 作业也可以清除内存缓存 - 这样它就不会变得太大。

然后,您可以根据 5 分钟间隔统计数据的聚合运行全局分析,这可能比分析数小时的 1500req/s 数据更易于管理。

How about keeping a memcache data structure of request info (recorded as they arrive) and then run an every 5 minute (or faster) cron job that crunches the stats on the last 5 minutes of requests from the memcache and just records those stats in the data store for that 5 minute interval. The same (or a different) cron job could then clear the memcache too - so that it doesn't get too big.

Then you can run big-picture analysis based on the aggregate of 5 minute interval stats, which might be more manageable than analyzing hours of 1500req/s data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文