Alertmanager简介Prometheus 架构中采集数据和发送告警是独立出来的, 告警触发后将信息转发到独立的组件 Alertmanager，满足告警触发条件就会向 Alertmanager 发送告警信息，最后通过接收器 recevier 发送给指定用户。 工作机制Alertmanager 收到告警信息后: 进行分组 Group（告警组） 通过定义好的路由 routing 转发到正确的接收器 recevier recevier 通过 email dingtalk wechat 等方式通知给定义好的接收人 四大功能 分组 (Grouping): 将同类型的告警进行分组, 合并多条告警到一个通知中 抑制 (Inhibition): 当某条告警已经发送, 停止重复发送由此告警引起的其他异常或者故障 静默 (Silences): 根据标签快速对告警进行静默处理, 如果告警符合静默的配置, Alertmanager 则不会发送告警通知 路由 (Route): 用于配置 Alertmanager 如何处理传入的特定类型的告警通知 配置详解123456789101112131415 ...
简介白盒监控vs黑盒监控白盒监控：监控主机的资源用量、容器的运行状态、数据库中间件的运行数据等等，这些都是支持业务和服务的基础设施，通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。 黑盒监控：以用户的身份测试服务的外部可见性，常见的黑盒监控包括 HTTP 探针 TCP 探针 等用于检测站点或者服务的可访问性，以及访问效率等。 黑盒监控相较于白盒监控最大的不同在于黑盒监控是以故障为导向的. 当故障发生时，黑盒监控能快速发现故障，而白盒监控则侧重于主动发现或者预测潜在的问题。一个完善的监控目标是要能够从白盒的角度发现潜在问题，能够在黑盒的角度快速发现已经发生的问题。 blackbox exporterBlackbox Exporter 是 Prometheus 社区提供的官方黑盒监控解决方案，其允许用户通过 HTTP HTTPS DNS TCP ICMP 以及 gPRC 的方式对 endpoints 端点进行探测。可以用于下面的这些场景： HTTP 测试：定义 Request Header 信息、判断 Http statu ...
服务发现简介在 Prometheus Operator 中, 我们无需手动编辑配置文件添加 kubernetes_sd_config 配置, Prometheus Operator 提供了下述资源： serviceMonitor：创建 endpoints 级别的服务发现 podMonitor：创建 pod 级别的服务发现 probe：创建 ingress 级别的服务发现(用于黑盒监控) 通过对这三种 CRD 资源的管理实现 prometheus 动态的服务发现。 除了 Kubernetes 集群中的一些资源对象、节点以及组件都需要监控，有的时候可能还需要根据实际的业务需求去添加自定义的监控项，添加一个自定义监控的步骤也是非常简单的。 第一步建立一个 ServiceMonitor 或 podMonitor 对象，用于 Prometheus 添加监控项 第二步为 ServiceMonitor 或 podMonitor 对象关联 metrics 数据接口的一个 Service 对象 第三步确保 Service 或 Pod 对象可以正确获取到 metrics 数据 接下来就来为大家演示 ...
Prometheus Operator介绍Prometheus Operator：为监控 Kubernetes 资源和 Prometheus 实例的管理提供了简单的定义，简化在 Kubernetes 上部署、管理和运行 Prometheus 和 Alertmanager 集群。 Prometheus Operator 的核心特性是 watch Kubernetes API 服务器对特定对象的更改，为 Kubernetes 提供了对 Prometheus 机器相关监控组件的本地部署和管理方案，该项目的目的是为了简化和自动化基于 Prometheus 的监控栈配置，主要包括以下几个功能： Kubernetes 自定义资源：使用 Kubernetes CRD 来部署和管理 Prometheus、Alertmanager 和相关组件。 简化的部署配置：直接通过 Kubernetes 资源清单配置 Prometheus，比如版本、持久化、副本、保留策略等等配置。 Prometheus 监控目标配置：基于熟知的 Kubernetes 标签查询自动生成监控目标配置，无需学习 Prometheus ...
日志报警对于生产环境以及一个有追求的运维人员来说，哪怕是毫秒级别的宕机也是不能容忍的。对基础设施及应用进行适当的日志记录和监控非常有助于解决问题，还可以帮助优化成本和资源，以及帮助检测以后可能会发生的一些问题。使用 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 ...
