我有以下设置:


创建多个工作器,进行计算,并在完成
后终止它们。


因此,每次运行任务都会是一个不同的实例,因此每个主机都将拥有自己的日志文件,这将导致文件列表很大。

这是一个好习惯吗?如果没有,那么在这种特殊用例中记录任务处理的更好方法是什么?

PS:我的基础架构是无服务器的。因此,现在,我正在登录(AWS)CloudWatch。但是,请独立于AWS回答问题,并尽可能适合无服务器设置。

#1 楼

“无服务器”主要是指您拥有相对简单的微服务,通常只有少量的webapp或自动连接到REST前端的单个功能。适用于更传统的Web服务的概念相同:通常是远程syslog和ElasticSearch writer的混合使用。

网络或远程syslog已经存在很长时间了,并且具有相当强大的功能。周围的工具。您将必须运行中央syslog服务器,但该协议非常简单,并且每种语言都有纯客户端库,可用于发送日志。远程系统日志的一个普遍问题是,它传统上是基于UDP的。这意味着在高负载下,某些日志消息可能会丢失。这可能是一件好事,有助于避免级联过载,但这是需要注意的。一些较新的syslog守护程序也支持基于TCP的协议,但是客户端支持的统一性较低,因此只需进行研究即可。

最近登录但非常流行的是登录ElasticSearch。由于Kibana仪表板和Logstash被点亮(通常称为ELK,ElasticSearch + Logstash + Kibana),因此这非常有用。亚马逊甚至提供了托管的ElasticSearch选项,使其入门起来更加容易。 ES使用相对简单的REST API,因此任何具有HTTP客户端的语言(阅读全部)都应该可以登录到ES,但是请确保在系统部分中断的情况下谨慎使用阻止网络操作(例如,确保您的应用程序不会陷入永远不会成功的日志记录调用中并停止为用户请求提供服务)。

更复杂的日志记录拓扑仅受您的想象力限制,尽管这些天您将看到很多在非常复杂的日志分发系统中,将Kafka数据库/队列/任何您想调用的东西用作联系点。

在“无服务器”端,您通常希望直接在网络级别上与这些系统集成,因此,将日志数据从服务/功能直接发送到syslog或ES,而不是写入本地文件(尽管可能会回显到这些文件)对于本地调试和开发也是如此。

#2 楼

这个答案更多地是关于可伸缩性的考虑-如果工作人员的数量可能很多,并且/或者其中多个工作人员可以同时高速率地生成日志。

是的,同时使用多个日志文件是一个很好的选择。练习。

尝试将多个工人的实时日志合并为一个日志文件会产生问题:


使用阻塞机制来防止消息丢失会减慢速度工人的日志消息可能会在组合的日志文件中乱序显示
由于写入速度有限,组合日志的集中式日志记录工具可能会过载,消息会丢失

共享日志文件(同时使用多个处于活动状态的日志文件)本身是某些托管服务提供商使用的一种技术,可提供高性能,可扩展的集中式日志记录服务。例如,将日志导出到文件时,Google的StackDriver Logging会生成多个分片的日志文件。从Google Cloud Storage中的日志条目中:


将日志导出到Cloud Storage存储桶时,Stackdriver
日志记录会将一组文件写入存储桶。这些文件按日志类型和日期在目录层次结构中进行组织。日志类型可以是
简单名称,例如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/)包含多个文件,每个文件
在文件中指定的时间段内保存导出的日志条目。 >名称。文件被分片,并且文件名以分片号
SnAn(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


这两个文件一起包含从0800 UTC开始的一个小时内所有
实例的syslog日志条目。要获取所有log
条目,必须读取每个时间段的所有分片-在这种情况下,文件分片为0和1。写入的文件分片的数量可以随每个时间而改变。时间段取决于日志条目的数量。


此类高性能日志记录服务还可以提供日志记录文件的替代方法,因此,如果有必要,可以完全避免管理日志文件:


直接将日志插入数据库。例如,Stackdriver Logging可以将日志直接推入Google BigQuery

,直接将日志推入处理引擎。例如,Stackdriver Logging可以将日志推送到Google Pub / Sub主题中


最后-如果不需要实时日志文件合并,则具有多个日志文件可以帮助进行离线日志管理:


易于设计渐进式日志备份,压缩,归档和最终处置方案
可以并行处理多组日志(日志文件),从而减少/避免了瓶颈效应
必须进行文件分割和重写