尧图网页设计 
示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载导读本文围绕 python-docs-samples 仓库中 run/logging-manual 示例讲解如何在 Cloud Run 服务中以手动方式不依赖专用日志 SDK 的自动注入向 Cloud Logging 发送结构化日志structured logs。读完本文你将掌握结构化日志条目的 JSON 构建方法、如何通过X-Cloud-Trace-Context请求头实现日志与链路追踪trace的关联、完整的 Docker 构建与本地运行流程以及通过gcloud将服务部署到 Cloud Run 并配合测试验证日志落地的完整闭环。示例定位为什么需要手动记录结构化日志Cloud Run 会自动把服务向stdout/stderr写入的每一行文本收集到 Cloud Logging并在请求日志中附带基础元数据。但默认的文本日志只能按整行检索无法按字段过滤、排序或聚合。logging-manual 示例演示的是不借助google-cloud-loggingSDK 自动采集的轻量做法应用自己把日志内容组织成 JSON 对象含severity、message、自定义字段等通过print(json.dumps(entry))输出Cloud Logging 会将其识别为jsonPayload结构化条目从而支持jsonPayload.component arbitrary-property这类精细查询。该示例的完整代码位于 run/logging-manual/main.py依赖配置见 run/logging-manual/requirements.txt。核心实现结构化日志条目的构建逻辑1. 项目 ID 的获取方式index()路由首先从环境变量读取项目 ID# This is set as a custom environment variable on deployment. # To automatically detect the current project, use the metadata server. PROJECT os.environ[GOOGLE_CLOUD_PROJECT]该环境变量在部署时由--set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}注入见下文部署一节源码注释同时指出如需自动探测当前项目可改用 Cloud Run 容器契约提供的 metadata server 机制。2. 请求日志关联X-Cloud-Trace-Context头解析Cloud Run 会在每个 HTTP 请求中注入X-Cloud-Trace-Context请求头格式为TRACE_ID/SPAN_ID;oOPTIONS。示例将其中的 trace id 提取出来拼装成 Cloud Logging 要求的 trace 资源名trace_header request.headers.get(X-Cloud-Trace-Context) if trace_header and PROJECT: trace trace_header.split(/) global_log_fields[ logging.googleapis.com/trace ] fprojects/{PROJECT}/traces/{trace[0]}要点只有携带该请求头时才会写入logging.googleapis.com/trace字段字段名是 Cloud Logging 的保留键写入后日志条目就会与对应 trace 关联可在 Cloud Logging 的日志详情中直接跳转链路追踪示例还做了request_is_defined判断避免在非 HTTP 上下文例如非 HTTP 型 Cloud Functions中访问未定义的request对象。3. 结构化条目的完整组装与输出entry dict( severityNOTICE, messageThis is the default display field., componentarbitrary-property, **global_log_fields, ) print(json.dumps(entry))severity日志级别使用 Cloud Logging 的标准级别名称如NOTICE、INFO、WARNING、ERROR此处为NOTICEmessage默认展示字段是日志查看器中最直观的文本内容component自定义业务字段落到jsonPayload.component下可被 Logging 过滤表达式精确匹配通过**global_log_fields将 trace 关联字段合并进条目print(json.dumps(entry))输出单行 JSON这正是 Cloud Logging 识别结构化日志的入口。完整的可运行实现见 run/logging-manual/main.py。构建容器镜像示例使用标准 Python 官方镜像构建Dockerfile 位于 run/logging-manual/Dockerfile几个关键点FROM python:3.14 ENV PYTHONUNBUFFERED True COPY requirements.txt ./ RUN pip install -r requirements.txt ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:appPYTHONUNBUFFERED True关闭 Python 输出缓冲保证日志语句立即出现在 Cloud Run 日志中这是日志类示例的关键配置先单独COPY requirements.txt再pip install可让依赖层利用 Docker 层缓存代码变更时无需重装依赖启动命令使用 gunicorn生产级 WSGI 服务器--bind :$PORT绑定容器运行时注入的端口--timeout 0关闭 worker 超时以适配 Cloud Run 的实例扩缩容模型多核环境可按核数调大--workers。执行构建README 原文命令docker build --tag logging-manual:python .本地运行与验证用 Docker 在本地跑起来docker run --rm -p 9090:8080 -e PORT8080 logging-manual:python-p 9090:8080把本机 9090 端口映射到容器内 8080-e PORT8080设置容器内的PORT环境变量gunicorn 将据此监听访问http://localhost:9090/页面返回Hello Logger!同时控制台会输出一行 JSON 结构化日志。本地直接运行非容器main.py底部的入口支持脱离 Docker 直接启动if __name__ __main__: PORT int(os.getenv(PORT)) if os.getenv(PORT) else 8080 app.run(host127.0.0.1, portPORT, debugTrue)注意本地开发模式下监听127.0.0.1仅用于调试Cloud Run 生产环境一律走 Dockerfile 中的 gunicorn 入口。测试单元测试与端到端验证单元测试mock 日志输出run/logging-manual/main_test.py 使用 Flask 测试客户端和 pytest 的capsys捕获标准输出覆盖三个场景测试用例行为断言test_no_trace_in_headers不带任何请求头访问/返回 200输出中不含tracetest_with_cloud_headers携带X-Cloud-Trace-Context: foo/bar访问/输出中包含trace即成功写入 trace 关联字段test_no_http_request直接调用main.index()无 HTTP 上下文输出中不含trace验证了非 HTTP 场景的容错分支本地执行pytest如未安装 pytest先执行pip install pytest测试依赖见 run/logging-manual/requirements-test.txt。端到端测试真实部署验证日志落地run/logging-manual/e2e_test.py 演示了完整的构建镜像 → 部署 Cloud Run → 验证日志链路用gcloud builds submit构建镜像用gcloud run deploy部署到us-central1--platformmanaged部署时设置GOOGLE_CLOUD_PROJECT环境变量并关闭匿名访问--no-allow-unauthenticated测试通过gcloud auth print-identity-token获取身份令牌后带Authorization: Bearer访问请求头同时携带X-Cloud-Trace-Context: foo/bar请求后 sleep 片刻再用LoggingServiceV2Client来自google-cloud-logging按过滤条件查询timestamp... resource.typecloud_run_revision AND severityNOTICE AND resource.labels.service_nameservice AND jsonPayload.componentarbitrary-property并做最多 10 次线性退避重试直至查到对应日志条目——这正是结构化日志字段severity、jsonPayload.component、服务标签真正可查询的实证。由于该测试依赖 Docker 与真实 GCP 环境仓库通过 run/logging-manual/noxfile_config.py 仅在 Python 3.14与 Dockerfile 一致会话中运行。部署到 Cloud RunREADME 提供了完整的部署命令依次完成三件事# 1. 设置项目 ID export GOOGLE_CLOUD_PROJECTPROJECT_ID # 2. 用 Cloud Build 提交构建并推送到 Container Registry gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/logging-manual # 3. 部署到 Cloud Run并把项目 ID 注入为环境变量 gcloud run deploy logging-manual \ --image gcr.io/${GOOGLE_CLOUD_PROJECT}/logging-manual \ --set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}部署要点--set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}不可或缺因为 main.py 会直接读取该变量来拼装 trace 资源名该环境变量也可在创建服务时通过 run/logging-manual/app.json 声明用于 Cloud Shell 一键部署时的参数提示部署完成后访问服务 URL随后到 Cloud Logging 控制台按resource.typecloud_run_revision过滤即可看到带jsonPayload的结构化日志条目。排查与调优建议日志不实时出现确认 Dockerfile 中保留了ENV PYTHONUNBUFFERED True否则 Python 缓冲可能导致日志延迟刷出trace 关联不生效检查日志中是否包含logging.googleapis.com/trace字段且GOOGLE_CLOUD_PROJECT是否与服务所在项目一致——该字段只有在请求携带X-Cloud-Trace-Context且项目 ID 存在时才写入参见 main.py自定义字段检索结构化日志的自定义字段如component会落在jsonPayload下查询时应写成jsonPayload.componentarbitrary-property这一点在 e2e_test.py 的过滤条件中已给出可直接复用的写法日志量控制手动日志不经过 SDK 采样对高流量服务应结合 Cloud Logging 的日志级别过滤或抽样策略使用避免成本失控。延伸阅读同仓库中 run/README.md 提供了 Cloud Run Python 示例的通用构建、本地运行含注入服务账号凭据与部署流程如需了解自动采集日志与更多 Cloud Run 运维细节可参考 Cloud Run 官方 Logging How-to GuideREADME 中给出的外部链接此处不再重复列出。本示例的核心价值在于用最少的依赖仅 Flask gunicorn通过一个print(json.dumps(...))就把日志从可读的文本升级为可检索、可关联 trace、可按字段过滤的结构化数据是理解 Cloud Logging 结构化日志模型的最佳入门范本。赞分享示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载相关推荐Google Cloud Run Python 示例指南从 Docker 本地构建到 gcloud 一键部署Google Cloud Run Python 示例指南从 Docker 本地构建到 gcloud 一键部署 本篇技术指南以 python docs samp示例工程python-docs-samples 实战基于 Cloud Run Job 将 Cloud Storage 导出的日志回灌到 Cloud Loggingpython docs samples 实战基于 Cloud Run Job 将 Cloud Storage 导出的日志回灌到 Cloud Logging 本示例工程如何用 AgentScope 2.0 搭建多智能体应用从终端到 Web 服务的快速上手指南如何用 AgentScope 2.0 搭建多智能体应用从终端到 Web 服务的快速上手指南 AgentScope 2.0 是阿里通义实验室开源的多智能体框架人工智能大模型AI Agent多智能体Agent 框架Agent 编排工具调用RAGMCP 服务语音上一篇Vulkan-Docs中的查询机制详解从基础到高级应用下一篇如何永久保存微信聊天记录5步实现数据备份与智能分析的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloud Run 手动结构化日志（logging-manual）Python 示例：从源码到部署全解析
示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载导读本文围绕 python-docs-samples 仓库中 run/logging-manual 示例讲解如何在 Cloud Run 服务中以手动方式不依赖专用日志 SDK 的自动注入向 Cloud Logging 发送结构化日志structured logs。读完本文你将掌握结构化日志条目的 JSON 构建方法、如何通过X-Cloud-Trace-Context请求头实现日志与链路追踪trace的关联、完整的 Docker 构建与本地运行流程以及通过gcloud将服务部署到 Cloud Run 并配合测试验证日志落地的完整闭环。示例定位为什么需要手动记录结构化日志Cloud Run 会自动把服务向stdout/stderr写入的每一行文本收集到 Cloud Logging并在请求日志中附带基础元数据。但默认的文本日志只能按整行检索无法按字段过滤、排序或聚合。logging-manual 示例演示的是不借助google-cloud-loggingSDK 自动采集的轻量做法应用自己把日志内容组织成 JSON 对象含severity、message、自定义字段等通过print(json.dumps(entry))输出Cloud Logging 会将其识别为jsonPayload结构化条目从而支持jsonPayload.component arbitrary-property这类精细查询。该示例的完整代码位于 run/logging-manual/main.py依赖配置见 run/logging-manual/requirements.txt。核心实现结构化日志条目的构建逻辑1. 项目 ID 的获取方式index()路由首先从环境变量读取项目 ID# This is set as a custom environment variable on deployment. # To automatically detect the current project, use the metadata server. PROJECT os.environ[GOOGLE_CLOUD_PROJECT]该环境变量在部署时由--set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}注入见下文部署一节源码注释同时指出如需自动探测当前项目可改用 Cloud Run 容器契约提供的 metadata server 机制。2. 请求日志关联X-Cloud-Trace-Context头解析Cloud Run 会在每个 HTTP 请求中注入X-Cloud-Trace-Context请求头格式为TRACE_ID/SPAN_ID;oOPTIONS。示例将其中的 trace id 提取出来拼装成 Cloud Logging 要求的 trace 资源名trace_header request.headers.get(X-Cloud-Trace-Context) if trace_header and PROJECT: trace trace_header.split(/) global_log_fields[ logging.googleapis.com/trace ] fprojects/{PROJECT}/traces/{trace[0]}要点只有携带该请求头时才会写入logging.googleapis.com/trace字段字段名是 Cloud Logging 的保留键写入后日志条目就会与对应 trace 关联可在 Cloud Logging 的日志详情中直接跳转链路追踪示例还做了request_is_defined判断避免在非 HTTP 上下文例如非 HTTP 型 Cloud Functions中访问未定义的request对象。3. 结构化条目的完整组装与输出entry dict( severityNOTICE, messageThis is the default display field., componentarbitrary-property, **global_log_fields, ) print(json.dumps(entry))severity日志级别使用 Cloud Logging 的标准级别名称如NOTICE、INFO、WARNING、ERROR此处为NOTICEmessage默认展示字段是日志查看器中最直观的文本内容component自定义业务字段落到jsonPayload.component下可被 Logging 过滤表达式精确匹配通过**global_log_fields将 trace 关联字段合并进条目print(json.dumps(entry))输出单行 JSON这正是 Cloud Logging 识别结构化日志的入口。完整的可运行实现见 run/logging-manual/main.py。构建容器镜像示例使用标准 Python 官方镜像构建Dockerfile 位于 run/logging-manual/Dockerfile几个关键点FROM python:3.14 ENV PYTHONUNBUFFERED True COPY requirements.txt ./ RUN pip install -r requirements.txt ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:appPYTHONUNBUFFERED True关闭 Python 输出缓冲保证日志语句立即出现在 Cloud Run 日志中这是日志类示例的关键配置先单独COPY requirements.txt再pip install可让依赖层利用 Docker 层缓存代码变更时无需重装依赖启动命令使用 gunicorn生产级 WSGI 服务器--bind :$PORT绑定容器运行时注入的端口--timeout 0关闭 worker 超时以适配 Cloud Run 的实例扩缩容模型多核环境可按核数调大--workers。执行构建README 原文命令docker build --tag logging-manual:python .本地运行与验证用 Docker 在本地跑起来docker run --rm -p 9090:8080 -e PORT8080 logging-manual:python-p 9090:8080把本机 9090 端口映射到容器内 8080-e PORT8080设置容器内的PORT环境变量gunicorn 将据此监听访问http://localhost:9090/页面返回Hello Logger!同时控制台会输出一行 JSON 结构化日志。本地直接运行非容器main.py底部的入口支持脱离 Docker 直接启动if __name__ __main__: PORT int(os.getenv(PORT)) if os.getenv(PORT) else 8080 app.run(host127.0.0.1, portPORT, debugTrue)注意本地开发模式下监听127.0.0.1仅用于调试Cloud Run 生产环境一律走 Dockerfile 中的 gunicorn 入口。测试单元测试与端到端验证单元测试mock 日志输出run/logging-manual/main_test.py 使用 Flask 测试客户端和 pytest 的capsys捕获标准输出覆盖三个场景测试用例行为断言test_no_trace_in_headers不带任何请求头访问/返回 200输出中不含tracetest_with_cloud_headers携带X-Cloud-Trace-Context: foo/bar访问/输出中包含trace即成功写入 trace 关联字段test_no_http_request直接调用main.index()无 HTTP 上下文输出中不含trace验证了非 HTTP 场景的容错分支本地执行pytest如未安装 pytest先执行pip install pytest测试依赖见 run/logging-manual/requirements-test.txt。端到端测试真实部署验证日志落地run/logging-manual/e2e_test.py 演示了完整的构建镜像 → 部署 Cloud Run → 验证日志链路用gcloud builds submit构建镜像用gcloud run deploy部署到us-central1--platformmanaged部署时设置GOOGLE_CLOUD_PROJECT环境变量并关闭匿名访问--no-allow-unauthenticated测试通过gcloud auth print-identity-token获取身份令牌后带Authorization: Bearer访问请求头同时携带X-Cloud-Trace-Context: foo/bar请求后 sleep 片刻再用LoggingServiceV2Client来自google-cloud-logging按过滤条件查询timestamp... resource.typecloud_run_revision AND severityNOTICE AND resource.labels.service_nameservice AND jsonPayload.componentarbitrary-property并做最多 10 次线性退避重试直至查到对应日志条目——这正是结构化日志字段severity、jsonPayload.component、服务标签真正可查询的实证。由于该测试依赖 Docker 与真实 GCP 环境仓库通过 run/logging-manual/noxfile_config.py 仅在 Python 3.14与 Dockerfile 一致会话中运行。部署到 Cloud RunREADME 提供了完整的部署命令依次完成三件事# 1. 设置项目 ID export GOOGLE_CLOUD_PROJECTPROJECT_ID # 2. 用 Cloud Build 提交构建并推送到 Container Registry gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/logging-manual # 3. 部署到 Cloud Run并把项目 ID 注入为环境变量 gcloud run deploy logging-manual \ --image gcr.io/${GOOGLE_CLOUD_PROJECT}/logging-manual \ --set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}部署要点--set-env-vars GOOGLE_CLOUD_PROJECT${GOOGLE_CLOUD_PROJECT}不可或缺因为 main.py 会直接读取该变量来拼装 trace 资源名该环境变量也可在创建服务时通过 run/logging-manual/app.json 声明用于 Cloud Shell 一键部署时的参数提示部署完成后访问服务 URL随后到 Cloud Logging 控制台按resource.typecloud_run_revision过滤即可看到带jsonPayload的结构化日志条目。排查与调优建议日志不实时出现确认 Dockerfile 中保留了ENV PYTHONUNBUFFERED True否则 Python 缓冲可能导致日志延迟刷出trace 关联不生效检查日志中是否包含logging.googleapis.com/trace字段且GOOGLE_CLOUD_PROJECT是否与服务所在项目一致——该字段只有在请求携带X-Cloud-Trace-Context且项目 ID 存在时才写入参见 main.py自定义字段检索结构化日志的自定义字段如component会落在jsonPayload下查询时应写成jsonPayload.componentarbitrary-property这一点在 e2e_test.py 的过滤条件中已给出可直接复用的写法日志量控制手动日志不经过 SDK 采样对高流量服务应结合 Cloud Logging 的日志级别过滤或抽样策略使用避免成本失控。延伸阅读同仓库中 run/README.md 提供了 Cloud Run Python 示例的通用构建、本地运行含注入服务账号凭据与部署流程如需了解自动采集日志与更多 Cloud Run 运维细节可参考 Cloud Run 官方 Logging How-to GuideREADME 中给出的外部链接此处不再重复列出。本示例的核心价值在于用最少的依赖仅 Flask gunicorn通过一个print(json.dumps(...))就把日志从可读的文本升级为可检索、可关联 trace、可按字段过滤的结构化数据是理解 Cloud Logging 结构化日志模型的最佳入门范本。赞分享示例工程【免费下载链接】python-docs-samplesCode samples used on cloud.google.com项目地址https://gitcode.com/GitHub_Trending/py/python-docs-samples点击查看免费下载相关推荐Google Cloud Run Python 示例指南从 Docker 本地构建到 gcloud 一键部署Google Cloud Run Python 示例指南从 Docker 本地构建到 gcloud 一键部署 本篇技术指南以 python docs samp示例工程python-docs-samples 实战基于 Cloud Run Job 将 Cloud Storage 导出的日志回灌到 Cloud Loggingpython docs samples 实战基于 Cloud Run Job 将 Cloud Storage 导出的日志回灌到 Cloud Logging 本示例工程如何用 AgentScope 2.0 搭建多智能体应用从终端到 Web 服务的快速上手指南如何用 AgentScope 2.0 搭建多智能体应用从终端到 Web 服务的快速上手指南 AgentScope 2.0 是阿里通义实验室开源的多智能体框架人工智能大模型AI Agent多智能体Agent 框架Agent 编排工具调用RAGMCP 服务语音上一篇Vulkan-Docs中的查询机制详解从基础到高级应用下一篇如何永久保存微信聊天记录5步实现数据备份与智能分析的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考