ViliusS commented on PR #3586: URL: https://github.com/apache/logging-log4j2/pull/3586#issuecomment-2824475309
> One particular thing that is bothering me about this _fix_ is... it breaks backward compatibility. We can say we're fixing the schema, but for users who have already been using the _broken_ schema, we are gonna create trouble. We can > > * Cross our fingers, release the fixed schema, and think of a solution if we ever happen to receive a complaint > * Release the new schema under a different name (e.g., `GcpLayout2.json`) > > @ppkarwasz, thoughts? > > @ViliusS, would you mind adding a changelog entry file (i.e., `src/changelog/.2.x.x/3586_fix_GcpLayout.xml`), please? (Mind the `entry.type` attribute and `entry > issue` element.) Changelog added. Regarding backward compatibility I see it this way. The proposed changes are not really fixes, they are changes/improvements. Old schema probably worked in some sense, but required a little bit tinkering for proper GCP field mapping on Google side. It is natural that schemas change and they need to be re-adjusted, there is no way to avoid that when dealing with 3rd party services. The real question is when backward compatibility and how it should be broken. You are right that some users could be using old schema already, so let's try to list what's actually changed and the use cases. 1) The `timestamp` field users who just send the data from previous field directly to GCP not realizing that it is not mapped to real log timestamp. Nothing serious changes for them, new timestamp fields will be sent to GCP and automatically mapped to log timestamp. They will be missing previous `jsonPayload.timestamp` field on GCP side, but that should not break anything serious. 2) `Timestamp` field users who processed current field values with Ops Agent or any other tool to be able to map it to GCP timestamp. Such tools usually just ignore missing field, but again information is now sent to GCP's timestamp field automatically, so nothing is lost. 3) Removed `insertId` field. Nothing should depend on this field. It is for internal GCP usage and will now be generated automatically. 4) Renamed/Changed `exception` format and removed separate `class` and `message` subfields. Some could depend on these fields in Google Cloud Monitoring but would consider it as an edge case, since the exception was/is duplicated in main `message` field anyway and was/is caught by the Google Error Reporting automatically. There was/is not need to configure separate monitoring. 5) Renamed `thread` and `logger` fields. Some could depend on these fields in Google Cloud Monitoring but, again, I would consider it as an edge case. Considering that new adjustments makes it a lot easier to send logs to GCP now without major processing in between, and if they are included in 2.25.0, I think it is fair. @ppkarwasz I wouldn't call it `OpsAgent`. This format could be used to print directly to stdout which is then automatically sent to GCP on Google's Kubernetes Engine or serverless AppEngine services. I would not differentiate it from ECS or Gelf you already support. I also don't think it belongs to Ops Agent repo. If, for example, I want to use two monitoring systems and both require different formats moving JSON template elsewhere means that I must use Ops Agent for one monitoring solution, and then use different agent for another solution. Having JSON templates in central repo makes things must easier and more transparent. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
