如何建立基于数据的统一监控平台?
现如今,越来越多的企业想要建设统一监控平台,但不知道从哪里开始着手。比如:
◇ 有些企业会直接将监控系统页面集成到统一监控的门户里,当作统一的监控平台。
◇ 有些企业把所有告警事件集中到统一系统里进行处理和流转。
◇ 还有些企业把所有数据比如性能数据、日志数据、事件数据接入大数据的平台,企图应用大数据平台的计算能力来完成统一监控。
如果没有明确的目标,缺少体系化的思考,这些做法会在后续使用的过程中面临各式各样的问题。
因此,我们邀请到嘉为蓝鲸产品总监苏文老师,为我们讲解建设基于数据的统一平台思路,希望能给有想建设统一监控平台的企业带来一些启发。
一、监控系统的六大核心模块
统一监控平台,说到底本质上也是一个监控系统,监控的基本能力是必不可少的,回归到监控的本质,先梳理下整个监控体系。
监控系统的本质是通过发现故障、解决故障、预防故障,从而保障业务的稳定。
监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理6大模块。
而数据采集、数据检测和告警处理是监控的最小闭环,但如果想要真正把监控系统做好,那故障管理闭环、视图管理、监控管理的模块也缺一不可。
1.数据采集
1)采集方式
数据采集一般分为Agent模式和非Agent模式。
- Agent模式包括插件采集、脚本采集、日志采集、进程采集、APM探针等。
- 非Agent模式包括通用协议采集、Web拨测、API接口等。
2)数据类型
监控的数据类型有指标、日志、跟踪数据三种类型。
◇ 指标数据是数值型的监控项,主要是通过维度来做标识。
◇ 日志数据是字符型的数据,主要是从中找一些关键字来做监控。
◇ 跟踪型数据反馈的是跟踪链路一个数据流转的过程,观察过程中的耗时是否正常。
由于数据类型不同,也衍生出三类不同的监控系统。
◇ 指标类型的监控,典型代表比如Zabbix、普罗米修斯。
◇ 日志类常见的监控系统有日志易、Splunk等,主要关注日志类数据的分析和监控。
◇ 跟踪型的系统是通过trace ID请求的过程来进行监控,即APM(应用性能监控)类型的监控,例如Dynatrace、Skywalking等。
由于三种数据互不兼容,导致数据存储分散,不利于集中分析,而近两年兴起的OpenTelemetry,将三种数据格式的输入和消费实现了统一,但并没有解决存储和分析的问题。
目前主流解决方案还是将三类数据存储到不同的库中,再封装一层统一的查询层,屏蔽数据存储层的差异,实现集中的分析查询。
3)采集频率
采集频率分秒级、分钟级、随机三种类型。常用的采集频率为分钟级。
- 关于分钟级与秒级
越来越多的客户开始对秒级有一种执念,觉得越快越好,认为越快就能更快发现问题。但是秒级的采集频率的增加,这对目标机器性能的影响也会增加,若因为数据采集导致业务性能本身出现问题,这就本末倒置了。
而且,随着数据量加倍,存储成倍增加,计算量级指数型增长,带来的成本损耗可能远超秒级监控带来的好处。在真实的应用场景中,大家需要思考使用秒级频率是否值得。这提前十几秒的告警发现,运维人员是否能够在这十几秒的时间内把问题解决掉,如果解决不掉,那秒级监控并没有太大的意义。比如腾讯游戏的业务是以秒来赚钱,所以需要针对关键指标需要做到秒级监控,配合自动伸缩替换故障节点,可以实现秒级恢复。这种情况下的秒级监控必不可少。
秒级监控是监控系统的一种必备的能力,但并不是所有的指标数据都需要秒级监控,需要挖掘真正的场景需求来判断是否需要这个秒级监控,而不是为了秒级而秒级,白白浪费资源,徒增维护成本。
- 随机采集
随机适用于增量采集或触发式采集,采集频率不定。主要场景是日志采集、应用系统异常事件上报。
4)采集传输
采集传输可按传输发起分类,也可按传输链路分类。
◇ 按传输发起分类有主动采集Pull(拉)、被动接收Push(推)。
◇ 按传输链路分类有直连模式、Proxy传输。
其中,Proxy传输不仅能解决监控数据跨网传输的问题,还可以缓解监控节点数量过多导致出现的数据传输的瓶颈,用Proxy实现数据分流。
5)数据存储
对于监控系统来说,主要有以下三种存储供选择:
- 关系型数据库
由于数据库本身的限制,很难搞定海量监控的场景,有性能瓶颈,只在传统监控系统常用。
例如MySQL、MSSQL、DB2;典型监控系统代表:Zabbix、SCOM、Tivoli。
- 时序数据库
为监控这种场景设计的数据库,擅长于指标数据存储和计算。
例如InfluxDB、OpenTSDB(基于Hbase)、Prometheus等;典型监控系统代表:TICK监控框架、 Open-falcon、Prometheus。
- 全文检索数据库
这类型数据库主要用于日志型存储,对数据检索非常友好,例如Elasticsearch。
2. 数据检测
1)数据加工
- 数据清洗
数据清洗比如日志数据的清洗,因为日志数据是非结构化的数据,信息密度较低,因此需要从中提取有用的数据。
- 数据计算
很多原始数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量,如果要检测磁盘使用率,就需要对现有指标进行一个简单的四则运算,才能得到磁盘使用率。
- 数据丰富
数据丰富就是给数据打上一些tags标签,比如打上主机、机房的标签,方便进行聚合计算。
- 指标派生
指标派生指的是通过已有的指标,通过计算得出新的指标。
2)检测算法
有固定规则和机器学习算法。
◇ 固定算法是较为常见的算法,静态阈值、同比环比、自定义规则
◇ 机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。
无论是固定规则还是机器学习,都会有相应的判断规则,即常见的< > >=和and/or的组合判断等。
2. 告警管理
1)告警丰富
告警丰富是为了后续告警事件分析做准备,需要辅助信息去判断该怎么处理、分析和通知。
告警丰富一般是通过规则,联动CMDB、知识库、作业历史记录等数据源,实现告警字段、关联信息的丰富。
通过人工打Tags也是一种丰富方式,不过实际场景下由于人工成本高导致难以落地。
2)告警收敛
告警收敛有三种思路:抑制、屏蔽和聚合。
- 抑制
即抑制同样的问题,避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。
- 屏蔽
屏蔽可预知的情况,比如变更维护期、固定的周期任务这些已经知道会发生的事件,心里已经有预期。
- 聚合
聚合是把类似或相同的告警进行合并,因为可能反馈的是同一个现象。
比如业务访问量升高,其他性能也飙升,这样把这些性能都聚合到一块,那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升,这样把这些性能指标都聚合到一块,更加便于告警的分析处理。
3)告警通知
- 通知到人
通过一些重要的渠道,能够触达到人。
这样在没有人盯屏的时候,可以通过微信、短信、邮件触发到工作人员。
- 通知到系统
一般通过API推送给第三方系统,便于进行后续的事件处理。另外还需要支持自定义渠道扩展(比如企业里有自己的IM系统,可以自行接入)
3. 故障管理
告警事件必须要处理有闭环,否则监控是没有意义的。
- 人工处理
这是最常见的方式,值班、工单、故障升级等。
- 经验积累
可以把人工处理的故障积累到知识库里面,为自动化处理做准备。
- 自动处理
通过提取一些特定告警的固化处理流程,实现特定场景的故障自愈,比如磁盘空间告警时把一些无用日志清掉。
- 智能分析
主要是通过故障的关联分析、定位、预测等AI算法,进一步提升故障定位和处理的效率。
4. 视图管理
视图管理也属于增值性功能,主要是满足人的心理述求,做到心中有底,面向的角色很多(领导、管理员、值班员等)。
- 大屏
面向领导,提供全局概览。
- 拓扑
面向运维人员,提供告警关联关系和影响面视图。
- 仪表盘
面向运维人员,提供自定义的关注指标的视图。
- 报表
面向运维人员、领导,提供一些统计汇总报表信息,例如周报、日报等。
- 检索
面向运维人员,用于故障分析场景下的各类数据检索。
5. 监控管理
监控管理是企业监控落地过程中的最大挑战。
前5个模块都是监控系统对外提供的服务功能,而监控管理才是面向监控系统自身的管理和控制,关注真正落地的过程的功能呈现。主要有以下几个方面:
◇ 配置:简单、批量、自动
◇ 覆盖率:监控水平的衡量指标
◇ 指标库:监控指标的规范
◇ 移动端:随时随地处理问题
◇ 权限:使用控制
◇ 审计:管理合规
◇ API:运维数据最大的来源,用于数据消费
◇ 自监控:自身稳定的保障
二、监控平台建设的现状和传统建设模式的挑战
1. 监控建设的现状
一般来说,企业监控建设的现状主要分成四个阶段:监控工具建设阶段、统一监控建设阶段、智能分析建设阶段、主动防御建设阶段,目前大部分企业都处在第一和第二阶段之间挣扎。
◇ 第一阶段的主要目标是全覆盖,能够全面监控对象,全面感知告警。
◇ 第二个阶段的核心重点在于管理,需要有统一的指标体系和统一的事件管理流程,同时也是为第三个阶段做数据的准备。
◇ 第三阶段重点关注的是效率提升,之前要配很多阈值的算法,有了智能检测算法就不需要再每个每个指标配置阈值了。而关联影响分析能够利用机器学习帮助机械能问题定位分析,减少人工定位分析的时间消耗。
◇ 第四阶段的核心是预防,提前预测来采取一些措施,去预防相关问题的发生。比如根据磁盘损耗的速率变化趋势,预测1个月后磁盘可能会坏掉,这样提前更换磁盘,将事故消灭在萌芽中。
2. 传统监控系统建设所面临的挑战
由于大部分传统监控系统在建设之初并没有考虑到统一监控,定位都是做一个监控的工具,在建设统一系统时,会面临以下困难和挑战:
◇ 技术演进快,监控复杂度日益升高;
◇ 监控工具多,统一治理无从下手;
◇ 工具互相隔离,无法联动协同,效率低下;
◇ 升级扩展慢,无法响应快速发展的业务要求;
◇ 系统复杂度高,故障分析定位难,业务损失大。
以上种种挑战都导致了企业亟待建设一个统一监控平台。
三、从两个层面建设统一监控平台
1. 产品能力上
除了需要有灵活的扩展能力,能够广泛适配各种对象的监控数据接入外,还得有统一采集、统一检测、统一告警、统一展示四个基本能力。
2. 产品架构上
主要为三层:接入层、能力层、功能层.
1)接入层
主要考虑各种数据的接入,除了本身Agent和插件的采集接入,还需要支持第三方监控源的数据接入,才能算一个完整的统一监控平台。
2)能力层
主要考虑监控的基础通用能力,包含数据采集模块、数据存储模块、数据加工模块、数据检测模块、AI分析模块。
3)功能层
功能层需要贴近用户使用场景,主要有管理、展示两类功能,在建设的过程中可以不断丰富功能场景。
另外,考虑到数据的关联关系,为未来的数据分析打下基础,监控和CMDB也需要紧密联动,所有的监控对象都应该用CMDB进行管理。
还可以配置驱动监控为指导理念,实现监控的自动上下线,告警通知自动识别负责人等场景,简化监控的维护管理。
嘉为蓝鲸统一监控平台的功能界面
1.基于CMDB的指标管理
联动CMDB,把CMBD的对象纳入到统一监控平台,并对监控对象的指标进行统一管理。至于如何去梳理构建整个监控指标体系,是接下来第4部分要讲解的内容。
2. 配置驱动监控
通过动态分组来实现,利用CMDB已知的属性来作为判断条件,去创建动态分组。
整个分组的实例是动态变化的,只有满足条件的的实例才会纳入分组,不满足时会自动剔除分组。
监控如果识别到实例数的动态变化,实现监控的自动上下线操作。
3. 插件式采集扩展
监控平台需要接受各种各样的数据,不仅支持监控对象的数据采集。还支持将第三方监控源的数据接入到平台,进行统一管理。
整个插件的设计可以直接在页面进行编辑或上传,这样扩展性会比较强,扩展也非常简单方便。
4. 模板化策略配置
强调模板化配置,根据不同的场景设置不同的模板。
比如说对测试环境,做一个主机测试环境的模板, 对生产环境做主机生产环境的策略模板,这样就减少监控配置量。
5. 集中事件中心
将前面产生的策略和告警事件在事件中心呈现,给出一些辅助信息比如指标、数据流转信息、字段等,帮助进行故障排查。
6. 动态菜单视图功能
第一个视角是资源视角,以动态菜单的形式去做,菜单根据添加的监控对象来自动生成。
第二个视角是应用视角,形式是应用监控视图。是为了在应用层面来看监控对象是否正常,应用的拓扑哪些节点发生了问题等。
四、构建指标体系的理念和规范
1. 核心理念
◇ 监控的指标体系是以CMDB为骨架,以监控指标为经脉,将整个统一监控平台的数据有机结合起来。
◇ 贯穿指标的生命周期管理,辅以指标的管理规范,保障监控平台长久有序的运行。
2. 指标管理规范
1)设计原则示例
最重要的是可度量、可采集、可理解、可消费。
落到监控指标,还有两个辅助原则,即构建统一监控指标体系规范;明确监控目标和消费场景。
2)指标分层的示例
从企业业务应用的视角出发,一般将企业监控的对象分为6层:基础设施层、硬件设备层、操作系统层、组件服务层、应用性能层、业务运营层。也可以根据企业自己的情况进行调整。
3. 指标分级规范
一般分三级,按重要程度区分:核心指标、关键指标和常规指标。
◇ 核心指标一般不会定太多,主要反映这个监控对象是活着还是死了,1到2个即可。
◇ 关键指标是看核心性能是否正常,参考谷歌定义的SRE四大常规指标。
◇ 常规指标可以根据实际的业务场景去考虑。
通过不同指标的分级、权重,可以建设模型,衡量整个业务的健康情况。
4. 命名规范示例
没有绝对的标准,可读就行,可根据企业情况自行设定。
5. 指标管理流程
目的是让整个指标的生命周期管理顺利运行下去,可以根据企业实际情况来设计相关流程。
本次直播主要讲述了四个部分,第一部分讲解了监控体系(采集-检测-告警-故障-视图-管理),第二部分讲解了现状和挑战,第三部分介绍了统一监控平台的产品设计(产品能力和产品架构两个角度),第四部分梳理了指标体系的建设管理(核心是以CMDB为骨架、以监控指标为经脉),保障统一监控平台的顺利落地。
精选互动问答
问:告警丰富阶段的处理时间,是否会影响到告警发送的及时性呢?
答:告警丰富是需要一定的时间损耗的,会影响告警发送及时性,但是相对于后期去找这些信息的时间来看,告警丰富所花时间几乎可以忽略不计,另外告警丰富之后,带来的更多信息除了可以辅助排错,还可以根据丰富的新的字段进行收敛、聚合等。
问:监控模板也是放置在CMDB吗,还是放在监控平台呢?
答:监控模板肯定放在监控平台,只不过监控模板应用的对象范围可以和CMDB联动,效果更佳
问:统一监控里包含网络性能监控吗?
答:统一监控平台是可以接入第三方网络监控系统数据的,例如Zabbix。
问:统一监控初期建设的时候,需要对接很多已有监控平台,比如Zabbix、Prometheus、听云、网管neteagle等,这个阶段应该如何对现有监控的纳管呢?
答:可以考虑分阶段建设:
1、建设CMDB,将所有的监控系统的监控对象和CMDB的对象对齐,为统一监控建设打下基础
2、将所有的监控系统的告警事件进行统一管理,联动CMDB进行告警的收敛和影响分析,提升告警处理效率,节省告警处理的时间,释放人力进行后期建设
3、梳理企业内部的指标管理体系,建立监控的管理规范和流程,将所有的监控系统的性能数据按指标体系接入统一监控平台,注意联动CMDB,实现统一管理和视图
4、引入AI平台,基于统一监控平台的数据进行智能检测和分析,进一步提升人效
问:监控系统和告警系统是两个团队去开发的么? 两者会有一些耦合的部分么? 比如对于CMDB 的依赖。
答:监控系统和告警系统是分开开发的,但是产品设计是统一设计的,两套系统可以直接联动,监控系统的告警事件可以直接推送到告警系统中,并且可以关闭监控系统中原有的告警通知功能,让两边的联动更加友好。且监控系统中和CMDB建立的关联关系,推送到告警系统中之后,CMDB关联关系依旧会保存下来,不必要重复建设关联关系。
推荐阅读
-
从 0 到 1 建立基于大数据的质量平台
-
如何建立基于数据的统一监控平台?
-
如何建立一个让用户满意的 "即服务 "数据平台 - 那么,为什么要提供服务?
-
智能消防:如何构建基于视频监控和智能分析技术的消防可视化风险预警平台?
-
移动云加强全方位云网保护,守护数字中国发展 - 新增云安全中心涵盖终端安全,整合EDR的查杀、预警、应对及溯源功能,实现终端安全管理一体化。它能迅速定位并处理各类网络威胁,如病毒、入侵和新漏洞,减少人工应对负担。EDR在HVV行动中是关键防护,能在终端建立坚固防线,阻止威胁扩散,并协同其他产品追踪攻击链路。 态势感知全面覆盖监控、审计、运维、评估和预警等多个方面,针对混合云环境,提供统一业务安全管理、全面安全信息收集、智能安全事件关联分析以及系统性能与可用性的全面检测,满足等保标准、安全运营、数据保护和重要时期的保障需求。 云堡垒机推出全新混合云版本,支持混合云、私有云及客户自建平台部署,专为运维资源管理和审计提供安全保障。安全资源池行业版则针对于私有云和行业云,提供定制化的场景化安全合规整体解决方案,并可根据需要提供改造、统一管理、远程更新等一系列配套服务。 共同构建安全、便捷且高效的远程办公环境。
-
玩转Java底层:JMX详解 - jconsole与自定义MBean监控工具的实际应用与区别" 在日常JVM调优中,我们熟知的jconsole工具通过JMX包装的bean以图形化形式展示管理数据,而像jstat和jmap这类内建监控工具则由JVM直接支持。本文将以jconsole为例,深入讲解其实质——基于JMX的MBean功能,包括可视化界面上的bean属性查看和操作调用。 MBeans在jconsole中的体现是那些可观察的组件属性和方法,如上图所示,通过名为"Verbose"的属性能看到其值为false,同时还能直接操作该bean的方法,例如"closeJerryMBean"。 尽管jconsole给我们提供了直观的可视化界面,但请注意,这里的MBean并非固定不变,开发者可根据JMX提供的接口将自己的自定义bean展示到jconsole。以下步骤展示了如何创建并注册一个名为"StudyJavaMBean"的自定义MBean: 1. 首先定义接口`StudyJavaMBean`,接口需遵循MBean规范,即后缀为"MBean"且包含getter方法代表属性,如`getApplicationName`,和无返回值的setter方法代表操作,如`closeJerryMBean`。 ```java public interface StudyJavaMBean { String getApplicationName(); void closeJerryMBean(); } ``` 2. 编写接口的实现类`StudyJavaMBeanImpl`,实现接口中的方法: ```java public class StudyJavaMBeanImpl implements StudyJavaMBean { @Override public String getApplicationName() { return "每天学Java"; } @Override public void closeJerryMBean() { System.out.println("关闭Jerry应用"); } } ``` 3. 在代码中注册自定义MBean,涉及的关键步骤包括: - 获取平台MBeanServer - 定义ObjectName,指定唯一的MBean标识符 - 注册MBean到服务器 - 启动RMI连接器服务,以便jconsole能够访问 ```java public void registerMBean() throws Exception { // ... 具体实现省略 ... } ``` 实际运行注册后的MBean,您将在jconsole中发现并查看自定义bean的属性和调用相关方法。然而,这种方式相较于传统的属性/日志查看和HTTP接口,实用性相对有限,可能存在潜在的安全风险。但不可否认的是,JMX及其MBean机制对于获取操作系统信息、内存状态等关键性能指标仍然具有重要价值。例如: 1. **获取操作系统信息**:通过JMX MBean,可以直接获取到诸如CPU使用率、操作系统版本等系统级信息,这对于资源管理和优化工作具有显著帮助。
-
Grid++Report 锐浪报表开发常见问题解答集锦-报表设计 问:怎样在设计时打印预览报表? 答:为了及时查看报表的设计效果,Grid++Report 报表设计应用程序提供了四种查看视图:普通视图、页面视图、预览视图与查询视图。通过窗口下边的 Tab 按钮可以在四种视图中任意切换。在预览视图中查看报表的打印预览效果,在查询视图中查看报表的查询显示效果。如果在报表的记录集提供了数据源连接串与查询 SQL,在进入预览视图与查询视图时会利用数据源连接串与查询 SQL 从数据源中自动取数,否则 Grid++Report 将自动生成模拟数据进行模拟打印预览与查询显示。注意:在预览视图与查询视图中看到的报表运行结果有可能与在你程序中的最终运行结果有差异,因为在报表的生成过程中我们可以在程序中对报表的生成行为进行一定的控制。 问:怎样用 Grid++Report 设计交叉表? 答:Grid++Report 没有提供专门实现交叉表的功能,其它的报表构件提供的交叉表功能一般也比较死板和功能有限。利用 Grid++Report 的编程接口可以做出灵活多变,功能丰富的交叉表。示例程序 CrossTab 就是一个实现交叉表的例子程序,认真领会此例子程序,你就可以做出自己想要各种交叉表,并能提取一些共用代码,便于重复使用。 问:怎样设置整个报表的缺省字体? 答:设置报表主对象的字体属性,也就是设置了整个报表的缺省字体。如果改变报表主对象的字体属性,则没有专门的设置字体属性的子对象的字体属性也跟随改变。同样每个报表节与明细网格也有字体属性,他们的字体属性也就是其拥有的子对象的缺省字体。 问:怎样在打印时限制一页的输出行数? 答:设定明细网格的内容行的‘每页行数(RowsPerPage)’属性即可。另外要注意‘调节行高(AdjustRowHeight)’属性值:为真时根据页面的输出高度自动调整行的高度,使整个页面的输出区域充满。为假时按设计时的高度输出行。 问:怎样显示中文大写金额? 答:将对象的“格式(Format)”属性设为 “$$” 及可,可以设置格式的对象有:字段(IGRField)、参数(IGRParameter)、系统变量(IGRSystemVarBox)与综合文字框(IGRMemoBox),其中综合文字框是在报表式上设格式。 问:能否实现自定义纸张与票据打印? 答:Grid++Report 完全支持自定义纸张的打印,只要在报表设定时在页面设置中选定自定义纸张,并指定准确的纸张尺寸。当然要在最终输出时得道合适的打印结果,输出打印机必须支持自定义纸张打印。Windows2000/XP/2003 操作系统上可以在打印机上定义自定义纸张,也可以采用这种方式实现自定义纸张打印。 问:怎样实现 0 值不打印? 答:直接设置格式串就可以,在“数字格式”设置对话框中选定“0 不显示”,就会得到合适的格式串。也可以通过直接录入格式串来指定 0 不显示,但格式串必须符合 Grid++Report 的规定格式。另一种实现办法是在报表获取明细记录数据时,在 BeforePostRecord 事件中将值为零的字段设为空,调用字段的 Clear 方法将字段置为空。 问:怎样实现多栏报表? 答:在明细网格上设‘页栏数(PageColumnCount)’属性值大于 1 即可。通过 Grid++Report 的“页栏输出顺序”还可以指定多栏报表的输出顺序是“先从上到下”还是“先从左到右”。 问:如何实现票据套打? 答:Grid++Report 为实现票据套打做了很多专门的安排:报表设计器提供了页面设计模式,按照设定的纸张尺寸显示设计面板,如果将空白票据的扫描图设为设计背景图,在定位报表内容的输出位置会非常方便。报表部件可以设定打印类别,非套打输出的内容在套打打印模式下就不会输出。 问:Grid++Report 有没有横向分页功能? 答:回答是肯定的,在列的总宽度超过打印页面的输出宽度时,Grid++Report 可以另起新页输出剩余的列,如果左边存在锁定列,锁定列可以在后面的新页中重复输出,这样可以保证关键数据列在每一页都有输出。仔细体会 Grid++Report 提供的多种打印适应策略,选用最合适的方式。Grid++Report 的多种打印适应策略为开发动态报表提供了很好的支持。 问:怎样实现报表本页小计功能? 答:定义一个报表分组,将本分组定义为页分组,在本分组的分组头与分组尾上定义统计。页分组就是在每页产生一个分组项,在每页的上端与下端都会分别显示页分组的分组头与分组尾,页分组不用定义分组依据字段。 报表运行 问:怎样与数据库建立连接? 答:如果在设计报表时指定了数据集的数据源连接串与查询 SQL 语句,Grid++Report 采用拉模式直接从数据源取得报表数据,Grid++Report 利用 OLE DB 从数据源取数,OLE DB 提供了广泛的数据源操作能力。如果 Grid++Report 的数据来源采用推模式,即 Grid++Report 不直接与数据库建立连接,各种编程语言/平台都提供了很好的数据库连接方式,并且易于操作,应用程序在报表主对象(IGridppReport)的 FetchRecord 事件中将数据传入,例子程序提供了各种编程语言填入数据的通用方法,对C++Builder 和 Delphi 还进行了专门的包装,直接关联 TDataSet 对象也可以将 TDataSet 对象中的数据传给报表。 问:打印时能否对打印纸张进行自适应?支持表格的折行打印吗? 答:Grid++Report 在打印时采用多种适应策略,通过设置明细网格(IGRDetailGrid)的‘打印策略(PrintAdaptMethod)’属性指定打印策略。(1)丢弃:按设计时列的宽度输出,超出范围的内容不显示。(2)绕行:按设计时列的宽度输出,如果在当前行不能完整输出,则另起新行进行输出。(3)缩放适应:对所有列的输出宽度进行按比例地缩放,使总宽度等于页面的输出宽度。(4)缩小适应:如果列的总宽度小于页面的输出宽度,对所有列的输出宽度进行按比例地缩小,使总宽度等于页面的输出宽度。(5)横向分页:超范围的列在新页中输出。(6)横向分页并重复锁定列。 问:如何改变缺省打印预览窗口的窗口标题? 答:改变报表主对象的‘标题(Title)’属性即可。 问:利用集合对象的编程接口取子对象的接口引用,但不是自己期望的结果。 答:Grid++Report中所有集合对象的下标索引都是从 1 开始,另按对象的名称查找对象的接口引用时,名称字符是不区分大小写的。 问:怎样在运行时控制报表中各个对象的可见性?即怎样在运行时显示或隐藏对象? 答:在报表主对象(GridppReport)的 SectionFormat 事件中设定相应报表子对象的可见(Visible)属性即可。 问:报表主对象重新载入数据,设计器中为什么没有反映新载入的数据? 答:应调用 IGRDesigner 的 Reload 方法。 问:怎样实现不进入打印预览界面,直接将报表打印出来?