Providing "resource" argument to CloudLoggingHandler class does't work

Question

Providing resource argument to CloudLoggingHandler class doesn't work, that is, it cannot logging to stackdriver. If I comment resource out, it works fine. I also tried a simple python script that doesn't run in Django, it worked fine too.

This actually my Django LOGGING handlers settings:

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

No resource, No problem:

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

A simple script works too:

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!')

I use google-cloud-logging version is 1.10.0. Can someone give some suggestions about debugging stackdriver logging?

Answer 1

This issue is most likely caused by the resource being malformed, either because the type is not supported (or no longer supported), because the labels do not match those expected for the given type, because required labels are missing, or because special permission is required to write logs against the specific resource type in question.

In this particular case, the use of container rather than k8s_container looks suspicious. Based on this conversation as well as the existence of k8s_container in the list of Stackdriver Monitoring resource types as well as Stackdriver Logging resource types, whereas container is documented only on the latter, this is likely a deprecated resource type that has been supplanted by k8s_container.

If that does not work, failures to write the remote logs should produce logs locally (or using whatever handlers have been attached to the background thread transport); though those logs are obviously harder to access, if you can get to those logs, it should be possible to see what went wrong with the attempt to write to Stackdriver Logging.