Grafana Loki 快速入门从零搭建日志聚合、采集与可视化全流程【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiLoki 是一款受 Prometheus 启发、专为云原生时代设计的日志聚合系统核心设计理念是只为日志流建立标签索引而不是为每行日志建立全文索引。本文以 docs/sources/get-started/_index.md 为主线完整梳理从安装 Loki、部署采集 Agent、接入 Grafana 到使用 LogQL 查询日志的四个标准步骤并结合仓库内的 docker-compose 示例、Loki 配置示例、Alloy 配置示例 以及 deployment-modes.md、components.md、labels 文档 等资源做源码级纵深。读完本文你将掌握一套可直接复制运行的 Loki 落地流程并理解标签labels、日志流log streams、部署模式与 LogQL 查询背后的底层原理。Loki 是什么不索引日志内容只索引标签Loki 是一个**水平可扩展horizontally scalable、高可用highly available、多租户multi-tenant**的日志聚合系统。它与其他日志系统最大的区别在于Loki 不索引日志行的内容而是为每条日志流log stream索引一组标签labels。文档对此有明确说明整个日志行的内容仍然可以被搜索到使用标签只是通过缩小查询时需要检索的日志数量让搜索更高效。这个设计带来两个直接收益成本低日志数据被压缩后以 chunk 形式存储在对象存储如 S3、GCS、Azure Blob Storage开发环境也可以是文件系统中由于只索引标签索引体积远小于其他日志聚合工具。正如 overview.md 所说A small index and highly compressed chunks simplify the operation and significantly lower the cost of Loki.易运维通过把对象存储作为唯一的数据存储机制Loki 继承了底层对象存储的可靠性和稳定性也规避了本地 SSD/HDD 的运维负担。从 overview.md 可以知道一个典型的 Loki 日志栈由三部分组成Agent采集端例如 Grafana Alloy。Agent 抓取日志通过添加标签把日志组织成流stream再通过 HTTP API 把流推送给 Loki。Loki服务端负责日志的摄取、存储和查询处理可以以三种不同的部署模式运行详见下文部署模式。Grafana可视化端用于查询和展示日志数据也可以通过命令行工具 LogCLI 或直接调用 Loki API 查询。Loki 的核心特性overview.md 罗列了 Loki 的主要特性可扩展性从跑在树莓派上的单实例到每天摄取 PB 级日志的大型集群支持单二进制、HA 单体、微服务三种模式。多租户允许多个租户共享同一个 Loki 实例各租户的数据和请求完全隔离通过在 Agent 中配置租户 ID 实现。高效存储高压缩比的 chunk 小体积索引 低成本对象存储。LogQL 查询语言熟悉 PromQL 的用户几乎可以无缝迁移。告警Alerting内置 ruler 组件可周期性评估日志查询并触发动作可对接 Prometheus Alertmanager 或 Grafana 内的告警管理器。与 Grafana/Mimir/Tempo 的深度集成构成完整的可观测性栈实现日志、指标、追踪的关联分析。完整实施步骤总览因为每个 Loki 落地场景各不相同安装过程会有差异但文档强调每次安装都有一些共通的步骤。收集并查看日志数据通常包含以下四个步骤见 loki-install.png 的流程图示意安装 Loki以单体单二进制模式在 Kubernetes 上用官方推荐的 Helm chart 安装并为其提供对象存储认证信息。相关资料还包括 存储选项、配置参考、配置示例。部署 Grafana Alloy 采集日志在 Kubernetes 上用 Helm chart 部署 Alloy配置它从集群抓取 Pod 日志并写入 Loki 端点同时按照标签最佳实践为日志添加标签大多数用户会从 region、cluster、environment 这类描述日志来源的标签开始。部署 Grafana 并配置 Loki 数据源部署 Grafana 或使用 Grafana Cloud配置 Loki 数据源。在 Explore 中查询日志选择时间范围 → 选择 Loki 数据源 → 用 LogQL 在查询编辑器中查询既可以使用 Builder 视图浏览标签也可以使用Kick start your query按钮选择预配置的示例查询。下一步深入学习 LogQL 查询语言。快速体验用 Docker Compose 本地跑起一整套 Loki如果只是想快速实验 Loki仓库 examples/getting-started/ 提供了完整的 Docker Compose 环境对应文档 quick-start/quick-start.md。它运行在simple scalable 模式注意该模式已弃用计划在 Loki 4.0 中移除生产环境请参考 deployment modes每个组件各占一个容器flog生成日志行的示例应用flog 是常见日志格式的日志生成器Grafana Alloy抓取 flog 的日志并通过网关推送给 LokiGatewaynginx根据请求 URL 把请求转发到合适的容器Loki read 组件运行 Query Frontend 和 QuerierLoki write 组件运行 Distributor 和 IngesterLoki backend 组件运行 Index Gateway、Compactor、Ruler 以及实验性的 Bloom Planner / Bloom Builder / Bloom GatewayMinioLoki 存储索引和 chunk 的对象存储Grafana可视化展示捕获的日志。启动步骤创建目录并进入mkdir evaluate-loki cd evaluate-loki下载三个配置文件wget https://raw.githubusercontent.com/grafana/loki/main/examples/getting-started/loki-config.yaml -O loki-config.yaml wget https://raw.githubusercontent.com/grafana/loki/main/examples/getting-started/alloy-local-config.yaml -O alloy-local-config.yaml wget https://raw.githubusercontent.com/grafana/loki/main/examples/getting-started/docker-compose.yaml -O docker-compose.yaml也可以使用curl --output替代wget -O。启动整个演示环境docker compose up -d命令执行完毕后你会看到类似下面的输出8 个容器依次启动✔ Network evaluate-loki_loki Created 0.1s ✔ Container evaluate-loki-minio-1 Started 0.6s ✔ Container evaluate-loki-flog-1 Started 0.6s ✔ Container evaluate-loki-backend-1 Started 0.8s ✔ Container evaluate-loki-write-1 Started 0.8s ✔ Container evaluate-loki-read-1 Started 0.8s ✔ Container evaluate-loki-gateway-1 Started 1.1s ✔ Container evaluate-loki-grafana-1 Started 1.4s ✔ Container evaluate-loki-alloy-1 Started 1.4s验证环境就绪read 组件就绪后访问 http://localhost:3101/ready 会返回ready就绪前会看到Query Frontend not ready: not ready: number of schedulers this worker is connected to is 0的提示。write 组件就绪后访问 http://localhost:3102/ready 会返回ready就绪前会看到Ingester not ready: waiting for 15s after being ready的提示。Grafana Alloy 的 UI 可通过 http://localhost:12345 访问。用docker ps -a可以检查所有容器是否在运行。深入compose 文件里的读写路径拆分与网关转发从 docker-compose.yaml 可以看到各 Loki 组件是如何以不同-target启动的read 组件-config.file/etc/loki/config.yaml -targetread -query-scheduler.use-scheduler-ringfalsewrite 组件-config.file/etc/loki/config.yaml -targetwritebackend 组件-config.file/etc/loki/config.yaml -targetbackend -legacy-read-modefalse。而 loki-config.yaml 中所有实例通过memberlist协议互相发现memberlist.join_members: [read, write, backend]存储后端统一指向 MinioS3 兼容schema_config: configs: - from: 2023-01-01 store: tsdb object_store: s3 schema: v13 index: prefix: index_ period: 24h common: path_prefix: /loki replication_factor: 1 compactor_address: http://backend:3100 storage: s3: endpoint: minio:9000 insecure: true bucketnames: loki-data access_key_id: loki secret_access_key: supersecret s3forcepathstyle: true ring: kvstore: store: memberlist其中schema: v13、store: tsdb表明使用的是 TSDB 单存储索引single store TSDB这也是当前 Loki 推荐的索引方案。网关nginx则通过 URL 匹配把写路径/loki/api/v1/push转发到 write 组件、把读路径/loki/api/.*与 tail 端点转发到 read 组件Alloy 和 Grafana 都通过http://gateway:3100这一统一入口访问 Loki。深入Alloy 如何发现并推送 Docker 容器日志alloy-local-config.yaml 展示了 Alloy 从 Docker 抓取日志的完整链路discovery.docker flog_scrape { host unix:///var/run/docker.sock refresh_interval 5s } discovery.relabel flog_scrape { targets [] rule { source_labels [__meta_docker_container_name] regex /(.*) target_label container } } loki.source.docker flog_scrape { host unix:///var/run/docker.sock targets discovery.docker.flog_scrape.targets forward_to [loki.write.default.receiver] relabel_rules discovery.relabel.flog_scrape.rules refresh_interval 5s } loki.write default { endpoint { url http://gateway:3100/loki/api/v1/push tenant_id tenant1 } external_labels {} }这里的关键链路是discovery.docker发现容器 →discovery.relabel把容器名去掉前导/重写为container标签 →loki.source.docker抓取日志并写入 →loki.write推送到 Loki 网关同时通过tenant_id tenant1指定多租户下的租户 ID。这也呼应了 labels 文档 中标签由采集客户端配置的说法。在生产环境Kubernetes中采集 Pod 日志并推送到 Loki回到主文档给出的生产级示例使用 Helm chart 把 Grafana Alloy 部署到 Kubernetes采集 Pod 日志并推送至 Loki。这个示例的values.yaml配置完成了三件事安装 Grafana Alloy 来发现 Pod 日志为日志添加container和pod标签使用租户 IDlocal将日志推送到 Loki 集群。操作步骤如下用 Helm chart 安装 Loki。用 Helm chart 部署 Grafana Alloy安装细节参考 Install Grafana Alloy on Kubernetes。创建values.yaml务必把forward_to [loki.write.endpoint.receiver]更新为你的实际端点alloy: mounts: varlog: true configMap: content: | logging { level info format logfmt } discovery.kubernetes pods { role pod } loki.source.kubernetes pods { targets discovery.kubernetes.pods.targets forward_to [loki.write.endpoint.receiver] } loki.write endpoint { endpoint { url http://loki-gateway.default.svc.cluster.local:80/loki/api/v1/push tenant_id local } }安装 Alloyhelm install alloy grafana/alloy -f ./values.yaml配置逐块拆解logging块设置 Alloy 自身的日志级别为info、格式为logfmt。discovery.kubernetes pods以role pod的方式发现集群中所有 Podtargets会被下游组件引用。loki.source.kubernetes pods从 Kubernetes 抓取 Pod 日志并把它转发给loki.write.endpoint的 receiver。Alloy 会自动为日志添加container、pod等来源标签。loki.write endpoint定义推送端点url指向 Loki 网关的 push APItenant_id local表示这批日志归属于local这个租户。与 alloy-local-config.yaml 对照可以看到无论本地 Docker 环境还是 Kubernetes 生产环境Alloy 的采集逻辑一致发现目标 → 抓取日志 → 添加标签 → 推送至 Loki 的/loki/api/v1/push端点区别仅在于发现机制discovery.dockervsdiscovery.kubernetes与租户 ID。多租户与 X-Scope-OrgID在 quick-start/quick-start.md 中有一个重要提示当 Loki 以非单体模式部署时必须在请求头中传递租户 ID否则查询会返回授权错误。示例的 Grafana 数据源通过如下方式在请求头中注入租户apiVersion: 1 datasources: - name: Loki type: loki access: proxy url: http://gateway:3100 jsonData: httpHeaderName1: X-Scope-OrgID secureJsonData: httpHeaderValue1: tenant1各字段含义Name是数据源名称Type: loki是数据源类型Access: proxy是访问方式URL指向 Loki 网关httpHeaderName1是组织 ID 的请求头名称X-Scope-OrgIDhttpHeaderValue1是组织 ID 的值。租户隔离在 overview.md 中被描述为各租户的数据和请求完全隔离这正是 Loki 多租户能力的体现。部署模式单体、HA 单体与微服务主文档建议第一步以单体monolithic / single-binary模式安装 Loki因此理解部署模式是快速入门的关键。根据 deployment-modes.mdLoki 是一个由众多微服务组成的分布式系统但有一个独特的构建模型所有微服务都存在于同一个二进制中。通过-target命令行参数指定启动时运行哪些微服务组件细节则在loki.yaml中配置。三种模式对比MonolithicHA MonolithicMicroservices数据持久性Durability✅✅✅高可用High availability❌✅✅执行路径分离❌❌✅运维复杂度 低 中 高可扩展性 低 中 高Monolithic单二进制模式最简单的模式通过-targetall启用所有微服务组件在单个进程单二进制或单个 Docker 镜像中运行。适合快速实验和小读写量约每天 20GB 以内。查询并行度受实例数和loki.yaml中的max_query_parallelism限制。HA Monolithic 模式该模式是已弃用的 Simple Scalable DeploymentSSD计划在 Loki 4.0 移除的替代方案介于单体与微服务之间提供高可用和中等水平的水平扩展而不引入管理单个微服务的运维复杂度。运行 HA 单体模式需要满足以下条件每个实例都以-targetall运行使每个进程都提供所有组件共享对象存储所有实例读写同一个 S3 兼容桶若使用 ruler 还需单独的桶本地磁盘仅用于临时缓存和 WALMemberlist 共享环状态配置memberlist块并设置common.ring.kvstore.store: memberlist让所有内部环ingester、distributor 等共享集群状态复制因子为 3设置common.replication_factor: 3并至少运行三个实例以容忍丢失一个实例而不丢数据专用 compactor 实例一个实例设置compactor.horizontal_scaling_mode: main其余设置为worker并在common.compactor_grpc_address中指定主 compactor 地址负载均衡器以轮询方式把所有 push 和 query 流量路由到每个副本。仓库 examples/ha-monolithic/ 提供了更完整的参考配置。Microservices微服务模式每个组件作为独立进程运行也叫分布式部署每个进程通过指定target启动。以 3.3 版本为例组件包括Bloom Builder实验、Bloom Gateway实验、Bloom Planner实验、Compactor、Distributor、Index Gateway、Ingester、Overrides Exporter、Querier、Query Frontend、Query Scheduler、Ruler、Table Manager已弃用。提示可以用-list-targets查看当前版本支持的完整 target 列表例如docker run docker.io/grafana/loki:3.2.1 -config.file/etc/loki/local-config.yaml -list-targets微服务模式按组件独立扩缩容更贴合具体场景但设置与维护复杂度最高仅推荐用于超大型集群或需要精细控制扩缩容的运维场景通常部署在 Kubernetes 上。理解标签Labels与日志流Log Streamslabels 文档 强调标签是 Loki 的基石它让 Loki 把日志消息组织和分组为日志流log stream。每条日志流至少需要一个标签才能被存储和查询。理解标签对快速上手并正确查询日志至关重要。什么是标签与日志流在 Loki 中日志行的内容不被索引日志条目被分组为流stream流通过标签被索引。标签是键值对例如deployment_environment developmentcloud_region us-west-1namespace grafana-server共享以上所有标签的一组日志消息即构成一个日志流。Loki 查询时先定位所选流中的所有消息再在流内迭代执行查询。标签策略会直接影响查询性能和仪表盘效果因此在开始向 Loki 摄取日志之前值得花时间设计标签策略。默认标签Loki 在摄取时不会解析或处理日志内容但取决于采集客户端部分标签可能被自动添加。service_nameLoki 在摄取时自动尝试填充默认的service_name标签用于 Grafana Logs Drilldown 和 Grafana Cloud Application Observability 中查找和探索日志。如果流上已有service_name标签则直接使用否则按顺序取以下标签的第一个非空值service、app、application、app_name、name、app_kubernetes_io_name、container、container_name、k8s_container_name、component、workload、job、k8s_job_name若都为空则应用unknown_service。可以通过limits_config块中的discover_service_name修改该列表。OpenTelemetry 默认标签若使用 Grafana Alloy 或 OpenTelemetry Collector 作为客户端Loki 会自动把部分 OTel 资源属性resource attributes作为标签点号.替换为下划线_其余属性作为结构化元数据存储。默认列表包括cloud.availability_zone、cloud.region、container.name、k8s.namespace.name、k8s.pod.name、service.name、service.namespace等 17 项。⚠️注意由于k8s.pod.name和service.instance.id存在高基数风险官方不再推荐将它们作为默认标签但为避免破坏现有用户尚未弃用。新用户可以参照 modify-default-labels.md 中的示例配置把这两个属性从索引标签转为结构化元数据。默认的资源属性标签列表可通过 distributor 的otlp_config下的default_resource_attributes_as_index_labels配置。创建低基数low-cardinality标签**基数cardinality**指唯一标签与值的组合数量它直接影响日志流数量。高基数会导致 Loki 构建出巨大的索引并向对象存储刷出成千上万个小 chunk严重降低性能与成本效益。高基数可能来自使用无界或大量取值的标签如 timestamp、ip_address也可能来自应用了过多标签即使每个标签取值有限。应优先使用更少、取值有界的标签。标签命名需遵循与 Prometheus 相同的限制可包含 ASCII 字母、数字、下划线和冒号须匹配正则[a-zA-Z_:][a-zA-Z0-9_:]*不支持的特殊字符应转换为下划线如app.kubernetes.io/name→app_kubernetes_io_name不要以双下划线开头和结尾该约定用于内部标签如__stream_shard__。添加自定义标签时遵循以下原则DO使用更少标签最多 1015 个更少标签意味着更小索引、更好性能DO尽量具体减少 Loki 的搜索量DO创建取值长期稳定的标签取值有界只要一个标签值变化就会创建新流DO基于用户实际会查询的维度创建标签DONT为非常具体如 user ID、customer ID或极少使用的搜索创建标签。标签与乱序摄取out-of-order writesLoki 默认全局启用乱序写入可通过集群或租户粒度开关控制。同一日志流相同标签组合内的条目必须在默认两小时时间窗口内按序摄取尝试发送过旧的条目会收到too far behind错误。对于摄取延迟不同的系统应使用标签分离流例如把{environmentproduction}拆分为{environmentproduction, appslow_app} {environmentproduction, appfast_app}这样快、慢应用各自独立成流、各自维持摄取顺序。标签实践示例Alloy 中动态添加标签labels 文档 给出了一段 Alloy 配置先用loki.process的stage.logfmt从日志行中提取level字段到提取映射extracted map再用stage.labels把它提升为level标签最后用loki.relabel追加一个静态标签oslocal.file_match tmplogs { path_targets [{__path__ /tmp/alloy-logs/*.log}] } loki.source.file local_files { targets local.file_match.tmplogs.targets forward_to [loki.process.add_new_label.receiver] } loki.process add_new_label { stage.logfmt { mapping { extracted_level level, } } stage.labels { values { level extracted_level, } } forward_to [loki.relabel.add_static_label.receiver] } loki.relabel add_static_label { forward_to [loki.write.local_loki.receiver] rule { target_label os replacement constants.os } } loki.write local_loki { endpoint { url http://localhost:3100/loki/api/v1/push } }高基数反例若用正则从 Apache 日志中动态提取actionGET/POST 等和status_code200/400 等作为标签4 种 action × 4 种状态码就会产生 16 个流、16 个 chunk若再为ip打标签每个用户的每次请求都会成为独立流轻松产生成千上万个流——这就是文档反复警告的高基数陷阱。正则提取到的值会被放入临时数据结构用于该日志行的处理处理完后即被丢弃。在 Grafana 中查询日志LogQL 实战日志收集完成后最直观的查看方式是通过 Grafana 的 Explore 功能命令行方式可参考 LogCLI。本地的快速体验环境已经预置了 Loki 数据源地址http://gateway:3100直接访问 http://localhost:3000 即可。查询步骤从 Grafana 主菜单点击Explore图标打开 Explore 页从仪表盘头部菜单中选择 Loki 数据源显示 Loki 查询编辑器查询编辑器有两种模式Builder 模式可视化查询设计器和Code 模式编写 LogQL 的功能丰富的编辑器点击Code进入 Code 模式粘贴以下示例查询后点击Run Query。基础查询示例Code 模式假设你按前面步骤创建了evaluate-loki目录查看容器标签为evaluate-loki-flog-1的所有日志行这在 Loki 中就是一个日志流{containerevaluate-loki-flog-1}查看容器标签为evaluate-loki-grafana-1的所有日志行{containerevaluate-loki-grafana-1}在{containerevaluate-loki-flog-1}流中查找包含字符串status的行{containerevaluate-loki-flog-1} | status在流中查找 JSON 字段status值为404的行{containerevaluate-loki-flog-1} | json | status404计算每秒日志条数JSON 字段status为404这是一个指标查询返回时间序列Grafana 会绘制图表可切换到Bars查看柱状图sum by(container) (rate({containerevaluate-loki-flog-1} | json | status404 [$__auto]))所有 Loki 查询都以标签选择器开头如{containerevaluate-loki-flog-1}其后可接行过滤器|、!与流水线阶段| json等。更多示例查询查看 flog 生成的所有日志行{containerevaluate-loki-flog-1}查看所有GET行{containerevaluate-loki-flog-1} | GET查看所有POST行{containerevaluate-loki-flog-1} | POST查看 JSON 字段status为401的行{containerevaluate-loki-flog-1} | json | status401查看所有不包含文本401的行{containerevaluate-loki-flog-1} ! 401Builder 模式与 Kick start your query点击Builder标签返回 Builder 模式后点击Kick start your query展开Log query starters部分选择第一项Parse log lines with logfmt parser点击Use this query在 Explore 页点击Label browser在对话框中选择一个容器并点击Show logs。Builder 模式让不熟悉 LogQL 的用户也能通过可视化方式浏览标签、组合查询。深入学习 LogQL 可参考 LogQL 参考文档。源码级支撑写路径与读路径上的关键组件主文档中的四个步骤最终都落到 Loki 内部的一组组件上。根据 components.md各组件与部署目标的对应关系如下组件独立运行allreadwritebackendDistributorxxxIngesterxxxQuery FrontendxxxQuery SchedulerxxxQuerierxxxIndex GatewayxxCompactorxxxRulerxxxPattern ingesterxxxBloom Planner实验xxBloom Builder实验xxBloom Gateway实验xx理解几个与快速上手最相关组件的职责能帮助你排查问题Distributor写路径第一站处理来自客户端的 push 请求校验流标签是否合法、时间戳是否过旧/过新、日志行是否过长对标签排序以支持确定性哈希与缓存并按租户进行速率限制把租户级限额除以当前 distributor 数量实现全局限制随扩缩容自动调整。随后按复制因子把流并行发送给n个 ingester。分布式系统采用 Dynamo 风格仲裁一致性例如复制因子为 3 时需要至少 2 个floor(3/2)1写入成功才返回成功否则报错重试。Ingester写路径核心负责持久化数据并推送到长期存储S3、GCS、Azure Blob 等在读取路径上返回近期内存中的日志数据。每个流在内存中累积为多个 chunk按可配置间隔刷到存储后端。chunk 在达到容量上限、超时未更新或触发 flush 时被压缩并标记为只读。结合 WAL预写日志与复制因子通常 3可防止数据丢失。ingester 通过 lifecycler 在哈希环中管理PENDING、JOINING、ACTIVE、LEAVING、UNHEALTHY状态。Query Frontend / Query Scheduler读路径加速Query Frontend 提供 querier 的 API 端点把大查询拆分为多个小查询并行执行并拼接结果支持指标查询结果缓存、日志查询的负缓存只缓存空结果的时间区间、索引统计与日志量查询缓存仅 TSDB 单存储。Query Scheduler 提供更高级的排队功能为每个租户维护独立队列以保证查询公平性。二者均为无状态组件。Querier执行 LogQL 查询先从所有 ingester 拉取内存数据再回退到后端存储执行相同查询由于复制因子可能收到重复数据querier 会对相同纳秒时间戳 相同标签集 相同日志消息做去重。Compactor把 ingester 生成并上传到对象存储的多个索引文件压缩为每天每租户一个索引文件并负责日志保留retention与日志删除logs deletion。这些组件在 docker-compose.yaml 中正好以-targetread、-targetwrite、-targetbackend三种目标分组运行与上面的组件表一一对应——这也是理解读/写路径分离最直观的源码证据。结语从 docs/sources/get-started/_index.md 出发本文完整走通了 Loki 落地四步法安装 Loki推荐单体/HA 单体模式、用 Grafana Alloy 采集并打标签、部署 Grafana 并配置数据源、在 Explore 中用 LogQL 查询日志。同时结合仓库的 examples/getting-started/ 全套配置、deployment-modes.md、components.md 与 labels 文档深入解释了日志流与标签、基数控制、部署模式选择以及读写路径组件的工作原理。建议的后续学习路径先本地跑通 examples/getting-started/ 的 Docker Compose 演示环境然后在 Kubernetes 上按 install 文档 落地生产部署查询能力方面深入学习 LogQL运维方面参考 存储选项、配置参考 与 标签最佳实践。记住贯穿始终的一条核心原则标签是日志流的身份低基数、有界取值、面向查询习惯的标签策略是 Loki 高性能与低成本的关键。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考