「Promtail」- 常见问题处理
场景：处理多行日志（Java）
febbweiss/java-log-generator – Docker Image | Docker Hub grafana – Promtail error pipeline stage must only contain one key – Stack Overflow promtail multiline Code Example
第一步、更新 Promtail 配置：
…
– job_name: kubernetes-pods
pipeline_stages:
– cri: {}
# 通过 firstline 匹配多行日志开始
– multiline:
firstline: ^(\d{2})-(\d{2})-(\d{4}) (\d{2}):(\d{2}):(\d{2})
max_lines: 128
max_wait_time: 3s
…
第二步、创建能够产生多行日志的容器，以用于测试：kubectl apply -f ./promtail-testing.yaml
第三步、最后，在 Grafan 中，观察 Java 日志是否被合并为单条日志记录；
Q：那么多日志，如果下一行是未匹配 firstline 的常规日志会怎样（两行日志具有不同格式）？ A：我们实在查看日志平台时产生的该疑问。实质上，同个日志文件，它的日志行是相同格式，如果下一行不匹配这种模式，则为视为多行日志。如果一个日志文件中具有多种日志格式行，则需要修改软件的设计，保持相同的日志格式；[……]
「Promtail」- 爬取 Linux Kernel 日志
解决方案
在 Linux 中，内核日志的保存路径并不相同： 1）在 Ubuntu 中，/var/log/kern.log
values.yaml（form Helm Chart）
// —————————————————————————- // 挂载日志文件
defaultVolumes:
– name: var-log
hostPath:
path: /var/log/
defaultVolumeMounts:
– name: var-log
mountPath: /var/log/
readOnly: true
// —————————————————————————- // 读取日志文件
config:
snippets:
extraScrapeConfigs: |
– job_name: linux-kernel
static_configs:
– targets:
– localhost
labels:
__path__: /var/log/kern.log
log_category: linux-kernel
hostname: ${HOSTNAME}
// —————————————————————————- // 解析配置文件中的环境变量
extraArgs:
– -config.expand-env
// —————————————————————————- // 授予日志文件访问权限
containerSecurityContext:
capabilities:
add:
– DAC_READ_SEARCH
关于 HOSTNAME 变量：Helm Chart 默认修改 HOSTNAME 变量，使其为 nodeName 值，所以该变量不会成为容器名；
关于 DAC_READ_SEARCH 参数：The CAP_DAC_OVERRIDE capability allows the root user to bypass kernel permissio[……]
「PROMTAIL」- 抓取 syslog 内容
问题描述
该笔记将记录：配置 Promtail 抓取 syslog 的方法，以及相关问题的解决办法；
解决方案
scrape_configs.syslog
Promtail，其提供 syslog 配置，但是其并不能直接抓取 syslog 日志，而是将 Promtail 作为 Listener，然后配置 rsyslog 将日志发送给 Promtail 服务；
我们希望减少对底层操作系统的变更（运维工作），所以并未采用该方案；
scrape_configs.static_configs
我们直接使用 static_configs 来抓取日志文件：我们的操作系统以 Ubuntu 为主；并且以云原生容器环境来运行；[……]
「Grafana Loki / Promtail」- 抓取 systemd journal 日志
问题描述
该笔记将记录：如何通过 Promtail 抓取 systemd journal 日志，以及相关问题的解决办法。
解决方案
补充说明：我们通过 Helm 部署 Promtail 实例，所以如下配置内容与 Helm Chart 具有相关性（但其他部署方式的配置思路也是相似的）
第一步、修改 Promtail 配置
挂载系统日志目录
修改 Helm Chart values.yaml 文件：
…
extraVolumes:
– name: journal
hostPath:
path: /var/log/journal
…
extraVolumeMounts:
– name: journal
mountPath: /var/log/journal
readOnly: true
…
配置日志文件抓取
extraScrapeConfigs: |
…
– job_name: systemd-journal
journal:
labels:
job: systemd-journal
path: /var/log/journal
max_age: 12h
relabel_configs:
– source_labels:
– __journal__systemd_unit
target_label: systemd_unit
– source_labels:
– __journal__hostname
target_label: hostname
– source_labels:
– __journal_syslog_identifier
target_label: syslog_identifier
…
第二步、增加 Dashboard 配置
我们没有找到满足需求的 Dashboard 配置，所以我们创建简单的 Dashboard 配置：
Variable： 1）loki_datasource: 2）hostname: label_values(hostname) 3）systemd_unit: label_values({hostname=~”$hostname”}, systemd_unit) 4）search: Text box
Pannel 1）Log browser: {hostname=”$hostname”,systemd_unit=”$systemd_unit”} |~ “(?i)$search”
参考文献
Grafana L[……]
「Grafana / Loki / Promtail」- 常见问题处理
节点日志无法被抓取
问题描述： 某个节点的容器日志无法被正常抓取；
环境信息： Kubernetes v1.22.15, Promtail 5.0.0, Loki 2.5.0, Grafana 8.5.3
原因分析： Bug: Promtail log is reporting error for non-existent symlink · Issue #2513 · grafana/loki promtail logs no such file or directory · Issue #429 · grafana/loki
解决方案： 重启该节点的 Promtail 服务；
… HTTP status 429 Too Many Requests …
how can I increase the maximum active stream limit? · Issue #3335 · grafana/loki · GitHub
问题描述：
level=warn ts=2022-11-10T05:10:49.533015596Z caller=client.go:349 component=client
host=loki-loki-distributed-gateway.loki.svc.cluster.local msg=”error sending batch, will retry”
status=429 error=”server returned HTTP status 429 Too Many Requests (429): Maximum
active stream limit exceeded, reduce the number of active streams (reduce labels or
reduce label values), or contact your Loki administrator to see if the limit can be increased”
解决方案： 修改 limits_config.max_streams_per_user: 0 配置；[……]
「Grafana Loki」- 处理重复日志
问题描述
在 Grafana Loki 中，我们发现重复日志，这些日志具有相同的时间戳。
解决方案
出现重复日志的原因由很多，这里将讨论我们遇到的问题。
场景：应用程序写入内容相同的日志
Loki logs panel deduplication · Issue #22498 · grafana/grafana · GitHub
原因分析
在短时间内，应用程序写入大量内容相同的日志。仔细观察，日志时间戳的毫秒位是不同的。
解决方案
我们在 Grafana 的 Panel 中，开启 Deduplication: Exact 选项，对日志进行去重。
Exact，根据 De-duplication of successive lines that are identical, ignoring ISO datetimes. 描述，将忽略前缀 ISO 时间的不同。
场景：… Maximum active stream limit exceeded …
how can I increase the maximum active stream limit? · Issue #3335 · grafana/loki · GitHub
在 Promtail Log 中，我们看到类似如下内容：
level=warn ts=2022-11-10T05:10:49.533015596Z caller=client.go:349 component=client
host=loki-loki-distributed-gateway.loki.svc.cluster.local msg=”error sending batch, will retry”
status=429 error=”server returned HTTP status 429 Too Many Requests (429): Maximum
active stream limit exceeded, reduce the number of active streams (reduce labels or
reduce label values), or contact your Loki administrator to see if the limit can be increased”
我们猜测是重试导致日志重复，但是我们并不能十分确定。
针对 … Maximum active stream limit exceeded … 信息，我们尝试修改 limits_config.max_streams_per_user: 0 配置，后面再做进一步观察。
场景[……]
「Alertmanager」- Prometheus 的告警发送工具
问题描述
我们将学习 Alertmanager 的使用方法，并整理学习笔记，学习资料以官方文档为主，辅以其他网络资料。
该笔记将记录：Alertmanager 的使用方法，其主要内容是对官方文档的学习、记录、整理，还包含部分常用配置示例。
解决方案
针对该部分内容，其均来自于官方文档，但仅提取出我们需要关注的内容，能让我们形成对 Alertmanger 的整体认识。 子章节将记录如何使用 Alertmanager 完成具体的工作任务，比如 配置 Slack 告警、定制告警消息格式。
ALERTING — Alerting overview: Concepts and Fundamentals — Alertmanager: Concepts and Fundamentals — Configuration: Maintenance, Administration — Clients: ALERTING.Clients — Notification template reference: Notification Template — Notification template examples: Notification Template — Management API: Maintenance, Administration — HTTPS and authentication: Maintenance, Administration
相关链接
Awesome Prometheus alerts | Collection of alerting rules
参考文献
How to check your prometheus.yml is valid – Robust Perception | Prometheus Monitoring Experts How do I configure the log level of Prometheus’ Alertmanager? – Server Fault alertmanager/simple.yml at master · prometheus/alertmanager What’s the difference between group_interval, group_wait, and repeat_interval? – Robust Perception | Prometheus Monitoring Experts Prometheus: understanding the delays on alerting[……]
「Alertmanager」- 概念术语
概念概览（=> ALERTING/Alerting overview）
Alerting overview | Prometheus
在 Prometheus 中，当指标异常而触发 Promethesu 的告警规则时，Promethesu 将请求 Alertmanager 服务，来要求 Alertmanager 发送告警信息，而 Alertmanger 负责处理这些告警消息，来决定是 是否发送消息、是否合并消息、何时发送、发送渠道等等。所以说，Alertmanager 负责管理告警消息的发送，但并不负责检查指标是否达到告警阈值（这属于 Prometheus 的任务）。
简而言之，Prometheus 负责产生告警，Alertmanager 负责进行告警信息的抑制、静默、聚合、发送；
在 Prometheus 中，配置告警的步骤如下： 1）安装并配置 Alertmanager 服务； 2）配置 Prometheus 连接 Alertmanager 服务； 3）配置 Prometheus 的 Alert Rule 来产生告警；
核心的基本概念（=> ALERTING/Alertmanager）
Alertmanager | Prometheus
消息分组（Grouping）
合并告警消息。例如，当数据中心网络故障，所有服务均不可连接，此时将产生大量告警消息。而我们仅仅希望收到一条汇总的告警消息，而不是针对每个服务的告警消息。这就是 Grouping 的作用，能够按照告警、时间、接收人来发送告警信息。对于该配置，需要在配置文件中进行设置。
Q：Alertmanager 依据什么参数来合并告警？ A：Alertmanger 通过 Label 来识别是否为同个告警，如果 Label 相同，则表示为同个告警，则进行相关去重等动作。Annotaion 则是作为描述信息，不用来区分告警。 R：Prometheus/Clients
消息抑制（Inhibition）
例如，如果集群无法访问，那么我们希望抑制与这个集群相关的告警信息。这就是 Inhibition 的作用，根据关系而仅发送最关键的告警。对于该配置，需要在配置文件中进行设置。
条件判断（Silences）
允许我们根据告警消息的条件、标签来过滤告警消息，以决定某些告警是否发送。对于该配置，需要在 Alertmanager 的 Web 界面中完成。
灵活请求（Client Behavior）
除了配合 Promethesu 来发送告警消息，还能够单独使用 Alertmanager 服务。我们能够发送自定义 HTTP 请求并附带某些信息，来要求 Alertmanager 发送告警。
高可用性（High Av[……]
「Alertmanager」- 安装部署
关于安装方法
参考 alertmanager/README.md at master 页面。如果希望以容器运行，参考 prom/alertmanager 页面。
on Kubernetes with Helm
How do I configure the log level of Prometheus’ Alertmanager? – Server Fault
我们通过 Helm 部署 Alertmanager 组件：
# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
# helm pull alertmanager-0.19.0.tgz # CHART 0.19.0, APP v0.23.0
# helm show values alertmanager-0.19.0.tgz > alertmanager-0.19.0.helm-values.yaml
# vim alertmanager-0.19.0.helm-values.yaml
…
# helm –namespace observing-system \
install alertmanager ./alertmanager-0.19.0.tgz \
-f alertmanager-0.19.0.helm-values.yaml \
–create-namespace
…
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods –namespace observing-system -l “app.kubernetes.io/name=alertmanager,app.kubernetes.io/instance=alertmanager” -o jsonpath=”{.items[0].metadata.name}”)
echo “Visit http://127.0.0.1:9093 to use your application”
kubectl –namespace observing-system port-forward $POD_NAME[……]
「Alertmanager」- 服务管理、服务维护
配置参数及配置文件（=> ALERTING/Configuration）
Configuration | Prometheus
能够通过 命令行 和 配置文件 指定运行参数。命令行仅能简单配置，而配置文件能够定义继承规则、通知路由、告警接收人等等复杂设置；
visual editor，用于构建路由树；
SIGHUP，http:///-/reload，重新加载配置；
针对配置选项的内容，这里不再展开，在具体应用场景中，我们将再进一步研读；
命令行选项
使用 alertmanager -h 查看全部命令行选项；
指定配置文件：alertmanager –config.file /path/to/alertmanager.yml
增加日志等级：alertmanager –log.level=debug
配置文件结构与语法
我们这里侧重学习配置文件的结构，而不是每个属性及字段的含义。当对配置文件的结构形成整体的认识，在解决具体问题时也会非常清楚该如何解决；
关于官方文档的阅读： 1）[]，表示该参数是可选择 2）占位符（Placeholder），即每个字段的结构及取值类型，是文档的主要内容并且需要我们了解其使用方法；
配置文件采用 YAML 格式。官方提供的示例配置文件：alertmanager/simple.yml at master · prometheus/alertmanager
根据我们学习，我们整理出如下示例配置文件：
# 定义全局配置，还定义某些参数
global:
resolve_timeout: 5m
# 邮箱相关信息
smtp_smarthost: ‘smtp.example.com’
smtp_auth_username: ‘username’
smtp_auth_password: ‘password’
smtp_from: ‘k4nz@example.com’
# 在发送通知时，使用的模板文件的路径
templates:
– ‘/etc/alertmanager/template/*.tmpl’
# 定义消息的方式渠道及相关参数
# 注意，receivers 仅定义告警消息的接收方式，而发送规则需要通过 route 定义
receivers:
# 告警到 Slack 平台
– name: ‘slack-notifications’
slack_configs:
– channel: ‘#alerts’
text: ‘https://internal.example.com/wiki/alerts/{{ .GroupLabels.app }}[……]
「Alertmanager」- 告警模板
定制通知模板
Notification template reference | Prometheus Notification template examples | Prometheus
Alertmanager 发送的告警消息将通过模板（Go templating）进行渲染，然后再将其发送给接受人。
鉴于介绍 Go templating 的使用方法会偏离主题，所以该笔记不会记录 Go templating 的使用方法，与其相关内容参考 Go templating 笔记。
模板大部分是开箱即用的，通常无需定制。如果希望定制模板，需要学习以下内容： 1）学习 Go templating 使用； 2）学习 Notification template reference 文档，以了解能在模板中使用的变量；
模板配置案例
官方 Notification template examples 文档，提供简单的配置示例，涵盖几个常用场景，足够我们学习入门。
这里我们将记录我们的使用场景，及相关配置： 1）发送告警消息到多个渠道，比如 Email、Slack 等等。[……]
「Alertmanager」- 常见问题处理
与 Alertmanager 配套的工具，具有如下功能： 1）检查配置文件是否正确：amtool check-config alertmanager.yml 2）查看当前触发的告警、并且能对这些告警进行相关操作；
Routing tree editor
测试 route 配置（类似 Routing tree editor 工具，但为命令行使用）
官方提供的 route 编辑器（Routing tree editor），能够用来测试消息的路由：根据 route 配置，以及当在告警信息中存在某些 Lable 时，哪些 receiver 将接收到消息。
告警通知渠道
PrometheusAlert
feiyu563/PrometheusAlert: Prometheus Alert是开源的运维告警中心消息转发系统,支持主流的监控系统Prometheus,Zabbix,日志系统Graylog和数据可视化系统Grafana发出的预警消息,支持钉钉,微信,华为云短信,腾讯云短信,腾讯云电话,阿里云短信,阿里云电话等
飞书告警：需要借助 PrometheusAlert 服务来实现
告警企业微信
Alertmanager 原生支持告警到企业微信，参照官方文档配置即可； 但是，鉴于企业微信要求配置 IP-ADDR 信任，所以调用方需要固定网络地址，否则告警接口调用将失败；[……]
「Alertmanager」- 发送测试通知（=> ALERTING/Clients）
问题描述
当进行 Alertmanager 设置之后，我们希望能够发送告警消息进行测试，以验证配置已生效。但是我们又不能直接关闭服务等待 Prometheus 触发告警消息 ：-）
解决方案
好在 Alertmanager 提供告警接口，允许我们以 HTTP 协议进行调用，来要求其发送告警信息。 当 Alertmanager 启动后，将监听 HTTP 9093 端口，Prometheus 将通过 HTTP 调用该接口来发送告警消息参数。而除此之外，我们能构建自己的告警参数，来发送自定义的 HTTP 请求以产生告警消息。
补充说明： 通过调用 API 告警的方式，仅作为补充手段，如果需要进行 Prometheus 告警，官方建议通过 Alert Rule 实现，不建议实现额外的客户端。
更多内容，参考 Clients | Prometheus 文档
告警脚本：send-alerts.sh
该部分将演示，在 Shell 中，调用 Alertmanager 服务来发送通知的方法，以及相关问题的处理方法。
下面是发送告警的简单示例：
#!/usr/bin/env bash
alerts_message='[
{
“labels”: {
“alertname”: “DiskRunningFull”,
“dev”: “sda1”,
“instance”: “example1”,
“msgtype”: “testing”
},
“annotations”: {
“info”: “The disk sda1 is running full”,
“summary”: “please check the instance example1”
}
},
{
“labels”: {
“alertname”: “DiskRunningFull”,
“dev”: “sda2”,
“instance”: “example1”,
“msgtype”: “testing”
},
“annotations”: {
“info”: “The disk sda2 is running full”,
“summary”: “please check the instance example1”,
“runbook”: “the following link http://test-url should be clickable”
}
}
]’
c[……]
「Alertmanager」- 告警到 Slack 频道
问题描述
该笔记将记录：在 Alertmanager 中，如何将告警消息发送到 Slack 频道，以及相关问题的处理方法。
解决方案
第一步、配置 Alertmanager 告警到 Slack 频道
该步骤将创建 Slack 应用，目的是为了获取 Webhook 以在 Alertmanager 中使用。
参考 Sending messages using Incoming Webhooks 文档，我们这里将简单记录过程。
1）创建 Slack 应用：https://api.slack.com/apps/new
App Name: AlertBot
Development Slack Workspace: Your Workspace
创建之后，会自动重定向到应用设置页面；
2）进入 Incoming Webhooks 页面
Activate Incoming Webhooks: On
然后，页面会显示新的内容
3）点击 Add New Webhook to Workspace 按钮，以创建新的 Webhook 地址
根据提示填写相关信息
点击 Allow 按钮，此时新的 Webhook 创建成功。
4）创建成功之后，页面会显示 curl 测试命令：
curl -X POST -H ‘Content-type: application/json’ –data ‘{“text”:”Hello, World!”}’ \
https://hooks.slack.com/services/xxxxxxxxxx
访问 https://api.slack.com/apps 地址，以查看所有应用，点击应用名以进入特定应用设置页面。
第二步、配置 Alertmanager 使用 Webhook 地址
修改 alertmanager.yml 文件 receivers 配置，并在 route 中引用：
…
receivers:
# slack
– name: ‘slack-channel’
slack_configs:
– api_url: ‘https://hooks.slack.com/services/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’
channel: ‘#devops-monitoring’
…
route:
receiver: ‘slack-channel’
…
第三步、定制告警模板
参考 Notification templat[……]
「Alertmanager」- 将告警信息发往多个渠道（Slack, Email, …）
问题描述
在出现告警时，我们希望立即收到告警消息，而不希望出现过多的延迟。这点邮件告警是无法满足的，因为邮件通知是由客户端定期查找邮箱才触发的，而且部分邮件服务器也不一定支持 IDLE 命令，因此使用邮件告警无法保证消息的即时性。此外单一的告警渠道无法满足容错的要求，比如邮箱服务出现问题，我们将错过或无法收到告警信息。
鉴于此，除了使用邮件告警，我们还需要接入 IM 进行告警通知。这便涉及将告警信息发送到多个通知渠道。
该笔记将记录：在 Alertmanager 中，将告警消息发送到多个告警渠道的方法，以及注意事项、常见问题的处理。
解决方案
方法一、通过 receiver 配置
在 receiver 中，单个条目能够包含多个告警渠道的配置：
receivers:
– name: slack_and_email
# Slack
slack_configs:
– api_url: ‘<THE_WEBHOOK_URL>’
channel: ‘#general’
– api_url: ‘<ANOTHER_WEBHOOK_URL>’
channel: ‘#alerts’
# Email
email_configs:
– to: ‘k4nz@example.com’
route:
receiver: slack_and_email
方法二、通过 route continue 参数
# 首先，我们定义多个不同的 receiver 信息
receivers:
– name: slack
slack_configs:
– api_url: THE_WEBHOOK_URL
channel: ‘#general’
– name: email
email_configs:
– to: ‘k4nz@example.com’
# 然后，在 route 中通过 continue 参数，是告警消息进行多个匹配
route:
receiver: slack # Fallback，必须设置 receiver 字段
routes:
– match:
severity: page
receiver: slack
continue: true
– match:
severity: page
receiver: pagerduty
通常告警消息的 Lable 匹配 match 之后，不会继续向下匹配。通过 continue: true 能够[……]
「Prometheus」- Exporters
Exports
Exporters and integrations | Prometheus
Export 负责从应用程序中抓取数据，并生成监控指标，以供 Prom 完成抓取。
某些应用程序已经提供 Prom 能够抓取的指标，所以不再需要独立的 Exporter 服务。
process-exporter
ncabatoff/process-exporter: Prometheus exporter that mines /proc to report on selected processes
Writing exporters
Writing exporters | Prometheus
在这部分内容中，官方介绍编写 Export 的方法，以及最佳实践。
Client Libraries and Writing
Client libraries | Prometheus
在 Prometheus 监控服务之前，需要通过 Client-Lib 能够将检测添加到代码中。简单说，通过 Client-Lib 并结合应用程序，使得我们能够快速生成 Prom 需要的指标类型；
官方 Writing client libraries 文档，其介绍编写 Client-Lib 的方法，目前已经有使用语言的客户端库，该文档旨在帮助新客户库的作者制作出好的库。
推送指标
Pushing metrics | Prometheus
Pushgateway 相关内容。
某些程序执行时间较短，在 Prom 抓取前可能已经退出，导致无法进一步抓取。
所以，通过 Push Gateway 特性，应用程序主动将数据推送到 Push Gateway 进而送入 Prom 服务中。
Exposition formats
Exposition formats | Prometheus
部分语言没有对应的 Client-Lib，所以官方在 Exposition formats 中描述 Target 暴露出的数据格式。所以，即使没有 Client-Lib，我们按照规范格式返回数据即可。
章节列表
「PROMETHEUS」- kubelet cAdvisor 「Prometheus」- 编写 Exporter 服务（Python） 「PROMETHEUS」- Process Exporter 「PROMETHEUS」- Node Exporter[……]
「Prometheus」- 编写 Exporter 服务（Python）
问题描述
我们需要为自己的应用编写 Prometheus Exporter 服务，以允许 Prometheus 抓取监控指标。
该笔记将记录：使用 Python 语言编写 Prometheus Exporter 服务的方法，以及常见问题处理。
解决方案
第一步、创建虚拟环境
mkvirtualenv prometheus-client
workon prometheus-client
pip install –upgrade pip
pip install prometheus-client
第二步、创建 Exporter 服务
# example.py
from prometheus_client import start_http_server, Summary
import random
import time
# Create a metric to track time spent and requests made.
REQUEST_TIME = Summary(‘request_processing_seconds’, ‘Time spent processing request’)
# Decorate function with metric.
@REQUEST_TIME.time()
def process_request(t):
“””A dummy function that takes some time.”””
time.sleep(t)
if __name__ == ‘__main__’:
# Start up the server to expose the metrics.
start_http_server(8000)
# Generate some requests.
while True:
process_request(random.random())
第三步、运行并访问该 Exporter 服务
# python example.py
# curl http://localhost:8000/
…
process_max_fds 1024.0
# HELP request_processing_seconds Time spent processing request
# TYPE request_processing_seconds summary
request_processing_seconds_count 0.0
request_processing_seconds_sum 0.0
# HELP request_processing_seco[……]
「PROMETHEUS」- Node Exporter
服务部署
部署 Node Exporter 服务
# helm pull prometheus-community/prometheus-node-exporter –version 4.3.0
# helm show value ./prometheus-node-exporter-4.3.0.tgz > prometheus-node-exporter-4.3.0.helm-values.yaml
# vim prometheus-node-exporter-4.3.0.helm-values.yaml
# helm install -n observing-client mon-node-exporter \
./prometheus-node-exporter-4.3.0.tgz -f prometheus-node-exporter-4.3.0.helm-values.yaml
配置 Prometheus 抓取
Configuration | Prometheus How to configure prometheus kubernetes_sd_configs to specify a specific host port?
prometheus-community https://prometheus-community.github.io/helm-charts prometheus-community/prometheus
…
extraScrapeConfigs: |
…
– job_name: ‘node-exporter’
kubernetes_sd_configs:
– role: node
relabel_configs:
– source_labels: [__address__]
action: replace
regex: ([^:]+):.*
replacement: $1:9100
target_label: __address__
…
配置 Grafana 展示
Grafana Labs/Dashboards/Node Exporter Full
指标数据
Block Device and File System
Mapping iostat to the node exporter’s node_disk_* metrics
IOPS, iostat (r/s) => rate(node_disk_reads_completed_total[5m]) IOPS, iostat (w/s)[……]
「PROMETHEUS」- Process Exporter
服务部署
mumoshu/prometheus-process-exporter
部署 Process Exporter 服务
# git clone https://github.com/mumoshu/prometheus-process-exporter.git
# helm show values ./prometheus-process-exporter/charts/prometheus-process-exporter/ \
> prometheus-process-exporter.helm-values.yaml
# vim prometheus-process-exporter.helm-values.yaml
…
groups:
– comm:
– etcd
…
# helm upgrade –install \
-n observing-client mon-process-exporter \
./prometheus-process-exporter/charts/prometheus-process-exporter/ \
-f prometheus-process-exporter.helm-values.yaml
添加 Prometheus Scrape 配置
– job_name: ‘process-exporter’
kubernetes_sd_configs:
– role: endpoints
relabel_configs:
– source_labels: [__address__]
action: replace
regex: ([^:]+):.*
replacement: $1:9100
target_label: __address__
– source_labels: [__meta_kubernetes_pod_node_name]
action: replace
target_label: instance
创建 Grafana Dashbaord 显示
process exporter dashboard with treemap | Grafana Labs Named processes | Grafana Labs[……]
「Thanos」- 实现 Prometheus 长期存储功
问题描述
Prometheus，监控数据默认写入本地磁盘，这将限制 Prometheus 的监控数据存储能力，同时数据备份、存储空间扩展都将收到限制。
解决方案
Thanos，提供 全局查询视图、高可用性、数据备份、历史、廉价数据访问 功能，作为 Prometheus 的后端存储。
原理简述
通过 Prometheus 的 Remote Read / Remote Write 特性，Promtheus 将数据写入 Thanos 中，也能从 Thanos 中读取数据。[……]
「Kubernetes」- 部署 Thanos 服务
问题描述
该笔记将记录：通过 Bitnami 提供的 Thanos Helm Chart 来部署 Thanos 服务的方法，以及相关问题的解决办法。
解决方案
helm repo pull bitnami/thanos
helm show values ./thanos-12.0.0.tgz > thanos-12.0.0.helm-values.yaml
vim thanos-12.0.0.helm-values.yaml
…（1）开启 receive、store-gateway 组件；
…（2）配置使用 S3 对象存储；
helm upgrade -n observing-system –install mon-thanos \
./thanos-12.0.0.tgz -f thanos-12.0.0.helm-values.yaml
补充说明
配置写入对象存储：
…
objstoreConfig: |
type: S3
config:
bucket: “infra-mon-prometheus”
endpoint: “stge.platform.d3rm.org:9000”
region: “”
access_key: “9r9elpyKi2mfzoGI”
insecure: true
signature_version2: false
secret_key: “Gv25TS7u5eCXnIjgVvaopl5ceITCnglI”
http_config:
idle_conn_timeout: 0s
insecure_skip_verify: true
…
修改 Prometheus 配置（Remote Write）：
remoteWrite:
– url: http://mon-thanos-receive:19291/api/v1/receive
参考文献
Thanos/Storage/S3 thanos/quick-tutorial.md at main · thanos-io/thanos[……]
「Elastic Stack」- 关于订阅
问题描述
官方提供多种订阅计划，同时也开放了 X-PACK 的部分功能。那么我们需要清楚的问题就是： 1）免费版本具有哪些功能？ 2）我们可以使用 X-PACK 的哪些功能？
对于这个问题，可以参考 Elastic Stack subscriptions 页面，无需阅读本笔记其他内容。
什么是订阅计划？
官方提供了几种灵活的订阅计划，用户可以更具自己的需要进行选择。所谓「订阅计划」就是普通版、会员版、黄金版啥的这一套。
本文将简单的介绍这些订阅计划，以及其中包含的功能（重点）。
订阅计划的种类
08/12/2019
目前只有 Open Source、Basic、Gold、Platinum 这四种订阅计划。
前两种订阅计划是免费的，可以免费下载的，而且 Basic 是默认的。
可以使用 GET /_xpack/license 查看许可状态。
06/01/2020
https://www.elastic.co/elasticsearch/service/pricing Standard Gold Gold Enterprise => 全部是付费版本
https://www.elastic.co/subscriptions OPEN SOURCE => 免费版本，但是不包含以下功能（这里只列举我们感兴趣的功能，其他描述请参考上面的链接）： 1）Index lifecycle management
订阅计划的功能列表
每种订阅计划都包含不同的功能，参考 Elastic Stack subscriptions 页面
关于 X-Pack 扩展
08/12/2019
另外，目前 X-Pack 已经开放了某些功能，在 Elastic Stack subscriptions 中也可以看到某些功能是否开放。
在 Elasticsearch 6.3 中，已经默认安装 X-Pack 包，所以无需单独安装，使用 GET _xpack 可以查看相关信息。
默认的Elasticsearch分发包括X-Pack的所有功能，但默认是“Basic”许可证。可以在Kibana (Management -> License)开启某些新特性的试用。
关于 Elasticsearch OSS 版本
而实际上并没有 Elassticsearch OSS 版本，参考 We opened X-Pack 文章。
参考文献
Elastic Stack subscriptions Elasticsearch Reference [6.3] » X-Pack APIs » Info API Kibana User Guide [6.3] » Ma[……]
「Elasticsearch」- 基本概念（学习笔记）
建议参考官方 Elasticsearch Reference [7.7] » Glossary of terms 文档。
索引（Index）
是具有某些类似特征的文档集合。例如，客户数据索引、产品目录索引、订单数据索引 等等。在单个群集中，可以根据需要定义任意数量的索引。
索引由名称进行标识（必须全部小写），此名称用于引用索引，以在对其中的文档执行索引、搜索、更新、删除操作。
分片（Shard）
Elasticsearch 可以把完整的 Index 切割分成多个“块”，“块”被称之为 Shard。因此在 Elasticsearch 中，Index 只是逻辑概念，而内部存储则是分割后的 Index —— Shard。
这样的好处有以下几点： 1）切割成多个 Shard 可以分布到不同节点，容易水平扩展集群，而不是增加单机硬件； 2）可以把一个大的索引拆分成多个，分布到不同的节点上，构成分布式搜索，提高性能。
分片的数量只能在索引创建前指定，并且索引创建后不能更改。
副本（Replica）
索引副本，是索引的副本。在 Elasticsearch 中可以设置多个索引的副本，副本的作用：一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复；二是提高ES的查询效率，ES会自动对搜索请求进行负载均衡。
Primary Shards / Replica Shards
Primary Shards：原始分片 Replica Shards：副本分片，复制原始分片而得到的分片
默认情况下，在 Elasticsearch 6.5 中的每一个索引都分配了 5 个索引分片和 1 个索引副本，这意味着：如果群集中至少有两个节点，则一个索引将包含 5 个主索引分片和另外 5 个副本分片（一个完整的索引副本），总计为每个索引有 10 个索引分片。
集群（Cluster）
集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。ES的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看ES集群，在逻辑上是个整体，你与任何一个节点的通信和与整个ES集群通信是等价的。
节点（node）
Elasticsearch Reference [7.6] » Modules » Node 节点，是作为群集一部分的单个服务器，存储数据并参与群集的索引和搜索功能。就像集群一样，节点由名称进行标识，默认情况下，该名称是在启动时分配给节点的随机通用唯一标识符（UUID）。如果不需要默认值，可以定义所需的任何节点名称。此名称对于管理目的非常重要，可以在其中识别网络中哪些服务器与Elasticsearch集群中的哪些[……]
「Elasticsearch」- 索引
索引，是具有某些类似特征的文档集合。 例如，可以拥有客户数据索引、产品目录索引、订单数据索引。 索引由名称进行标识（必须全部小写），此名称用于引用索引，以在对其中的文档执行索引、搜索、更新、删除操作。
在单个群集中，可以根据需要定义任意数量的索引。
默认情况下，在Elasticsearch中的每一个索引都分配了5个索引分片和1个索引副本，这意味着：如果群集中至少有两个节点，则一个索引将包含5个主索引分片和另外5个副本分片（一个完整的索引副本），总计为每个索引有10个索引分片。
「分片」与「副本」
关于分片（Shard）
一个索引可以存储很多的数据，但是过多的数据会超过硬件的限制。比如，对于有1TB数据的索引，如果存储在单个节点的硬盘上，可能会空间不足，或者搜索速度很慢。
为了解决这个问题，ES提供了将一个索引分割成多个“片”的能力，这个“片”被称为「分片」。当定义「索引」时，你可以指定「分片」的数量。每个「分片」本身都是一个功能完整且独立的「索引」，它拥有「整个索引」的一部分数据，可以托管在集群中的任何节点上。
从另一个角度看，「索引」是一个逻辑上的概念，实际在存储时被分成多个「分片」。
对索引分片有两个重要的原因：
更方便的水平扩容
可以夸分片进行并行/分布操作，因此增加性能/吞吐
「分片」的分布和搜索结果的聚合完全由ES管理，对用户来说是透明的。
关于副本（Replica）
在网路环境中，随时都可能发生故障。强烈建议有一个故障迁移机制，在「分片」或「节点」离线/消失时发挥作用。
在ES中，允许你创建“索引的分片”的“复制”，这些“复制”称为「副本」。
副本的存在有两个重要的原因：
在分片/节点失败时，提供高可用性。鉴于此，”副本分片“绝对不会和”它所拷贝的主分片“在同一个节点上
扩展搜索量/吞吐量，因为可以在所有「副本」上并行地执行搜索
总而言之，每个「索引」可以拆分为多个「分片」。 「索引」也可以被复制零次或更多次。复制后，每个「索引」都将具有「主分片」（从中复制的原始分片）和「副本分片」（主分片的副本）。
在索引创建是，可以基于索引定义「分片」和「副本」数。创建后，可以随意修改「副本」数量。可以使用「_shrink」和「_split」接口更改现有「索引」的「分片」数量，但这不是一个简单的任务，最好是能够预先计划正确数量的「分片」数量。
默认情况下，会为每个「索引」分配5个「主分片」和1个「副本」，如果你有两个节点，那你的「索引」将会有五个「主分片」，五个「副本分片」（一个完整的副本），也就是说每个「索引」有十个分片。
参考文献
Elasticsear[……]
「Elasticsearch」- 安装（CentOS）
Elasticsearch 7.6.2 on CentOS 7.4
Elasticsearch Reference [7.6] » Install Elasticsearch with RPM Elasticsearch Reference [7.6] » Set up Elasticsearch » Bootstrap Checks
第一步、安装 Elasticsearch、Kibana 服务
#!/bin/sh
rpm –import https://artifacts.elastic.co/GPG-KEY-elasticsearch
cat > /etc/yum.repos.d/elasticsearch.repo <<EOF
[elasticsearch]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md
EOF
yum install –enablerepo=elasticsearch elasticsearch
yum install –enablerepo=elasticsearch kibana
第二步、修改 Elasticserach、Kibana 配置
Elasticsearch：
network.host: 0.0.0.0
discovery.type: single-node
Kibana：
elasticsearch.hosts: [“http://localhost:9200”]
第三步、添加 Nginx 反向代理
server {
server_name es-foo.example.com;
location / {
proxy_pass http://127.0.0.1:5601;
}
}
补充说明（对于 7.6.2 版本）
通过非回环地址：如果无法与其他主机组成集群，则视为开发模式；如果能够与其他主机组成集群，则视为生产模式；
Elasticsearch 6.8.6 on CentOS 7.4
Install Elasticsearch with RPM Set up Elasticsearch/Java (JVM) Ver[……]
「Elasticsearch」- 安装（Debian 8.2 and Elasticsearch 6.5.0）
环境概述
操作系统：Debian 8.2 软件版本：Elasticsearch 6.5.0
安装依赖
由于Elasticsearch依赖于Java环境，但是从源中安装Elasticsearch时并不会自动安装JDK包，因此需要进行手动安装。并且不同版本的Elasticsearch依赖的JDK版本不同：
Elasticsearch 6.5.0: Java 8(1.8.0_131 or a later version in the Java 8 release series)
否则APT（DPKG）安装会失败。下载地址：https://jdk.java.net
安装服务
#!/bin/sh
wget -qO – https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add –
apt-get install apt-transport-https
echo “deb https://artifacts.elastic.co/packages/6.x/apt stable main” | tee -a /etc/apt/sources.list.d/elastic-6.x.list
apt-get update
apt-get install elasticsearch=6.5.0
配置服务
修改/etc/elasticsearch/elasticsearch.yml文件的内容如下：
cluster.name: elk # 集群名称
node.name: master # 该节点名称
node.master: true # 意思是该节点为主节点
node.data: true # 表示这是数据节点
network.host: 0.0.0.0 # 监听全部ip，在实际环境中应设置为一个安全的ip
http.port: 9200 # es服务的端口号
# discovery.zen.ping.unicast.hosts: [“192.168.77.128”, “192.168.77.130”, “192.168.77.134”] # 配置自动发现
由于没有配置集群，所以这个节点既是master节点，也是data节点。
启动服务
执行systemctl start elasticsearch.service来启动Elasticsearch服务。
验证访问
执行curl http://localhost:9200来查看服务是否正常。如果产生类似如下的输入，则表示正常：
{
“name” : “master”,
“clust[……]
「Elasticsearch」- “Hot-Warm” Architecture
内容简介
当使用Elasticsearch做为“大时间”的数据分析的时候，建议使用时间作为索引，并设置三种不同类型的节点（主、热、温），也就是我们说的「Hot-Warm」架构。
本文介绍了「Hot-Warm」架构的一些基本概念、要注意的一些问题、如何搭建集群。
节点类型
每个节点都有他们自己的作用，下面将会进行介绍每个节点的作用。
# 主节点（Master Nodes）
作用：专用的Master节点负责处理集群的管理和状态，以提供集群的稳定性。
配置：在集群中，设置三个专用的Master节点，以提供最大的弹性。在专用的Master节点中，不会保存参与搜索的数据，也不会进行文档索引。因此也不会有很长时间的GC停顿，而且对CPU、RAM、DISK等资源的要求也低于其他数据节点。
要配置discovery.zen.minimum_master_nodes=2选项以防止集群脑裂。
# 热节点（Hot Nodes）
作用：专用的数据节点，复制执行群集中的所有数据的索引。它们也拥有最新的索引，并且这些索引通常是查询频率最高的。
配置：由于索引是CPU和IO密集型操作，因此这些服务器需要较高的配置，并且需要连接SSD存储。建议至少运行三个热节点，以实现高可用性。根据数据量的要求，可能需要增加数量来实现某些性能目标。
# 温节点（Warm Nodes）
作用：这种类型的节点旨在处理大量不经常查询的只读索引。由于这些索引是只读的，因此节点倾向于使用大容量磁盘，机械盘即可。
配置：与热节点一样，建议至少使用3个温节点以实现高可用性。需要注意的是，和以前一样，如果数据量较大可能需要额外的节点来满足性能要求。另外CPU和内存配置通常需要与热节点的配置相同。具体的配置只能通过模拟在生产环境中吞吐的来确定。
搭建概述
# 节点区分
首先，要有办法区分三种类型的节点，以告诉Elasticsearch在那个节点上分配索引。这可以通过为节点设置属性：
# in elasticsearch.yml
node.attr.box_type: hot
# in elasticsearch.yml
node.attr.box_type: warm
其中的box_type是自定义的属性，完全可以使用自己喜欢的名字。
因此，如果希望某个索引分配到热节点，可以在创建索引时指定标签：
PUT /logs_2016-12-26
{
“settings”: {
“index.routing.allocation.require.box_type”: “hot”
}
}
# 索引配置
如果使用logstash或beats管[……]
「Elasticsearch」- 设置 GC 日志
Elasticsearch Reference [6.3]
Set up Elasticsearch » Important Elasticsearch configuration » GC logging
默认开启，已配置轮转，每个文件最大 64M，总共消耗 2GB 磁盘空间。
参考文献
Elasticsearch Reference [6.3] » Set up Elasticsearch » Important Elasticsearch configuration » GC logging[……]
「Elasticsearch」- 管理与维护
查看当前集群配置
方法一、检查集群配置文件
通过配置文件查看配置信息：/etc/elasticsearch/
潜在问题：某些配置是通过 REST API 修改的，无法在配置文件中体现。
方法二、使用 REST API 查看
# 返回集群全部设置
GET /_cluster/settings?include_defaults=true
修改集群配置
方法一、通过配置文件修改
1）修改 /etc/elasticsearch/ 配置文件 2）重启服务，以使配置生效
方法二、通过 REST API 修改
通过 REST API 修改（持久修改）：
# PUT /_cluster/settings
curl -X PUT \
-H “Content-Type: application/json” \
-d ‘{“persistent” : {“indices.recovery.max_bytes_per_sec” : “40mb”}}’ \
http://127.0.0.1:9200/_cluster/settings
通过 REST API 修改（临时修改）：
# PUT /_cluster/settings
curl -X PUT \
-H “Content-Type: application/json” \
-d ‘{“transient” : {“indices.recovery.max_bytes_per_sec” : “40mb”}}’ \
http://127.0.0.1:9200/_cluster/settings
注意事项： 1）某些属性无法通过 API 修改，在修改这些属性时会返回：not dynamically updateable 2）如果属性不存在，将返回：not recognized
常用操作汇总
# 重命名索引
# https://stackoverflow.com/questions/28626803/how-to-rename-an-index-in-a-cluster
POST /_reindex
{
“source”: {
“index”: “twitter”
},
“dest”: {
“index”: “new_twitter”
}
}
参考文献
How do I POST JSON data with cURL? Elasticsearch Reference [7.7] » REST APIs » Cluster APIs » Cluster update settings API[……]
「Elasticsearch」- 分析器
参考文献
Elasticsearch Reference [6.5] » Analysis
章节列表
「Elasticsearch」- 中文拼音分析器 「Elasticsearch」- 安装中文分析器 「Elasticsearch」- 分词过滤器[……]