问题描述
目前，有多个微服务将日志记录到各自的文件中。如果出现问题，团队就像无头苍蝇一样进行调试。为了防止这种情况发生，目标是引入聚合日志记录，例如Elastic。迁移到这样的聚合日志记录系统的最佳实践是什么？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
一个最佳实践是将所有日志记录到同一个位置。你的”当前想法”表明你将在本地运行Elastic stack，这对于本地开发环境来说是很好的，但对于其他任何环境，你都希望将所有微服务的日志记录发送到同一个位置。这样可以让你对日志进行关联，并以”单一视图”的方式查看日志。
为了实现这一点，你需要在服务器上运行它，或者使用Elastic Cloud或AWS Elasticsearch等托管服务。你可以通过包管理器（如yum或apt）安装组件，或者在Docker中运行它。stack-docker存储库非常适合在本地运行，但由于缺乏可扩展性，不适合部署规模较大的环境。
你发送日志的终点将取决于你用于发送日志的方法/协议，例如在AWS EC2实例上运行的Nginx可能会使用Filebeat，并将日志发送到Elasticsearch前面的负载均衡器，或者如果你使用Docker，你可以使用gelf Docker logdriver将日志发送到Logstash。
以下是一些其他最佳实践：
– 使用JSON记录所有消息，重点是对象/字段，而不是长字符串消息。
– 异常应该是可操作的，其他内容可以是警告。
– 避免多行日志。
– 使用关联ID。如果你的应用程序传递了关联ID，它应该在每个由该调用触发的消息中包含它，否则它应该生成一个关联ID。关联ID应该包含在对其他微服务的调用中。
– 在日志记录方面，宁愿记录更多而不是更少，你永远不知道什么时候可能需要那些数据，或者通过分析一个看似不起眼的数据可能会发现什么趋势。
– 在逻辑上将环境分开，这样你就可以在日志上有不同的保留期和归档。
以上是关于在组织中实施和使用Elastic的最佳实践的解决方案。希望对你有所帮助！