AppEngine Dev Server上的Google KMS - 日志混乱 [英] Google KMS on AppEngine Dev Server - logging clutter

问题描述

这是一个已知问题： https://issuetracker.google。 com / issues / 63253097

继续关于让Google KMS与App Engine合作的问题，我打开了一个关于相关但存在问题的副作用的新问题。

即，Google Cloud API发现似乎想要在AppEngine沙盒外漫游若干路径。这本身并不是问题，但它使得测试和调试非常成问题，因为每次尝试都会被记录下来，产生如下几百行： > INFO 03 Jul 2017 14:44:51 Sandbox阻止访问文件/ Users

INFO 03 Jul 2017 14:44:51如果它是一个静态文件，检查在你的app.yaml中设置了 application_readable：true

INFO 03 Jul 2017 14:44:52 Sandbox阻止访问文件/ usr / lib / Acrobat9 / Resource / CMap

INFO 03 Jul 2017 14:44:52如果它是一个静态文件，请检查 application_readable：true 设置在您的app.yaml中

INFO 03 Jul 2017 14:44:52 Sandbox阻止访问文件/ usr / lib / Acrobat8 / Resource / CMap

INFO 03 Jul 2017 14:44:52如果它是一个静态文件，请检查 application_readable：true 设置在你的app.yaml中

是否有aw ay禁用或禁止这些请求或日志？

编辑* 通过添加 traceback打印的许多结果之一。 print_stack（）到 log_access_check_fail 在 stub.py 中（抱歉，这里不太清晰） ：
$ b

测试＃1：Sentry.io的Raven导入 pkg_resources

 在< module>文件中的/Users/bmh/testapp/application.py，第3行。 
 from nassau.application导入应用程序，sentry 
在< module>文件中的/Users/bmh/testapp/nassau/application.py，第28行， 
 from raven.contrib.flask import Sentry 
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/raven/__init__.py，第16行，in <模块> 
 VERSION = __import __（'pkg_resources'）\ 
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第3037行，在< module> 
 @_call_aside 
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第3021行，在_call_aside 
f（ * args，** kwargs）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第3050行，在_initialize_master_working_set 
 working_set = WorkingSet._build_master（）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第646行，在_build_master 
中ws = cls（）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第639行，位于__init__ 
 self。 add_entry（entry）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，第695行，在add_entry中
 for dist in find_distributions（entry，True）：
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，2006行，in fi nd_on_path 
 path_item = _normalize_cached（path_item）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，行2217，位于_normalize_cached 
 _cache [文件名] =结果= normalize_path（文件名）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py，行2210，在normalize_path 
 return os.path.normcase（os.path.realpath（filename））
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py ，第375行，在实际路径中
路径，ok = _joinrealpath（''，filename，{}）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath。 py，第400行，在_joinrealpath 
中，如果不是islink（newpath）：
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py，第135行，在islink 
 st = os.lstat（路径）
文件/ usr / local / Caskroom / google-cloud-sdk / latest / google-cloud-sdk / platform / google_appengine / google / appengine / to ols / devappserver2 / python / stubs.py，第286行，在__call__ 
 log_access_check_fail（路径）
文件/ usr / local / Caskroom / google-cloud-sdk / latest / google-cloud-sdk /platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py，第51行，在log_access_check_fail中
 traceback.print_stack（）
  

我删除了对Sentry / Raven的依赖，但堆栈跟踪继续，通过：

测试＃2：Flask导入 pkgutil

 文件/ Users / bmh / testapp / application。 py，第3行，在< module> 
 from nassau.application import app 
在< module>文件中的/Users/bmh/testapp/nassau/application.py，第72行。 
 app = Flask（'nassau'）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/app.py，第331行，in __init__ 
 instance_path = self.auto_find_instance_path（）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/app.py，第622行，在auto_find_instance_path 
前缀，package_path = find_package（self.import_name）
文件/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/helpers.py，行661，在find_package 
 loader = pkgutil.get_loader（root_mod_name）
文件中/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /pkgutil.py，第464行，在get_loader 
返回find_loader（全名）
文件/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib /python2.7/pkgutil.py，第475行，在find_loader 
 loader = importer.find_module（fullname）
文件/usr/local/Cellar/python/2.7.13/Frameworks/Python。 F ramework / Versions / 2.7 / lib / python2.7 / pkgutil.py，第184行，在find_module 
 path = [os.path.realpath（self.path）] 
文件/ Users / bmh /testapp/python-virtualenv/lib/python2.7/posixpath.py，第375行，在实际路径中
 path，ok = _joinrealpath（''，filename，{}）
文件/ Users / bmh / testapp / python-virtualenv / lib / python2.7 / posixpath.py，第400行，在_joinrealpath中
如果不是islink（newpath）：
文件/ Users / bmh / testapp / virtualenv / lib / python2.7 / posixpath.py，第135行，在islink中
 st = os.lstat（path）
文件/ usr / local / Caskroom / google-cloud-sdk / latest /google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py，第286行，在__call__ 
 log_access_check_fail（路径）
文件/ usr / local / Cascroom / google-cloud-sdk / latest / google-cloud-sdk / platform / google_appengine / google / appengine / tools / devappserver2 / python / stubs.py，第51行，在log_access_check_fail 
 traceback.print_stack（）
  

必须有更好的方式来表示堆栈溢出的堆栈跟踪：）

解决方案

我是一名在dev_appserver上工作的全职工程师。
此日志消息从/google/appengine/tools/devappserver2/python/stubs.py中报告，方法 log_access_check_fail

我们添加此日志消息来提醒用户dev_appserver阻止文件访问的行为。

建议的解决方法：
dev_appserver.py - log_level警告

- log_level在本地python运行时进程中设置日志级别。 log_access_check_fail（）被设置为INFO并且不会被记录。注意，这个标志也会阻止你的应用程序中的其他INFO级别的日志记录。

同时，我们正在修复这个log_access_check_fail方法。它可能会将log_access_check_fail（）日志级别降低为DEBUG。

This is a known issue: https://issuetracker.google.com/issues/63253097

Further to my question about getting Google KMS working with App Engine, I'm opening a new question about a related but problematic side effect.

Namely, the Google Cloud API discovery appears to want to walk a number of paths outside the AppEngine sandbox. This itself is not a problem, but it makes testing and debugging very problematic because each attempt is logged, producing hundreds of lines like the following:

INFO 03 Jul 2017 14:44:51 Sandbox prevented access to file "/Users"

INFO 03 Jul 2017 14:44:51 If it is a static file, check that application_readable: true is set in your app.yaml

INFO 03 Jul 2017 14:44:52 Sandbox prevented access to file "/usr/lib/Acrobat9/Resource/CMap"

INFO 03 Jul 2017 14:44:52 If it is a static file, check that application_readable: true is set in your app.yaml

INFO 03 Jul 2017 14:44:52 Sandbox prevented access to file "/usr/lib/Acrobat8/Resource/CMap"

INFO 03 Jul 2017 14:44:52 If it is a static file, check that application_readable: true is set in your app.yaml

Is there a way to disable or silence these requests or logs?

EDIT* One of the many results printed by adding traceback.print_stack() to log_access_check_fail in stub.py (sorry it's not very legible here):

Test #1: Sentry.io's Raven imports pkg_resources

  File "/Users/bmh/testapp/application.py", line 3, in <module>
    from nassau.application import app, sentry
  File "/Users/bmh/testapp/nassau/application.py", line 28, in <module>
    from raven.contrib.flask import Sentry
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/raven/__init__.py", line 16, in <module>
    VERSION = __import__('pkg_resources') \
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3037, in <module>
    @_call_aside
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3021, in _call_aside
    f(*args, **kwargs)
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3050, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 646, in _build_master
    ws = cls()
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 639, in __init__
    self.add_entry(entry)
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 695, in add_entry
    for dist in find_distributions(entry, True):
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2006, in find_on_path
    path_item = _normalize_cached(path_item)
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2217, in _normalize_cached
    _cache[filename] = result = normalize_path(filename)
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2210, in normalize_path
    return os.path.normcase(os.path.realpath(filename))
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 375, in realpath
    path, ok = _joinrealpath('', filename, {})
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 400, in _joinrealpath
    if not islink(newpath):
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 135, in islink
    st = os.lstat(path)
  File "/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py", line 286, in __call__
    log_access_check_fail(path)
  File "/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py", line 51, in log_access_check_fail
    traceback.print_stack()

I removed the dependency on Sentry / Raven, but the stack traces continue, via:

Test #2: Flask imports pkgutil

  File "/Users/bmh/testapp/application.py", line 3, in <module>
    from nassau.application import app
  File "/Users/bmh/testapp/nassau/application.py", line 72, in <module>
    app = Flask('nassau')
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/app.py", line 331, in __init__
    instance_path = self.auto_find_instance_path()
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/app.py", line 622, in auto_find_instance_path
    prefix, package_path = find_package(self.import_name)
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/site-packages/flask/helpers.py", line 661, in find_package
    loader = pkgutil.get_loader(root_mod_name)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pkgutil.py", line 464, in get_loader
    return find_loader(fullname)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pkgutil.py", line 475, in find_loader
    loader = importer.find_module(fullname)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pkgutil.py", line 184, in find_module
    path = [os.path.realpath(self.path)]
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 375, in realpath
    path, ok = _joinrealpath('', filename, {})
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 400, in _joinrealpath
    if not islink(newpath):
  File "/Users/bmh/testapp/python-virtualenv/lib/python2.7/posixpath.py", line 135, in islink
    st = os.lstat(path)
  File "/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py", line 286, in __call__
    log_access_check_fail(path)
  File "/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/stubs.py", line 51, in log_access_check_fail
    traceback.print_stack()

There must be a better way to represent a stack trace on stack overflow :)

解决方案

I am a fulltime engineer working on dev_appserver. This log message is reported from /google/appengine/tools/devappserver2/python/stubs.py, in the method log_access_check_fail

We added this log message to remind users of dev_appserver's behavior of blocking file access.

Recommended workaround: dev_appserver.py --log_level warning

--log_level sets the log level in local python runtime process. The log_access_check_fail() is set to INFO and would not be logged. NOTE, this flag will also prevent other INFO level logging in your application.

Meanwhile, we are working on a fix to this log_access_check_fail method. It could be lowering log_access_check_fail() logging level to DEBUG.

这篇关于AppEngine Dev Server上的Google KMS - 日志混乱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！