检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
es 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 表2 Query参数 参数 是否必选 参数类型 描述 engine 是 String 消息引擎:kafka。 name 否 String 实例名称。
{instance_id} 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 instance_id 是 String 实例ID。 请求参数 无 响应参数 状态码: 200 表2 响应Body参数 参数
U使用率”查看,具体步骤请参考查看Kafka监控数据。 带宽限制是指设定Topic进行副本同步的带宽上限,确保不会对该实例上的其他Topic造成流量冲击。但需要注意,带宽限制不会区分是正常的生产消息造成的副本同步还是分区平衡造成的副本同步,如果带宽限制设定过小,可能会影响正常的生
Connect任务名_source_1”。 如果Topic中的消息在进行下一次数据同步前,已经全部老化,此时实际是没有待同步的Kafka数据,但是Kafka数据同步监控指标使用的是包含老化数据的offset值,“待同步Kafka数据量”会显示老化的消息数。 维度 Key Value kafka_instance_id
Kafka的消费组删除了,怎么监控页面还可以看到这个消费组? 监控数据是每分钟进行采集上报,上报的数据经过整理后才会显示在监控页面上,此过程大约需要几分钟到十几分钟,建议您在删除消费组后,过一段时间再去监控页面查看。 父主题: 监控告警问题
明显波动? 磁盘读流量、磁盘写流量、磁盘平均读操作耗时、磁盘平均写操作耗时和CPU使用率这几个监控指标采集的是瞬时值,仅作为系统资源评估参考。它们出现明显波动通常情况下是由于Kafka数据采用异步落盘会消耗磁盘I/O和CPU导致的,这种波动不会对业务产生影响。 父主题: 监控告警问题
Topic-01 --num-records 8000000 --record-size 1024 --throughput 102400 执行结果如下: 8000000 records sent, 34128.673632 records/sec (33.33 MB/sec),
ConsumerRecords<Object, Object> records = consumer.poll(1000); System.out.println("the numbers of topic:" + records.count());
DMS for Kafka安全使用建议 安全性是华为云与您的共同责任。华为云负责云服务自身的安全,提供安全的云;作为租户,您需要合理使用云服务提供的安全能力对数据进行保护,安全地使用云。详情请参见责任共担。 本文提供了使用DMS for Kafka过程中的安全最佳实践,旨在为提高
回收站中,此时实例中的数据尚未被彻底删除,在保留天数内支持从回收站中恢复此实例。超过保留天数的实例会被彻底删除,无法恢复。 回收站策略默认是关闭状态。 约束与限制 回收站中的按需实例不会收取实例的费用,但是会收取存储空间的费用。 包年/包月的实例退订后会存入回收站中,此时不会收取
} 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 instance_id 是 String 实例ID。 task_id 是 String Smart Connector任务ID。 请求参数 无 响应参数
nnector/tasks 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 instance_id 是 String 实例ID。 请求参数 表2 请求Body参数 参数 是否必选 参数类型 描述 task_name
nnector/tasks 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID,获取方式请参见获取项目ID。 instance_id 是 String 实例ID。 表2 Query参数 参数 是否必选 参数类型 描述 offset 否
见表1。 表1 常用Golang客户端对比 客户端 优点 缺点 Confluent-Kafka-go Confluent-Kafka-go是由Confluent提供的官方Kafka客户端库,与Kafka完全兼容,支持所有的Kafka特性。 稳定性高,基于librdkafka,具有高性能和低延迟的特点。
2u4g.cluster 是 超高I/O kafka-02 3 kafka.4u8g.cluster 是 超高I/O kafka-03 3 kafka.8u16g.cluster 是 超高I/O kafka-04 3 kafka.12u24g.cluster 是 超高I/O kafka-05
可能原因1:消息已被老化。 解决方法:修改老化时间。 可能原因2:消息的createTime时间戳不对。 Console页面是根据时间查询的,所以查不到。时间戳是由客户端生成,不同客户端有不同的处理策略,有的客户端默认值会是0或者-1,则查询不到消息。 解决方法:检查客户端消息的createTime设置是否正确。
消息堆积处理建议 方案概述 Kafka将Topic划分为多个分区,消息被分布式存储在分区中。同一个消费组内,一个消费者可同时消费多个分区,但一个分区在同一时刻只能被一个消费者消费。 在消息处理过程中,如果客户端的消费速度跟不上服务端的发送速度,未处理的消息会越来越多,这部分消息就
Kafka进行生产,会占用源端和目标端Kafka的带宽。 出于性能考虑,Smart Connect实时同步源端和目标端的数据,但是消费进度是通过批处理同步的,可能会导致源端和目标端每个分区的消费进度存在0-100之间的差异。 迁移准备 配置网络环境。 Kafka实例分内网地址以及
后台运维对租户完全透明,整个服务运行具有完备的监控和告警功能。有异常可以及时通知相关人员。避免7*24小时人工值守。 需要自行开发完善运维功能,尤其是告警及通知功能,否则只能人工值守。 安全保证 VPC隔离,支持SSL通道加密。 需要自行进行安全加固。
通过查看服务端日志,消费组存在大量rebalance动作,大部分rebalance都会秒级完成,但偶尔会有分钟级别的rebalance耗时,而rebalance过程中是无法正常消费的,只有在rebalance动作完成才可以进行消费。 该现象与问题现象描述的偶现长时间时延行为相吻合,问题确定。 详细分析 查看