- Logstash
- Logstash - 入门示例
- 入门示例 - 下载安装
- 入门示例 - hello world
- 入门示例 - 配置语法
- 入门示例 - plugin的安装
- 入门示例 - 长期运行
- Logstash - 插件配置
- 插件配置 - input配置
- input配置 - file
- input配置 - stdin
- input配置 - syslog
- input配置 - tcp
- 插件配置 - codec配置
- codec配置 - json
- codec配置 - multiline
- codec配置 - collectd
- codec配置 - netflow
- 插件配置 - filter配置
- filter配置 - date
- filter配置 - grok
- filter配置 - dissect
- filter配置 - geoip
- filter配置 - json
- filter配置 - kv
- filter配置 - metrics
- filter配置 - mutate
- filter配置 - ruby
- filter配置 - split
- filter配置 - elapsed
- 插件配置 - output配置
- output配置 - elasticsearch
- output配置 - email
- output配置 - exec
- output配置 - file
- output配置 - nagios
- output配置 - statsd
- output配置 - stdout
- output配置 - tcp
- output配置 - hdfs
- Logstash - 场景示例
- 场景示例 - nginx访问日志
- 场景示例 - nginx错误日志
- 场景示例 - postfix日志
- 场景示例 - ossec日志
- 场景示例 - windows系统日志
- 场景示例 - Java日志
- 场景示例 - MySQL慢查询日志
- Logstash - 性能与测试
- 性能与测试 - generator方式
- 性能与测试 - 监控方案
- 监控方案 - logstash-input-heartbeat方式
- 监控方案 - jmx启动参数方式
- 监控方案 - API方式
- Logstash - 扩展方案
- 扩展方案 - 通过redis传输
- 扩展方案 - 通过kafka传输
- 扩展方案 - AIX 平台上的logstash-forwarder-java
- 扩展方案 - rsyslog
- 扩展方案 - nxlog
- 扩展方案 - heka
- 扩展方案 - fluent
- 扩展方案 - Message::Passing
- Logstash - 源码解析
- 源码解析 - pipeline流程
- 源码解析 - Event的生成
- Logstash - 插件开发
- 插件开发 - utmp插件示例
- Beats
- Beats - filebeat
- Beats - packetbeat网络流量分析
- Beats - metricbeat
- Beats - winlogbeat
- ElasticSearch
- ElasticSearch - 架构原理
- 架构原理 - segment、buffer和translog对实时性的影响
- 架构原理 - segment merge对写入性能的影响
- 架构原理 - routing和replica的读写过程
- 架构原理 - shard的allocate控制
- 架构原理 - 自动发现的配置
- ElasticSearch - 接口使用示例
- 接口使用示例 - 增删改查操作
- 接口使用示例 - 搜索请求
- 接口使用示例 - Painless脚本
- 接口使用示例 - reindex接口
- ElasticSearch - 性能优化
- 性能优化 - bulk提交
- 性能优化 - gateway配置
- 性能优化 - 集群状态维护
- 性能优化 - 缓存
- 性能优化 - fielddata
- 性能优化 - curator工具
- 性能优化 - profile接口
- ElasticSearch - rally测试方案
- ElasticSearch - 多集群互联
- ElasticSearch - 别名的应用
- ElasticSearch - 映射与模板的定制
- ElasticSearch - puppet-elasticsearch模块的使用
- ElasticSearch - 计划内停机升级的操作流程
- ElasticSearch - 镜像备份
- ElasticSearch - rollover和shrink
- ElasticSearch - Ingest节点
- ElasticSearch - Hadoop 集成
- Hadoop 集成 - spark streaming交互
- ElasticSearch - 权限管理
- 权限管理 - Shield
- 权限管理 - Search-Guard 在 Elasticsearch 2.x 上的运用
- ElasticSearch - 监控方案
- 监控方案 - 监控相关接口
- 监控相关接口 - 集群健康状态
- 监控相关接口 - 节点状态
- 监控相关接口 - 索引状态
- 监控相关接口 - 任务管理
- 监控相关接口 - cat 接口的命令行使用
- 监控方案 - 日志记录
- 监控方案 - 实时bigdesk方案
- 监控方案 - cerebro
- 监控方案 - zabbix trapper方案
- ElasticSearch - ES在运维监控领域的其他玩法
- ES在运维监控领域的其他玩法 - percolator接口
- ES在运维监控领域的其他玩法 - watcher报警
- ES在运维监控领域的其他玩法 - ElastAlert
- ES在运维监控领域的其他玩法 - 时序数据库
- ES在运维监控领域的其他玩法 - Grafana
- ES在运维监控领域的其他玩法 - juttle
- ES在运维监控领域的其他玩法 - Etsy的Kale异常检测
- Kibana 5
- Kibana 5 - 安装、配置和运行
- Kibana 5 - 生产环境部署
- Kibana 5 - discover功能
- Kibana 5 - 各visualize功能
- 各visualize功能 - area
- 各visualize功能 - table
- 各visualize功能 - line
- 各visualize功能 - markdown
- 各visualize功能 - metric
- 各visualize功能 - pie
- 各visualize功能 - tile map
- 各visualize功能 - vertical bar
- Kibana 5 - dashboard功能
- Kibana 5 - timelion 介绍
- Kibana 5 - console 介绍
- Kibana 5 - setting功能
- Kibana 5 - 常用sub agg示例
- 常用sub agg示例 - 函数堆栈链分析
- 常用sub agg示例 - 分图统计
- 常用sub agg示例 - TopN的时序趋势图
- 常用sub agg示例 - 响应时间的百分占比趋势图
- 常用sub agg示例 - 响应时间的概率分布在不同时段的相似度对比
- Kibana 5 - 源码解析
- 源码解析 - .kibana索引的数据结构
- 源码解析 - 主页入口
- 源码解析 - discover解析
- 源码解析 - visualize解析
- 源码解析 - dashboard解析
- Kibana 5 - 插件
- 插件 - 可视化开发示例
- 插件 - 后端开发示例
- 插件 - 完整app开发示例
- Kibana 5 - Kibana报表
- 竞品对比
监控相关接口 - cat 接口的命令行使用
之前介绍的各种接口数据,其响应数据都是 JSON 格式,更适用于程序处理。对于我们日常运维,在 Linux 命令行终端环境来说,简单的分行和分列表格才是更方便的样式。为此,Elasticsearch 提供了 cat 接口。
cat 接口可以读取各种监控数据,可用接口列表如下:
- /_cat/nodes
- /_cat/shards
- /_cat/shards/{index}
- /_cat/aliases
- /_cat/aliases/{alias}
- /_cat/tasks
- /_cat/master
- /_cat/plugins
- /_cat/fielddata
- /_cat/fielddata/{fields}
- /_cat/pending_tasks
- /_cat/count
- /_cat/count/{index}
- /_cat/snapshots/{repository}
- /_cat/recovery
- /_cat/recovery/{index}
- /_cat/segments
- /_cat/segments/{index}
- /_cat/thread_pool
- /_cat/thread_pool/{thread_pools}/_cat/nodeattrs
- /_cat/allocation
- /_cat/repositories
- /_cat/health
- /_cat/indices
- /_cat/indices/{index}
集群状态
还是以最基础的集群状态为例,采用 cat 接口查询集群状态的命令如下:
# curl -XGET http://127.0.0.1:9200/_cat/health
1434300299 00:44:59 es1003 red 39 27 2589 1505 4 1 0 0 - 100.0%
如果单看这行输出,或许不熟悉的用户会有些茫然。可以通过添加 ?v
参数,输出表头:
# curl -XGET http://127.0.0.1:9200/_cat/health?v
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1434300334 00:45:34 es1003 green 39 27 2590 1506 5 0 0 0 - 100.0%
节点状态
# curl -XGET http://127.0.0.1:9200/_cat/nodes?v
host ip heap.percent ram.percent load_1m load_5m load_15m node.role master name
esnode109 10.19.0.109 62 69 6.37 d - 10.19.0.109
esnode096 10.19.0.96 63 69 0.29 - - 10.19.0.96
esnode100 10.19.0.100 56 79 0.07 - m 10.19.0.100
跟集群状态不一样的是,节点状态数据太多,cat 接口不方便在一行表格中放下所有数据。所以默认的返回,只是最基本的内存和负载数据。具体想看某方面的数据,也是通过请求参数的方式额外指明。比如想看 heap 百分比和最大值:
# curl -XGET 'http://127.0.0.1:9200/_cat/nodes?v&h=ip,port,heapPercent,heapMax'
ip port heapPercent heapMax
192.168.1.131 9300 66 25gb
h
请求参数可用的值,可以通过 ?help
请求参数来查询:
# curl -XGET http://127.0.0.1:9200/_cat/nodes?help
id | id,nodeId | unique node id
host | h | host name
ip | i | ip address
port | po | bound transport port
heap.percent | hp,heapPercent | used heap ratio
heap.max | hm,heapMax | max configured heap
ram.percent | rp,ramPercent | used machine memory ratio
ram.max | rm,ramMax | total machine memory
load | l | most recent load avg
node.role | r,role,dc,nodeRole | d:data node, c:client node
...
中间第二列就是对应的请求参数的值及其缩写。也就是说上面示例还可以写成:
# curl -XGET http://127.0.0.1:9200/_cat/nodes?v&h=i,po,hp,hm
索引状态
查询索引列表和存储的数据状态是也是 cat 接口最常用的功能之一。为了方便阅读,默认输出时会把数据大小以更可读的方式自动换算成合适的单位,比如 3.2tb 这样。
如果你打算通过 shell 管道做后续处理,那么可以加上 ?bytes
参数,指明统一采用字节数输出,这样保证在同一个级别上排序:
# curl -XGET http://127.0.0.1:9200/_cat/indices?bytes=b | sort -rnk8
green open logstash-mweibo-2015.06.12 26 1 754641614 0 2534955821580 1256680767317
green open logstash-mweibo-2015.06.14 27 1 855516794 0 2419569433696 1222355996673
分片状态
# curl -XGET http://127.0.0.1:9200/_cat/shards?v
index shard prirep state docs store ip node
logstash-mweibo-h5view-2015.06.10 20 p STARTED 4690968 679.2mb 127.0.0.1 10.19.0.108
logstash-mweibo-h5view-2015.06.10 20 r STARTED 4690968 679.4mb 127.0.0.1 10.19.0.39
logstash-mweibo-h5view-2015.06.10 2 p STARTED 4725961 684.3mb 127.0.0.1 10.19.0.53
logstash-mweibo-h5view-2015.06.10 2 r STARTED 4725961 684.3mb 127.0.0.1 10.19.0.102
同样,可以用 ?help
查询其他可用数据细节。比如每个分片的 segment.count:
# curl -XGET 'http://127.0.0.1:9200/_cat/shards/logstash-mweibo-nginx-2015.06.14?v&h=n,iic,sc'
n iic sc
10.19.0.72 0 42
10.19.0.41 0 36
10.19.0.104 0 32
10.19.0.102 0 40
恢复状态
在出现集群状态波动时,通过这个接口查看数据迁移和恢复速度也是一个非常有用的功能。不过默认输出是把集群历史上所有发生的 recovery 记录都返回出来,所以一般会加上 ?active_only
参数,仅列出当前还在运行的恢复状态:
# curl -XGET 'http://127.0.0.1:9200/_cat/recovery?active_only&v&h=i,s,shost,thost,fp,bp,tr,trp,trt'
i s shost thost fp bp tr trp trt
logstash-mweibo-2015.06.12 10 esnode041 esnode080 87.6% 35.3% 0 100.0% 0
logstash-mweibo-2015.06.13 10 esnode108 esnode080 95.5% 88.3% 0 100.0% 0
logstash-mweibo-2015.06.14 17 esnode102 esnode080 96.3% 92.5% 0 0.0% 118758
线程池状态
curl -s -XGET http://127.0.0.1:9200/_cat/thread_pool?v
node_name name active queue rejected
esnode073 bulk 1 0 20669
esnode073 fetch_shard_started 0 0 0
esnode073 fetch_shard_store 0 0 0
esnode073 flush 0 0 0
esnode073 force_merge 0 0 0
esnode073 generic 0 0 0
esnode073 get 0 0 0
esnode073 index 0 0 50
esnode073 listener 0 0 0
esnode073 management 1 0 0
esnode073 refresh 0 0 0
esnode073 search 4 0 0
esnode073 snapshot 0 0 0
esnode073 warmer 0 0 0
这个接口的输出形式和 5.0 之前的版本有了较大变化,把不同类型的线程状态做了一次行列转换,大大减少了列数以后,对人眼更加合适了。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论