如何从GCE实例中经过容器优化的OS中获取启动脚本日志? [英] How do I get startup-script logs from Container-optimized OS in a GCE instance?

本文介绍了如何从GCE实例中经过容器优化的OS中获取启动脚本日志?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用此启动脚本运行容器优化的计算实例:

I'm running a container-optimized compute instance with this startup-script:

#!/bin/bash

mkdir /home/my-app
cd /home/my-app
export HOME=/home/my-app

docker-credential-gcr configure-docker


docker run --rm --log-driver=gcplogs --name my-app --security-opt seccomp=./config.json gcr.io/my-project/my-app:latest

-日志驱动程序-name 标志是根据但是我没有看到容器启动的日志.

Yet I see no logs from the container boot up.

此外,当我通过SSH进入实例并运行命令 logger您好,来自记录器" 时,我看不到它在云记录器中显示.我尝试将其转换为高级过滤器,并删除除来自记录器的Hello"之外的所有过滤器.字符串过滤器.

Also, when I'm SSHing into the instance and running command logger "hello from logger", I don't see it showing up in cloud logger. I've tried converting it to advanced filters and removing all filtering except "hello from logger" string filter.

如何正确设置日志记录?我在NodeJS应用程序中使用 bunyan ,但是当该应用程序失败时,我绝对看不见吗?我很想将 journalctl 中的所有日志保存在云记录器中.或者,至少是 journalctl startup-script 部分.现在,我通过SSH进入实例并运行 journalctl -r |来检索它们.grep启动脚本.

How do I properly setup the logging? I'm using bunyan inside my NodeJS app, but when it the app fails I have absolutely no visibility? I'd love to have all the logs from journalctl in cloud logger. Or, at least the startup-script part of journalctl. Right now I'm retrieving them by SSHing into the instance and running journalctl -r | grep startup-script.

正确设置了访问范围:

Stackdriver Logging API: Write Only
Stackdriver Logging API: Write Only

我正在使用默认的计算引擎服务帐户.这是我用来创建此VM的命令:

I'm using a default compute engine service account. Here the command that I'm creating this VM with:

gcloud compute instance-templates create $APP_ID-template \
    --scopes=bigquery,default,compute-rw,storage-rw \
    --image-project=cos-cloud \
    --image-family=cos-77-lts \
    --machine-type=e2-medium \
    --metadata-from-file=startup-script=./start.sh \
    --tags=http-server,https-server

gcloud compute instance-groups managed create $APP_ID-group \
    --size=1 \
    --template=$APP_ID-template

启动脚本:

#!/bin/bash

mkdir /home/startDir
cd /home/startDir
export HOME=/home/startDir

docker-credential-gcr configure-docker

docker run --log-driver=gcplogs --name my-app --security-opt seccomp=./config.json gcr.io/project-id/app:latest

此VM运行NodeJS脚本.我没有为我的NodeJS脚本提供JSON密钥. bunyan 记录器正确地将日志发送到云记录器.只有在服务器完全崩溃时,它才无法发送日志.

This VM running a NodeJS script. I'm not providing JSON keys to my NodeJS script. The bunyan logger is correctly sending logs to the cloud logger. It only fails to send logs when server completely crashes.

已启用日志记录API.我得到这个:

Logging API is enabled. I'm getting this:

● stackdriver-logging.service - Fluentd container for Stackdriver Logging
   Loaded: loaded (/usr/lib/systemd/system/stackdriver-logging.service; static; vendor preset: disabled)
   Active: inactive (dead)

在VM中运行 sudo systemctl status stackdriver-logging 命令时

推荐答案

Google Compute Engine容器-优化操作系统默认情况下启用了操作日志记录(以前称为Stackdriver).

Google Compute Engine Container-Optimize OS has Operations Logging (formerly Stackdriver) enabled by default.

在我的问题和解决方案列表中,问题#3是我的经验中最常见的问题.

In my list of problems and solutions, Problem #3 is the most common in my experience.

可能的问题1:

默认情况下,新实例启用了以下范围:

By default, new instances have the following scopes enabled:

  • Stackdriver Logging API:仅写
  • Stackdriver Monitoring API:仅写

如果您已修改实例的访问范围,请确保已启用Stackdriver范围.这需要停止实例以修改范围.

If you have modified the instance's Access Scopes, make sure that the Stackdriver scopes are enabled. This requires stopping the instance to modify scopes.

可能的问题2:

如果您为此实例使用自定义服务帐户,请确保该服务帐户至少具有角色 roles/logging.logWriter .没有此角色或类似角色,记录器将失败.

If you are using a custom service account for this instance, make sure the service account has at least the role roles/logging.logWriter. Without this role or similar, the logger will fail.

可能的问题3:

一个常见的问题是项目所有者未启用"Cloud Logging API".如果未启用此API,则实例记录器将失败.

A common problem is the Project Owner did not enable the `Cloud Logging API". Without enabling this API, the instance logger will fail.

要验证实例中的记录器是否发生故障,请SSH进入实例并执行以下命令:

To verify if the logger within the instance is failing, SSH into the instance and execute this command:

sudo systemctl status stackdriver-logging

如果您看到与日志记录API相关的错误消息,请启用Cloud Logging API.

If you see error messages related to the logging API, then enable the Cloud Logging API.

通过CLI启用Cloud Logging API:

Enable the Cloud Logging API via the CLI:

gcloud services enable logging.googleapis.com --project=<PROJECT_ID>

或通过Google Cloud Console:

Or via the Google Cloud Console:

https://console.cloud.google.com/apis/library/logging.googleapis.com

可能的问题4:

通过CLI创建实例时,您需要指定以下命令行选项,否则日志服务将无法启动:

When creating an instance via the CLI, you need to specify the following command line option otherwise the logging service will not start:

--metadata=google-logging-enabled=true

[UPDATE 01/22/2021]

OP有两个问题.1)Stackdriver服务未运行.以上步骤解决了该问题.2)启动脚本部分不会转到Stackdriver.

The OP has two problems. 1) Stackdriver service was not running. The above steps solved that problem. 2) The startup script section was not going to Stackdriver.

Container OS的当前配置的日志级别设置太低,无法将启动脚本日志发送到Stackdriver.

The current configuration for Container OS has the log level set too low to send startup-script logs to Stackdriver.

日志级别由文件/etc/stackdriver/logging.config.d/fluentd-lakitu.conf 设置.

查找部分收集优先级为> =警告的所有日记日志.优先级是0->4.如果您添加"5",和"6"表示到列表中,然后在操作日志中记录启动脚本.

Look for the section Collects all journal logs with priority >= warning. The PRIORITY is 0 -> 4. If you add "5" and "6" to the list, then the startup-scripts are logged in Operations Logging.

您可以更改日志级别,但是此更改不会在重新启动后持续存在.我没有找到使更改永久生效的解决方案.

You can change the log level but this change does not persist across reboots. I have not found a solution to make changes permanent.

这篇关于如何从GCE实例中经过容器优化的OS中获取启动脚本日志?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆