0. 写在前面:为什么你需要“神器”而非“常用命令
大家好,我是老杨,干货满满的老杨.欢迎来到互联网遥遥领先的博客. 欢迎点击原文链接或直接访问vps.top365app.com,来看老杨的全球vps信息还有各种咱们用得着的信息实时收集分析项目.
帮老杨点赞、转发、在看以及打开小星标哦
攒今世之功德,修来世之福报
当今不说AI都显得好土。 但是别的咱们不清楚,就运维这行见过太多炫酷的概念,真正落地能用的没几个。不过怀疑和鄙视之外还是要做一些尝试,跟几个大厂的小伙伴做了一些交流.他们主要是从以下几个方面入手AI改造。
某二线大厂(跨境电商)的p7跟老杨说了几个场景.
比如以前每天早上8点钟,准时开始巡检。一台台服务器检查过去,看系统负载、磁盘空间、内存使用:
# 检查系统负载
uptime
09:15:01 up 45 days, 2:31, 2 users, load average: 0.15, 0.18, 0.12
# 检查磁盘使用率
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 28G 10G 74% /
/dev/vdb1 100G 85G 10G 90% /data
# 检查内存使用
free -m
total used free shared buff/cache available
Mem: 7821 3256 1234 125 3331 414250台服务器检查下来要半个多小时。关键是人工检查容易漏。比如这种磁盘使用率已经90%了。
现在用机器学习做异常检测就不一样了。先用node_exporter收集指标:
# 安装node_exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.6.1.linux-amd64.tar.gz
./node_exporter --web.listen-address=":9100"然后写个Python脚本做异常检测:
import pandas as pd
from sklearn.ensemble import IsolationForest
# 读取监控数据
data = pd.read_csv('server_metrics.csv')
# 训练异常检测模型
model = IsolationForest(contamination=0.1)
model.fit(data[['cpu_usage', 'memory_usage', 'disk_usage']])
# 预测异常
anomalies = model.predict(data[['cpu_usage', 'memory_usage', 'disk_usage']])这套操作之后异常检测准确率达到92%,误报控制在8%。24小时不间断监控,再也不会因为人工疏漏漏掉问题。
另一个在某团某业务负责的运维小伙伴说在AIOps故障发现方面的实践表明,通过机器学习方式能够有效解决传统自动化运维无法处理的问题。他们的智能监控系统已经在生产环境大规模使用。
传统日志分析就是grep大法:
# 查找错误日志
grep -i "error" /var/log/application.log
2024-09-01 09:15:23 ERROR: Database connection failed
2024-09-01 09:16:45 ERROR: API timeout after 30 seconds
...
# 统计错误数量
grep -c "ERROR" /var/log/application.log
1248这种方法局限性很大。同一个问题可能用不同的词描述,而且看不出错误之间的关联。
现在用ELK Stack配合机器学习做日志分析:
# docker-compose.yml
version: '3'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.8.0
environment:
- discovery.type=single-node
ports:
- "9200:9200"
logstash:
image: docker.elastic.co/logstash/logstash:8.8.0
volumes:
- ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
ports:
- "5044:5044"
kibana:
image: docker.elastic.co/kibana/kibana:8.8.0
ports:
- "5601:5601"中文日志分析要用jieba分词:
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans
import jieba
# 中文日志分词
def tokenize_chinese(text):
return ' '.join(jieba.cut(text))
# 日志聚类分析
logs = ["数据库连接超时", "API调用失败", "内存不足警告", ...]
logs_tokenized = [tokenize_chinese(log) for log in logs]
vectorizer = TfidfVectorizer()
X = vectorizer.fit_transform(logs_tokenized)
kmeans = KMeans(n_clusters=5)
clusters = kmeans.fit_predict(X)故障定位时间从平均25分钟缩短到5分钟。能自动识别90%的常见故障模式。
以前都是故障发生了才知道。就像开车不看油表,等车抛锚了才知道没油。
很多故障其实有征兆。CPU使用率持续上涨、内存慢慢泄漏、磁盘空间逐渐减少。这些问题如果提前发现,完全可以避免宕机。
用时间序列分析预测系统状态:
import numpy as np
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_squared_error
# 构造时间序列特征
def create_features(data, window_size=24):
features = []
targets = []
for i in range(window_size, len(data)):
features.append(data[i-window_size:i])
targets.append(data[i])
return np.array(features), np.array(targets)
# 训练预测模型
cpu_data = [12.3, 15.6, 18.9, ...] # CPU使用率时间序列
X, y = create_features(cpu_data)
model = RandomForestRegressor(n_estimators=100)
model.fit(X, y)
# 预测未来1小时的CPU使用率
future_cpu = model.predict(X[-1:])
print(f"预计1小时后CPU使用率: {future_cpu[0]:.2f}%")容量规划也能自动化:
# 基于历史数据预测流量增长
import pandas as pd
from prophet import Prophet
# 历史流量数据
df = pd.DataFrame({
'ds': ['2024-01-01', '2024-01-02', ...],
'y': [1000, 1200, 1150, ...] # 每日QPS
})
# 训练Prophet模型
model = Prophet()
model.fit(df)
# 预测未来30天流量
future = model.make_future_dataframe(periods=30)
forecast = model.predict(future)
# 计算所需服务器数量
max_qps = forecast['yhat'].max()
servers_needed = int(max_qps / 1000) + 1 # 假设每台服务器能处理1000 QPS预测模型准确率达到88%。提前3小时预警资源不足,避免了6次因为流量突增导致的服务不可用。
传统自动化就是写Shell脚本:
#!/bin/bash
# 自动重启异常服务
SERVICE="nginx"
if ! systemctl is-active --quiet $SERVICE; then
echo "$(date): $SERVICE is down, restarting..."
systemctl restart $SERVICE
sleep 5
if systemctl is-active --quiet $SERVICE; then
echo "$(date): $SERVICE restarted successfully"
else
echo "$(date): Failed to restart $SERVICE, alerting admin"
# 发送告警
fi
fi这种方法太死板,不能根据具体情况调整。
现在可以用强化学习训练决策模型:
import gym
from stable_baselines3 import PPO
# 定义运维环境
class OpsEnvironment(gym.Env):
def __init__(self):
self.action_space = gym.spaces.Discrete(4) # 重启、扩容、降级、不处理
self.observation_space = gym.spaces.Box(low=0, high=100, shape=(3,)) # CPU、内存、磁盘
def step(self, action):
# 执行动作并返回奖励
if action == 0: # 重启服务
reward = self._restart_service()
elif action == 1: # 自动扩容
reward = self._scale_up()
# ...
return self._get_state(), reward, done, info
# 训练智能运维代理
env = OpsEnvironment()
model = PPO("MlpPolicy", env, verbose=1)
model.learn(total_timesteps=10000)
# 使用训练好的模型
obs = env.reset()
action, _states = model.predict(obs)智能决策系统上线3个月,资源利用率提高了28%,故障自愈成功率达到82%。
传统告警就是简单的阈值判断。CPU超过80%告警,内存超过90%告警。结果告警满天飞,真正的问题被埋没了。
之前的公司运维群一天收到300多条告警。大家都麻木了,重要告警也容易被忽略。
用机器学习做告警分级:
from sklearn.ensemble import GradientBoostingClassifier
import pandas as pd
# 历史告警数据
alert_data = pd.DataFrame({
'cpu_usage': [85, 92, 78, 95, ...],
'memory_usage': [75, 88, 82, 91, ...],
'error_rate': [0.1, 0.5, 0.2, 1.2, ...],
'is_critical': [0, 1, 0, 1, ...] # 是否是关键告警
})
# 训练告警分类模型
X = alert_data[['cpu_usage', 'memory_usage', 'error_rate']]
y = alert_data['is_critical']
model = GradientBoostingClassifier()
model.fit(X, y)
# 实时告警分级
def classify_alert(cpu, memory, error_rate):
prob = model.predict_proba([[cpu, memory, error_rate]])[0][1]
if prob > 0.8:
return "紧急"
elif prob > 0.5:
return "重要"
else:
return "一般"告警关联分析能合并相关告警:
from mlxtend.frequent_patterns import apriori, association_rules
# 告警关联分析
alerts_df = pd.DataFrame({
'database_slow': [1, 1, 0, 1, ...],
'api_timeout': [1, 1, 0, 1, ...],
'high_cpu': [0, 1, 1, 1, ...],
})
# 找出频繁告警组合
frequent_itemsets = apriori(alerts_df, min_support=0.3, use_colnames=True)
rules = association_rules(frequent_itemsets, metric="confidence", min_threshold=0.8)
print(rules[['antecedents', 'consequents', 'confidence']])他们的告警优化后,告警数量减少了65%,误报率从28%降到7%。运维同事终于不用被无关紧要的告警轰炸了。
数据质量决定效果
AI模型效果很大程度取决于数据质量。如果监控数据本身就不准确,训练出来的模型肯定也不好用。
比如之前有个CPU使用率监控,因为采集频率太低(5分钟一次),很多短时间的CPU峰值都漏掉了。用这种数据训练出来的异常检测模型效果很差。
建议:
别过度依赖AI
AI只是工具,不是万能的。复杂故障还是需要有经验的工程师分析处理。
而且AI系统本身也可能出问题。我们的异常检测系统曾经因为训练数据有偏差,连续误报了一周。最后还是要人工介入调整。
建议保留传统的监控告警作为备用,不要把所有鸡蛋放在一个篮子里。
循序渐进很重要
不要想着一步到位。从最简单的异常检测开始,积累经验后再增加复杂功能。
我见过有团队一上来就要做复杂的多维关联分析,结果搞了半年都没落地。最后还是回到基础的单指标异常检测。
团队技能要跟上
AI运维需要运维工程师掌握一些机器学习知识,至少要能看懂Python代码,理解基本的统计概念。
建议先安排几个人学习相关技术,作为种子选手。然后再逐步推广到整个团队。
AI改造主要是为了解决实际问题:减少重复劳动,提高响应速度,降低故障影响,通过机器学习方式来解决传统自动化运维无法处理的问题。但这个过程需要时间和耐心,不要期望一夜之间就能看到巨大改变。
这里老杨先声明一下,日常生活中大家都叫老杨波哥,跟辈分没关系,主要是岁数大了.就一个代称而已. 老杨的00后小同事老杨喊都是带哥的.张哥,李哥的. 但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适. 比如上次某集团策划总监,公司开大会来一句:“今个咱高兴!有请IT运维技术圈的波哥讲两句“ 这个氛围配这个称呼在互联网这行来讲就有点对不齐! 每次遇到这个情况老杨就想这么接话: “遇到各位是缘分,承蒙厚爱,啥也别说了,都在酒里了.老杨干了,你们随意!” 所以以后咱们改叫老杨,即市井又低调.还挺亲切,老杨觉得挺好.
运维X档案系列文章:
企业级 Kubernetes 集群安全加固全攻略( 附带一键检查脚本)
看完别走.修行在于点赞、转发、在看.攒今世之功德,修来世之福报
点击阅读原文或打开地址实时收集分析全球vps的项目 vps.top365app.com
老杨AI的号: 98dev