Re: How about adding a new flunt log client implementation
Dell - Internal Use - Confidential
We have talked about potentially changing the new Go logging service to use an open logging framework. I’ll add this to architectural discussions we need to look at for Delhi or beyond. As we consider potential options, there are a few requirements that we have that we should consider as we discuss options:
1) The logging service (and implementation framework underneath) must be able to log to a file or other persistence mechanism (like Mongo or other database) or both
2) The logging service must offer a unifying/collector for all logs of all micro services, but each service should have the option to log locally as well (and potentially not log through the logging service)
3) The logging service (and implementation framework underneath) must allow for historical query across whatever logs it keeps and allow queries that are supportive of the current logging service API.
4) The logging service should be non-blocking so that the performance hit on the actual micro service is minimal.
Additionally, we want to make sure any framework we use is OS and hardware agnostic and that we weighed it against the impact on overall footprint, startup time, and other performance metric that we consider critical.
From: EdgeX-GoLang@... [mailto:EdgeX-GoLang@...] On Behalf Of vinoyang
Sent: Friday, May 04, 2018 9:49 AM
Subject: [Edgex-golang] How about adding a new flunt log client implementation
fluentd's golang version. fluntd is a popular unified logging layer.