Loki介绍

　　GrafanaLoki是一套可以组合成一个功能齐全的日志堆栈组件，与其他日志记录系统不同，Loki是基于仅索引有关日志元数据的想法而构建的：标签（就像Prometheus标签一样）。日志数据本身被压缩然后并存储在对象存储（例如S3或GCS）的块中，甚至存储在本地文件系统上，轻量级的索引和高度压缩的块简化了操作，并显著降低了Loki的成本，Loki更适合中小团队。由于Loki使用和Prometheus类似的标签概念，所以如果你熟悉Prometheus那么将很容易上手，也可以直接和Grafana集成，只需要添加Loki数据源就可以开始查询日志数据了。
　　Loki还提供了一个专门用于日志查询的LogQL查询语句，类似于PromQL，通过LogQL我们可以很容易查询到需要的日志，也可以很轻松获取监控指标。Loki还能够将LogQL查询直接转换为Prometheus指标。此外Loki允许我们定义有关LogQL指标的报警，并可以将它们和Alertmanager进行对接。
　　GrafanaLoki主要由3部分组成：loki：日志记录引擎，负责存储日志和处理查询promtail：代理，负责收集日志并将其发送给lokigrafana：UI界面概述
　　Loki是一组可以组成功能齐全的日志收集堆栈的组件，与其他日志收集系统不同，Loki的构建思想是仅为日志建立索引标签，而使原始日志消息保持未索引状态。这意味着Loki的运营成本更低，并且效率更高。多租户
　　Loki支持多租户，以使租户之间的数据完全分离。当Loki在多租户模式下运行时，所有数据（包括内存和长期存储中的数据）都由租户ID分区，该租户ID是从请求中的XScopeOrgIDHTTP头中提取的。当Loki不在多租户模式下时，将忽略Header头，并将租户ID设置为fake，这将显示在索引和存储的块中。运行模式
　　Loki针对本地运行（或小规模运行）和水平扩展进行了优化，Loki带有单一进程模式，可在一个进程中运行所有必需的微服务。单进程模式非常适合测试Loki或以小规模运行。为了实现水平可伸缩性，可以将Loki的服务拆分为单独的组件，从而使它们彼此独立地扩展。每个组件都产生一个用于内部请求的gRPC服务器和一个用于外部API请求的HTTP服务，所有组件都带有HTTP服务器，但是大多数只暴露就绪接口、运行状况和指标端点。
　　Loki运行哪个组件取决于命令行中的target标志或Loki的配置文件中的target：配置。当target的值为all时，Loki将在单进程中运行其所有组件。，这称为单进程或单体模式。使用Helm安装Loki时，单体模式是默认部署方式。
　　当target未设置为all（即被设置为querier、ingester、queryfrontend或distributor），则可以说Loki在水平伸缩或微服务模式下运行。
　　Loki的每个组件，例如ingester和distributors都使用Loki配置中定义的gRPC监听端口通过gRPC相互通信。当以单体模式运行组件时，仍然是这样的，尽管每个组件都以相同的进程运行，但它们仍将通过本地网络相互连接进行组件之间的通信。
　　单体模式非常适合于本地开发、小规模等场景，单体模式可以通过多个进程进行扩展，但有以下限制：当运行带有多个副本的单体模式时，当前无法使用本地索引和本地存储，因为每个副本必须能够访问相同的存储后端，并且本地存储对于并发访问并不安全。各个组件无法独立缩放，因此读取组件的数量不能超过写入组件的数量。组件
　　Distributor
　　distributor服务负责处理客户端写入的日志，它本质上是日志数据写入路径中的第一站，一旦distributor收到日志数据，会将其拆分为多个批次，然后并行发送给多个ingester。distributor通过gRPC与ingester通信，它们都是无状态的，所以可以根据需要扩大或缩小规模。
　　Hashing
　　distributor将一致性Hash和可配置的复制因子结合使用，以确定ingester服务的哪些实例应该接收指定的数据流。
　　流是一组与租户和唯一标签集关联的日志，使用租户ID和标签集对流进行hash处理，然后使用哈希查询要发送流的ingester。
　　存储在ConsulEtcd中的哈希环被用来实现一致性哈希，所有的ingester都会使用自己拥有的一组Token注册到哈希环中，每个Token是一个随机的无符号32位数字，与一组Token一起，ingester将其状态注册到哈希环中，状态JOINING和ACTIVE都可以接收写请求，而ACTIVE和LEAVING的ingester可以接收读请求。在进行哈希查询时，distributor只使用处于请求的适当状态的ingester的Token。
　　为了进行哈希查找，distributor找到最小合适的Token，其值大于日志流的哈希值，当复制因子大于1时，属于不同ingester的下一个后续Token（在环中顺时针方向）也将被包括在结果中。
　　这种哈希配置的效果是，一个ingester拥有的每个Token都负责一个范围的哈希值，如果有三个值为0、25和50的Token，那么3的哈希值将被给予拥有25这个Token的ingester，拥有25这个Token的ingester负责125的哈希值范围。Ingester
　　ingester负责接收distributor发送过来的日志数据，存储日志的索引数据以及内容数据。此外ingester会验证摄取的日志行是否按照时间戳递增的顺序接收的（即每条日志的时间戳都比前面的日志晚一些），当ingester收到不符合这个顺序的日志时，该日志行会被拒绝并返回一个错误。如果传入的行与之前收到的行完全匹配（与之前的时间戳和日志文本都匹配），传入的行将被视为完全重复并被忽略。如果传入的行与前一行的时间戳相同，但内容不同，则接受该日志行，表示同一时间戳有两个不同的日志行是可能的。
　　来自每个唯一标签集的日志在内存中被建立成chunks（块），然后可以根据配置的时间间隔刷新到支持的后端存储。在下列情况下，块被压缩并标记为只读：当前块容量已满（该值可配置）过了太长时间没有更新当前块的内容刷新了
　　每当一个数据块被压缩并标记为只读时，一个可写的数据块就会取代它。如果一个ingester进程崩溃或突然退出，所有尚未刷新的数据都会丢失，Loki通常配置为多个副本来降低这种风险。
　　当向持久存储刷新时，该块将根据其租户、标签和内容进行哈希处理，这意味着具有相同数据副本的多个ingester实例不会将相同的数据两次写入备份存储中，但如果对其中一个副本的写入失败，则会在备份存储中创建多个不同的块对象。
　　WAL
　　上面我们提到了ingester将数据临时存储在内存中，如果发生了崩溃，可能会导致数据丢失，而WAL就可以帮助我们来提高这方面的可靠性。
　　在计算机领域，WAL（Writeaheadlogging，预写式日志）是数据库系统提供原子性和持久化的一系列技术。
　　在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统状态中。通常包含redo和undo两部分信息。为什么需要使用WAL，然后包含redo和undo信息呢？举个例子，如果一个系统直接将变更应用到系统状态中，那么在机器断电重启之后系统需要知道操作是成功了，还是只有部分成功或者是失败了（为了恢复状态）。如果使用了WAL，那么在重启之后系统可以通过比较日志和系统状态来决定是继续完成操作还是撤销操作。
　　redolog称为重做日志，每当有操作时，在数据变更之前将操作写入redolog，这样当发生断电之类的情况时系统可以在重启后继续操作。undolog称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态。
　　Loki中的WAL记录了传入的数据，并将其存储在本地文件系统中，以保证在进程崩溃的情况下持久保存已确认的数据。重新启动后，Loki将重放日志中的所有数据，然后将自身注册，准备进行后续写操作。这使得Loki能够保持在内存中缓冲数据的性能和成本优势，以及持久性优势（一旦写被确认，它就不会丢失数据）。Querier
　　Querier接收日志数据查询、聚合统计请求，使用LogQL查询语言处理查询，从ingester和长期存储中获取日志。
　　查询器查询所有ingester的内存数据，然后再到后端存储运行相同的查询。由于复制因子，查询器有可能会收到重复的数据。为了解决这个问题，查询器在内部对具有相同纳秒时间戳、标签集和日志信息的数据进行重复数据删除。QueryFrontend
　　QueryFrontend查询前端是一个可选的服务，可以用来加速读取路径。当查询前端就位时，将传入的查询请求定向到查询前端，而不是querier，为了执行实际的查询，群集中仍需要querier服务。
　　查询前端在内部执行一些查询调整，并在内部队列中保存查询。querier作为workers从队列中提取作业，执行它们，并将它们返回到查询前端进行汇总。querier需要配置查询前端地址，以便允许它们连接到查询前端。
　　查询前端是无状态的，然而，由于内部队列的工作方式，建议运行几个查询前台的副本，以获得公平调度的好处，在大多数情况下，两个副本应该足够了。
　　队列
　　查询前端的排队机制用于：确保可能导致querier出现内存不足（OOM）错误的查询在失败时被重试。这样管理员就可以为查询提供稍低的内存，或者并行运行更多的小型查询，这有助于降低总成本。通过使用先进先出队列（FIFO）将多个大型请求分配到所有querier上，以防止在单个querier中进行多个大型请求。通过在租户之间公平调度查询。
　　分割
　　查询前端将较大的查询分割成多个较小的查询，在下游querier上并行执行这些查询，并将结果再次拼接起来。这可以防止大型查询在单个查询器中造成内存不足的问题，并有助于更快地执行这些查询。
　　缓存
　　查询前端支持缓存查询结果，并在后续查询中重复使用。如果缓存的结果不完整，查询前端会计算所需的子查询，并在下游querier上并行执行这些子查询。查询前端可以选择将查询与其step参数对齐，以提高查询结果的可缓存性。读取路径
　　日志读取路径的流程如下所示：查询器收到一个对数据的HTTP请求。查询器将查询传递给所有ingester。ingester收到读取请求，并返回与查询相匹配的数据。如果没有ingester返回数据，查询器会从后端存储加载数据，并对其运行查询。查询器对所有收到的数据进行迭代和重复计算，通过HTTP连接返回最后一组数据。写入路径
　　整体的日志写入路径如下所示：distributor收到一个HTTP请求，以存储流的数据。每个流都使用哈希环进行哈希操作。distributor将每个流发送到合适的ingester和他们的副本（基于配置的复制因子）。每个ingester将为日志流数据创建一个块或附加到一个现有的块上。每个租户和每个标签集的块是唯一的。安装
　　首先添加Loki的Chart仓库：helmrepoaddgrafanahttps：grafana。github。iohelmchartshelmrepoupdate
　　获取lokistack的Chart包并解压：helmpullgrafanalokistackuntarversion2。6。4
　　lokistack这个Chart包里面包含所有的Loki相关工具依赖，在安装的时候可以根据需要开启或关闭，比如我们想要安装Grafana，则可以在安装的时候简单设置setgrafana。enabledtrue即可。默认情况下loki、promtail是自动开启的，也可以根据我们的需要选择使用filebeat或者logstash，同样在Chart包根目录下面创建用于安装的Values文件：valuesprod。yamlloki：enabled：truereplicas：1rbac：pspEnabled：falsepersistence：enabled：truestorageClassName：localpathpromtail：enabled：truerbac：pspEnabled：falsegrafana：enabled：trueservice：type：NodePortrbac：pspEnabled：falsepersistence：enabled：truestorageClassName：localpathaccessModes：ReadWriteOncesize：1Gi
　　然后直接使用上面的Values文件进行安装即可：helmupgradeinstalllokinloggingfvaluesprod。yaml。Releaselokidoesnotexist。Installingitnow。NAME：lokiLASTDEPLOYED：TueJun1414：45：502022NAMESPACE：loggingSTATUS：deployedREVISION：1NOTES：TheLokistackhasbeendeployedtoyourcluster。LokicannowbeaddedasadatasourceinGrafana。Seehttp：docs。grafana。orgfeaturesdatasourceslokiformoredetail。
　　安装完成后可以查看Pod的状态：kubectlgetpodsnloggingNAMEREADYSTATUSRESTARTSAGEloki011Running05m19slokigrafana5f9df99f6d8rwbz22Running05m19slokipromtailptxxl11Running05m19slokipromtailxc55z11Running05m19slokipromtailzg9tv11Running05m19s
　　这里我们为Grafana设置的NodePort类型的Service：kubectlgetsvcnloggingNAMETYPECLUSTERIPEXTERNALIPPORT（S）AGElokiClusterIP10。104。186。9none3100TCP5m34slokigrafanaNodePort10。110。58。196none80：31634TCP5m34slokiheadlessClusterIPNonenone3100TCP5m34s
　　可以通过NodePort端口31634访问Grafana，使用下面的命令获取Grafana的登录密码：kubectlgetsecretnamespacelogginglokigrafanaojsonpath｛。data。adminpassword｝base64decode；echo
　　使用用户名admin和上面的获取的密码即可登录Grafana，由于HelmChart已经为Grafana配置好了Loki的数据源，所以我们可以直接获取到日志数据了。点击左侧Explore菜单，然后就可以筛选Loki的日志数据了：
　　我们使用Helm安装的Promtail默认已经帮我们做好了配置，已经针对Kubernetes做了优化，我们可以查看其配置：kubectlgetsecretlokipromtailnloggingojsonjqr。data。promtail。yamlbase64decodeserver：loglevel：infohttplistenport：3101client：url：http：loki：3100lokiapiv1pushpositions：filename：runpromtailpositions。yamlscrapeconfigs：Seealsohttps：github。comgrafanalokiblobmasterproductionksonnetpromtailscrapeconfig。libsonnetforreferencejobname：kubernetespodspipelinestages：cri：｛｝kubernetessdconfigs：role：podrelabelconfigs：sourcelabels：metakubernetespodcontrollernameregex：（〔09az。〕？）（〔09af〕｛8，10｝）？action：replacetargetlabel：tmpcontrollernamesourcelabels：metakubernetespodlabelappkubernetesionamemetakubernetespodlabelapptmpcontrollernamemetakubernetespodnameregex：；（〔；〕）（；。）？action：replacetargetlabel：appsourcelabels：metakubernetespodlabelappkubernetesiocomponentmetakubernetespodlabelcomponentregex：；（〔；〕）（；。）？action：replacetargetlabel：componentaction：replacesourcelabels：metakubernetespodnodenametargetlabel：nodenameaction：replacesourcelabels：metakubernetesnamespacetargetlabel：namespaceaction：replacereplacement：1separator：sourcelabels：namespaceapptargetlabel：jobaction：replacesourcelabels：metakubernetespodnametargetlabel：podaction：replacesourcelabels：metakubernetespodcontainernametargetlabel：containeraction：replacereplacement：varlogpods1。logseparator：sourcelabels：metakubernetespoduidmetakubernetespodcontainernametargetlabel：pathaction：replaceregex：true（。）replacement：varlogpods1。logseparator：sourcelabels：metakubernetespodannotationpresentkubernetesioconfighashmetakubernetespodannotationkubernetesioconfighashmetakubernetespodcontainernametargetlabel：pathIngress日志展示