>> 5S2H胜利法：5步2小时的极限方法论
此前一直倡导以应用为中心的CMDB，其中应用需要人工创建，但客户可能并不确切知道自己拥有哪些应用以及如何对应用进行划分。7.6版本基于以应用系统为中心的CMDB管理方法做了重构升级，能够更好、更快的明确基本管理系统下的机器情况、进程实例、所使用中间件及其版本，以及是否存在漏洞等问题。
在以应用系统为中心实施 CMDB 时，需围绕系统展开工作，我们建议挑选一个系统进行试点，5步！2小时！快速实现：
在选定系统下维护的环境和主机中挑选部分主机进行尝试测试，以发现进程和服务实例；接着通过节点聚类创建应用和服务节点之间的关联，点击智能分析，即可呈现所有现网扫描上来的服务实例进程，CMDB 会按照一定规则默认规整好。按需勾选后，点击录入即可完成。
>> 产品局部展示：
- 系统维护下所有的应用和及其部署实例：
- 服务访问拓扑：
>> 更全面的可观测：从功能优化到用户体验提升的再进化
在使用监控我们通常会面临以下问题:
这些问题乍看之下较为简单，然而，随着对监控系统的使用程度不断加深，疑问也会愈发增大。我们充分认识到，我们的监控系统拥有巨大的发展潜力。为此，我们致力于消除这些使用过程中的障碍，以实现将监控系统的上下限同步拓宽。
1. 菜单优化：
在原监控菜单中，存在选项繁多、层级复杂的问题。同时，核心功能与非核心功能平铺展示，致使核心功能被淹没其中，整体呈现相对混乱。
鉴于此，我们实施了重大调整，将菜单划分为事件中心、系统态势、服务观测、资源监控、指标分析以及设置等板块，下拉即可查看细分类目。其中新菜单中的系统态势、服务观测、资源监控是监控核心，我们也正是围绕着系统、服务、资源三位一体的理念构建的整个监控系统。
2. 监控资源覆盖：
关于我们的监控能覆盖哪些资源的问题，此前在我们的产品页面上，并无明确展示监控所能覆盖的资源以及相应的监控手段。
鉴于此，我们在产品页面增设了通用监控和资源监控：
-
通用监控：能够对HTTP、TCP、TCP Ping、进程监控以及日志类等内容进行监控；
-
资源监控：可对主机、K8S、DOCKER、MySQL 等资源进行监控。
将这些资源平铺展示，使用户能够清晰直观地看到我们所能覆盖的资源范围，且这些均为标准资源，包稳的。此次，首批标准化覆盖了45个资源，后续还会有二、三批资源陆续推出。
当用户点击资源时，可以看到资源对应的套件以及采集任务等信息，能够从资源维度了解有哪些采集脚本以及当前正在执行的任务。
同时，我们提供详尽的使用指引，阐释了诸如开通账号、明确权限等接入和采集的基本问题，确保进行监控采集配置的顺利进行。
3. 指标采集：
在监控使用的实际操作中，用户可能会产生诸如以下困惑：
为此，我们改变了产品思路，以应用系统为中心建设监控平台。首先构建应用系统管理体系，通过主机Agent的智能扫描轻松完成自下而上的应用系统资源纳管。然后初始化为监控资源，以系统为中心进行监控采集。
采控平台的数据采集分为系统监控和其他监控。
点击系统监控进入系统树，选择任意系统可查看该系统相关采集，如指标采集、主动拨测、日志监控、链路自动采集等。通过系统及采集方式，可明确不同监控的用途，如拨测用于可用性/存活监控，日志用于业务监控等，能清晰了解一个系统下的采集情况。
采集的具体操作如下：点击采集后新建采集时，需先选择采集对象所属的系统和环境，接着设置采集实例时，所选实例范围仅为已选系统和环境下的资源实例，不会出现其他实例。从而做到核心系统、生产环境的资源隔离。
同时，系统态势感知页面也添加了采集标签和新建入口，可进行快速操作。
4. 查看监控指标数据：
Q：完成采集后，如何查看监控数据呢？
A：以系统为中心多层级的立体数据统一展示！
以下图为例，点击 “Redis”，可抽出看到Redis的专用监控视图，包括节点状态、请求分析等内容。在系统态势感知中，对于这类标准中间件，都可以看到其对应的专业监控视图；而对于资源服务应用，由于无法标识标准指标，则可自行挑选指标并挂载 dashboard 来查看资源服务监控。
另外，系统标签也做了优化，基于客户反馈以满足其看到更多信息的需求，当前标签可查看系统、应用、主机、容器组四大类。
四类标签下都可以实现对应的日志搜索，对于主机日志，支持从 agent 实时搜索日志，且通过预定义能力，无需手动输入日志路径，快速选择所需路径；应用与主机联动。无论是从系统还是应用服务下搜索日志，都能获取相应的主机日志。
在以前的日志搜索中，每次都需要人为输入日志路径，较为麻烦，新版本已解决该问题。7.6版本支持日志路径预先定义，允许用户使用通配符预定义日志路径，往后便无需每次都输入日志路径查找；并且基于大家看日志看最后的习惯，我们也将最新更新的日志文件放置最后，便于查找；针对多行日志（如堆栈）进行默认整合，避免了以往通过关键字过滤后堆栈信息丢失的情况，在查找error等情况时能更好地展示堆栈信息。
在架构视图方面，实现了架构视图与监控数据的融合。
新版本能够通过架构视图去查看监控指标、渲染监控数据，同时，架构视图中的每个点点击后弹出的抽屉与态势感知保持一致。
另外，有些情况并非以系统为单位进入，例如主机运维，我们将主机的监控应用视图和自定义视图进行了融合，既可以使用出厂默认的指标视图，也可以根据需要采集指标来自定义视图，甚至可以将自定义视图设置为默认概览页。
5. 告警处理：
面对告警处理我们通常关注：
-
告警产生的源头分析，包括采集任务（如脚本等）是否正常、告警规则（阈值和通知内容）是否合理；
-
告警状态的时间特征以及稳定性判断，即告警的产生时间、是否持续波动；
-
告警的综合分析及处理反馈，包括查看关联指标、确定通知对象、通知是否成功送达。
每一个关注点背后都是希望获取相应的信息，而告警处理页面作为监控系统日常使用的页面，展示信息有限，存在下转需求。7.6版满足你！
展示标签包括有所属系统、关联应用、报警规则、采集任务、指标大屏和通知标记等，每个标签均可下转查看相对应的信息。如，通知标记展示发送人数，点击可查看发送人名称、通知是否成功、通知内容及趋势等信息。
PS：指标大屏点击不直接跳转，而是给出实时抓取的几个路径供自主选择跳转，一个贴心的小交互送给大家。
更值得留意的是，我们已将 AI 融入告警分析页面。点击 AI 小按钮，右侧便会呈现告警分析模块，能够实时分析告警。其分析过程大致为：先确定告警类型、指标、指标阈值、持续时长、是否已发送通知以及报警起始时间等关键信息，AI 依据这些信息在故障排查知识库中进行检索，进而动态生成排查计划，如采用排查磁盘、进程、内存、日志等手段。接着逐一执行这些分析手段，再对执行结果进行分析，最终给出分析结果。
目前版本做到了将原本需人工在机器上进行的各种排查工作交由 AI 完成，并对结果进行简单分析后提供给用户查看，但未直接给出结论。虽然已实现智能与自动操作，但我们并不满足于此，仍在持续探索中。下一阶段，AI 告警分析将进一步为用户提供结论，甚至做到更加智能化。
>> 数据可视化大屏优化：关于提升效率、降低成本的新一轮“死磕”
如今数据可视化大屏成为众多企业提升决策效率、展示实力的关键工具，深受客户喜爱。在过去半年，我们承接了大量大屏需求，已成功覆盖40+客户，且每个客户往往拥有多个大屏。大言不惭的说，在大屏方面可谓已有相当沉淀，为此我总结分析历史项目，针对大屏做了以下优化：
-
制作大屏专属卡片：
大屏专属卡片，使数据呈现更加精准、高效；
-
提升数据对接灵活性：
提升 Dashboard 大屏对接数据的灵活性，以近期2个项目为例，一个现场仅需对少量卡片进行额外数据加工；另一个，网络拓扑图的告警提示完全依靠平台自带接口，无需现场编写脚本，极大减少了人力时间成本；
-
提供完善操作指引：
用户在平台安装后，可通过右上角小问号进入监控产品模块，找到仪表盘专门说明，轻松上手操作。
这一系列优化措施成效显著，极大地提升了大屏的交付效率，同时大幅降低了实施成本。原本每块大屏平均需20人/天的高成本，经优化后可降低10倍左右。
- end -
1421
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
