为什么要做监控¶
1、分析长期趋势。例如数据库目前的数据量，以及增长速度；每日活跃用户的数量增长的速度等。 2、跨时间范围的比较。增加节点后，memcache 的缓存命中率是否增加；网站速度是否比上周速度要慢等。 3、报警。当某项东西出现故障了，需要立刻有人修复，或者需要有人尽快查看。 4、监控台页面 dashboard。用来回答有关服务的一些基本问题。 5、临时性的回溯分析。
监控术语¶
- 监控
- 收集
- 处理
- 汇总
- 白盒监控
- 日志分析
- java虚拟机
- http接口
- 黑盒监控
- 某种外部用户可见的系统行为监控
- 监控台面
- 提供某个服务核心指标的应用程序
监控的四个黄金指标¶
- 延时
- 请求所需的时间
- 流量
- IO负载
- 错误
- 请求失败的速率
- 饱和度
- 服务容量(cpu/内存等)
三类重要输出¶
- 紧急报警
- 必须立即处理的操作
- 工单
- 必须在几天内进行处理
- 日志
- 不会马上使用,用做以后的分析
目前需求¶
功能¶
- 采集
- 存储
- 查询
- 报警
平台¶
- window
- linux
> 主¶
- ELK¶
E：Elasticsearch L：Logstash K：Kibana
-
优点 1、处理方式灵活：elasticsearch是实时全文索引，具有强大的搜索功能 2、配置相对简单：elasticsearch全部使用JSON 接口，logstash使用模块配置，kibana的配置文件部分更简单。 3、检索性能高效：基于优秀的设计，虽然每次查询都是实时，但是也可以达到百亿级数据的查询秒级响应。 4、集群线性扩展：elasticsearch和logstash都可以灵活线性扩展 5、前端操作绚丽：kibana的前端设计比较绚丽，而且操作简单
-
ELK缺点 1、不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的Java异常打印 2、不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。 3、不复合正则表达式匹配的日志行，被全部丢弃。
> 备¶
- EFK¶
E：Elasticsearch F：Flume K：Kibana
- 优点： Flume是java开发，并且它系统框架好，模块分明，易于订制开发，可靠
- 缺点： 日志格式处理单一，配置复杂，资源开销小
- grayLog¶
-
优点 1、一体化方案，安装方便，不像ELK有3个独立系统间的集成问题。 2、采集原始日志，并可以事后再添加字段，比如http_status_code，response_time等等。 3、自己开发采集日志的脚本，并用curl/nc发送到Graylog Server，发送格式是自定义的GELF，Flunted和Logstash都有相应的输出GELF消息的插件。自己开发带来很大的自由度。实际上只需要用inotify_wait监控日志的MODIFY事件，并把日志的新增行用curl/nc发送到Graylog Server就可。 4、搜索结果高亮显示，就像google一样。 5、搜索语法简单，比如： source:mongo AND reponse_time_ms:>5000 ，避免直接输入elasticsearch搜索json语法 6、搜索条件可以导出为elasticsearch的搜索json文本，方便直接开发调用elasticsearch rest api的搜索脚本。
-
缺点 1、控制台操作页面是英文的，针对国内开发使用者使用起来不方便，还得额外汉化，汉化可能失败 2、使用网络传输，可能会占用项目网络