菜单
文档breadcrumb arrow Grafana Lokibreadcrumb arrow 管理breadcrumb arrow 监控 Loki
开源 RSS

Loki 元监控

作为 Loki 实现的一部分，您还会想要监控您的 Loki 集群。

作为最佳实践，您应该在独立的 Loki、Prometheus 和 Grafana 实例中收集关于 Loki 的数据。例如，将您的 Loki 集群数据发送到 Grafana Cloud 账户。这样您就可以在正常工作的集群中排除故障损坏的 Loki 集群。

Loki 自身暴露以下可观测性数据：

  • 指标：Loki 提供一个 /metrics 端点，以 Prometheus 格式发送关于 Loki 的信息。这些指标提供您的 Loki 集群健康状况的聚合指标，允许您观察查询响应时间等。每个 Loki 组件都会发送自己的指标，以便对您的 Loki 集群健康状况进行精细监控。有关 Loki 暴露的更多指标信息，请参阅指标。在运行大型分布式 Loki 集群时，务必牢记指标基数。

  • 日志：Loki 为每个查询发出详细的日志行 metrics.go，其中显示了查询持续时间、返回的行数、查询吞吐量、执行的具体 LogQL、搜索的块等更多信息。您可以使用这些日志行来改进和优化您的查询性能。您还可以收集 Loki 组件的 Pod 日志，以监控和深入分析特定问题。

监控 Loki

监控 Loki 主要有三个组成部分：

  1. Kubernetes Monitoring Helm：Kubernetes Monitoring Helm chart 提供了一个全面的 Kubernetes 集群监控解决方案。它还提供了直接集成，用于监控完整的 LGTM（Loki、Grafana、Tempo 和 Mimir）堆栈。要了解如何部署 Kubernetes Monitoring Helm chart，请参阅部署元监控。

  2. Grafana Cloud 账户或独立的 LGTM 堆栈：从 Loki 集群收集的数据可以发送到 Grafana Cloud 账户或独立的 LGTM 堆栈。我们建议使用 Grafana Cloud，因为 Grafana Labs 负责维护 Grafana Cloud 服务的可用性和性能。

  3. Loki mixin：是一套精选的仪表板、告警和记录规则，用于监控您的 Loki 集群。该 mixin 提供了一个全面的软件包，用于生产环境中的 Loki 监控。您可以将该 mixin 安装到 Grafana 实例中。要安装 Loki mixin，请遵循这些说明。

您还应该单独规划基础设施层面的监控，例如监控存储提供商或网络层的容量或吞吐量。

Grafana Labs 用于监控 Loki 的 Kubernetes Monitoring Helm chart 也开箱即用地提供了这些功能，默认启用了 Kubernetes 监控。您可以根据要收集的数据量和您的元监控预算选择启用或禁用这些功能。

Loki 指标

由于 Loki 是一个分布式系统，每个组件都会导出自己的指标。/metrics 端点暴露了数百个不同的指标。您可以在以下部分找到 Loki 暴露的部分指标及其描述。

您可以通过检查 /metrics 端点找到暴露的完整指标列表。

http://<主机>:<http_监听端口>/metrics

例如：

https://:3100/metrics

Grafana Loki 和 Alloy 都暴露一个 /metrics 端点，用于暴露 Prometheus 指标（Loki 的默认端口是 3100，Alloy 的默认端口是 12345）。要存储这些指标，您可以使用 Prometheus 或 Mimir。

Loki 的所有组件都暴露以下指标：

指标名称指标类型描述
loki_internal_log_messages_total计数器Loki 自身创建的日志消息总数。
loki_request_duration_seconds直方图接收到的 HTTP 请求数。

请注意，大多数指标是计数器，在正常操作期间应持续增加。

  1. 您的应用向 Alloy 跟踪的文件发出日志行。
  2. Alloy 读取新行并增加其计数器。
  3. Alloy 将日志行转发给 Loki 分发器 (distributor)，其中接收到的计数器应增加。
  4. Loki 分发器将日志行转发给 Loki 摄取器 (ingester)，其中请求持续时间计数器应增加。

如果 Alloy 使用任何带有 metrics 阶段的 pipeline，这些指标也将由 Alloy 在其 /metrics 端点暴露。

指标基数

一些 Loki 可观测性指标是按每个跟踪的文件（活动文件）发出的，文件路径包含在标签中。这会增加环境中标签值的数量，从而增加基数。使用 Prometheus 标签的最佳实践不鼓励以这种方式增加基数。Kubernetes Monitoring Helm chart 提供了监控 Loki 的最佳实践，包括如何管理基数，但在实现 Loki 集群组件的自动扩展时，务必注意基数问题。

Loki 日志行示例：metrics.go

Loki 从 Querier、Query frontend 和 Ruler 组件发出 metrics.go 日志行，您可以借此检查查询和记录规则的性能。这是一个关于查询的详细日志行 metrics.go 示例。

日志示例

level=info ts=2024-03-11T13:44:10.322919331Z caller=metrics.go:143 component=frontend org_id=mycompany latency=fast query="sum(count_over_time({kind=\"auditing\"} | json | user_userId =`` [1m]))" query_type=metric range_type=range length=10m0s start_delta=10m10.322900424s end_delta=10.322900663s step=1s duration=47.61044ms status=200 limit=100 returned_lines=0 throughput=9.8MB total_bytes=467kB total_entries=1 queue_time=0s subqueries=2 cache_chunk_req=1 cache_chunk_hit=1 cache_chunk_bytes_stored=0 cache_chunk_bytes_fetched=14394 cache_index_req=19 cache_index_hit=19 cache_result_req=1 cache_result_hit=1

您可以使用 query-frontend 的 metrics.go 行来了解查询的整体性能。Querier 输出的 metrics.go 行包含与 Query frontend 相同的信息，但通常在理解和排查查询性能问题时更有帮助。这主要是因为它能告诉您 querier 执行子查询所花费的时间。以下是最有用的统计信息：

  • total_bytes：查询处理的总字节数
  • duration：查询执行所需时间
  • throughput：总字节数/持续时间
  • total_lines：查询处理的总行数
  • length：查询执行的时间范围
  • post_filter_lines：匹配查询中过滤器的行数
  • cache_chunk_req：查询获取的总块数（缓存会请求每个块，因此这等同于请求的总块数）
  • splits：根据时间和 split_queries_by_interval，查询被分割成的部分数量
  • shards：查询被分割成的分片数量

欲了解更多信息，请参阅博客文章：Loki 简明指南：如何充分利用查询性能。

配置日志级别

要更改 Loki 日志级别的配置，请更新您的 config.yaml 文件中的 log_level 配置参数。

yaml 
# Only log messages with the given severity or above. Valid levels: [debug,
# info, warn, error]
# CLI flag: -log.level
[log_level: <string> | default = "info"]