即使服务器运行正常，它也能检测到数周内未被察觉的业务故障。
该系统监控3个服务中的13个服务器组件，以及实际业务结果，例如发票传输和KakaoTalk通知。我们开发了一个运维工具，可以聚合来自服务器API和用户PC应用程序的错误，从而引导用户从Slack通知到管理员屏幕上的根本原因验证。
- 0.5秒→0.1秒慢查询改进后立即观察到的订单服务平均数据库响应时间
- 6例通过监控警报发现并修复的运行问题
- 13个地方每分钟检查一次服务器组件
这是内部开发的管理员状态界面。它显示每项服务的当前状态和操作历史记录。内部识别信息已被隐藏。
本地化参考图 · 查看韩语原图- 已分配角色
- 我设计了监控标准和通知流程。监控程序、服务器状态界面、工作结果验证、API错误和PC应用错误收集以及用于查看所有这些信息的管理员控制台均由我亲自开发。
- 成果
- 我们创建了一个监控系统，可以同时检查服务器状态、实际业务处理结果以及 API/PC 应用程序错误。已将警报、恢复通知和定期报告与管理控制台连接，并修复了监控发现的 6 个问题的原因，包括查询缓慢以及发票和 KakaoTalk 集成问题。
- 1服务器监控13 个位置被判定为正常、性能不佳、故障或无法确认。
- 2检查工作结果根据请求是否实际处理而非是否被接收来确定
- 3通知和报告当连续发生 3 次故障时发出警报，恢复期间再次发生故障时发出警报，并每天定期报告两次。
- 4错误收集收集服务器 API 错误和 PC 应用程序错误，并将类似的错误分组在一起。
此技术预期带来的变更
小团队的操作响应
负责人无需持续监控多个管理屏幕，即可通过通知检查异常情况并进行恢复，从而减轻重复检查的负担，使其能够专注于查找问题根源。
在交付给客户之前发现问题
即使服务器正常，它也能检测到诸如缺少发货信息或业务通知等故障，帮助您在客户咨询之前采取行动。
导致改进的错误日志
通过对服务器和用户PC上发生的错误进行分组，该系统能够识别重复出现的问题，并留下运行证据，以便在修复后进行状态对比。
问题及解决方案
问题即使服务器正常，跟踪号码传输或 KakaoTalk 通知仍可能显示为失败。
已解决。区分请求接收和实际处理结果，并将任务失败和未完成的执行与监控关联起来。
问题管理员分析任务或等待首次结果的状态显示为实际失败。
已解决。对工作源进行分类，并对待收集、未确认结果和已确认失败的情况进行分类，以识别需要处理的异常情况。
问题如果在中断期间采集连接丢失，则该期间的状态历史记录为空。
已解决。观察结果会临时存储，并在连接恢复后发送，不会重复发送，从而可以持续查看故障和恢复流程。
问题当服务器运行缓慢或断开连接时，等待错误传输会导致家具构建器编辑和输出同时停止。
已解决。无需等待编辑和输出即可单独发送错误，并限制同一错误的重复发送。
问题错误信息中可能包含标记或文件路径。
已解决。只留下第一行，PC端和服务器端都删除了敏感部分，不发送绘图内容。
确认的结果
- 对比管理员状态屏幕、Slack 报告以及故障和恢复历史记录。
- 我们确认了操作图表，显示修复慢查询后，平均数据库响应时间立即从 0.5 秒左右降至 0.1 秒左右。
- 记录了 6 起通过监控警报（例如发票、KakaoTalk 和数据库连接）追踪并纠正了原因的案例。
13处每分钟检查一次
设计与加工平台8处
- Nginx (运维、开发)前端服务器自响应
- API服务器 (运维、开发)状态响应与引擎加载
- GPU工作者 (运维、开发)上次心跳时间
- DB (运维、开发)连接和慢速查找
家具订购服务3处
- 网页服务 (运维)首屏及应用文件响应
- DB (运维)连接和慢速查找
- 数据库函数调用 (运维)各函数平均响应时间
工厂管理服务2处
- 网页服务 (运维)登录界面及应用文件响应
- API服务器 (运维)响应只读请求
- 常规操作
- 支付后处理
- 工作队列
- 外部链接
- 发送通知对话
错误发生时即会被收集
服务器 API设计与加工平台
5xx 和所有未处理的异常，仅 4xx 示例
API错误屏幕将相同的错误分组，并记录处理状态和历史记录。
用户 PC 应用Furniture Builder、连接器、绘图器
仅发送错误位置和目标，无需停止操作
本地应用程序问题屏幕按程序、错误代码和完成度指标分组的趋势
监控发现的实际问题 6项
橙色线代表订单服务数据库。在我开始记录的当晚，修复慢查询后，平均响应时间立即从 0.5 秒左右降至 0.1 秒左右。
本地化参考图 · 查看韩语原图启用监控的第一天，发现订单服务数据库的平均响应时间约为 0.5 秒，管理界面按周期查询趋势平均需要 4 到 5 秒。
修复此查找问题后，数据库平均响应时间立即降至约 0.1 秒。另有 17 个相同原因导致的查找问题也以相同方式修复。
部署检查作业会在保持数据库事务打开的情况下读取文件存储，连接保持时间超过 10 秒。
仅在连接内进行数据库搜索，并在连接关闭后进行文件检查。
同时开始的两笔发票传输被记录为失败。
已消除重复发票传输，例如传输冲突。
4 条消息的送达通知结果未送达。检查过去 120 天，发现有 65 条消息未收到结果。
每分钟发送一次消息，如果未收到结果，则重新检查这些消息以进行匹配。
从九月初开始，连续六周，每次发送完整账单时，都会出现一个订单失败的情况。
已修改，记录状态为“已完成”，并与已注册的编号进行比较。
虚拟账户充值期间，重新发送订单完成通知消息时被拒绝。
我们已阻止在订单处理过程中已发送的通知消息在付款后再次发送。
运维中需要检查的屏幕
报告所有状态组件每天运行两次。故障和恢复警报也通过同一通知流程发送。
本地化参考图 · 查看韩语原图将峰值与持续异常值进行比较。
本地化参考图 · 查看韩语原图从中断开始到恢复期间的记录。
本地化参考图 · 查看韩语原图