- 计算
- 网络
- 存储与CDN
-
数据库
-
云数据库 RDS MySQL
- 产品概述
- 产品定价
- 快速入门
- 操作手册
- 案例实践
- API文档
-
常见问题
- 如何访问MySQL实例?
- MySQL实例的安全性如何?
- 如何向MySQL实例中导入数据?
- 如何向MySQL实例中导出数据?
- 如何创建新用户并授予权限?
- QPS是如何统计的?
- 什么是内存溢出?
- 默认的最大连接数是多少?
- 如何查看数据库运行状态?
- 如何查看MySQL实例的SlowLog?
- 如何修改MySQL实例的配置参数?
- 如何安装和卸载插件?
- 如何使用MySQL-Proxy使MySQL实例可以通过外网访问?
- 何查看MySQL实例的各项监控指标?
- 是否可以查看云数据库运行状态?
- 默认的配置是针对哪种存储引擎优化的?
- 如何在云主机上搭建云数据库从库并进行主从同步呢?
- 如何正确设置字符集?
- 如何查询MySQL实例的客户端和服务器端版本
- 相关协议
- 云数据库 RDS PostgreSQL
- 云数据库 Redis
- 云数据库 MongoDB
- 分布式数据库 InDDB
- 云数据库 Memcache
-
云数据库 RDS MySQL
- 安全
- 人工智能
- 大数据
- 管理和监控
-
API
-
对象存储OSS
- 创建Bucket-CreateBucket
- 获取Bucket信息-DescribeBucket
- 更改Bucket属性-UpdateBucket
- 删除Bucket-DeleteBucket
- 前缀列表查询 – PrefixFileList
- 上传文件 – PutFile
- 表单上传 – PostFile
- 秒传文件-UploadHit
- 下载文件-GetFile
- 查询文件基本信息-HEADFile
- 删除文件 – DeleteFile
- 初始化分片 – InitiateMultipartUpload
- 上传分片 – UploadPart
- 完成分片 – FinishMultipartUpload
- 放弃分片 – AbortMultipartUpload
- 查看配额状态-GetUFileQuota
- 查询配额支付价格-GetUFileQuotaPrice
- 查看配额使用报表-GetUFileReport
- 获取配额信息-GetUFileQuotaInfo
- 获取已上传成功的分片列表-GetMultiUploadPart
- 更新令牌-UpdateUFileToken
- 删除令牌-DeleteUFileToken
- 获取令牌信息-DescribeUFileToken
- OSS 错误码列表
- 操作文件的Meta信息 – OpMeta
- API文档综述
-
弹性公网IP EIP
- 1、申请弹性IP-AllocateEIP
- 2、获取弹性IP信息-DescribeEIP
- 3、更新弹性IP属性-UpdateEIPAttribute
- 4、释放弹性IP-ReleaseEIP
- 5、绑定弹性IP-BindEIP
- 6、解绑弹性IP-UnBindEIP
- 7、调整弹性IP带宽-ModifyEIPBandwidth
- 8. 修改弹性IP出口权重-ModifyEIPWeight
- 9. 获取弹性IP价格-GetEIPPrice
- 10. 获取弹性IP带宽改动价格-GetEIPUpgradePrice
- 11. 获取弹性IP计费方式-GetEIPPayMode
- 12. 设置弹性IP计费方式-SetEIPPayMode
- 13. 申请内网虚拟IP-AllocateVIP
- 14. 获取内网虚拟IP信息-DescribeVIP
- 15. 释放内网虚拟IP- ReleaseVIP
- 16. 创建带宽包-CreateBandwidthPackage
- 17. 获取带宽包信息-DescribeBandwidthPackage
- 18. 删除带宽包-DeleteBandwidthPackage
- 19. 开通共享带宽-AllocateShareBandwidth
- 20. 获取共享带宽信息-DescribeShareBandwidth
- 21. 调整共享带宽-ResizeShareBandwidth
- 22. 关闭共享带宽-ReleaseShareBandwidth
- 23. 将EIP加入共享带宽-AssociateEIPWithShareBandwidth
- 24. 将EIP移出共享带宽-DisassociateEIPWithShareBandwidth
- 25. 获取带宽用量-DescribeBandwidthUsage
- 26. 更新防火墙属性-UpdateFirewallAttribute
- 27. 获取防火墙信息-DescribeFirewall
- 28. 应用防火墙-GrantFirewall
- 29. 错误码
-
云服务器ECS
- 1、获取VNC登录信息-GetUHostInstanceVncInfo
- 2、启动云服务器-StartUHostInstance
- 3、重启云服务器-RebootUHostInstance
- 4、关闭云服务器-StopUHostInstance
- 5、获取云服务器业务组列表-DescribeUHostTags
- 6、字段规范
- 7、删除云服务器-TerminateUHostInstance
- 8、重置云服务器密码-ResetUHostInstancePassword
- 9、修改云服务器业务组-ModifyUHostInstanceTag
- 10、修改云服务器名-ModifyUHostInstanceName
- 11、获取挂载磁盘的升级价格-GetAttachedDiskUpgradePrice
- 12、修改云服务器配置-ResizeUHostInstance
- 13、获取升级配置价格-GetUHostUpgradePrice
- 14、创建云服务器-CreateUHostInstance
- 15、移除硬件隔离组-LeaveIsolationGroup
- 16、创建硬件隔离组-CreateIsolationGroup
- 17、删除自制镜像-TerminateCustomImage
- 18、创建自制镜像-CreateCustomImage
- 19、导入镜像-ImportCustomImage
- 20、修改云服务器备注-ModifyUHostInstanceRemark
- 21、修改挂载的磁盘大小-ResizeAttachedDisk
- 22、模拟服务器掉电-PoweroffUHostInstance
- 23、重装系统-ReinstallUHostInstance
- 24、获取镜像列表-DescribeImage
- 25、获取云服务器价格-GetUHostInstancePrice
- 26、获取云服务器信息-DescribeUHostInstance
- 27、普通机型开启CDP-UpgradeToArkUHostInstance
-
对象存储OSS
- 用户提醒
- 服务等级协议(SLA)
- 企业上云常见问题
- 其他协议
- 云市场
- 开发者
- 账户管理
-
集群健康是对集群的所有信息进行高度概述,而节点统计值 API 提供一个让人眼花缭乱的统计数据的数组,包含集群的每一个节点统计值。
节点统计值 API 可以通过如下命令执行:
GET /_nodes/stats
在输出内容的开头,我们可以看到集群名称和我们的第一个节点:
{
"_nodes": {
"total": 3,
"successful": 3,
"failed": 0
},
"cluster_name": "ues-qwerty",
"nodes": {
"cZabQfdFTVCOdh9Zxrjocg": {
"timestamp": 1515997798238,
"name": "ues-qwerty-01",
"transport_address": "192.168.1.1:9300",
"host": "192.168.1.1",
"ip": "192.168.1.1:9300",
"roles": [
"master",
"data",
"ingest"
],
"indices": {
...
节点是排列在一个哈希里,以节点的 UUID 作为键名。还显示了节点网络属性的一些信息,这些值对调试诸如节点未加入集群这类自动发现问题很有用。通常你会发现是端口用错了,或者节点绑定在错误的 IP 地址/网络接口上了。
索引部分
索引(indices)部分列出了这个节点上所有索引的聚合过的统计值 :
"indices": {"docs": {"count": 0,"deleted": 0},"store": {"size_in_bytes": 0,"throttle_time_in_millis": 0},● docs 展示节点内存有多少文档,包括还没有从段里清除的已删除文档数量。
● store 部分显示节点耗用了多少物理存储。这个指标包括主分片和副本分片在内。如果限流时间很大,那可能表明你的磁盘限流设置得过低。
"indexing": {"index_total": 2,"index_time_in_millis": 146,"index_current": 0,"index_failed": 0,"delete_total": 1,"delete_time_in_millis": 6,"delete_current": 0,"noop_update_total": 0,"is_throttled": false,"throttle_time_in_millis": 0},"get": {"total": 2,"time_in_millis": 7,"exists_total": 2,"exists_time_in_millis": 7,"missing_total": 0,"missing_time_in_millis": 0,"current": 0},"search": {"open_contexts": 0,"query_total": 50,"query_time_in_millis": 74,"query_current": 0,"fetch_total": 40,"fetch_time_in_millis": 25,"fetch_current": 0,"scroll_total": 0,"scroll_time_in_millis": 0,"scroll_current": 0,"suggest_total": 0,"suggest_time_in_millis": 0,"suggest_current": 0},"merges": {"current": 0,"current_docs": 0,"current_size_in_bytes": 0,"total": 0,"total_time_in_millis": 0,"total_docs": 0,"total_size_in_bytes": 0,"total_stopped_time_in_millis": 0,"total_throttled_time_in_millis": 0,"total_auto_throttle_in_bytes": 104857600},● indexing 显示已经索引了多少文档。这个值是一个累加计数器,在文档被删除时,数值不会下降,在发生文档更新等内部索引操作时,值会增加。此外还列出了索引操作耗费的时间,正在索引的文档数量,以及删除操作的类似统计值。
● get 显示通过 ID 获取文档的接口相关的统计值。包括对单个文档的 GET 和 HEAD 请求。
● search 描述在活跃中的搜索(open_contexts)数量、查询的总数量、以及自节点启动以来在查询上消耗的总时间。用 query_time_in_millis / query_total 计算的比值,可以用来粗略的评价你的查询有多高效。比值越大,每个查询花费的时间越多,你应该要考虑调优了。
● fetch 统计值展示了查询处理的后一半流程(query-then-fetch 里的 fetch)。如果 fetch 耗时比 query 还多,说明磁盘较慢,或者获取了太多文档,或者可能搜索请求设置了太大的分页(比如,size: 10000)。
● merges 包括了 Lucene 段合并相关的信息。它会告诉你目前在运行几个合并,合并涉及的文档数量,正在合并的段的总大小,以及在合并操作上消耗的总时间。
● 在你的集群写入压力很大时,合并统计值非常重要。合并要消耗大量的磁盘 I/O 和 CPU 资源。如果你的索引有大量的写入,同时又发现大量的合并数,一定要去阅读索引性能技巧。
"filter_cache": {"memory_size_in_bytes": 48,"evictions": 0},"fielddata": {"memory_size_in_bytes": 0,"evictions": 0},"segments": {"count": 319,"memory_in_bytes": 65812120},...● filter_cache 展示了已缓存的过滤器位集合所用的内存数量,以及过滤器被驱逐出内存的次数。过多的驱逐数 可能 说明你需要加大过滤器缓存的大小,或者你的过滤器不太适合缓存(比如它们因为高基数而在大量产生,就像是缓存一个 now 时间表达式)。
● 不过,驱逐数是一个很难评定的指标。过滤器是在每个段的基础上缓存的,而从一个小的段里驱逐过滤器,代价比从一个大的段里要廉价的多。有可能你有很大的驱逐数,但是它们都发生在小段上,也就意味着这些对查询性能只有很小的影响。把驱逐数指标作为一个粗略的参考。如果你看到数字很大,检查一下你的过滤器,确保他们都是正常缓存的。不断驱逐着的过滤器,哪怕都发生在很小的段上,效果也比正确缓存住了的过滤器差很多。
● field_data 显示 fielddata 使用的内存, 用以聚合、排序等等。这里也有一个驱逐计数。和 filter_cache 不同的是,这里的驱逐计数是很有用的:这个数应该或者至少是接近于 0。因为 fielddata 不是缓存,任何驱逐都消耗巨大,应该避免掉。如果你在这里看到驱逐数,你需要重新评估你的内存情况,fielddata 限制,请求语句,或者这三者。
● segments 会展示这个节点目前正在服务中的 Lucene 段的数量。 这是一个重要的数字。大多数索引会有大概 50–150 个段,哪怕它们存有 TB 级别的数十亿条文档。段数量过大表明合并出现了问题(比如,合并速度跟不上段的创建)。注意这个统计值是节点上所有索引的汇聚总数。
● memory 统计值展示了 Lucene 段自己用掉的内存大小。 这里包括底层数据结构,比如倒排表,字典,和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销,这个内存使用量就是一个方便用来衡量开销的度量值。
操作系统和进程部分
OS 和Process 部分基本是自描述的,不会在细节中展开讲解。它们列出来基础的资源统计值,比如 CPU 和负载。OS 部分描述了整个操作系统,而 Process 部分只显示 Elasticsearch 的 JVM 进程使用的资源情况。
这些都是非常有用的指标,不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些:
● CPU
● 负载
● 内存使用率
● Swap 使用率
● 打开的文件描述符
JVM部分
jvm部分包括了运行 Elasticsearch 的 JVM 进程一些很关键的信息。最重要的,它包括了垃圾回收的细节,这对你的 Elasticsearch 集群的稳定性有着重大影响。
"jvm": {"timestamp": 1515997798245,"uptime_in_millis": 1704518268,"mem": {"heap_used_in_bytes": 143523960,"heap_used_percent": 3,"heap_committed_in_bytes": 4277534720,"heap_max_in_bytes": 4277534720,"non_heap_used_in_bytes": 95476824,"non_heap_committed_in_bytes": 102416384,线程池部分
Elasticsearch 在内部维护了线程池。这些线程池相互协作完成任务,有必要的话相互间还会传递任务。通常来说,你不需要配置或者调优线程池,不过查看它们的统计值有时候还是有用的,可以洞察你的集群表现如何。
这有一系列的线程池,但以相同的格式输出:
"index": {"threads": 1,"queue": 0,"active": 0,"rejected": 0,"largest": 1,"completed": 1}每个线程池会列出已配置的线程数量(threads),当前在处理任务的线程数量(active),以及在队列中等待处理的任务单元数量(queue)。
如果队列中任务单元数达到了极限,新的任务单元会开始被拒绝,你会在 rejected 统计值上看到它反映出来。这通常是你的集群在某些资源上碰到瓶颈的信号。因为队列满意味着你的节点或集群在用较高的速度运行,但依然跟不上工作的蜂拥而入。
值得关注的线程池部分有:
● indexing
普通的索引请求的线程池
● bulk
批量请求,和单条的索引请求不同的线程池
● get
Get-by-ID 操作
● search
所有的搜索和查询请求
● merging
专用于管理 Lucene 合并的线程池
文件系统和网络部分
继续向下阅读 /_node/stats API,你会看到一串和你的文件系统相关的统计值:可用空间,数据目录路径,磁盘 I/O 统计值,等等。如果你没有监控磁盘可用空间的话,可以从这里获取这些统计值。磁盘 I/O 统计值也很方便,不过通常那些更专门的命令行工具(比如 iostat )会更有用些。
显然,Elasticsearch 在磁盘空间满的时候很难运行——所以请确保不会这样。
还有两个跟网络统计值相关的部分:
"transport": {"server_open": 26,"rx_count": 8834703,"rx_size_in_bytes": 19706396482,"tx_count": 8834702,"tx_size_in_bytes": 18212792172},"http": {"current_open": 3,"total_opened": 153},● transport 显示和 传输地址 相关的一些基础统计值。包括节点间的通信(通常是 9300 端口)以及任意传输客户端或者节点客户端的连接。如果看到这里有很多连接数不要担心;Elasticsearch 在节点之间维护了大量的连接。
● http 显示 HTTP 端口(通常是 9200)的统计值。如果你看到 total_opened 数很大而且还在一直上涨,这是一个明确信号,说明你的 HTTP 客户端里有没启用 keep-alive 长连接的。持续的 keep-alive 长连接对性能很重要,因为连接、断开套接字是很昂贵的(而且浪费文件描述符)。请确认你的客户端都配置正确。
断路有
fielddata 断路器相关的统计值:
"fielddata": {"limit_size_in_bytes": 2566520832,"limit_size": "2.3gb","estimated_size_in_bytes": 0,"estimated_size": "0b","overhead": 1.03,"tripped": 0},这里你可以看到断路器的最大值(比如,一个请求申请更多的内存时会触发断路器)。这个部分还会让你知道断路器被触发了多少次,以及当前配置的间接开销。间接开销用来铺垫评估,因为有些请求比其他请求更难评估。
主要需要关注的是 tripped 指标。如果这个数字很大或者持续上涨,这是一个信号,说明你的请求需要优化,或者你需要添加更多内存(单机上添加,或者通过添加新节点的方式)。