设置用于日志分析的基础管道

选择用于清理、解析和结构化日志数据的工具可能会让人感到不知所措（而且成本高昂）。但是，当您刚开始时，可以使用一个简单的设置，通过像 Metabase 这样的 BI 工具进行临时分析。以下是设置用于分析日志的基本管道时应遵循的一些最佳实践。

使用数据连接器工具作为摄取的快捷方式

Airbyte 等工具可以快速连接到您的数据库并为您构建日志结构。选择您的日志记录源，例如 AWS CloudTrail，并将其连接到数据库，例如 Snowflake（一个相对简单、可扩展、成本合理的解决方案），或 AWS Aurora Serverless Postgres（一个简单、在某种程度上可扩展、低成本的解决方案）。

其他 ETL 工具，如 Fivetran 或 Stitch，工作方式类似。它们使用连接器将日志数据从 CloudTrail 等来源移动到您的数据库。您还可以结合使用 ETL 工具并执行数据建模，以完成一些繁重的工作。

使用单一云提供商将所有内容集中在一处

Google Cloud Logging 与 BigQuery 连接，因此您可以自动将日志摄取到您的数据仓库中。AWS 有多个日志记录选项，如 CloudTrail 或 CloudWatch，您可以将其连接到他们的数据库选项之一，如 Postgres for RDS。Azure Monitor 也具有日志记录和存储功能。

高级用例：将来自多个 AWS 服务的日志转储到 S3 存储桶中，并使用 Athena 查询它们

如果您有一些云服务（如 AWS）的经验，则可以使用整套云服务从多个不同的服务获取日志，并将它们推送到一个中心位置，以便为分析做准备。

例如，将来自 EC2 实例的 Web 服务器或应用程序日志与 CloudTrail 日志一起推送到 S3 存储桶中。将您的 S3 存储桶连接到查询工具（如 Athena），以便您可以创建一些表以用于分析。一旦您有了表，就可以连接到您的分析工具并创建一个故障排除仪表板，例如将 EC2 事件映射到 CloudTrail 事件以进行根本原因分析的仪表板。

以下是一些您可以与 S3 和 Athena 一起使用的其他 AWS 日志记录选项

• CloudWatch：存储应用程序、系统或自定义日志
• RDS：存储错误、慢查询或事务日志
• Lambda：存储包含执行详细信息、错误消息和自定义日志语句的 Lambda 日志
• 弹性负载均衡器 (ELB)：存储包含客户端 IP 地址、请求时间和响应状态代码的 ELB 日志

如果想更进一步，您可以将 Athena 连接到 dbt，并学习如何在 SQL 中编写自己的数据转换。dbt 简化了版本控制、部署和测试，而无需运行单独的工具。但是，如果您熟悉数据建模和开发者工具，我们才推荐此设置。

批量加载日志以提高效率

您应该将日志直接批量加载到数据仓库或 S3 等存储选项中，以避免延迟和资源消耗。大多数云服务都提供批量服务，您可以在其中调度和排队作业。请注意，如果您要为数据库或日志存储付费，请先仔细检查批量加载的价格，因为某些云服务会按每次批量上传收费。

使用数据库客户端库或连接器进行摄取

没有连接器工具不是问题，但这可能需要更多开发工作。使用现有的数据库客户端库或驱动程序可以帮助您在日志记录时直接将日志摄取到存储/数据仓库中。

例如，Postgres 有驱动程序，而 MySQL 有连接器。使用其中一个来连接到您的数据库，而无需重新发明轮子。

确保您的日志包含时间戳、来源、消息和日志级别

我们建议在日志文件中添加四个方面，以使日志分析更顺畅

• 时间戳：这将更容易建立事件序列。如果您使用分析工具创建用于性能监控或审计和合规性的仪表板，则时间戳尤其重要。
• 来源：就像创建日志的服务一样，还有日志来自哪个位置/文件/子服务。您可以使用服务字段进行故障排除，或者仅用于衡量分配给每个服务的资源。
• 日志消息：保持消息清晰简洁，以便您可以理解每个事件。重复使用关键字，以便在文本分析期间更容易过滤和查找所需内容。
• 日志级别：您可以按级别（如 ALERT 和 CRITICAL）进行过滤，以找出哪个日志需要立即调查和响应。

其他最佳实践和日志分析思路

如果您的目标是实时日志分析，或者高级或频繁的日志分析，则特定于日志的工具往往更适合。如果您的团队已经在使用 ELK 堆栈，则 Grafana 等工具可能适合。

以下是一些其他资源，您可以使用它们在构建小型日志记录管道时做出决策

• 了解如何将数据科学原理应用于日志记录.
• 有关使用哪个 AWS 数据库和服务的指南。Google 也提供了文档。
• 了解可以帮助您降低成本和随时间扩展的日志存储策略.