- 一、背景介绍
- 二、注册
-
三、功能
- Dashboards & reports
- Dashboards
- Reports
- Analyze
- Problems
- User Sessions
- Log files
- Smartscape topology
- CPU profiler (code-level)
- Monitor
- Applications
- Synthetic availablity
- Transactions & services
- Databases
- Hosts, Network, Technologies, VMware, AWS, Docker
- Manage
- Deploy Dynatrace
- Deployment status
- Settings
- Dashboards & reports
- 四、总结
一、背景介绍
https://www.dynatrace.com/zh/ 是一家“客户导向时代的数字化性能管理”公司,具有“革命性的应用性能监测”。
它的主要功能包括以下几个方面,对我们做审计、日志、监控、拓扑等系统有借鉴效果。所以使用一下。
二、注册
注册-新建账号.png注册-补充信息.png
注册-选择区域.png
注册成功.png
注册完成后的基本页面如下:
Dynatrace首页.png
三、功能
从左边的菜单栏来看,包括了4各模块:"Dashboards & reports", "Analyze", "Monitor", "Manage"。
Dashboards & reports
Dashboards
新建Dashboard,新建各式各样的Chart,再添加进Dashboard。(应该和Kibana类似,但是没有数据,也没尝试)。上面注册完的截图就表示了名为Home的Dashboard,然后包含了一些基本的Chart。点击右上角的 Edit,可以拖拽、删除、编辑、设置默认时间范围(默认最近两小时)等。Dashboard里有Title、Section、Layout等概念,同时可以分享、复制、删除Dashboard。
Dashboards.png
Reports
这里的reports是针对服务质量的。从世界各地选取三个(充钱就可以选择更多)服务器对某个Web服务进行探活,每15分钟一次,每周出一个报表。
Reports.png
一个Report样例:
1. Title: Service quality: Aug 14 - Aug 20, 2017
2. Content:
a. Service quality report: Dynatrace score (Applications, Services, Infrastructure, User actions monitored, Service calls monitored, Host hours monitored)
* Application score: Apdex, Problematic user actions
* Service score: Failure rate, Problematic calls
* Infrastructure score: Problematic hours
b. No infrastructure problems detected
c. Peak infrastructure usage
Report样例.png
Analyze
Problems
这是一个监控告警模块。它对应用的性能、流量、错误进行监控,并通过自动检查各服务的依赖关系来判断故障的影响范围并查找故障的具体原因。该模块还提供了回放机制,用以方便地定位和解决问题。
此外,“设置通知”可以帮助客户及时地知晓故障情况,该功能在 “Manage -> Settings” 里。
User Sessions
用户分析依赖于用户的监控数据,这些数据包括了用户的地点、操作系统、浏览器、IP地址、屏幕分辨率、JS错误等等。以下是一个示例:
User Sessions.png
这里,可以针对多个维度进行聚合:
- by application: blog.mysite.com, dynatrace.com
- by browser: Mobile, Desktop, Tablet, Robots, Synthetic
- by bounce: Yes, No
- by converted: Yes, No
- by conversion goals: Subscription, Upgrade, Checkout, More than 20 actions
- by browser type: Desktop browser
- by JavaScript error count: 出现0次错误的session的数量,出现1次错误的session的数量,出现2次错误的session的数量 。。。
-
by location:
按地理位置聚合.png - by ISP
- by OS: Andriod, Windows
- over time: 如上
-
per hour: 这个图很直观
按登录的小时聚合.png - by screen resolution: 768576, 25602048, 5120*2880, ...
- by user action count: 类似#7,by JS error
- by users
优点:每张图都很清晰明了,#2和#10是饼图,#8是地图,#12是钟表图,其他都是柱状图。而且柱状图比饼图要更清晰,而且当文字比较长的时候不会有重叠的问题。
Log files
选中Demo Host,选中Demo process group instance,选中3个demo log,然后即可对这些日志进行搜索分析了。
Dynatrace实现了一套类似Lucene的搜索语法:https://help.dynatrace.com/infrastructure-monitoring/log-analytics/dynatrace-search-query-language/
Dynatrace的搜索引擎2.png
Dynatrace的搜索引擎3.png
Summarized就是做了一下聚合。这里的View chart by source,只能看到 demo1.log ,不知道是什么原因。
Smartscape topology
智能拓扑图-应用.png智能拓扑图-服务.png
智能拓扑图-进程.png
智能拓扑图-主机.png
智能拓扑图-数据中心.png
CPU profiler (code-level)
无数据,空
Monitor
Applications
应用监控包括Web App和Mobile App,涵盖了性能、用户行为等数据。同时点击上部分的每个数据,都会在下面展示详细信息,比如Network performance, Called Services
应用监控-性能分析.png
应用监控-用户行为.png
应用监控-服务状况.png
Synthetic availablity
对服务的可用状况进行监控
服务的可用状况-即探活.png
Transactions & services
Transactions & services.pngDatabases
数据库.pngHosts, Network, Technologies, VMware, AWS, Docker
这6个监控模块,各自监控一些基础指标,同上面的Transactions、Databases类似。
Manage
Deploy Dynatrace
在Windows、Linux、AIX环境部署Dynatrace的步骤。
在Linux系统中,首先下载一个90M的shell脚本,再签名校验,最后运行该脚本即可。通过该流程,在目标服务器上按照了一个Agent(Dynatrace-OneAgent-Linux-1.125.168.sh),然后自动上传服务器、应用信息,接着可以在Deployment status里查看状态,并在Settings里进行更丰富的设置。
Deployment status
如题。下图的slave是jenkins的一个slave进程,用于分摊CI构建任务的。
部署状况.png
Settings
监控部分
设置-监控部分1.png
设置-监控部分2.png
日志分析
设置-日志分析.png
报警
设置-报警.png
还有其他针对各种用途(监控、分析、云、虚拟化、集成、标签)的各种配置,不再记录。
四、总结
- 不能光用饼图:对于三个及三个以下的数据,用饼图会很清晰,也较小概率会出现文字重叠的现象。超过3个,就可以考虑使用柱状图。
- 数据的联动性:即上面的统计图与下面的详情列表可以联动。这解决了Kibana“只能在Discover页面才能看到详情”的问题。这对我们的要求就是,尽可能多的设计好数据统计图表,从而减少手动查询的次数。
- 数据可视化:以前的想法都局限于Kibana的图表,要多看看其他可视化用例。
- 设置模块:目前需要设置的不多,也大都比较简单,可以直接操作数据库。
- Agent:目前不在考虑范围里。在业务不多的情况,人工或自动地去解析日志、配置logstash,都是可以接受的。
- 审计报表:Dynatrace的Reports模块跟传统的报表不太一样,依然是数据统计式得展示(也可能因为我没有数据,所以功能没体现出来)。但是可以借鉴日志分析和报警的设置模块。
- 性能优化:空。
- 离线计算,对原始数据进行分析,总结出真正需要审计的行为,从而达到预警的效果。
- 登录不是审计行为,登录太频繁是;登录失败不是审计行为,连续登录失败是。
- 缓存数据,解决前端绘图太慢的问题。
- 即不是直接从ES里取数据
- 引入规则(Rule)系统,把预警的行为定义成Rule。
- 类似 Elastalert
- 更长远的目标:对人进行审计。以人员为中心,把它相关的操作全都关联起来,以一种直观的方式(数据可视化)展现出来。
- 任务调度系统。封装成 Job,可以方便Rerun
网友评论