为日志分析设置基本管道

选择清理、解析和结构化日志数据的工具可能令人望而生畏（且成本高昂）。但对于初学者来说，使用像 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 也有相关文档。
• 了解可帮助您随着时间推移降低成本和扩展的日志存储策略.