- 01_prometheus零基础入门，grafana基础操作，主流exporter采集配置
- 02_prometheus全组件配置使用、底层原理解析、高可用实战
- 03_prometheus-thanos使用和源码解读
- 04_kube-prometheus和prometheus-operator实战和原理介绍
- 05_prometheus源码讲解和二次开发
- 06_prometheus监控k8s的实战配置和原理讲解，写go项目暴露业务指标
- golang基础课程
- golang实战课，一天编写一个任务执行系统，客户端和服务端架构
- golang运维开发项目之k8s网络探测实战
- golang运维平台实战，服务树,日志监控，任务执行，分布式探测
- golang运维开发实战课程之k8s巡检平台
| 学习方向 | 分析进阶视频 | 教程地址 | 备注 |
|---|---|---|---|
| 01_k8s零基础入门实战 | 地址 | 地址 | |
| 02_k8s纯源码解读课程，助力你变成k8s专家 | 地址 | 地址 | |
| 03_k8s底层原理和源码讲解之精华篇 | 地址 | 地址 | |
| 04_k8s底层原理和源码讲解之进阶篇 | 地址 | 地址 |
- k8s零基础买这个课，只需有linux基础就能学。玩转k8s集群常用的监控/日志/控制台等组件 https://ke.qq.com/course/5829699
- k8s中的prometheus监控实战和底层原理讲解 https://ke.qq.com/course/5837369
- k8s源码解读看这3个课，合在一起是个大课，没有顺序
- https://ke.qq.com/course/4697341
- https://ke.qq.com/course/4093533
- https://ke.qq.com/course/4236389
- 偏k8s二次开发 k8s-operator和crd实战开发 https://ke.qq.com/course/5458555
- k8s运维大师课程是 真实高并发k8s集群调优，疑难杂症解决和一些工具的开发 https://ke.qq.com/course/5586848
- k8s二次开发之基于真实负载的调度器 https://ke.qq.com/course/5814034
| 学习方向 | 分析进阶视频 | 教程地址 | 备注 |
|---|---|---|---|
| 01_k8s运维大师课程 | 地址 | 地址 | |
| 02_k8s-operator和crd实战开发 助你成为k8s专家 | 地址 | 地址 | |
| 02_k8s二次开发之基于真实负载的调度器 | 地址 | 地址 |
| 学习方向 | 分析进阶视频 | 教程地址 | 备注 |
|---|---|---|---|
| 01_prometheus零基础入门，grafana基础操作，主流exporter采集配置 | 地址 | 地址 | |
| 02_prometheus全组件配置使用、底层原理解析、高可用实战 | 地址 | 地址 | |
| 03_kube-prometheus和prometheus-operator实战和原理介绍 | 地址 | 地址 | |
| 04_prometheus-thanos使用和源码解读 | 地址 | 地址 | |
| 05_prometheus源码讲解和二次开发 | 地址 | 地址 |
| 学习方向 | 分析进阶视频 | 教程地址 | 备注 |
|---|---|---|---|
| 01_golang基础课程 | 地址 | 地址 | |
| 02_golang运维平台实战，服务树,日志监控，任务执行，分布式探测 | 地址 | 地址 | |
| 03_golang运维开发实战课程之k8s巡检平台] | 地址 | 地址 |
| 学习方向 | 分析进阶视频 | 教程地址 | 备注 |
|---|---|---|---|
| 01_tekton全流水线实战和pipeline运行原理源码解读 | 地址 | 地址 |
- 白嫖当然没关系，我已经贡献了很多文章和开源项目，当然还有免费的视频
- 但是客观的讲，如果你能力超强是可以一直白嫖的，可以看源码。什么问题都可以解决
- 看似免费的资料很多，但大部分都是边角料，核心的东西不会免费，更不会有大神给你答疑
- thanos和kube-prometheus如果你对prometheus源码把控很好的话，再加上k8s知识的话就觉得不难了
- 没有使用grouping对应的接口uri为
http://pushgateway_addr/metrics/job/<JOB_NAME>
- 使用grouping对应的接口uri为
http://pushgateway_addr/metrics/job/<JOB_NAME>/<LABEL_NAME>/<LABEL_VALUE>
- put/post方法区别在于 put只替换metrics和job相同的 post替换label全部相同的
- lb后面rr轮询:如果不加控制的让push数据随机打到多个pushgateway实例上,prometheus无差别scrape会导致数据错乱,表现如下
- 根本原因是在t1时刻 指标的值为10 t2时刻 值为20
- t1时刻轮询打点到了pgw-a上 t2时刻打点到了pgw-b上
- 而promethues采集的时候两边全都采集导致本应该一直上升的值呈锯齿状
- 假设有3个pgw,前面lb根据request_uri做一致性哈希
- promethues scrape时静态配置3个pgw实例
- job_name: pushgateway
honor_labels: true
honor_timestamps: true
scrape_interval: 5s
scrape_timeout: 4s
metrics_path: /metrics
scheme: http
static_configs:
- targets:
- pgw-a:9091
- pgw-b:9091
- 结果是可以做到哈希分流,但无法解决某个pgw实例挂掉,哈希到这个实例上面的请求失败问题
- dynamic-sharding服务启动会根据配置文件注册pgw服务到consul中
- 由consul定时对pgw server做http check
- push请求会根据请求path做一致性哈希分离,eg:
# 仅job不同
- http://pushgateway_addr/metrics/job/job_a
- http://pushgateway_addr/metrics/job/job_b
- http://pushgateway_addr/metrics/job/job_c
# label不同
- http://pushgateway_addr/metrics/job/job_a/tag_a/value_a
- http://pushgateway_addr/metrics/job/job_a/tag_a/value_b
- 当多个pgw中实例oom或异常重启,consul check service会将bad实例标记为down
- dynamic-sharding轮询检查实例数量变化 - dynamic-sharding 会
Watchpgw节点数量变化 - 重新生成哈希环,rehash将job分流
- 同时promethues使用consul服务发现的pgw实例列表,无需手动变更
- 采用redirect而不处理请求,简单高效
- dynamic-sharding本身无状态,可启动多个实例作为流量接入层和pgw server之间
- 扩容时同时也需要重启所有存量pgw服务
- 不足:没有解决promethues单点问题和分片问题 项目地址: https://github.com/ning1875/dynamic-sharding
编译或下载
# 编译build
$ git clone https://github.com/ning1875/dynamic-sharding.git
$ cd dynamic-sharding && make
# 下载 ：releases中直接下载tag包
# 如https://github.com/ning1875/dynamic-sharding/releases/download/v2.0/dynamic-sharding-2.0.linux-amd64.tar.gz修改配置
# 修改配置文件
# 补充dynamic-sharding.yml中的信息:启动dynamic-sharding服务
./dynamic-sharding --config.file=dynamic-sharding.yml和promtheus集成 Add the following text to your promtheus.yaml's scrape_configs section
scrape_configs:
- job_name: pushgateway
consul_sd_configs:
- server: $cousul_api
services:
- pushgateway
relabel_configs:
- source_labels: ["__meta_consul_dc"]
target_label: "dc"
调用方调用 dynamic-sharding接口即可 eg: http://localhost:9292/
eg: 启动了4个pgw实例,其中一个宕机了,则流量从4->3,以此类推
eg: 启动了4个pgw实例,其中一个宕机了,过一会儿恢复了,那么它会被consul unregister掉 避免出现和扩容一样的case: 再次rehash的job 会持续在原有pgw被prome scrap，而且value不会更新
修改yml配置文件将pgw servers 调整到扩容后的数量,重启服务dynamic-sharding 注意 同时也要重启所有存量pgw服务,不然rehash的job 会持续在原有pgw被prome scrap，而且value不会更新
# 方法一
## 调用cousul api
curl -vvv --request PUT 'http://$cousul_api/v1/agent/service/deregister/$pgw_addr_$pgw_port'
eg: curl -vvv --request PUT 'http://localhost:8500/v1/agent/service/deregister/1.1.1.1_9091'
## 修改yml配置文件将pgw servers 调整到缩容后的数量，避免服务重启时再次注册缩容节点
# 方法二
## 停止缩容节点服务,consul会将服务踢出,然后再注销
- 查看代码得知python sdk在构造pgw实例时使用默认的handler方法，而其没有
follow_redirect导致的
def push_to_gateway(gateway, job, registry, grouping_key=None, timeout=30,handler=default_handler):- 使用requests库自定义一个handler，初始化的时候指定
def custom_handle(url, method, timeout, headers, data):
def handle():
h = {}
for k, v in headers:
h[k] = v
if method == 'PUT':
resp = requests.put(url, data=data, headers=h, timeout=timeout)
elif method == 'POST':
resp = requests.post(url, data=data, headers=h, timeout=timeout)
elif method == 'DELETE':
resp = requests.delete(url, data=data, headers=h, timeout=timeout)
else:
return
if resp.status_code >= 400:
raise IOError("error talking to pushgateway: {0} {1}".format(resp.status_code, resp.text))
return handle
# push_to_gateway(push_addr, job='some_job', registry=r1, handler=custom_handle)