日志报警对于生产环境以及一个有追求的运维人员来说，哪怕是毫秒级别的宕机也是不能容忍的。对基础设施及应用进行适当的日志记录和监控非常有助于解决问题，还可以帮助优化成本和资源，以及帮助检测以后可能会发生的一些问题。使用 Loki 收集日志是否可以根据采集的日志来进行报警呢？答案是肯定的，而且有两种方式可以来实现：Promtail 中的 metrics 阶段和 Loki 的 ruler 组件。 测试应用比如现在我们有一个如下所的 nginx 应用用于 Loki 日志报警： 123456789101112131415161718192021222324252627282930313233343536cat > appv1.yml <<EOFapiVersion: apps/v1kind: Deploymentmetadata: name: appv1spec: selector: matchLabels: app: appv1 template: metadata: labels: use: test app: ...
环境准备准备三台Linux机器（本文以Ubuntu 23.10系统为例），三台机器之间能相互通信。 以下是本文使用的三台Ubuntu 23.10： hostname IP memory k8s-master 10.1.1.20 4GB k8s-node1 10.1.1.30 2GB k8s-node2 10.1.1.40 2GB 系统初始化需分别在k8s-master、k8s-node1、k8s-node2 中执行，建议通过root用户操作 将普通用户(work)设置免密sudo切换 1234visudo # Allow members of group sudo to execute any command# 添加如下配置work ALL=(ALL) NOPASSWD:ALL 设置时区为上海 123timedatectl set-timezone Asia/Shanghaiapt-get install -y ntpdate >/dev/null 2>&1ntpdate ntp.aliyun.com 关闭swap 12sed -i ...
简介项目地址 官方文档 Grafana Loki 是一个水平可扩展，高可用性，多租户的日志聚合系统，Loki 是基于仅索引有关日志元数据的想法而构建的：标签（就像 Prometheus 标签一样）。日志数据本身被压缩然后并存储在对象存储（例如 S3 或 GCS）的块中，甚至存储在本地文件系统上，轻量级的索引和高度压缩的块简化了操作，并显著降低了 Loki 的成本，Loki 更适合中小团队。由于 Loki 使用和 Prometheus 类似的标签概念，所以如果你熟悉 Prometheus 那么将很容易上手，也可以直接和 Grafana 集成，只需要添加 Loki 数据源就可以开始查询日志数据了。 Loki 还提供了一个专门用于日志查询的 LogQL 查询语句，类似于 PromQL，通过 LogQL 我们可以很容易查询到需要的日志，也可以很轻松获取监控指标。Loki 还能够将 LogQL 查询直接转换为 Prometheus 指标。此外 Loki 允许我们定义有关 LogQL 指标的报警，并可以将它们和 Alertmanager 进行对接。 Grafana Loki 主要由 3 部分组成: ...
07bf558d4045265bd25330bc704e56c8362c64f2f3a01a03b0c6d9133d11823d17d3c8679647323f96496524fa8b4ad6a00bf4ff129efb34e9777e511ff698a6907a9bdc4b4c6281b80c2978f3f1873ea1f639644d9b3d3ef082df5cf22718a0d1f92b72af8d3555df3c2bc3c6973591c986047ce8cbe9c4586eb93f345612f1c41ff234cd92390ec0991dc8f10c4ced8918d6f92698d4811a1bd704e7806546019cb419c37ccb55afdef792a681a79726cfdd4309aa0eb9b2f955dcc148e416ceb794693b87300a8ff8713f52a42cbe8c08fd8f1250730b381749f9cba79e8be7cd622b9ce861f7cd4ec1e12d9c224192f1b6fb9e55b61b5 ...
3bfb72595ead2e149d77d9a193cd733251059b01b6642c49860faab10edac6002202fe51966c64eda10f4eeb1d704c2246412d4ec96b0ea08ba1ca4fa8b8ed86cbbf4baa5da5b6c527fb819f2c7273be246ec0c53c0f50ff98c58aa5f185f768d23c9d6514e5f36ca2dc81af8cf3c43927876815a03e3d69781efb18e436046a6bc8a938e78cf6a414083da9226a88870691aa7ac2fd0726fea1f5a429ab7f50d14e70dcd308e333dc10ff3c9851b216abe547c406324f978f627a82c2e68457b7959952934b31a32fccb368b85c01e44c575c991a4aac46d0124dc773d86ec97d5af1c74d85b1437b1f71a7292a337c54d866aecd3b63bf0 ...
日志收集架构日志对于调试问题和监视集群情况也是非常有用的。而且大部分的应用都会有日志记录，对于传统的应用大部分都会写入到本地的日志文件之中。对于容器化应用程序来说则更简单，只需要将日志信息写入到 stdout 和 stderr 即可，容器默认情况下就会把这些日志输出到宿主机上的一个 JSON 文件之中，同样也可以通过 docker logs 或者 kubectl logs 来查看到对应的日志信息。 但是，通常来说容器引擎或运行时提供的功能不足以记录完整的日志信息，比如，如果容器崩溃了、Pod 被驱逐了或者节点挂掉了，仍然也希望访问应用程序的日志。所以，日志应该独立于节点、Pod 或容器的生命周期，这种设计方式被称为 cluster-level-logging，即完全独立于 Kubernetes 系统，需要自己提供单独的日志后端存储、分析和查询工具。 Kubernetes 日志收集Kubernetes 集群本身不提供日志收集的解决方案，一般来说有主要的 3 种方案来做日志收集： 在每个节点上运行的节点级日志收集代理。 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器 ...
Prometheus简介Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具，是一个独立的开源项目，于 2016 年加入了 CNCF 基金会，作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工具主要有以下几个特点： 具有由 metric 名称和键/值对标识的时间序列数据的多维数据模型 有一个灵活的查询语言 不依赖分布式存储，只和本地磁盘有关 通过 HTTP 的服务拉取时间序列数据 也支持推送的方式来添加时间序列数据 还支持通过服务发现或静态配置发现目标 多种图形和仪表板支持 Prometheus 由多个组件组成，但是其中有些组件是可选的： Prometheus Server：用于抓取指标、存储时间序列数据 exporter：暴露指标让任务来抓 pushgateway：push 的方式将指标数据推送到该网关 alertmanager：处理报警的报警组件 adhoc：用于数据查询 大多数 Prometheus 组件都是用 Go 编写的，因此很容易构建和部署为静态的二进制文件。下图是 Prometheu ...
APISIX高级使用Apache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能、可扩展的微服务 API 网关，目前已经是 Apache 顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B 测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。 重定向-redirect官方文档 现在当我们访问 http://whoami.boysec.cn/tls 或者 http://whoami.boysec.cn/tls/ 的时候都可以得到正常的结果，一般来说我们可能希望能够统一访问路径，比如访问 /tls 子路径的时候可以自动跳转到 /tls/ 以 Splash 结尾的路径上去。同样要实现该需求我们只需要使用一个名为 redirect 的插件即可，该插件是 URI 重定向插件，可配置的属性如下所示： 名称 类型 必选项 默认值 有效值 描述 http_to_https boolean 否 false ...
APISIXApache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能、可扩展的微服务 API 网关，目前已经是 Apache 顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B 测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。 APISIX 基于 Nginx 和 etcd，与传统 API 网关相比，APISIX 具有动态路由和热加载插件功能，避免了配置之后的 reload 操作，同时 APISIX 支持 HTTP(S)、HTTP2、Dubbo、QUIC、MQTT、TCP/UDP 等更多的协议。而且还内置了 Dashboard，提供强大而灵活的界面。同样也提供了丰富的插件支持功能，而且还可以让用户自定义插件。 上图是 APISIX 的架构图，整体上分成数据面和控制面两个部分，控制面用来管理路由，主要通过 etcd 来实现配置中心，数据面用来处理客户端请求，通过 APISIX 自身来 ...
Pods调度我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们希望一些机器学习的应用只跑在有 GPU 的节点上；但是有的时候我们的服务之间交流比较频繁，又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了，主要有两个概念：亲和性和反亲和性，亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。 定向调度(nodeSelector)如果要实现定向调度，首先的第一步就是要为Node节点搭上标签（Label），我们知道 label 标签是 kubernetes 中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的 Service 对象通过 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。可以使用kubectl label命令： 12345# 添加label标签kubectl label nod ...
Traefik自动申请证书Traefik实现自动申请HTTPS证书要使用Let’s Encrypt自动生成证书，需要使用ACME。需要在静态配置中定义 “证书解析器”，Traefik负责从ACME服务器中检索证书。 然后，每个 “路由器 “被配置为启用TLS，并通过tls.certresolver配置选项与一个证书解析器关联。 Traefik的ACME验证方式主要有以下三种： tlsChallenge httpChallenge dnsChallenge 如果使用tlsChallenge，则要求Let’s Encrypt到 Traefik 443 端口必须是可达的。如果使用httpChallenge，则要求Let’s Encrypt到 Traefik 80端口必须是可达的。如果使用dnsChallenge，则需要对应的providers。 部署cert-manager借助 Kubernetes，我们获得了一个强大且可扩展的平台来解决许多复杂的场景。cert-manager是一个功能强大的解决方案，可以帮助我们自动化和管理与 TLS 证书相关的几乎所有内容。它提供了一套针对各种场景的 ...
简介traefik 的路由规则就可以实现 4 层和 7 层的基本负载均衡操作，使用 IngressRoute IngressRouteTCP IngressRouteUDP 资源即可。但是如果想要实现 加权轮询、流量复制 等高级操作，traefik抽象出了一个 TraefikService 资源。此时整体流量走向为：外部流量先通过 entryPoints 端口进入 traefik，然后由 IngressRoute/IngressRouteTCP/IngressRouteUDP 匹配后进入 TraefikService，在 TraefikService 这一层实现加权轮循和流量复制，最后将请求转发至kubernetes的service。 除此之外traefik还支持7层的粘性会话、健康检查、传递请求头、响应转发、故障转移等操作。 灰度发布官方文档 Traefik2.0 的一个更强大的功能就是灰度发布，灰度发布也称为金丝雀发布（Canary），主要就是让一部分测试的服务也参与到线上去，经过测试观察看是否符号上线要求。 比如现在我们有两个名为 appv1 和 appv2 ...
