前言更多运维相关知识蓝队技能学习_其实防守也摸鱼的博客-CSDN博客​持续更新ing~介绍如果把服务器比作病人那么运维人员就是医生。监控与日志分析正是医生的“听诊器”和“化验单”。面对成百上千台服务器我们不可能每天挨个登录去敲命令查看状态。因此我们需要一套自动化的系统来帮我们盯着这些机器并在出问题时迅速定位。这通常分为两大核心板块监控告警看指标和日志分析查细节。 监控告警给服务器戴上“智能手环”监控系统的核心作用是实时收集各种“指标Metrics”比如 CPU 使用率、内存占用、磁盘剩余空间、网络流量等。当这些指标超过设定的安全线时系统就会自动触发告警。目前主流的监控工具有两个Zabbix和Prometheus。它们的设计理念有所不同适用于不同的场景 Zabbix传统 IT 架构的“全能大管家”Zabbix 是一个非常成熟的企业级监控工具它的特点是“大而全”非常适合监控传统的物理机、虚拟机、交换机、路由器等硬件设备。工作原理Zabbix 采用推Push和拉Pull结合的模式。通常需要在被监控的服务器上安装一个轻量级的 Agent代理程序这个 Agent 会主动收集本机的 CPU、内存等数据然后定期发送给 Zabbix 服务器。同时Zabbix 也支持通过 SNMP 协议去轮询网络设备。核心组件Zabbix Server核心大脑负责接收数据、处理数据、判断是否触发告警。Zabbix Agent部署在目标机器上的“眼线”负责采集数据。Zabbix Proxy当监控的机器非常多时可以部署 Proxy 来分担 Server 的压力实现分布式监控。数据库所有的配置和收集到的历史数据都存在数据库里如 MySQL。优势自带非常丰富的 Web 界面开箱即用的模板极多比如一键监控 MySQL、Nginx权限管理和告警通知邮件、钉钉、微信等机制非常完善。 Prometheus云原生时代的“监控标杆”随着 Docker 和 K8s 的普及Prometheus 凭借其强大的动态发现能力和对微服务架构的完美支持成为了云原生时代的绝对主流。工作原理Prometheus 采用的是拉Pull模式。它不会被动等待数据上报而是会主动、定期地去“抓取Scrape”目标服务的/metrics接口来获取数据。核心组件Prometheus Server核心服务负责抓取、存储时间序列数据TSDB并执行告警规则。Exporters因为很多传统软件如 MySQL、Node.js本身不暴露 Prometheus 格式的数据所以需要 Exporters 作为“翻译官”把这些软件的指标转换成 Prometheus 能懂的格式。Alertmanager专门负责处理告警。Prometheus 发现异常后会把告警发给 Alertmanager由它负责去重、分组然后通过邮件、Slack 等渠道发出去。Pushgateway专门用来接收那些“生命周期很短”的任务比如定时脚本推送过来的指标。优势强大的多维度数据模型和查询语言PromQL能极其灵活地对数据进行聚合和计算与 K8s 结合得非常紧密能自动发现动态变化的 Pod 和容器。一句话总结监控传统物理机和网络设备Zabbix 依然是王者但如果你的业务全面拥抱了容器化和微服务Prometheus 是必选项。 日志分析从海量文本中“大海捞针”监控能告诉你“服务器 CPU 飙高了”或者“接口报 500 错误了”但为什么报错是哪行代码出了问题这就需要去查日志。在分布式系统中一个用户的请求可能会经过网关、订单服务、支付服务等多个节点日志散落在几十台不同的服务器上。如果还靠手动登录服务器用grep查日志效率极低。因此我们需要ELKElastic Stack这样的集中式日志分析平台。ELK 是三个开源软件的缩写现在通常还包含一个轻量级采集器 Beats合称 Elastic Stack 采集与处理Beats LogstashBeats如 Filebeat非常轻量级的数据采集器。你把它安装在每一台应用服务器上指定好日志文件的路径比如/var/log/nginx/access.log它就会实时监听文件的变化把新产生的日志一行行抓取出来发送给下游。Logstash一个强大的数据处理管道。它接收来自 Beats 的日志进行复杂的过滤、解析、格式化比如把非结构化的文本日志转换成结构化的 JSON然后再输出。 存储与搜索Elasticsearch这是整个架构的核心引擎。它接收 Logstash 处理好的数据并建立强大的索引。它的检索速度极快即使面对 TB 级别的海量日志也能在毫秒级返回搜索结果。 可视化KibanaKibana 是 Elasticsearch 的官方可视化面板。运维和开发人员通过浏览器访问 Kibana就可以通过关键字、时间范围、错误级别ERROR/WARN等条件快速检索出需要的日志。将日志数据生成直观的折线图、饼图、仪表盘比如统计过去一小时 500 错误的趋势。一句话总结ELK 架构把分散在各处的日志集中起来让你像用百度/谷歌一样去搜索和分析服务器的日志极大地提升了排查问题的效率。 监控与日志是如何协同工作的在实际的运维场景中这两者通常是紧密配合的发现问题Prometheus 监控到某个订单服务的接口响应时间突然飙升或者 5xx 错误率超过了 5%。触发告警Alertmanager 立刻给运维人员的钉钉群发了一条告警“订单服务异常请处理”。定位问题运维人员看到告警后立刻打开 Kibana输入时间范围和ERROR关键字瞬间过滤出该时间段内所有的报错日志。解决问题通过日志发现是数据库连接池满了进而排查数据库性能瓶颈并修复。到这里从基础系统、网络到自动化部署再到现在的监控与日志现代运维的核心知识体系基本就完整了。 极简实操用 Docker 一键拉起 Prometheus 监控Prometheus 的生态里有一个非常好用的工具叫cAdvisor它可以自动采集宿主机和容器的 CPU、内存等指标并暴露给 Prometheus 抓取。1. 准备配置文件Prometheus 需要知道去哪里抓取数据。新建一个文件夹并创建一个配置文件mkdir prometheus-demo cd prometheus-demo nano prometheus.yml把下面这段内容写进去告诉 Prometheus 每隔 5 秒去抓取一次 cAdvisor 的数据global: scrape_interval: 5s scrape_configs: - job_name: cadvisor static_configs: - targets: [cadvisor:8080]2. 用 Docker Compose 一键启动为了同时启动 Prometheus 和 cAdvisor我们写一个简单的docker-compose.yml文件nano docker-compose.yml填入以下内容version: 3 services: prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - 9090:9090 cadvisor: image: gcr.io/cadvisor/cadvisor:latest volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro ports: - 8080:80803. 启动并查看效果docker-compose up -d启动成功后打开浏览器访问http://localhost:9090。在顶部的搜索框里输入container_cpu_usage_seconds_total并点击Execute然后切换到Graph标签页。你就能看到一条实时跳动的 CPU 使用率曲线了 极简实操用 Docker 一键拉起 ELK 日志系统完整的 ELK 包含三个组件如果一个个配会非常麻烦。开源社区有一个现成的神器叫elk-docker一个命令就能把 Elasticsearch、Logstash 和 Kibana 全部搞定。1. 一键启动 ELK直接运行下面这行命令第一次运行需要下载几个 GB 的镜像请耐心等待docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -it --name elk sebp/elk(解释5601 是 Kibana 的端口9200 是 Elasticsearch 的端口5044 是接收日志的端口)2. 查看 Kibana 面板等待大概 1-2 分钟等容器里的服务都启动完毕后打开浏览器访问http://localhost:5601。第一次进入 Kibana 会让你配置一个“索引模式Index Pattern”直接输入*然后点击下一步创建即可。3. 模拟发送一条日志ELK 跑起来了但里面还没有数据。我们可以用nc命令手动往里塞一条测试日志echo ERROR: 数据库连接超时请检查网络 | nc localhost 50444. 见证奇迹回到 Kibana 页面点击左侧菜单的Discover放大镜图标。你会看到刚才手动发送的那条报错日志已经静静地躺在里面了在实际工作中你只需要在左上角调整时间范围就能像用搜索引擎一样快速过滤出成百上千台机器里的报错信息。 总结通过这两个极简实操你会发现Prometheus cAdvisor让你拥有了上帝视角能实时看到系统资源的消耗情况。ELK让你拥有了“时光机”能把散落的日志集中起来随时回溯和搜索报错细节。有了监控和日志这两双“眼睛”以后不管线上出什么诡异的 Bug你都能做到心里有底、手中有招了。