为什么运维开发告警这么多
近日见闻
在Meta新的重返办公室政策生效前几周，该公司的人力资源主管写信给员工，警告一再违反规则的员工将面临严重后果。zoom和亚马逊也都宣布，重返办公室。就是说，远程工作并没那么容易实现。
根据F5的2023年应用战略现状报告调查的1000多名全球IT领导者，混合云网络很热门。42%的调查受访者提到了混合网络。这高于AIOps和边缘计算等热门话题,接近第三位零信任和IT/OT融合,这两个话题的占比均为44%。
未来的工作是人工智能增强和远程。今年商业领域最大的两个悬而未决的问题是远程工作是否会继续存在，以及人工智能将如何影响工作。可以看下麦肯锡的全球调查名为“2023 年人工智能的状态：生成人工智能的突破之年”（对“代表各个地区、行业、公司规模、职能专业和任期的 1，684 名参与者”的调查）显示了人工智能在商业领域的增长速度。
夜莺监控发布v6.0.3版本，增强告警订阅功能。
关于告警消息的一点思考
先来梳理下有一般有哪些告警
服务器资源告警：这种类型的告警通常涉及服务器资源的消耗，如CPU、内存、磁盘空间等。
应用程序错误告警：这些告警涉及到应用程序在运行过程中出现的错误、异常或崩溃。
网络故障告警：这些告警涉及网络设备、连接或协议的问题。
服务可用性告警：这些告警通知管理员某个服务不可用或无法正常访问。
硬件故障告警：涉及到硬件设备（如磁盘、电源、风扇等）出现故障。
这些告警的实现方式有哪些？
- 服务器资源告警
监控工具：使用监控工具（例如Prometheus、Zabbix、Nagios等）定期检查服务器资源的使用情况，当资源超过预定阈值时，生成告警。
阈值设置：管理员可以设置资源使用的阈值，当资源使用率达到或超过这些阈值时，告警被触发。
这里主要就是关注检测方式、告警条件以及对应的响应措施，比如检查到异常，如何进行处理，手动执行还是自动脚本执行，是需要思考的点。
- 应用程序错误告警
日志监控：监控应用程序日志文件，当日志中出现错误、异常等关键词时，生成告警。
异常检测：在代码中内置异常检测机制，当应用程序抛出异常时，触发告警。
这个主要关注的就是日志监控、异常捕获（代码中使用try catch块等）和记录（写入日志文件），然后就是异常处理和告警触发，收到信息后能够快速定位问题，过程中会涉及日志查看、分析堆栈跟踪、代码修复重新部署等。
- 网络故障告警
网络监控工具：使用网络监控工具（例如Nmap、Wireshark、PRTG等）来监测网络设备和流量，检测到异常时触发告警。
Ping/Traceroute：定期执行Ping或Traceroute来检查网络设备的可用性和响应时间，如果有问题则生成告警。
这部分一般会有网络工程师专门负责，当然掌握基础的告警实现和原理也是必要的。比如使用基础网络监控工具、端口状态监控等。
- 安全事件告警
入侵检测系统（IDS）：部署入侵检测系统，监控网络流量和系统行为，发现异常活动时生成告警。
日志分析：分析系统和应用程序的安全日志，识别可能的安全事件并生成告警。
这部分内容就是安全工程师去负责的，包括网路流量分析、异常行为检测、恶意软件检测、登录审计、日志分析、外部威胁分析、行为分析等等。
- 服务可用性告警
心跳检测：定期发送心跳请求来检测服务是否响应，如果未响应则生成告警。
HTTP监控：定期请求服务的HTTP端点，如果返回状态码表明服务不可用，触发告警。
这个就一般由应用运维工程师去配置查看，比如一般的HTTP状态码检测、TCP/UDP端口检测，端口不可达触发告警。还有各种事务、服务日志、容器、云监控等。
- 硬件故障告警
硬件监控工具：使用硬件监控工具（如IPMI、SNMP等）来监测硬件状态，发现异常时生成告警。
这部分，一般就是负责硬件工程师去负责，根据监控目标，配置告警规则、比如温度、磁盘故障、硬件状态等等。
梳理了以上告警情况，发现其实很多小公司的运维或开发工程师都会或多或少的去做这上面的告警任务，但是不得不说，正因为做了这些告警和对应的处理规则，就不用担心面对故障手足无措的情况，尽管告警也不能百分百的避免故障的发生，但至少可以避开很多不应该发生的故障。减少我们故障处理的概率，不再害怕on call的情况。