AlertManager简介与使用

目录
  • 一、AlertManager简介
    • AlertManager 常用的功能
    • Prometheus 和 AlertManager 的关系
  • 二、分组、抑制、静默
    • 分组
    • 抑制
    • 静默
  • 三、Alertmanager部署
    • 基于k8s部署
      • PVC资源 alertmanager-storage.yaml
      • ConfigMap（邮件方式）
      • deploy.yaml
      • 创建svc.yaml
      • ingress.yaml
  • 四、Prometheus添加告警配置
    • k8s部署添加
      • 修改 prometheus-config.yaml
      • 查看
  • 五、Alertmanager配置解析
    • 全局配置
    • 模板
    • 告警路由
    • 接收者
    • 抑制规则
    • 测试告警规则

一、AlertManager简介

AlertManager 常用的功能

  • 抑制：指的是当某一告警信息发送后，可以停止由此告警引发的其它告警，避免相同的告警信息重复发送。
  • 静默：静默也是一种机制，指的是依据设置的标签，对告警行为进行静默处理。
  • 发送告警：支持配置多种告警规则，可以根据不同的路由配置，采用不同的告警方式发送告警通知。
  • 告警分组：分组机制可以将详细的告警信息合并成一个通知。

Prometheus 和 AlertManager 的关系

二、分组、抑制、静默

分组

被触发的警报合并为一个警报进行通知，避免瞬间突发性的接受大量警报通知，使得管理员无法对问题进行快速定位。
场景：
在Kubernetes集群中，运行着重量级规模的实例，即便是集群中持续很小一段时间的网络延迟或者延迟导致网络抖动，也会引发大量类似服务应用无法连接 DB 的故障。如果在警报规则中定义每一个应用实例都发送警报，那么到最后的结果就是会有大量的警报信息通过Alertmanager发送给咱们的运维及研发小伙伴。

抑制

Inhibition 是 当某条警报已经发送，停止重复发送由此警报引发的其他异常或故障的警报机制。
场景：
在我们的灾备体系中，当原有集群故障宕机业务彻底无法访问的时候，会把用户流量切换到备份集群中，这样为故障集群及其提供的各个微服务状态发送警报机会失去了意义，此时， Alertmanager 的抑制特性就可以在一定程度上避免管理员收到过多无用的警报通知。

静默

Silences 提供了一个简单的机制，根据标签快速对警报进行静默处理；对传进来的警报进行匹配检查，如果接受到警报符合静默的配置，Alertmanager 则不会发送警报通知。
场景：

  • 用于解决严重生产故障问题时，因所花费的时间过长，通过静默设置避免接收到过多的无用通知；
  • 在已知的例行维护中，为了防止对例行维护的机器发送不必要的警报；

三、Alertmanager部署

基于k8s部署

PVC资源 alertmanager-storage.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: alertmanager-pvcnamespace: monitor
spec:accessModes:- ReadWriteManystorageClassName: "nfs-storage"resources:requests:storage: 5Gi

ConfigMap（邮件方式）

apiVersion: v1
kind: ConfigMap
metadata:name: alertmanager-confignamespace: monitor
data:alertmanager.yml: |-global:resolve_timeout: 1msmtp_smarthost: 'smtp.qq.com:465'     # 邮箱服务器的SMTP主机配置smtp_from: '123@qq.com'    # 发送人smtp_auth_username: '123@qq.com'      # 登录用户名smtp_auth_password: 'XXXX'    # 此处的auth password是邮箱的第三方登录授权密码，而非用户密码smtp_require_tls: false           # 有些邮箱需要开启此配置，这里使用的是企微邮箱，仅做测试，不需要开启此功能。templates:- '/etc/alertmanager/*.tmpl'route:group_by: ['dba','dev','ops','group','job','alertname','cluster']   # 报警分组group_wait: 5s      # 在组内等待所配置的时间，如果同组内，5秒内出现相同报警，在一个组内出现。group_interval: 1m        # 如果组内内容不变化，合并为一条警报信息，2m后发送。repeat_interval: 2m    # 发送报警间隔，如果指定时间内没有修复，则重新发送报警。receiver: 'ops'  #默认接收者routes:#- receiver: 'dba'#  match:#    severity: critical#  group_wait: 5s#  group_interval: 5m#  repeat_interval: 30m- receiver: 'dev'match:severity: criticalalertname: nginx service status is WODNgroup_wait: 5sgroup_interval: 5mrepeat_interval: 30m- receiver: 'ops'match:severity: criticalalertname: EtcdNoLeadergroup_wait: 5sgroup_interval: 5mrepeat_interval: 30mreceivers:- name: 'ops'email_configs:- to: '123@qq.com'send_resolved: truehtml: '{{ template "wechat.default.message" . }}'- name: 'default-receiver'email_configs:- to: '123456789@qq.com'send_resolved: truehtml: '{{ template "email.to.html" . }}'- name: 'dev'email_configs:- to: '123@163.com'send_resolved: truehtml: '{{ template "email.to.html" . }}'inhibit_rules:    # 抑制规则- source_match: alertname: 'node节点挂了'  instance: node13  target_match:project: test-web   #当node节点标签触发时，下面project的标签也就是nginx就会被抑制 - source_match: severity: critical  #当触发告警标签，severity=critical时，触发抑制规则，包含severity=warning的告警将被抑制 target_match:severity: warning   #包含severity=warning的告警将被抑制equal:- project             #还添加了一个equal标签，作用就是source和target中都包含project这个标签，且他们的值一致时，才会抑制，比如nginx端口挂了,监控https的就会被抑制#- source_match:       # 源标签警报触发时抑制含有目标标签的警报，在当前警报匹配 servrity: 'critical'#    severity: 'critical'#  target_match:#    severity: 'warning'    # 目标标签值正则匹配，可以是正则表达式如: ".*MySQL.*"#  equal: ['alertname', 'dev', 'instance']    # 确保这个配置下的标签内容相同才会抑制，也就是说警报中必须有这三个标签值才会被抑制。wechat.tmpl: |-{{ define "wechat.default.message" }}{{- if gt (len .Alerts.Firing) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}========= 监控报警 =========告警状态：{{   .Status }}告警级别：{{ .Labels.severity }}告警类型：{{ $alert.Labels.alertname }}故障主机: {{ $alert.Labels.instance }}告警主题: {{ $alert.Annotations.summary }}告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};触发阀值：{{ .Annotations.value }}故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}========= = end =  ========={{- end }}{{- end }}{{- end }}{{- if gt (len .Alerts.Resolved) 0 -}}{{- range $index, $alert := .Alerts -}}{{- if eq $index 0 }}========= 告警恢复 =========告警类型：{{ .Labels.alertname }}告警状态：{{   .Status }}告警主题: {{ $alert.Annotations.summary }}告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}{{- if gt (len $alert.Labels.instance) 0 }}实例信息: {{ $alert.Labels.instance }}{{- end }}========= = end =  ========={{- end }}{{- end }}{{- end }}{{- end }}email.tmpl: |-{{ define "email.from" }}xxx.com{{ end }}{{ define "email.to" }}xxx.com{{ end }}{{ define "email.to.html" }}{{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}========= 监控报警 =========<br>告警程序: prometheus_alert <br>告警级别: {{ .Labels.severity }} <br>告警类型: {{ .Labels.alertname }} <br>告警主机: {{ .Labels.instance }} <br>告警主题: {{ .Annotations.summary }}  <br>告警详情: {{ .Annotations.description }} <br>#触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} <br>触发时间: {{ .alert.StartsAt.Local  }} <br>========= = end =  =========<br>{{ end }}{{ end -}}{{- if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }}========= 告警恢复 =========<br>告警程序: prometheus_alert <br>告警级别: {{ .Labels.severity }} <br>告警类型: {{ .Labels.alertname }} <br>告警主机: {{ .Labels.instance }} <br>告警主题: {{ .Annotations.summary }} <br>告警详情: {{ .Annotations.description }} <br>触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} <br>恢复时间: {{ .EndsAt.Format "2006-01-02 15:04:05" }} <br>========= = end =  =========<br>{{ end }}{{ end -}}{{- end }}

参数说明：


global:resolve_timeout: 5m    ##超时,默认5minsmtp_smarthost: 'smtp.exmail.qq.com:25'smtp_from: 'xxxxxxx'smtp_auth_username: 'xxxx'smtp_auth_password: '123'smtp_require_tls: falsetemplates:    ##告警模板(可定义多个)- '/etc/alertmanager/*.tmpl'##route:用来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的入口点
##另外，根路由需要配置一个接收器(receiver)，用来处理那些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警），即缺省
##接收器。告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。因为在route中
##continue默认为false，如果continue为true，则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route，则该告警将从其上一级(
##匹配)route或者根route发出（按最后匹配到的规则发出邮件）。查看你的告警路由树，https://www.prometheus.io/webtools/alerting/routing-tree-editor/,
##将alertmanager.yml配置文件复制到对话框，然后点击"Draw Routing Tree"
route:group_by: ['env','instance','type','group','job','alertname','cluster']    ##用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组，然后作为一个通知发送。如果想完全禁用聚合，可以设置为group_by: [...]group_wait: 10s    ##当一个新的告警组被创建时，需要等待'group_wait'后才发送初始通知。这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为一个通知发送group_interval: 2m    ##当第一次告警通知发出后，在新的评估周期内又收到了该分组最新的告警，则需等待'group_interval'时间后，开始发送为该组触发的新告警，可以简单理解为，group就相当于一个通道(channel)repeat_interval: 10m    ##告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔(根据实际情况来调整)receiver: 'email'        ##配置告警消息接收者，与下面配置的对应，例如常用的 email、wechat、slack、webhook 等消息通知方式。routes:    ##子路由- receiver: 'wechat'match:    ##通过标签去匹配这次告警是否符合这个路由节点；也可以使用match_re进行正则匹配severity: error    ##标签severity为error时满足条件使用wechat警报continue: true   ##匹配到这个路由后是否继续匹配，默认flase
receivers:    ##配置报警信息接收者信息
- name: 'email' ##警报接收者名称email_configs:- to: 'xxxxxx'  ##接收警报的email（可引用模板文件中定义的变量）,可定义多个
##    html: '{{ template "email.to.html" .}}' ##发送邮件的内容（调用模板文件中的）helo: 'alertmanager.com' #alertmanager的地址send_resolved: true #故障恢复后通知- name: 'wechat'wechat_configs:- corp_id: xxxxxxxxx    ##企业信息to_user: '@all'        ##发送给企业微信用户的ID，这里是所有人agent_id: xxxxx    ##企业微信AgentIdapi_secret: xxxxxxxxx        ##企业微信Secret 
##    message: '{{ template "wechat.default.message" .}}'    ##发送内容(调用模板里面的微信模板)send_resolved: true         ##故障恢复后通知inhibit_rules:        ##抑制规则配置，当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）- source_match:severity: 'critical'target_match:severity: 'warning'equal: ['alertname', 'dev', 'instance']

deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: alertmanagernamespace: monitorlabels:k8s-app: alertmanager
spec:replicas: 1selector:matchLabels:k8s-app: alertmanagertemplate:metadata:labels:k8s-app: alertmanagerspec:containers:- name: alertmanagerimage: prom/alertmanager:v0.24.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 31093args:## 指定容器中AlertManager配置文件存放地址 (Docker容器中的绝对位置)- "--config.file=/etc/alertmanager/alertmanager.yml"## 指定AlertManager管理界面地址，用于在发生的告警信息中,附加AlertManager告警信息页面地址- "--web.external-url=https://alertmanager.kubernets.cn"  ## 指定监听的地址及端口- '--cluster.advertise-address=0.0.0.0:31093'## 指定数据存储位置 (Docker容器中的绝对位置)- "--storage.path=/alertmanager"resources:limits:cpu: 1000mmemory: 512Mirequests:cpu: 1000mmemory: 512MireadinessProbe:httpGet:path: /-/readyport: 31093initialDelaySeconds: 5timeoutSeconds: 10livenessProbe:httpGet:path: /-/healthyport: 31093initialDelaySeconds: 30timeoutSeconds: 30volumeMounts:- name: datamountPath: /alertmanager - name: configmountPath: /etc/alertmanager- name: configmap-reloadimage: jimmidyson/configmap-reload:v0.7.1args:- "--volume-dir=/etc/config"- "--webhook-url=http://localhost:31093/-/reload"resources:limits:cpu: 100mmemory: 100Mirequests:cpu: 100mmemory: 100MivolumeMounts:- name: configmountPath: /etc/configreadOnly: truevolumes:- name: datapersistentVolumeClaim:claimName: alertmanager-pvc- name: configconfigMap:name: alertmanager-config

查看启动状态

kubectl  -n monitor  logs -f alertmanager-6786c86556-2jlpj  alertmanager

image.png

创建svc.yaml

apiVersion: v1
kind: Service
metadata:name: alertmanagernamespace: monitorlabels:k8s-app: alertmanager
spec:type: NodePortports:- name: httpport: 31093targetPort: 31093nodePort: 31093selector:k8s-app: alertmanager

ingress.yaml


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:namespace: monitorname: alertmanager-ingress
spec:ingressClassName: nginxrules:- host: alertmanager.kubernets.cnhttp:paths:- pathType: Prefixbackend:service:name: alertmanagerport:number: 31093path: /

访问验证：

$ curl http://alertmanager.kubernets.cn

四、Prometheus添加告警配置

修改ConfigMap资源文件prometheus-config.yaml，改动内容如下:

  • 添加AlertManager服务器地址
  • 指定告警规则文件路径位置
  • 添加Prometheus中触发告警的告警规则（已经简单添加了2条）

k8s部署添加

修改 prometheus-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:name: prometheus-confignamespace: monitor
data:prometheus.yml: |global:scrape_interval:     15sevaluation_interval: 15sexternal_labels:cluster: "kubernetes"alerting:alertmanagers:- static_configs:- targets: ['alertmanager:31093']############ 数据采集job ###################scrape_configs:- job_name: prometheusstatic_configs:- targets: ['127.0.0.1:9090']labels:instance: prometheus

按上面方法重载 Prometheus，打开 Prometheus 的 Target 页面，就会看到 上面定义的 mysql-exporter 任务

kubectl apply -f prometheus-config.yaml
kubectl apply -f prometheus-deploy.yaml
url -XPOST http://10.0.0.0.12:30090/-/reload

查看

image.png

五、Alertmanager配置解析

alertmanager配置一般分为以下五个部分

  • 全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置、Slack配置等。
  • 模版（templates）：用于定义告警通知时的模板，如HTML模板、邮件模板等。
  • 告警路由（route）：根据标签匹配，确定当前告警应该如何处理。
  • 接收者（receivers）：接收者是一个抽象的概念，它可以是一个邮箱，也可以是微信、Slack或者Webhook等。接收者一般配合告警路由使用。
  • 抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生。

全局配置

  • 用于定义一些全局的公共参数，如全局的SMTP配置、Slack配置等。
global:resolve_timeout: 1msmtp_smarthost: 'smtp.qq.com:465'  # 邮箱服务器的SMTP主机配置smtp_from: '1748310713@qq.com'  # 发送人smtp_auth_username: '1748310713@qq.com'  # 登录用户名smtp_auth_password: 'rebmydxljnawfaie'  # 此处的auth password是邮箱的第三方登录授权密码，而非用户密码smtp_require_tls: false  # 有些邮箱需要开启此配置，这里使用的是企微邮箱，仅做测试，不需要开启此

模板

  • 用于定义告警通知时的模板，如HTML模板、邮件模板等。
templates:- '/etc/alertmanager/*.tmpl'

告警路由

  • 根据标签匹配，确定当前告警应该如何处理
# 每个告警信息进入的根路由，用于设置告警的分发策略
route:# 根路由不能有任何匹配器，因为它是所有告警的入口点。它需要配置一个接收器，以便将不匹配任何# 子路由的告警发送出去，receiver的默认值为default，如果某条告警没有被一个route匹配，# 则发送给默认的接收器receiver: 'team-X-mails'# 将多个告警匹配聚合到单个组中，这将完全禁用聚合，按原样传递所有告警。例如，group_by: […]group_by: ['alertname', 'cluster']# 当一个新的告警组被创建时，至少要等待'group_wait'时间来发送初始通知。通过这种方式，# 可以确保有足够多的时间为同一份组获取多条告警，然后一起触发这些告警信息group_wait: 30s# 在发送完第一条告警以后，等待group_interval时间来发送一组新的告警信息group_interval: 5m# 如果告警已成功发送，则等待'repeat_interval'时间重新发送它们repeat_interval: 3h# 所有上述属性是根路由的内容，由所有子路由继承，并且可以覆盖每个子路由routes:# 此路由对告警标签执行正则表达式匹配，以捕捉与服务列表相关的告警- matchers:- service=~"^(foo1|foo2|baz)$"receiver: team-X-mails# 该服务有一个用于紧急告警的子路由，任何不匹配的告警，!= severity: critical，# 都会退回到父节点并发送到“team- x -mail”routes:- matchers:- severity="critical"receiver: team-X-pager- matchers:- service="files"receiver: team-Y-mailsroutes:- matchers:- severity="critical"receiver: team-Y-pager# 此路由处理来自数据库服务的所有告警。如果没有团队来处理它，则默认由DB团队处理- matchers:- service="database"receiver: team-DB-pager# 还可以根据受影响的数据库对告警进行分组group_by: [alertname, cluster, database]routes:- matchers:- owner="team-X"receiver: team-X-pager- matchers:- owner="team-Y"receiver: team-Y-pager

接收者

receivers:- name: 'ops'webhook_configs:- url: http://10.0.0.11:31008/prometheusalert?type=dd&tpl=dd-test&ddurl=https://oapi.dingtalk.com/robot/send?access_token=6081ef0eaec970f0ef3e5f2799f46a8b0e3c343744ec90e990f212b07910f03c- name: 'dev'email_configs:- to: '13168993708@163.com'send_resolved: truehtml: '{{ template "email.to.html" . }}'- name: 'dba'email_configs:- to: '13168993708@163.com'send_resolved: truehtml: '{{ template "email.to.html" . }}'

抑制规则

inhibit_rules:  # 抑制规则- source_match:alertname: 'node节点挂了'instance: node13target_match:project: test-web  # 当node节点标签触发时，下面project的标签也就是nginx就会被抑制- source_match:severity: critical  # 当触发告警标签，severity=critical时，触发抑制规则，包含severity=warning的告警将被抑制target_match:severity: warning  # 包含severity=warning的告警将被抑制equal:- project  # 还添加了一个equal标签，作用就是source和target中都包含project这个标签，且他们的值一致时，才会抑制，比如nginx端口挂了,监控https的就会被抑制# - source_match:  # 源标签警报触发时抑制含有目标标签的警报，在当前警报匹配 servrity: 'critical'#     severity: 'critical'#   target_match:#     severity: 'warning'  # 目标标签值正则匹配，可以是正则表达式如: ".*MySQL.*"#   equal: ['alertname', 'dev', 'instance']  # 确保这个配置下的标签内容相同才会抑制，也就是说警报中必须有这三个标签值才会被抑制。

测试告警规则

curl -X POST http://10.0.0.11:9093/api/v1/alerts \-H "Content-Type: application/json" \-d '[{"labels": {"alertname": "主机内存高","job": "node-exporter","instance": "node01","severity": "warning","application": "NodeExporter"},"annotations": {"description": "主机内存利用率过高","summary": "主机内存高","value": "node01"},"startsAt": "2024-07-02T09:36:01.979669601Z"}]'

v2接口

curl -XPOST -H 'Content-Type: application/json' \
http://IP:9093/api/v1/alerts -d  \
'[{"labels":{"severity":"critical"},"annotations":{"summary":"测试一下告警"}}]'

Prometheus UI查看配置和告警规则是否生效
image.png

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/776181.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

汽车虚拟仿真应用存在的几大挑战及解决方案

汽车虚拟仿真应用存在的几大挑战及解决方案

汽车虚拟仿真是指利用软件和数学模型,模拟汽车的设计、制造、测试和运行等过程,以及汽车与环境、驾驶员、乘客等的交互.实时云渲染技术可以将汽车虚拟仿真应用的运行画面,以可实时交互的视频流的形式推送到用户终端.汽车虚拟仿真是指利用软件和数学模型，模拟汽车的设计、制造、…
阅读更多...
19C-ORA-00800

19C-ORA-00800

原文:https://www.xifenfei.com/2022/11/ora-00800.html 在一套19.16 的linux 2节点rac库中,使用sqlplus启动数据库成功,但是alert日志报 ORA-00800: soft external error, arguments: [Set Priority Failed] ***alter 日志信息2024-07-31T11:31:33.381384+08:00Starting back…
阅读更多...
C-V2X安全证书：保障车路云系统通信安全的关键

C-V2X安全证书：保障车路云系统通信安全的关键

前言随着智能网联（C-V2X）技术和车路云一体化系统的快速发展，汽车、道路和云端之间的信息交换变得越来越频繁和复杂。在这个信息高度互联的时代，如何确保车路云一体化通信的安全性成为了亟待解决的问题。车路云一体化系统与C-V2X安全证书车路云一体化系统通过新一代信息与通…
阅读更多...
python 音频处理（1）——重采样、音高提取

python 音频处理（1）——重采样、音高提取

python音频处理 音高提取 f0 提取pitch基频特征 torchaudio resample 重采样采集数据->采样率调整使用torchaudio进行重采样（cpu版）首先导入相关包，既然使用torch作为我们的选项，安装torch环境我就不必多说了，如果你不想用torch可以使用后文提到的另一个库1 import to…
阅读更多...
信呼OA2.6.3文件上传漏洞

信呼OA2.6.3文件上传漏洞

感觉过程还是蛮简单的，主要思路没有见过。 危险函数createtxt()侵权声明 本文章中的所有内容（包括但不限于文字、图像和其他媒体）仅供教育和参考目的。如果在本文章中使用了任何受版权保护的材料，我们满怀敬意地承认该内容的版权归原作者所有。 如果您是版权持有人，并且认…
阅读更多...
一次动态接口替换经历

一次动态接口替换经历

接口改造 背景 现有旧订单接口 orderDetail，该接口会返回全量节点，部分节点不会使用因此造成了冗余，给数据库造成了较大压力，因此改造新接口 basicOrderDetail(xxx) 支持传入需要赋值的节点，方便赋值。 有如下改造方案：现有多个其他部分接口调用当前 orderDetail 接口获取…
阅读更多...
智算引领，数耀鹭岛！天翼云与厦门电信共筑智算时代新底座！

智算引领，数耀鹭岛！天翼云与厦门电信共筑智算时代新底座！

在数字化浪潮的推动下，算力已成为推动社会进步的重要力量。近日，由厦门市数据管理局指导，天翼云科技有限公司、中国电信有限公司厦门分公司（以下简称“厦门电信”）主办的“智算引领 数耀鹭岛”——厦门智算中心（电信中心）发布会暨算力补贴政策宣贯会在福建厦门成功举办。…
阅读更多...
行业标准引领者！天翼云助推智算领域规范化发展！

行业标准引领者！天翼云助推智算领域规范化发展！

7月24日，2024可信云大会召开期间，智算云服务论坛上，天翼云荣获中国信通院颁发的“智算工程平台能力要求标准参编证书”，代表了业界对天翼云在推动行业标准制定中所作贡献及成果的重要肯定，以及对天翼云技术创新水平的高度认可。会上，天翼云科技有限公司智算产品线资深技术…
阅读更多...
07HTML+CSS

07HTML+CSS

标准流 标准流也叫文档流，指的是标签在页面中默认的排布规则，例如：块元素独占一行，行内元素可以一行显示多个。 浮动（了解） 作用：让块元素水平排列。 属性名：float 属性值 • left：左对齐 • right：右对齐 特点： • 浮动后的盒子顶对齐 • 浮动后的盒子具备行内块特…
阅读更多...
推荐一款好用的刷题工具

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率，阿里云特别推出“通义灵码陪你备战求职季”活动，精心挑选百道历史校招技术面试/笔试题，借助通义灵码智能问答、代码智能生成、代码优化等核心功能，帮助开发者更加准确地了解程序员职业所需的核心技能，加强对问题解决思维和解题…
阅读更多...
win10 in arm

win10 in arm

记得流水账了，非技术控跳过即可。 10年前，早在win10刚出的那些天，就浏览到有支持arm架构的信息，只是未见缘来打怪，磨蹭到微软快要取消支持的了，方哦，哦，哦... 老板的华为平板cpu是枭龙850+8g内存，64位家庭版。平板上旧系统中了comup.dll的毒，一阵删杀后把系统给搞崩了…
阅读更多...
Getty 携手英伟达升级商业文生图 AI 模型；苹果新专利探索「心跳」解锁 iPhone 丨 RTE 开发者日报

Getty 携手英伟达升级商业文生图 AI 模型；苹果新专利探索「心跳」解锁 iPhone 丨 RTE 开发者日报

开发者朋友们大家好：这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的 新闻 」、「有态度的 观点 」、「有意思的 数据 」、「有思考的 文章 」、「有看点的 会议 」，但内容仅代表编辑…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023