Answers:
“无服务器”主要是指您拥有相对简单的微服务，通常只有少量的webapp或自动连接到REST前端的单个功能。应用与使用更传统的Web服务时相同的概念：通常是远程syslog和ElasticSearch编写器的混合使用。
网络或远程系统日志已经存在很长时间了，并且具有相当强大的工具集。您将必须运行中央syslog服务器，但是协议非常简单，并且每种语言都有纯客户端库，可用于发送日志。远程系统日志的一个普遍问题是，它传统上是基于UDP的。这意味着在高负载下，某些日志消息可能会丢失。这可能是一件好事，有助于避免级联过载，但这是需要注意的事情。一些较新的syslog守护程序也支持基于TCP的协议，但是客户端支持的统一性较低，因此只需进行研究即可。
最近但很流行的是登录到ElasticSearch。由于Kibana仪表板和Logstash被点亮（通常称为ELK，ElasticSearch + Logstash + Kibana），因此这非常有用。亚马逊甚至提供了托管的ElasticSearch选项，使入门起来更加容易。ES使用相对简单的REST API，因此带有HTTP客户端（阅读所有语言）的任何语言都应该可以登录到ES，但是请确保在系统部分中断的情况下小心阻止网络操作（例如，确保您的应用程序不会陷入永远不会成功的日志记录调用中并停止为用户请求提供服务）。
更复杂的日志记录拓扑仅受您的想象力限制，尽管这些天您会发现，在非常复杂的日志分发系统中，大量使用了Kafka数据库/队列/您想调用的东西作为联系点。
在“无服务器”端，您通常希望直接在网络级别上与这些系统集成，因此，将日志数据从服务/功能直接发送到syslog或ES，而不是写入本地文件（尽管可能会回显到本地文件）对于本地调试和开发也是如此）。
这个答案更多地是关于可伸缩性的考虑-如果工人的数量可能很高和/或其中多个工人可以同时以高速率生产日志。
是的，同时使用多个日志文件是一个好习惯。
尝试将来自多个工作程序的日志实时合并为一个日志文件会产生问题：
分片日志文件（使用同时处于活动状态的多个日志文件）本身是某些托管服务提供商使用的一种技术，可提供高性能，可扩展的集中式日志记录服务。例如，将日志导出到文件时，Google的StackDriver Logging会生成多个分片的日志文件。从Google Cloud Storage中的日志条目：
当您将日志导出到Cloud Storage存储桶时，Stackdriver Logging将一组文件写入存储桶。这些文件按日志类型和日期按目录层次结构进行组织。日志类型可以是简单名称（例如）
syslog或复合名称（例如）appengine.googleapis.com/request_log。如果这些日志存储在名为的存储桶中my-gcs-bucket，则目录将如以下示例中所示：my-gcs-bucket/syslog/YYYY/MM/DD/ my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/一个存储桶可以包含来自多种日志类型的日志。
叶子目录（
DD/）包含多个文件，每个文件在文件名中指定的时间段内保存导出的日志条目。文件被分片，文件名以分片号Sn或An（n = 0，1，2，...）结尾 。例如，这是两个可能存储在的文件directory my-gcs-bucket/syslog/2015/01/13/：08:00:00_08:59:59_S0.json 08:00:00_08:59:59_S1.json这两个文件一起包含
syslog从0800 UTC开始的一个小时内所有实例的日志条目。要获取所有日志条目，必须读取每个时间段的所有分片-在这种情况下，文件分片为0和1。写入的文件分片的数量可以在每个时间段内变化，具体取决于日志条目的数量。
这种高性能的日志记录服务还可以提供日志记录的替代方法，因此，如果有必要，可以完全避免对日志文件的管理：
最后-如果不需要实时日志文件合并，则具有多个日志文件可以帮助进行离线日志管理：