k8s1.28.8版本配置prometheus监控告警

2024-03-29 20:52
文章标签 配置 云原生 版本 k8s 监控 prometheus 告警 1.28

本文主要是介绍k8s1.28.8版本配置prometheus监控告警，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

          • 官方架构图
          • 组件的具体介绍
          • kube-prometheus包含的组件
            • 简介：
            • 文件存储路径：
        • 结构分析
          • 官网自带的一些规则
            • 自己总结流程
    • 1-创建规则
          • 磁盘使用率报警规则
      • 详解上面rule流程
        • Alertmanagerg查看
    • 2-报警接收器
        • 2.1-邮件报警
          • 修改Alertmanager配置
          • 查看现有的secret alertmanager-main
          • 源配置文件
          • 修改 secret alertmanager-main
          • 参数详解
        • 总结
          • 查看生成的 secret alertmanager-main
    • 3-AlertmanagerConfig 配置
          • 3.1-创建alertmanagerconfig.yaml 邮件版本
          • 3.2-修改alertmanager-alertmanager.yaml
    • 4-告警模板
        • 4.1-Alertmanager CRD 支持 `configMaps` 参数, 会自动挂载到 `/etc/alertmanager/configmaps` 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl
        • 4.2-创建 configmap
        • 4.3-更新 Alertmanager 示例, 添加 configmap
        • 4.4-修改 AlertmanagerConfig 配置文件, 指定模板文件
    • 企业微信报警
        • 1告警规则这个自定义的有点长，我后面单独发一篇博客
        • 2-修改Alertmanager配置
        • 3-AlertmanagerConfig 配置
        • 企业微信告警模板
    • 什么是热更新
      • 怎么热更新
        • 查看prometheus的pod的ip地址

参考文档 

[Kubernetes集群监控-使用Alertmanager报警配置-腾讯云开发者社区-腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/2377069)
官方架构图

上图是`Prometheus-Operator`官方提供的架构图，其中`Operator`是最核心的部分，作为一个控制器，他会去创建`Prometheus`、`ServiceMonitor`、`AlertManager`以及`PrometheusRule`4个`CRD`资源对象，然后会一直监控并维持这4个资源对象的状态。其中创建的`prometheus`这种资源对象就是作为`Prometheus Server`存在，而`ServiceMonitor`就是`exporter`的各种抽象，是用来提供专门提供`metrics`数据接口的工具，`Prometheus`就是通过`ServiceMonitor`提供的`metrics`数据接口去 pull 数据的，当然`alertmanager`这种资源对象就是对应的`AlertManager`的抽象，而`PrometheusRule`是用来被`Prometheus`实例使用的报警规则文件。这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的资源对象了，是不是方便很多了。上图中的 Service 和 ServiceMonitor 都是 Kubernetes 的资源，一个 ServiceMonitor 可以通过 labelSelector 的方式去匹配一类 Service，Prometheus 也可以通过 labelSelector 去匹配多个ServiceMonitor。
组件的具体介绍
  • Operator： Operator 资源会根据自定义资源（Custom Resource Definition / CRDs）来部署和管理 Prometheus Server，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。
  • Prometheus： Prometheus 资源是声明性地描述 Prometheus 部署的期望状态。
  • Prometheus Server： Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server 集群，这些自定义资源可以看作是用来管理 Prometheus Server 集群的 StatefulSets 资源。
  • ServiceMonitor： ServiceMonitor 也是一个自定义资源，它描述了一组被 Prometheus 监控的 targets 列表。该资源通过 Labels 来选取对应的 Service Endpoint，让 Prometheus Server 通过选取的 Service 来获取 Metrics 信息。
  • Service： Service 资源主要用来对应 Kubernetes 集群中的 Metrics Server Pod，来提供给 ServiceMonitor 选取让 Prometheus Server 来获取信息。简单的说就是 Prometheus 监控的对象，例如 Node Exporter Service、Mysql Exporter Service 等等。
  • Alertmanager： Alertmanager 也是一个自定义资源类型，由 Operator 根据资源描述内容来部署 Alertmanager 集群。
kube-prometheus包含的组件
  • Prometheus Operator
  • 高可用的 Prometheus 默认会部署2个pod
  • 高可用的 Alertmanager
  • Prometheus node-exporter
  • Prometheus Adapter for Kubernetes Metrics APIs
  • kube-state-metrics
  • Grafana
简介：
这个kube-prometheus目前应该是开源最好的方案了，该存储库收集Kubernetes清单，Grafana仪表板和Prometheus规则，以及文档和脚本，以使用Prometheus Operator 通过Prometheus提供易于操作的端到端Kubernetes集群监视。以容器的方式部署到k8s集群，而且还可以自定义配置，非常的方便
文件存储路径：
prometheus的监控规则文件在prometheus Pod中的路径：/etc/prometheus/rules/prometheus-prometheus-kube-prometheus-prometheus-rulefiles-0/而这些文件都是通过一个叫PrometheusRule的k8s资源生成的，PrometheusRule用于配置Promtheus的 Rule 规则文件，包括 recording rules 和 alerting，可以自动被 Prometheus 加载。至于为什么 Prometheus 能够识别这个 PrometheusRule 资源对象呢？这就需要查看我们创建的 prometheus 这个资源对象了，里面有非常重要的一个属性 ruleSelector，用来匹配 rule 规则的过滤器，我们这里没有过滤，所以可以匹配所有的，假设要求匹配具有 prometheus=k8s 和 role=alert-rules 标签的 PrometheusRule 资源对象
结构分析
alertmanager-secret.yaml  # 告警配置
prometheus-prometheus.yaml　　# 监控配置
prometheusOperator-prometheusRule.yaml  # 默认监控项
官网自带的一些规则

如果这里你接上告警，他默认的一些配置会一直发消息

alertmanager-prometheusRule.yaml    
kubePrometheus-prometheusRule.yaml
kubernetesControlPlane-prometheusRule.yaml  #禁用了我先
kubeStateMetrics-prometheusRule.yaml
nodeExporter-prometheusRule.yaml
prometheusOperator-prometheusRule.yaml
prometheus-prometheusRule.yaml

image.png

自己总结流程
1-创建规则*.rules.yaml,他会自己引用到规则里面
2-报警接收器，先定义Alertmanager文件，然后kubectl create 创建成新的yaml，更新引用
3-创建AlertmanagerConfig，定义告警接收模板，预留标签
4-更新alertmanager-alertmanager.yaml，添加模板绑定标签
5-告警模板，创建*.tmpl模板，更新alertmanager-alertmanager.yaml添加configmap，修改 AlertmanagerConfig 配置文件, 指定模板文件

1-创建规则

磁盘使用率报警规则

当磁盘可用空间少于 50% 时触发告警，如果需要添加其他规则也是创建*.rules.yaml
创建 prometheus-rules.yaml，

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:name: demonamespace: monitoring
spec:groups:- name: demorules:- alert: nodeDiskUsageannotations:description: |节点 {{$labels.instance }}挂载目录 {{ $labels.mountpoint }}当前可用空间 {{ printf "%.2f" $value }}%          summary: |挂载目录可用空间低于 50%expr: |node_filesystem_avail_bytes{fstype!="",job="node-exporter"} /node_filesystem_size_bytes{fstype!="",job="node-exporter"} * 100 < 50        for: 1mlabels:severity: warning

查看生成的告警规则, 当前状态是 pending ，我们设置了 1m 的评估等待时间。一分钟过后进入 firing 状态, 正式发出告警, 此时我们设置的 $label 还没有解析。

image.png

去 Alertmanager 看一下, 成功收到了告警, 且 labels和value 也已经正常解析了
image.png

详解上面rule流程

对于 prometheusrule 的更新操作 (create, delete, update) 都会被 watch 到, 然后更新到统一的一个 configmap 中, 然后 prometheus 自动重载配置
每个 prometheusrule 会作为 configmap prometheus-k8s-rulefiles-0 中的一个 data , data 的命名规则为 <namespace>-<rulename>-ruleuid

root@k8s-master01:~# kubectl get cm prometheus-k8s-rulefiles-0 -n monitoring
NAME                         DATA   AGE
prometheus-k8s-rulefiles-0   7      9m25s# prometheus 实例的挂载信息
root@k8s-master01:~# kubectl get pod prometheus-k8s-0 -n monitoring -o jsonpath='{.spec.volumes[?(@.name=="prometheus-k8s-rulefiles-0")]}' | python3 -m json.tool
{"configMap": {"defaultMode": 420,"name": "prometheus-k8s-rulefiles-0"},"name": "prometheus-k8s-rulefiles-0"
}# prometheus 中实际的存储路径
root@k8s-master01:~# kubectl exec -it prometheus-k8s-0 -n monitoring -- ls /etc/prometheus/rules/prometheus-k8s-rulefiles-0/
monitoring-alertmanager-main-rules-3ebc6559-253d-4f65-9270-f0bf3193d640.yaml
monitoring-grafana-rules-a36dde23-2c31-487e-a115-5cec930163c2.yaml
monitoring-k8s-rules-c102dd2a-580e-4f86-b388-eb51953ada9e.yaml
monitoring-kube-prometheus-rules-a4aeb093-9683-45a2-900e-24de81d551f6.yaml
monitoring-kube-state-metrics-rules-b3f61676-d442-4b7b-bf66-421f710687a7.yaml
monitoring-node-exporter-rules-d6c9d3ba-c1cd-4767-8ccf-ce29a3c67e36.yaml
monitoring-prometheus-operator-rules-3560e71d-f6de-40a6-99df-d0daac87cfb5.yaml

image.png

Alertmanagerg查看

只有当我们设置的规则被触发了我们这边查看才会显示
image.png

image.png

2-报警接收器

Alertmanager 支持很多内置的报警接收器，如 email、slack、企业微信、webhook 等。

2.1-邮件报警
修改Alertmanager配置

vim alertmanager.yaml # 新建的一个yaml

global:resolve_timeout: 5msmtp_from: '0@163.com'smtp_smarthost: 'smtp.163.com:25'smtp_auth_username: '@163.com'smtp_auth_password: 'password'smtp_require_tls: falsesmtp_hello: '163.com'
templates:- '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'
route:receiver: Defaultgroup_by: ['alertname', 'cluster']continue: falsegroup_wait: 30sgroup_interval: 5mrepeat_interval: 12h
receivers:
- name: Defaultemail_configs:- to: '@boysec.cn'send_resolved: true
查看现有的secret alertmanager-main

默认的我们可以看到是没有配置接收器以及告警人

kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d

image.png

源配置文件

image.png

image.png

修改 secret alertmanager-main
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yamlkubectl apply -f alertmanager-main-secret.yaml
参数详解
- `kubectl create secret generic`: 这是创建一个通用类型的Secret的命令，它可以用于存储任何类型的敏感数据。
- `alertmanager-main`: 这是要创建的Secret的名称，这里命名为 `alertmanager-main`。
- `-n monitoring`: `-n` 参数用于指定命名空间，这里将Secret创建在名为 `monitoring` 的命名空间中。
- `--from-file=alertmanager.yaml`: `--from-file` 参数指定了要从文件中读取数据并将其存储在Secret中。在这里，`alertmanager.yaml` 文件中的内容将作为Secret的数据。
- `--dry-run=client`: 这个选项告诉 `kubectl` 仅模拟执行，而不会实际执行创建操作。这样可以将生成的YAML文件输出到标准输出，而不会真正创建Secret。
- `-o yaml`: `-o` 参数指定输出格式，这里指定为YAML格式。
- `> alertmanager-main-secret.yaml`: 将生成的YAML输出重定向到名为 `alertmanager-main-secret.yaml` 的文件中，以供后续使用
总结
#个人总结就是 创建alertmanager.yaml文件的secret，然后导出成新的yaml，类似configmap。然后再去执行新生成的yaml文件，他就会挂载进pod里面
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yaml
查看生成的 secret alertmanager-main

配置文件里面的模板就变成你改的模板了

kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d

3-AlertmanagerConfig 配置

新建一个 AlertmanagerConfig 类型的资源对象，可以通过 kubectl explain AlertmanagerConfig 或者在线 API 文档来查看字段的含义

3.1-创建alertmanagerconfig.yaml 邮件版本

这个是需要我们创建的，然后修改主alertmanager.yaml，对应标签

# vim alertmanagerconfig.yaml
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: wangxiansen #这里标签注意等下要用
spec:route:groupBy: ['alertname']groupWait: 30sgroupInterval: 5mrepeatInterval: 12hreceiver: 'Critical'continue: falseroutes:- receiver: 'Critical'match:severity: criticalreceivers:- name: CriticalemailConfigs:- to: '@boysec.cn'sendResolved: truewebhookConfigs:- url: http://dingtalksendResolved: true

不过如果直接创建上面的配置是不会生效的，我们需要添加一个 Label 标签，并在 Alertmanager 的资源对象中通过标签来关联上面的这个对象，比如我们这里新增了一个 Label 标签：alertmanagerConfig: wangxiansen，然后需要重新更新 Alertmanager 对象，添加 alertmanagerConfigSelector 属性去匹配 AlertmanagerConfig 资源对象

3.2-修改alertmanager-alertmanager.yaml

我的这个主配置文件路径在kube-prometheus-0.13.0/manifests

# vim alertmanager-alertmanager.yaml
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:labels:app.kubernetes.io/component: alert-routerapp.kubernetes.io/instance: mainapp.kubernetes.io/name: alertmanagerapp.kubernetes.io/part-of: kube-prometheusapp.kubernetes.io/version: 0.26.0name: mainnamespace: monitoring
spec:image: quay.io/prometheus/alertmanager:v0.26.0nodeSelector:kubernetes.io/os: linuxpodMetadata:labels:app.kubernetes.io/component: alert-routerapp.kubernetes.io/instance: mainapp.kubernetes.io/name: alertmanagerapp.kubernetes.io/part-of: kube-prometheusapp.kubernetes.io/version: 0.26.0replicas: 1                 # 资源问题，这里就先启动一个podsresources:limits:cpu: 100mmemory: 100Mirequests:cpu: 4mmemory: 100Misecrets: []alertmanagerConfigSelector: # 匹配 AlertmanagerConfig 的标签matchLabels:alertmanagerConfig: wangxiansen  # 这个是上面要记得标签securityContext:fsGroup: 2000runAsNonRoot: truerunAsUser: 1000serviceAccountName: alertmanager-mainversion: 0.26.0

image.png

4-告警模板

Alertmanager 收到的告警大概长这个样子
image.png

4.1-Alertmanager CRD 支持 configMaps 参数, 会自动挂载到 /etc/alertmanager/configmaps 目录, 我们可以将模板文件配置成 configmap，创建模板文件 email.tmpl

vim email.tmpl

{{ define "email.html" }}
<html><body>{{- if gt (len .Alerts.Firing) 0 -}}{{- range $index, $alert := .Alerts -}}<p>========= ERROR ==========</p><h3 style="color:red;">告警名称: {{ .Labels.alertname }}</h3><p>告警级别: {{ .Labels.severity }}</p><p>告警机器: {{ .Labels.instance }} {{ .Labels.device }}</p><p>告警详情: {{ .Annotations.summary }}</p><p>告警时间: {{ time (unixMillis .StartsAt) "2006-01-02 15:04:05" }}</p><p>========= END ==========</p>{{- end }}{{- end }}{{- if gt (len .Alerts.Resolved) 0 -}}{{- range $index, $alert := .Alerts -}}<p>========= INFO ==========</p><h3 style="color:green;">告警名称: {{ .Labels.alertname }}</h3><p>告警级别: {{ .Labels.severity }}</p><p>告警机器: {{ .Labels.instance }}</p><p>告警详情: {{ .Annotations.summary }}</p><p>告警时间: {{ time (unixMillis .StartsAt) "2006-01-02 15:04:05" }}</p><p>恢复时间: {{ time (unixMillis .EndsAt) "2006-01-02 15:04:05" }}</p><p>========= END ==========</p>{{- end }}{{- end }}</body>
</html>
{{- end }}
4.2-创建 configmap
kubectl create configmap alertmanager-templates --from-file=email.tmpl --dry-run=client -o yaml -n monitoring > alertmanager-configmap-templates.yaml kubectl apply -f alertmanager-configmap-templates.yaml
4.3-更新 Alertmanager 示例, 添加 configmap

vim alertmanager-alertmanager.yaml

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
spec:
.....alertmanagerConfigSelector:matchLabels:alertmanager: mainconfigMaps:- alertmanager-templates

image.png

4.4-修改 AlertmanagerConfig 配置文件, 指定模板文件
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: wangxiansen
spec:route:groupBy: ['alertname']groupWait: 30sgroupInterval: 5mrepeatInterval: 12hreceiver: 'Critical'continue: falseroutes:- receiver: 'Critical'match:severity: criticalreceivers:- name: CriticalemailConfigs:- to: 'xxxxx@boysec.cn'html: '{{ template "email.html" . }}'          # 添加 与模板中的 define 对应sendResolved: true

更新报警配置

kubectl apply -f alertmanagerconfig.yaml

查看新生成的告警邮件

image.png

企业微信报警

1告警规则这个自定义的有点长，我后面单独发一篇博客
2-修改Alertmanager配置

vim alertmanager.yaml # 新建的一个yaml

    global:resolve_timeout: 1msmtp_smarthost: 'smtp.163.com:25'smtp_from: ''smtp_auth_username: ''smtp_auth_password: ''smtp_require_tls: falseroute:group_by: [alertname]group_wait: 10sgroup_interval: 10srepeat_interval: 10mreceiver: wechat-001receivers:- name: 'wechat-001'wechat_configs:- corp_id: xxxx # 企业IDto_user: '@all'             # 发送所有人agent_id: xxxx          # agentIDapi_secret:  # secret

步骤跟邮件告警一样，参考上面

3-AlertmanagerConfig 配置
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:name: email-confignamespace: monitoringlabels:alertmanagerConfig: aike  # 标识此配置对象的标签，用于分类和识别
spec:route:  # 警报路由配置groupBy: ['alertname']  # 根据警报名称分组groupWait: 30s  # 组等待时间groupInterval: 5m  # 组间隔时间repeatInterval: 12h  # 重复间隔时间receiver: 'Critical'  # 默认接收器continue: false  # 是否继续路由routes:- receiver: 'Critical'match:severity: critical  # 匹配严重程度为 critical 的警报receivers:  # 接收器配置- name: Critical  # 接收器名称emailConfigs:  # 邮件配置，用于发送邮件通知- to: ''  # 接收邮件的邮箱地址html: '{{ template "email.html" . }}'  # 添加 与模板中的 define 对应sendResolved: true  # 发送解决警报的通知webhookConfigs:  # Webhook 配置，用于发送警报通知至钉企业微信- url:   # Webhook URLsendResolved: true  # 发送解决警报的通知

修改alertmanager-alertmanager.yaml
步骤一样 省略

企业微信告警模板
{{ define "email.html" }}
<html><body>{{- if gt (len .Alerts.Firing) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}<p>========= xxx环境监控报警 =========</p><p>告警状态：{{ .Status }}</p><p>告警级别：{{ .Labels.severity }}</p><p>告警类型：{{ $alert.Labels.alertname }}</p><p>故障主机: {{ $alert.Labels.instance }} {{ $alert.Labels.pod }}</p><p>告警主题: {{ $alert.Annotations.summary }}</p><p>告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }}</p><p>触发阀值：{{ .Annotations.value }}</p><p>故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p><p>========= end =========</p>{{- end }}{{- end }}{{- end }}{{- if gt (len .Alerts.Resolved) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}<p>========= xxx环境异常恢复 =========</p><p>告警类型：{{ .Labels.alertname }}</p><p>告警状态：{{ .Status }}</p><p>告警主题: {{ $alert.Annotations.summary }}</p><p>告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description }}</p><p>故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p><p>恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}</p>{{- if gt (len $alert.Labels.instance) 0 }}<p>实例信息: {{ $alert.Labels.instance }}</p>{{- end }}<p>========= end =========</p>{{- end }}{{- end }}{{- end }}</body>
</html>
{{- end }}

流程大概就是这样。。。。
然后进行一下热更新

什么是热更新

为了每次修改配置文件可以热加载prometheus，也就是不停止prometheus，就可以使配置生效

怎么热更新

举例：如修改prometheus-cfg.yaml，想要使配置生效可如下操作

# 修改prometheus-cfg.yaml后
kubectl delete -f /root/k8s/monitor/prometheus-cfg.yaml 
kubectl apply -f  /root/k8s/monitor/prometheus-cfg.yaml # 告诉prometheus-deploy.yaml 需要重新加载 prometheus-cfg.yaml文件的内容
curl -X POST http://10.244.1.52:9090/-/reload
查看prometheus的pod的ip地址
kubectl get pods -n monitoring -o wide | grep prometheus

这篇关于k8s1.28.8版本配置prometheus监控告警的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/859615。

相关文章

使用Python实现IP地址和端口状态检测与监控

使用Python实现IP地址和端口状态检测与监控

《使用Python实现IP地址和端口状态检测与监控》在网络运维和服务器管理中,IP地址和端口的可用性监控是保障业务连续性的基础需求,本文将带你用Python从零打造一个高可用IP监控系统,感兴趣的小伙... 目录概述：为什么需要IP监控系统使用步骤说明1. 环境准备2. 系统部署3. 核心功能配置系统效果展
阅读更多...
SpringBoot3.4配置校验新特性的用法详解

SpringBoot3.4配置校验新特性的用法详解

《SpringBoot3.4配置校验新特性的用法详解》SpringBoot3.4对配置校验支持进行了全面升级,这篇文章为大家详细介绍了一下它们的具体使用,文中的示例代码讲解详细,感兴趣的小伙伴可以参考... 目录基本用法示例定义配置类配置 application.yml注入使用嵌套对象与集合元素深度校验开发
阅读更多...
IntelliJ IDEA 中配置 Spring MVC 环境的详细步骤及问题解决

IntelliJ IDEA 中配置 Spring MVC 环境的详细步骤及问题解决

《IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决》：本文主要介绍IntelliJIDEA中配置SpringMVC环境的详细步骤及问题解决,本文分步骤结合实例给大... 目录步骤 1：创建 Maven Web 项目步骤 2：添加 Spring MVC 依赖1、保存后执行2、将新的依赖
阅读更多...
SpringBoot基于配置实现短信服务策略的动态切换

SpringBoot基于配置实现短信服务策略的动态切换

《SpringBoot基于配置实现短信服务策略的动态切换》这篇文章主要为大家详细介绍了SpringBoot在接入多个短信服务商（如阿里云、腾讯云、华为云）后,如何根据配置或环境切换使用不同的服务商,需... 目录目标功能示例配置（application.yml）配置类绑定短信发送策略接口示例：阿里云 & 腾
阅读更多...
如何为Yarn配置国内源的详细教程

如何为Yarn配置国内源的详细教程

《如何为Yarn配置国内源的详细教程》在使用Yarn进行项目开发时,由于网络原因,直接使用官方源可能会导致下载速度慢或连接失败,配置国内源可以显著提高包的下载速度和稳定性,本文将详细介绍如何为Yarn... 目录一、查询当前使用的镜像源二、设置国内源1. 设置为淘宝镜像源2. 设置为其他国内源三、还原为官方
阅读更多...
CentOS7更改默认SSH端口与配置指南

CentOS7更改默认SSH端口与配置指南

《CentOS7更改默认SSH端口与配置指南》SSH是Linux服务器远程管理的核心工具,其默认监听端口为22,由于端口22众所周知,这也使得服务器容易受到自动化扫描和暴力破解攻击,本文将系统性地介绍... 目录引言为什么要更改 SSH 默认端口？步骤详解：如何更改 Centos 7 的 SSH 默认端口1
阅读更多...
Maven的使用和配置国内源的保姆级教程

Maven的使用和配置国内源的保姆级教程

《Maven的使用和配置国内源的保姆级教程》Maven是⼀个项目管理工具,基于POM(ProjectObjectModel,项目对象模型)的概念,Maven可以通过一小段描述信息来管理项目的构建,报告... 目录1. 什么是Maven?2.创建⼀个Maven项目3.Maven 核心功能4.使用Maven H
阅读更多...
SpringBoot多数据源配置完整指南

SpringBoot多数据源配置完整指南

《SpringBoot多数据源配置完整指南》在复杂的企业应用中,经常需要连接多个数据库,SpringBoot提供了灵活的多数据源配置方式,以下是详细的实现方案,需要的朋友可以参考下... 目录一、基础多数据源配置1. 添加依赖2. 配置多个数据源3. 配置数据源Bean二、JPA多数据源配置1. 配置主数据
阅读更多...
Spring 基于XML配置 bean管理 Bean-IOC的方法

Spring 基于XML配置 bean管理 Bean-IOC的方法

《Spring基于XML配置bean管理Bean-IOC的方法》：本文主要介绍Spring基于XML配置bean管理Bean-IOC的方法,本文给大家介绍的非常详细,对大家的学习或工作具有一... 目录一. spring学习的核心内容二. 基于 XML 配置 bean1. 通过类型来获取 bean2. 通过
阅读更多...
如何使用Nginx配置将80端口重定向到443端口

如何使用Nginx配置将80端口重定向到443端口

《如何使用Nginx配置将80端口重定向到443端口》这篇文章主要为大家详细介绍了如何将Nginx配置为将HTTP（80端口）请求重定向到HTTPS（443端口）,文中的示例代码讲解详细,有需要的小伙... 目录1. 创建或编辑Nginx配置文件2. 配置HTTP重定向到HTTPS3. 配置HTTPS服务器
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2