标签：两种 大小 阈值 一个 观测 文本 业务监控 大致 了解
前篇已经提到过监控系统的重要性，那么一个较为良好的监控系统应该从哪几方面上手的呢？我个人理解可以通过以下几个方面入手：
大致从以上几点开始，下面我们简单来介绍上面所说。
当下各个企业的产品不同，业务方向不同，程序代码不同，系统架构更不同，对于各个地方的细节都需要有一定程度的认知才可以开启设计的源头。
比如，我们以系统架构为例，如果你是老牌服务 VS 微服务 我相信面向服务的监控体系一定会比面向主机监控更加顺畅的多；又比如Python亦或者Java，更甚者PHP都有着不同的监控体系，所以这里要根据自身情况相结合进行合理的选择。
分类监控，我们将需要的监控项进行整合分类便于后期管理实施的便捷性，那么一般可分为：业务级别监控、系统级别监控、网络监控、程序代码监控、日志监控、用户行为分析监控、其他种类监控。
举例来如，如下：
目前各种监控软件层出不穷，包括开源的、商业的、自行开发的等几百种的可选方案；选取呢应该针对企业的架构特点，大小，种类，人员多少 等等 选取合适的技术方案，而不应该熟悉那个则上那个，那样可能会给后期扩展升级带来巨大的挑战。
运维团队自身就应该将相关任务进行消化掉，同时划分相关项目功能模块，责任到人；中间不免需要开发团队的配合，很多监控设计的工作，也需要寻求开发人员配合才可以进行。
监控系统首选需要评估，存储周期，高可用问题，以及多AZ（多机房，多可用区）问题，根据存在的这个问题我们进行选择部署形式。
目前来说，数据采取形式多为Agent采取；工具多为一下几种：
数据采集一般分为两种形式：
如果你不配置对数据的分析（有些分析需要算法的加持），那么存放在哪里的只是一堆没用的数据；当我们能够把数据转化成为监控公式与报警的阈值才能发挥出监控本该有的意义。
比如：CPU状态，传统监控多为采用系统负载load来判断系统繁忙状态， 那你如何确定是用户态还是系统态，以及更多的信息呢？ 假如我们通过算法对CPU使用情况统计5分钟的增长比率超过0.8，同时持续了30分钟呢？是不是比load更加可以清晰呢。
不管采集形式如何，只要运行才Linux上，多会对系统有或多或少的影响，所以稳定性测试，就是通过一段时间的观测，确保能平滑上线。
随着业务量增大，机器、服务增多我们就需要对监控值进行管理以及Agent的扩展等问题，自动化的因为会很大程度上缩短我们对监控系统的维护成本。
我这里推荐: Ansible，有兴趣的小伙伴可以了解下。
想一想酷炫的大屏；采集的数据和准备好的算法相结合，就可以做出一个非常棒的图形展示，比如：多数据源聚合展示，多源对比等等。
所以，监控成图也是很重要的一个点。
上面扯了一堆，其实我们需要结合自身实际情况以及未来的发展趋势来做设计即可。
标签：两种 大小 阈值 一个 观测 文本 业务监控 大致 了解
原文地址：https://www.cnblogs.com/evan-blog/p/10206273.html
