Предоставление аргумента «ресурс» классу CloudLoggingHandler не работает - PullRequest
Новая
       20

Предоставление аргумента «ресурс» классу CloudLoggingHandler не работает

1 голос
/ 20 апреля 2019

Предоставление resource аргумента для CloudLoggingHandler класса не работает, то есть он не может войти в систему stackdriver.Если я прокомментирую resource, он работает нормально.Я также попробовал простой скрипт на Python, который не работает в Django, он тоже работал нормально.

Это мои настройки обработчика Django LOGGING: 

'handlers': {
    'stderr': {
        'class': 'google.cloud.logging.handlers.CloudLoggingHandler',
        'name': "name",
        'resource': Resource(
            type="container",
            labels={
                ...
            },
        ),
        'client': google.cloud.logging.Client()
    },
},

Нет resource, нет проблем: 

'handlers': {
    'stderr': {
        'class': 'google.cloud.logging.handlers.CloudLoggingHandler',
        'name': "name",
        'client': google.cloud.logging.Client()
    },
},

Также работает простой скрипт: 

import logging
import google.cloud.logging # Don't conflict with standard logging
from google.cloud.logging.handlers import CloudLoggingHandler, setup_logging
from google.cloud.logging.resource import Resource

client = google.cloud.logging.Client()
logging.getLogger().setLevel(logging.INFO) # defaults to WARN

res = Resource(
    type="container",
    labels={
       ...
    },
)
handler = CloudLoggingHandler(client, name='name', resource=res)
setup_logging(handler)
logging.error('logging!')

Я использую google-cloud-logging версия 1.10.0.Может кто-нибудь дать несколько советов по отладке stackdriver logging?

1 Ответ

0 голосов
/ 24 мая 2019

Эта проблема, скорее всего, вызвана неправильным формированием ресурса, либо потому, что тип не поддерживается (или больше не поддерживается), потому что метки не соответствуют ожидаемым для данного типа, потому что отсутствуют требуемые метки, либо потому, чтотребуется специальное разрешение для записи журналов с указанием конкретного типа ресурса.

В этом конкретном случае использование container вместо k8s_container выглядит подозрительно.На основании этого разговора , а также наличия k8s_container в списке типов ресурсов мониторинга Stackdriver , а также типов ресурсов ведения журнала Stackdriver , тогда как container документировано только в последнем случае, это, вероятно, устаревший тип ресурса, который был заменен k8s_container.

Если это не сработает, ошибки при записи удаленных журналов должны создавать журналы локально (или с использованием любого другого типа).обработчики были прикреплены к фоновому потоку );хотя к этим журналам, очевидно, труднее получить доступ, если вы сможете добраться до этих журналов, должно быть возможно увидеть, что пошло не так с попыткой записи в журнал Stackdriver.

...