我正在寻找一种解决方案，使我能够自动捕获在 Amazon EC2 上运行的进程的 STDOUT/STDERR，并将其（远程）发送到另一台服务器。
听起来很简单，但事实并非如此：
- 我将使用现货实例，这意味着我无法准确控制它们何时启动，并且它们可以随时终止（无需正确关闭）
- 因为没有关机，所以在过程完成时我无法写入本地文件并将其传输（例如传输到 s3）。
- 输出结构不太好（例如，日志文件中没有表格字段），因此“标准”云日志解决方案并不简单，使用其中一个云数据库并不理想。
我考虑了几个想法，但每个想法都有一个问题：
- 无法将内容附加到“s3”上的文件，并且重写文件的速度太慢，无法进行日志记录。
- 据我所知，共享 EBS 卷（作为驱动器）是不可能的。
- 使用“simple_db”听起来太慢了（并且“simple_db”已经处于测试阶段好几年了，所以我不确定它是否可用）。
- 使用 SQS（例如每行输出一条消息？）非常慢。
- 如果连接断开一秒钟，重定向到网络套接字将失败（例如“myprogram 2>&1 | nc my.log.server 7070”
也许有一个带有远程日志记录的“syslog”解决方案？但这是否需要单独的“按需”实例来收集信息？
任何建议和想法都将不胜感激。
谢谢，-g
答案1
我希望亚马逊有专为日志记录而设计的“仅附加”或“主要附加”服务。
也许像 Amazon Kinesis 那样？
借助 Amazon Kinesis，您可以让生产者将数据直接推送到 Amazon Kinesis 流中。例如，系统和应用程序日志可以提交到 Amazon Kinesis 并在几秒钟内进行处理。这可以防止前端或应用程序服务器发生故障时丢失日志数据。Amazon Kinesis 提供加速数据馈送接收，因为您无需在服务器上对数据进行批处理即可提交接收。
我还没有尝试过这个，但是，因为我有一个使用 S3 和 SQS 的自制监督流程......在流的开始处，它会为临时文件（在实例上）创建唯一的名称，这些临时文件将捕获日志并通过 SQS 发送一条消息，导致有关该过程及其日志文件位置的信息存储在数据库中;当进程停止时（这些是计划的或事件驱动的，而不是连续运行的作业），会发送另一条 SQS 消息，其中包含有关临时文件位置的冗余信息，并为我提供该过程的退出状态;然后两个日志（输出和错误）都被压缩并上传到 S3，每个进程都会生成额外的 SQS 消息来报告 S3 上传状态......
您可能会注意到，SQS 消息在很大程度上是多余的，但这实际上是为了消除我不知道的可能性某物关于进程的存在，因为所有 4 条消息（start、stop、stdout-upload-info、stderr-upload-info）都包含足够的信息来识别主机、进程、参数以及日志文件将要去哪里、已经去哪里或应该去哪里，在 S3 中。当然，所有这些冗余几乎完全没有必要，因为进程和 SQS/S3 非常稳定，但如果需要的话，冗余是存在的。
我不需要实时记录这些工作，但如果我需要，另一个选择是修改日志收集器，这样我就不用保存日志然后将它们全部发送到 S3，而是可以对收集到的每“x”字节日志进行或者运行时间每“y”秒（以先发生者为准）将累积数据“刷新”到 SQS 消息中……无需为每一行发送一条 SQS 消息。
答案2
首先，您在 EC2 上运行并没有什么特别之处。对于任何集中式日志记录基础设施，您都希望最大限度地减少日志丢失的可能性，因此需要尽快发送日志。
其次，不要指望这里有魔法。你需要保存你的日志消息某处，因此您可能需要运行一个长时间运行的实例（在 EC2 内部或其他地方）来收集和存储您的消息。
以下是我的建议：
- 使用运行您的应用程序主管。这不仅会为您提供一些基本的进程监控/重启功能，而且更重要的是，supervisord 将处理输出流的收集并写入日志文件。
- 在每个应用程序服务器上，使用logstash 转发器读取 Supervisord 写入的日志文件并将其发送到...
- A日志存储/elasticsearch服务器，其中 logstash 从您的节点接收日志，组织它们（如果需要），并将它们提交给 elasticsearch 进行长期存储和搜索。
一些额外的评论：
- Logstash 转发器能够加密与 logstash 的通信，因此您可以在需要时通过公共网络发送日志，而不必担心信息泄露。
- Elasticsearch 实现起来非常简单，并且惊人的索引你的邮件的工作
- Elasticsearch 提供了一个 REST 接口，你可以使用它来发出查询，但如果你想要一个 Web GUI，Kibana3是一个很好的选择。
- 如果你需要监控日志并针对特定模式发出警报/通知，可以配置 logstash 来执行此操作