A couple other common log collection setups I've come across over time: * Logging to stdout/stderr in a standard format, then use a log collection API from your orchestration engine (common in the Kubernetes world to avoid logging to a file). * Logging to a log file as normal, but running a log forwarding agent alongside (e.g., Splunk, Logstash). * Logging to syslog (typically more important for auditing and security related logs)
For the log format itself, JSON template layouts work great here for customizing how much info you need in your logs. It also makes it much easier to create log indices in various log searching products. Which particular one hasn't been as important in my experience as trying to stay consistent. On Fri, Jun 18, 2021 at 7:40 AM Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > ECS <https://www.elastic.co/guide/en/ecs/current/ecs-reference.html>, the > default schema shipped with JsonTemplateLayout, is nowadays the de facto > structure for JSON formatted logs. Since Chainsaw will parse logs emitted > mostly from Log4j, it is wise to make it fully compliant with the one we > ship in Log4j. For that, search for EcsLayout.json in the sources. > > Nowadays, cool kids erect an ELK stack and hook themselves either to > Logstash (accepting JSON over TCP/IP) or Elasticsearch (accepting JSON over > HTTP). Supporting both can be handy, since then they just need to change > the host/port they have in their Log4j configuration without touching the > appender. > > > > On Fri, Jun 18, 2021 at 3:09 AM Robert Middleton <rmiddle...@apache.org> > wrote: > > > I'm looking into adding some more modern JSON support into Chainsaw > > for processing log statements from applications, but I'm not sure what > > the best format for that is at the moment. Is there a standard JSON > > format that would make the most sense to use? > > > > Currently, I'm thinking that this would make the most sense to have > > Chainsaw listen on a TCP or UDP port for the JSON messages. Are there > > any other ways that you would normally send a log message that I'm not > > thinking about? > > > > -Robert Middleton > >
