企业监控体系架构演进系列
MYSQL的监控
MySQL权限经验原则
权限控制主要是出于安全因素，因此需要遵循一下几个经验原则：
- 只授予能满足需要的最小权限，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。
- 创建用户的时候限制用户的登录主机，一般是限制成指定IP或者内网IP段。
- 初始化数据库的时候删除没有密码的用户。安装完数据库的时候会自动创建一些用户，这些用户默认没有密码。
- 为每个用户设置满足密码复杂度的密码。
- 定期清理不需要的用户。回收权限或者删除用户。
eg:
Prometheus是一个开源的监控与时间序列数据库系统,在近年来得到了越来越广泛的应用。
官方的架构图如图所示：
在互联网业务分布式、高并发、多云部署的大背景下，SRE（网站稳定性工程） 成为保障服务可用性的核心角色，而监控体系则是SRE的“眼睛”。本文从SRE核心理念出发，拆解现代监控体系的痛点、技术栈选型、Prometheus核心原理与告警实战，还原一套可落地的企业级监控建设思路。
前情概述：
在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。
前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。
在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。
前情概述：
在《监控系统企业架构演进史-跨地域混合云》中，监控系统已经逐步成熟且企业化发展。 这一章节简单讲述一下期间的拨测能力搭建，以下是这套系统的发展史，在监控平台搭建的过程中，内部监控采集还不足以满足企业业务需求，在计划发展apm之前，异地拨测的黑匣子监控也纳入了该系统的一个子功能。
在互联网服务的全链路监控体系中，白盒监控侧重主动挖掘潜在隐患、提前预判风险，黑盒监控则以故障为核心导向，快速感知已发生的线上问题。二者协同才能构建完整的监控闭环。而多数互联网企业长期存在公网服务、用户侧最后一公里的监控盲区，用户侧故障往往只能被动等待报障后才启动排查，黑盒拨测监控系统正是为解决这一行业痛点而生。
在互联网业务高速扩张、多云部署、资产指数级增长的背景下，监控平台是保障服务稳定性的核心基建。本文完整复盘某大型互联网公司监控平台2019-2021年的演进之路，从解决老旧监控性能瓶颈，到跨云分布式监控落地，再到云原生平台化治理，呈现监控体系从0到1搭建→规模化扩展→平台化治理的完整蜕变。
在企业业务全球化、混合云规模化部署的背景下，跨IDC、跨国内外、多云异构的监控治理成为稳定性保障的核心难题。传统监控方案要么依赖高成本专线改造、侵入业务架构，要么无法兼顾节点自治与全局统一，同时监控系统作为非营收类基建，还需严格控制资源占用且不允许能力降级。
在多云部署、全球化组网、服务规模指数级增长的互联网业务场景中，监控平台早已超越“指标采集+告警通知”的基础定位，成为保障全链路稳定性的核心基建。本文基于大型互联网企业监控平台的真实演进历程，拆解2022年监控平台从规模化覆盖向产品化、易用化、智能化升级的完整规划与落地思路。