ViliusS commented on PR #3586: URL: https://github.com/apache/logging-log4j2/pull/3586#issuecomment-2830515465
> > 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. > > Looking at [GoogleCloudPlatform/ops-agent#1920 (comment)](https://github.com/GoogleCloudPlatform/ops-agent/issues/1920#issuecomment-2769381753) there are currently three different ways to interpret structured logs in Google Cloud: > > 1. The [legacy `fluentd`-based agent](https://cloud.google.com/logging/docs/agent/logging/configuration#special-fields), which we can probably disregard. > 2. The default [`out_stackdriver` configuration](https://github.com/fluent/fluent-bit-docs/blob/master/pipeline/outputs/stackdriver_special_fields.md). > 3. The [special fields interpreted by `OpsAgent`](https://cloud.google.com/logging/docs/agent/ops-agent/configuration#special-fields). > > So I think we should use a template name that suggests, which of these formats is supported, like `GoogleOpsAgent.json`. This way we can further specialize the format by: > > * Replacing `severity` with `logging.googleapis.com/severity`. > * Removing the unsupported `logging.googleapis.com/trace_sampled` field. > > **Note**: We can also add multiple templates, one for `stackdriver` and one for `OpsAgent`. What do you think? To properly maintain the new templates, for me it is important to know **exactly** which specification we need to follow. I thought about this earlier, but for me it looked like too few differences to support different templates. Also, because of those subtle differences, it could be complicated to document for the end users which template in which case needs to be used. Given that OpsAgent is just one tool to process logs, and folks could be using any other log sending methods or processors, like for example native OTLP one, there is a question how many of these JSON templates we should have. That's why I tried to come up with a format which is as close as possible natively supported by Google Cloud Looging itself. Sure you need to apply few tricks in every processor (in OpsAgent case for `severity` and `trace_sampled` fields), but in my mind these tools are there exactly for that reason, i.e. match log fields from source to destination, in case of differences. Nevertheless, I will support any decision. -- 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
