KubeMonitor is a macOS app that displays information about your active Kubernetes cluster in your menu bar
convert client info into gapic subclass
fixed lint issues
Merge branch 'fix_headers' of github.com:googleapis/python-logging into fix_headers
When client_info is not given to a new client, it now defaults to the values used by
self._connection._client_info, rather than using None. This will allow the expected headers to be populated when using the grpc transport
Also added tests to ensure client_info is always set as expected in all classes
When a new client is initialized, there is no default value for the
client_info parameter. This means that some of the expected headers are not being set on calls through the client, causing our instrumentation to not capture them properly.
Yes, this seems directly related to https://github.com/googleapis/google-cloud-go/issues/6995. Unfortunately, fully fixing would significantly change the current behaviour of existing loggers, since many jsonPayloads would change into textPayloads after the change. So it will have to wait until we are ready for our next major release to make the breaking change.
We can partially address this by adding an extra timestamp value with the proper formatting. There would still be an extra timestamp in the jsonPayload, but at least the timestamp field would also be set properly. I can try to look into that soon
Improve the Logging quickstart in Python. Quickstart should work out of the box and contain all the instructions (in comments) so users can immediately see their logs.
logging.warning(text)rather than directly writing LogEntries. Context: In an ideal world, customers should be able to use existing logging frameworks native to their language. With some simple appender/handler to also ship logs to Cloud Logging. Customers aren't locked into logging library syntax, thus it's easier to both onboarding and offboard off of these client libraries.
I tryed to use
google.cloud.logging_v2.handlers.middleware.RequestMiddleware at Django 4.1.3, Python 3.10 but errors raises bellow:
/path --> error raised.
# settings.py at Django MIDDLEWARE = [ 'google.cloud.logging_v2.handlers.middleware.RequestMiddleware', 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]
Traceback (most recent call last): File "/home/vagrant/tmp/myproject/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) File "/home/vagrant/tmp/myproject/venv/lib/python3.10/site-packages/django/utils/deprecation.py", line 131, in __call__ if self._is_coroutine: AttributeError: 'RequestMiddleware' object has no attribute '_is_coroutine'
At the same code, when using Django 4.0.8, it's working.
I just did a quick test with Django 4.1.3, and didn't run into any issues. Please re-open it if you still have problems after the 3.3.0 release
Given the expectations to the backward compatibility and an attempt to avoid introduction of the new interfaces while keeping the existing interface intuitive, I propose the following implementation and recommend to extend it to the java-logging-logback library:
LoggingHandler.severityFor(Level level)method to switch/case based on the
java.util.logging.Levelvalues and not
Integervalues that supposed to reflect the numeric values of the logging levels.
- For the
case Level.OFFreturn null:
case Level.OFF: return null;
- Keep the rest implementation (I mainly reference to LoggingImpl.java:885) as it is now.
Yeah, this seems like a great solution to me. It seems to be in line with the original intent of the setFlushSeverity function, where null was documented to mean "flush off", so this feels like the safest way to implement this change
Unrecognized is part of the log severity proto definition. The spec doesn't make it clear how it is meant to be used, but that doesn't mean it's safe to redefine.
We will likely encounter some legitimate logs with their severity field set to "unrecognized". (speculation: maybe some OTel exporters will use "unrecognized" when there's not a direct mapping between a GCP LogSeverity and a different vendor's?) If we treat "Unrecognized" to mean "Log flushing Off", that could make things confusing if customers attempt to actually filter for those logs. And it could be hard to fix in the future
pending writes if log severity is equal or above flush severity...
LogSeverity.UNRECOGNIZEDalready exists and I use it only for this specific feature to indicate that we should skip logging since flush severity
My concern is that the spec for LogSeverity.UNRECOGNIZED was not intended to mean "log flusing off", so I'm worried about future problems from overloading the meaning of that field
but I was thinking that creating
Severity.OFF = LogSeverity.UNRECOGNIZEDdid not make much sense either since
Severityis tied with
Could we do
Severity.OFF = null instead, so we're not overloading an existing field?
Severity.UNRECOGNIZEDas a severity to signal turning off flushing for
java-loggingsince there is no way to extend equivalent
Severity.UNRECOGNIZED for this doesn't really sit right with me. It feels like it could cause significant technical debt in the future.
There was an extra space in the API doc markdown table, causing the formatting to break