本章节介绍注册配置中心RCC子产品应用场景 分布式协同 提供分布式系统中服务注册发现及协同调度能力，确保系统状态一致性并完成预期的功能请求，包括状态管理，分布式锁，服务发现，监控检查等。助力用户轻松构建稳定、高可用的分布式服务。 分布式系统中一个绕不过去的问题是如何协同系统中各个分布的模块，确保系统状态的一致性并完成预期的功能，包括状态管理，分布式锁，服务发现等；将分布式系统这一核心必备能力抽象成为组件对外提供服务，使得开发者不用过多了解分布式细节，即可基于这列组件轻松构建稳定、高可用的分布式服务。 分布式配置管理 提供分布式应用配置集中管理能力，包括配置热生效、配置历史查看、配置数据回滚等，支持主流的Nacos 配置中心，支持原生数据无缝迁移，帮助您高效解决分布式环境下多应用的配置管理问题。 在分布式服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移分割，这样配置就分散了，不仅如此，分散中还包含着冗余，而配置中心将配置从各应用中剥离出来，对配置进行统一管理，应用自身不需要自己去管理配置。

本章节介绍了分布式消息服务RocketMQ的计费项。 分布式消息服务RocketMQ的费用计算分为两部分，一部分为实例费用，一部分为存储空间费用。 表 分布式消息服务RocketMQ计费项 计费项 计费说明 :: 实例费用 对您选择的实例规格计费，具体请参见表2。 RocketMQ实例提供包年包月、按需两种计费方式。 存储空间费用 对您选择的实例存储空间计费（每个实例规格您都可以选择高IO和超高IO两种不同的云硬盘类型以满足您的业务需求）。 存储空间范围见表2，步长100GB。 ·实例存储提供包年包月、按需两种计费方式。 表 实例规格说明 资源规格 代理（个） 存储容量（GB/代理） 单个代理TPS 单个代理Topic数上限 单个代理消费组数上限 rocketmq.4u8g.cluster.small 1 ~ 2 300 ~ 30000 15000 2000 2000 rocketmq.4u8g.cluster 1 ~ 10 300 ~ 600000 20000 4000 4000 rocketmq.8u16g.cluster 1 ~ 10 300 ~ 900000 25000 8000 8000 rocketmq.12u24g.cluster 1 ~ 10 300 ~ 900000 28000 12000 12000 rocketmq.16u32g.cluster 1 ~ 10 300 ~ 900000 30000 16000 16000 计费模式 提供按小时、按月、按年的计费方式供您灵活选择，使用越久越便宜。预付费（包年包月）：这种购买方式相对于按需付费提供更大的折扣，对于长期使用者，推荐该方式。按需付费（小时）：这种购买方式比较灵活，可以即开即停，按实际使用时长计费。以自然小时 续费 为防止资源到期或者浪费，已经购买包年/包月实例的用户，可执行续费操作，延长资源包的有效期，也可以设置到期自动续费。

本章节主要介绍如何查看分布式消息服务RabbitMQ的云审计日志。 查看RabbitMQ云审计日志，请参考《云审计服务 用户指南》的“查看追踪事件”章节。

翼云OpenAPI门户提供了产品的API 文档、API调试、SDK中心等。 关于用户如何使用分布式消息服务RabbitMQ产品API的详细介绍，请参见使用API。您可以在OpenAPI门户可以了解到具体的调用前必知、API概览、如何调用API以及具体的API的接口详细说明。 说明 分布式消息服务RabbitMQ提供两种版本接口供用户调用 V3版本：适用于 华东1、华北2、西南1、华南2、上海36、青岛20、长沙42、南昌5、武汉41、杭州7、西南2贵州、太原4、郑州5、西安7、呼和浩特3 资源池。 V2版本：适用于 芜湖2、南京3、上海7、重庆2、乌鲁木齐27、石家庄20、内蒙6、保定、北京5 资源池。部分资源池已不再开放新实例订购，仅存量实例调用。

本小节介绍日志审计(原生版)场景下的程序日志定位告警异常处理实践。 应用场景 日志审计（原生版）已经采集到日志，但未触发对应告警。 前提准备 进入日志审计（原生版）平台。 通过控制台进入日志审计（原生版）实例。 告警服务逻辑 告警涉及服务：esinsert、alarmMgr、eventanalysvr。 告警涉及流程： eventana（告警解析）：通过Kafka接收logp解析的日志，根据告警规则解析该日志是否符合告警条件，符合条件则将该告警信息转发给alarm。 alarm：通过Kafka接收eventana的告警信息，并触发告警，产生告警。 esinsert（录入ElasticSearch）将产生的告警录入ElasticSearch。 查看程序 点击“系统配置 > 系统运维”，在服务管理中，查看相关服务状态，出现异常时，点击“重启”重启程序，大约1分钟后刷新页面，再次查看服务状态是否正常。 查看程序日志 点击“系统配置 > 系统运维”，在服务管理中，点击“导出日志”，可导出服务日志。按流程步骤依次查看esinsert、alarmMgr、eventanalysvr等服务日志是否有异常信息。 中间件故障 各程序报告日志出现报错 ：Broker transport failure: 127.0.0.1:9092/0: Connect to ipv4127.0.0.1:9092 failed 日志分析：9092为Kafka服务端口，该提示说明Kafka服务出现异常。

关闭公网访问 步骤 1 登录管理控制台。 步骤 2 在管理控制台右上角单击，选择区域。 说明 此处请选择RabbitMQ实例所在的区域。 步骤 3 在管理控制台左上角单击，选择“企业中间件”>“分布式消息服务”>“RabbitMQ专享版”，进入分布式消息服务RabbitMQ专享版页面。 步骤 4 单击待关闭公网访问的实例名称，进入实例详情页面。 步骤 5 单击“公网访问”右侧的，关闭公网访问开关。 步骤 6 单击，关闭公网访问功能。 关闭公网访问功能大约需要10~30秒，请耐心等待。关闭公网访问后，页面会自动跳转到“后台任务管理”页签，当任务状态为“成功”时，表示关闭公网访问成功。

本文介绍分布式消息服务RocketMQ入门指引的生产消费验证内容。 背景信息 RocketMQ的生产消费验证是指在使用RocketMQ进行消息生产和消费时的验证过程。具体而言，验证包括以下几个方面： 生产者验证：RocketMQ提供了丰富的生产者API，开发人员可以使用这些API将消息发送到RocketMQ的消息队列中。在验证阶段，可以通过发送消息并检查返回结果来确保消息成功发送到Broker节点。此外，生产者还应该验证消息的顺序性、事务性以及可靠性等方面。 消费者验证：RocketMQ的消费者可以订阅特定的消息主题，从而消费这些主题下的消息。在验证阶段，消费者应该能够正确地从Broker节点拉取消息并进行消费处理。消费者还可以验证消息的顺序性、重试机制以及消息过滤等功能。 操作步骤 1、 天翼云官网点击控制中心，选择产品分布式消息服务RocketMQ。 2、 登录分布式消息服务RocketMQ控制台，点击右上角地域选择对应资源池。 3、 进入实例列表，点击【管理】按钮进入管理菜单。 4、 进入Topic管理菜单，点击【拨测】按钮，进行生产消费的拨测验证，验证开通的消息实例和主题。 1）生产测试拨测： 选择消息类型，默认普通消息。 填写需要产生的测试消息数量，以及每条消息的大小，默认每条消息1KB，建议不超过4MB(4096KB)。 选择已建的消息主题，若无选项，请新增主题，详见上文创建主题和订阅组。 点击【测试】按钮，按照已填写规格及数量产生测试消息数据，展示消息数据的信息，包括消息ID(messageID)、发送状态、主题名（topic名）、Broker名、队列ID。 拨测功能涉及消息发送状态码，以下是RocketMQ消息发送状态码及其说明： ✧ SENDOK（发送成功）：表示消息成功发送到了消息服务器。 ✧ FLUSHDISKTIMEOUT（刷新磁盘超时）：表示消息已经成功发送到消息服务器，但是刷新到磁盘上超时。这可能会导致消息服务器在宕机后，尚未持久化到磁盘上的数据丢失。 ✧ FLUSHSLAVETIMEOUT（刷新从服务器超时）：表示消息已经成功发送到消息服务器，但是刷新到从服务器上超时。这可能会导致主从同步不一致。 ✧ SLAVENOTAVAILABLE（从服务器不可用）：表示消息已经成功发送到消息服务器，但是从服务器不可用。这可能是由于网络故障或从服务器宕机引起的。 ✧ UNKNOWNERROR（未知错误）：表示发送消息时遇到了未知的错误。一般情况下建议重试发送消息。 ✧ MESSAGESIZEEXCEEDED（消息大小超过限制）：表示消息的大小超过了消息服务器的限制。需要检查消息的大小是否合适。 ✧ PRODUCETHROTTLE（消息生产被限流）：表示消息生产者的频率超出了消息服务器的限制。这可能是由于消息发送频率过高引起的。 ✧ SERVICENOTAVAILABLE（服务不可用）：表示消息服务器不可用。这可能是由于网络故障或者消息服务器宕机引起的。 请注意，以上状态码仅适用于RocketMQ消息发送阶段，并且不代表消息是否成功被消费者接收。同时，这些状态码也可能因版本变化而有所不同，建议查阅官方文档获取最新信息。 2）消费测试拨测： 选择消息顺序，下拉选择无序/有序，默认选项为无序。 RocketMQ是一种开源的分布式消息中间件，它支持有序消息和无序消息。 ✧ 有序消息是指消息的消费顺序与发送顺序完全一致。在某些业务场景下，消息的处理需要保证顺序性，例如订单的处理或者任务的执行。RocketMQ提供了有序消息的支持，通过指定消息的顺序属性或使用消息队列的分区机制，可以确保消息按照指定的顺序进行消费。 ✧ 无序消息则是指消息的消费顺序与发送顺序无关。无序消息的特点是高吞吐量和低延迟，适用于一些不要求严格顺序的业务场景，如日志收集等。 在RocketMQ中，有序消息和无序消息的实现方式略有不同。有序消息需要借助MessageQueue的分区机制和消费者端的顺序消息消费来实现。而无序消息则是通过消息的发送和接收的并发处理来实现的。 总的来说，RocketMQ既支持有序消息也支持无序消息，根据业务需求选择合适的消息类型来满足业务的要求。 选择消费方式，目前仅提供pull方式。值得注意的是，RocketMQ还提供了推送（push）方式的消费模式，其中消息队列服务器会主动将消息推送给消费者。但在当前仅限于pull方式的消费模式。 填写消费数量。 下拉选择选择已建的消息主题和订阅组，若无选项，请新增主题和订阅组，详见上文创建主题和订阅组。 点击【测试】按钮，按照已填写规格及数量产生消费数据，展示消息数据的信息，包括消息ID(messageID)、主题名称（topicName）、生成时间、存储时间、队列ID、消费状态。 拨测功能涉及消息消费状态码，RocketMQ消费状态码是指在消息消费过程中，对消费结果进行标识的状态码。以下是常见的RocketMQ消费状态码： ✧ CONSUMESUCCESS（消费成功）：表示消息成功被消费。 ✧ RECONSUMELATER（稍后重试）：表示消费失败，需要稍后再次进行消费。 ✧ CONSUMEFAILURE（消费失败）：表示消息消费出现异常或失败。 ✧ SLAVENOTAVAILABLE（从节点不可用）：表示消费者无法访问从节点来消费消息。 ✧ NOMATCHEDMESSAGE（无匹配的消息）：表示当前没有匹配的消息需要消费。 ✧ OFFSETILLEGAL（偏移量非法）：表示消费的偏移量参数不合法。 ✧ BROKERTIMEOUT（Broker超时）：表示由于Broker超时导致消费失败。 5、 用户应用按照规范接入RocketMQ，发送、消费消息。 1）生产者示例API 以下适用于南京3、上海7、重庆2、乌鲁木齐27、保定、石家庄20、内蒙6、晋中、北京5节点。 ctgmq引擎版本，SDK下载方式详见环境准备其他工具章节。 package com.ctg.guide; import com.ctg.mq.api.CTGMQFactory; import com.ctg.mq.api.IMQProducer; import com.ctg.mq.api.PropertyKeyConst; import com.ctg.mq.api.bean.MQMessage; import com.ctg.mq.api.bean.MQSendResult; import com.ctg.mq.api.exception.MQException; import com.ctg.mq.api.exception.MQProducerException; import java.util.Properties; / Producer，发送消息 / public class Producer { public static void main(String[] args) throws InterruptedException, MQException { Properties properties new Properties(); properties.setProperty(PropertyKeyConst.ProducerGroupName, "producergroup"); properties.setProperty(PropertyKeyConst.NamesrvAddr, "10.50.208.1:9876;10.50.208.2:9876;10.50.208.3:9876"); properties.setProperty(PropertyKeyConst.NamesrvAuthID, "app4test"); properties.setProperty(PropertyKeyConst.NamesrvAuthPwd, ""); properties.setProperty(PropertyKeyConst.ClusterName, "defaultMQBrokerCluster"); properties.setProperty(PropertyKeyConst.TenantID, "defaultMQTenantID"); IMQProducer producer CTGMQFactory.createProducer(properties);//建议应用启动时创建 int connectResult producer.connect(); if(connectResult ! 0){ return; } for (int i 0; i mqResultList) { //mqResultList 默认为1，可通过批量消费数量设置 for(MQResult result : mqResultList) { //TODO System.out.println(result); } return ConsumerTopicStatus.CONSUMESUCCESS;//对消息批量确认(成功) //return ConsumerTopicStatus.RECONSUMELATER;//对消息批量确认(失败) } }); } } 以下适用于华东1、华北2、西南1、华南2、上海36、青岛20、长沙42、南昌5、武汉41、杭州7、西南2贵州、太原4、郑州5、西安7、呼和浩特3节点。 rocketmq引擎版本，SDK下载方式详见环境准备其他工具章节。 importorg.apache.rocketmq.client.consumer.DefaultMQPushConsumer; importorg.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus; importorg.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently; importorg.apache.rocketmq.client.exception.MQClientException; publicclassPushConsumer{ public static void main(String[] args) throws Exception{ AclClientRPCHook rpcHook newAclClientRPCHook(newSessionCredentials(ACCESSKEY, SECRETKEY)); DefaultMQPushConsumer consumer new DefaultMQPushConsumer(rpcHook); consumer.setConsumerGroup("ConsumerGroupName"); // 填入元数据地址 consumer.setNamesrvAddr("XXX:xxx"); ; //如果需要开启SSL，请增加此行代码 consumer.subscribe("YOUR TOPIC",""); consumer.registerMessageListener((MessageListenerConcurrently)(msgs, context)>{ System.out.printf("%s Receive New Messages: %s %n",Thread.currentThread().getName(), msgs); returnConsumeConcurrentlyStatus.CONSUMESUCCESS; }); consumer.start(); System.out.printf("Consumer Started.%n"); } } 示例参数说明： Namesrv地址 Namesrv地址可从控制台查看，多个地址按分号分隔。 应用用户和密码 这个应用用户和密码就是控制台创建的应用用户和密码。 租户id和集群名 集群名和租户id可以从应用用户管理查询。 订阅组 消费组名需要在控制台提前创建好。

本章节主要介绍ALM24005 Flume传输数据异常的告警。 告警解释 告警模块对Flume Channel的容量状态进行监控，当Channel满的时长超过阈值，或Source向Channel放数据失败的次数超过阈值后，系统即时上报告警。 默认阈值为10，用户可通过conf目录下的配置文件properties.properties修改阈值：修改对应channel的“channelfullcount”参数。 当Flume Channel空间被释放，且告警处理完成时，告警恢复。 告警属性 告警ID 告警级别 是否自动清除 24005 重要 是 告警参数 参数名称 参数含义 来源 产生告警的集群名称。 服务名 产生告警的服务名称。 主机名 产生告警的主机名。 AgentId 产生告警的Agent id。 部件类型 产生告警的元素类型。 部件名 产生告警的元素名称。 对系统的影响 Flume Channel的磁盘空间使用量有继续增长的趋势，将会使数据导入到指定目的地的时间增长，当Flume Channel的磁盘空间使用量达到100%时会导致Flume Agent进程暂停工作。 可能原因 Flume Sink故障，导致数据无法发送。 网络故障，导致数据无法发送。 处理步骤 检查Flume Sink是否故障 1.本地打开用户自定义配置文件properties.properties，搜索配置文件中是否有“type hdfs”关键字确认Flume Sink是否是HDFS类型。 是，执行步骤2。 否，执行步骤3。 2.在FusionInsight Manager的告警列表中查看是否有“HDFS服务不可用”告警产生，服务列表中HDFS是否已停止。 是，如果有告警参考“ALM14000 HDFS服务不可用”的处理步骤处理该故障；如果HDFS已停止，启动HDFS服务，执行步骤7。 否，执行步骤7。 3.本地打开用户自定义配置文件properties.properties，搜索配置文件中是否有“type hbase”关键字确认Flume Sink是否是HBase类型。 是，执行步骤4。 否，执行步骤5。 4.在FusionInsight Manager的告警列表中，查看是否有“HBase服务不可用”告警产生，服务列表中HBase是否已停止。 是，如果有告警参考“ALM19000 HBase服务不可用”的处理步骤处理该故障，如果HBase已停止，启动HBase服务。执行步骤7。 否，执行步骤7。 5.本地打开用户自定义配置文件properties.properties，搜索配置文件中是否有“org.apache.flume.sink.kafka.KafkaSink”关键字确认Flume Sink是否是Kafka类型。 是，执行步骤6。 否，执行步骤9。 6.在FusionInsight Manager的告警列表中，查看是否有“Kafka服务不可用”告警产生，服务列表中Kafka是否已停止。 是，如果有告警参考“ALM38000 Kafka服务不可用”的处理步骤处理该故障；如果Kafka已停止，启动Kafka服务，执行步骤7。 否，执行步骤7。 7.在FusionInsight Manager首页，选择“集群 > 待操作集群的名称 > 服务 > Flume > 实例”。 8.单击进入故障节点的Flume实例页面，查看指标“Sink速度指标”，检查其速度是否为0。 是，执行步骤13。 否，执行步骤9。

中间件故障 各程序报告日志出现如下报错 ：Broker transport failure: 127.0.0.1:9092/0: Connect to ipv4127.0.0.1:9092 failed 日志分析：9092为Kafka服务端口，该提示说明Kafka服务出现异常。

本章节主要介绍准备Flink作业数据。 创建Flink作业需要输入数据源和数据输出通道，即常说的Source和Sink。用户使用其他服务作为数据源或输出通道时，需要先开通相应服务。 Flink作业支持以下数据源和输出通道： OBS数据源 如果用户作业需要对象存储服务（OBS）作为数据源，则要先开通OBS服务，具体操作请参见对象存储用户指南中的有关开通OBS服务的章节。 开通OBS服务后，用户需要将本地文件通过Internet上传至OBS指定的位置，具体操作请参见对象存储用户指南中的“上传文件”章节。 RDS输出通道 如果用户作业需要RDS作为输出通道，需要创建RDS实例，具体操作请参见对应版本关系数据库产品《用户指南》中“创建实例”章节。 SMN输出通道 如果用户作业需要SMN作为输出通道，需要先在SMN中创建主题，获取URN资源标识，再添加订阅。 Kafka数据源和输出通道 如果用户作业需要Kafka作为数据源和输出通道，则必须要通过创建增强型跨源连接与Kafka进行对接，具体操作请参见增强型跨源连接。 如果Kafka服务端的端口监听在hostname上，则需要将Kafka Broker节点的hostname和ip的对应关系添加到跨源连接中。 CloudTable数据源和输出通道 如果用户作业需要CloudTable作为数据源和输出通道，需要先在CloudTable中创建集群，获取集群ID。 云搜索服务输出通道 如果用户作业需要云搜索服务作为输出通道，需要先在云搜索服务中创建集群，获取集群内网访问地址。具体操作请参见云搜索服务用户指南中的“快速入门”章节。 DCS输出通道 如果用户作业需要DCS作为输出通道，需要先在DCS中创建Redis类型的缓存实例，获取Redis实例连接地址。

本文主要介绍分布式消息服务RabbitMQ的惰性队列。 使用场景 默认情况下，RabbitMQ生产者生产的消息存储在内存中，当需要释放内存时，会将内存中的消息换页至磁盘中。换页操作会消耗较长的时间，且换页过程中队列无法处理消息。 如果生产速度过快（例如执行批处理任务），或者消费者由于各种原因（例如消费者下线、宕机）长时间内无法消费消息，导致消息大量堆积，使得内存使用率过高，换页频繁，可能会影响其他队列的消息收发。这种场景下，建议您启用惰性队列。 惰性队列（Lazy Queue）会尽可能的将消息存入磁盘中，在消费者消费到相应的消息时才会被加载到内存中，这样可以减少内存的消耗，但是会增加I/O的使用，影响单个队列的吞吐量。惰性队列的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储/消息堆积。 在以下情况下，推荐使用惰性队列： 队列可能会产生消息堆积 队列对性能（吞吐量）的要求不是非常高，例如TPS 1万以下的场景 希望队列有稳定的生产消费性能，不受内存影响而波动 处于以下情况时，无需使用惰性队列： RabbitMQ需要高性能的场景 队列总是很短（即队列中没有消息堆积） 设置了最大长度策略 更多关于惰性队列的说明，请参考Lazy Queues。

介绍分布式消息服务RabbitMQ创建虚拟主机操作内容。 背景信息 虚拟主机，用作逻辑隔离，分别管理各自的交换器、队列和绑定，使得应用安全地运行在不同的虚拟主机上，相互之间不会干扰。一个实例下可以有多个虚拟主机，一个虚拟主机里面可以有若干个交换器和队列。生产者和消费者连接分布式消息服务 RabbitMQ 版需要指定一个虚拟主机。 操作步骤 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“集群管理”后点击“虚拟主机”到达虚拟主机管理页面，点击“新建”按钮。 （5）点击“新建”后出现以下创建，输入虚拟主机名称后点击确定。 注意：设置虚拟主机名称时，有如下要求： 虚拟主机名称只能包含字母、数字、短划线（）、下划线（）。 虚拟主机名称长度限制在1~64个字符。 虚拟主机创建成功后，Vhost名称不可修改。

本节介绍了分布式消息服务RabbitMQ产品计费模式的区别。 包周期（包年/包月）、按需2种计费模式供您灵活选择，使用越久越便宜。 按包周期实例计费 天翼云提供包月和包年的购买模式。这种购买方式相对于按需付费则能够提供更大的折扣，对于长期使用者，推荐该方式。包周期计费按照订单的购买周期来进行结算。 按需实例计费 这种购买方式比较灵活，可以即开即停，支持秒级计费。实例从“开通”开启计费到“删除”结束计费，按实际购买时长（精确到秒）计费。 下表列出两种模式的区别： 计费模式 包年/包月 按需计费 付费方式 预付费按照订单的购买周期结算。 后付费按照云服务器实际使用时长计费。 计费周期 按订单的购买周期计费。 按小时结算。 实例升级 支持扩容，工单施工完生效，但是施工过程中服务不可用；不支持缩容。 支持扩容，工单施工完生效，但是施工过程中服务不可用；不支持缩容。 更改计费模式 支持变更为按需资源。 支持变更为包周期资源。 变更规格 支持变更实例规格。 支持变更实例规格。 适用场景 适用于可预估资源使用周期的场景，价格比按需计费模式更优惠。对于长期使用者，推荐该方式。 适用于消息资源需求波动的场景，可以随时开通，随时删除。 变更配置：天翼云分布式消息服务支持计费模式变更，更多操作内容请参考按需转包周期。

本章节主要介绍分布式消息服务RabbitMQ的预取值特性。 使用场景 设置预取值可以限制未被确认的消息个数，一旦消费者中未被确认的消息数量达到设置的预取值，服务端将不再向此消费者发送消息，除非至少有一个未被确认的消息被确认。设置预取值本质上是一种对消费者进行流控的方法。 设置预取值时，需要考虑多种因素： 预取值设置太小可能会损害性能，RabbitMQ会一直在等待获得发送消息的权限。 预取值设置太大可能会导致从队列中取出大量消息传递给一个消费者，而使其他消费者处于空闲状态。另外还需要考虑消费者的配置，消费者在处理消息时会将所有消息保存在内存中，太大的预取值会对消费者的性能产生负面影响，甚至可能会导致消费者崩溃。 更多关于预取值的说明，请参考Consumer Prefetch。 如何设置合适的预取值？ 如果您只有一个或很少几个消费者在处理消息，建议一次预取多条消息，尽量让客户端保持忙碌。如果您的处理时间和网络状态稳定，则只需将总往返时间除以每条消息在客户端的处理时间即可获得估计的预取值。 在消费者多且处理时间短的情况下，建议使用较低的预取值。过低的预取值会使消费者闲置，因为消费者在处理完消息后需要等待下一批的消息到达。过高的值可能会使单个消费者忙碌，其他消费者处于空闲状态。 在消费者多且处理时间很长的情况下，建议您将预取值设置为1，以便消息在所有消费者间均匀分布。 说明 如果客户端配置的消息确认机制为自动确认，则设置的预取值无效，已确认的消息会从队列中删除。

本章节主要介绍翼MapReduce的分配机架操作。 操作场景 大型集群的所有主机通常分布在多个机架上，不同机架间的主机通过交换机进行数据通信，且同一机架上的不同机器间的网络带宽要远大于不同机架机器间的网络带宽。在这种情况下网络拓扑规划应满足以下要求： 为了提高通信速率，希望不同主机之间的通信能够尽量发生在同一个机架之内，而不是跨机架。 为了提高容错能力，分布式服务的进程或数据需要尽可能存在多个机架的不同主机上。 Hadoop使用一种类似于文件目录结构的方式来表示主机。两层网络的集群如下图所示，Node1的Rack建议设置为 /Switch1/Rack1 ，Node4的Rack建议设置为 /Switch1/Rack2 。 两层网络结构 由于HDFS不能自动判断集群中各个DataNode的网络拓扑情况，管理员需设置机架名称来确定主机所处的机架，NameNode才能绘出DataNode的网络拓扑图，并尽可能将DataNode的数据备份在不同机架中。同理，YARN需要获取机架信息，在可允许的范围内将任务分配给不同的NodeManager执行。 当集群网络拓扑发生变化时，需要使用FusionInsight Manager为主机重新分配机架，相关服务才会自动调整。 对系统的影响 修改主机机架名称，将影响HDFS的副本存放策略、Yarn的任务分配及Kafka的Partition存储位置。修改后需重启HDFS、Yarn和Kafka，使配置信息生效。 不合理的机架配置会导致集群的节点之间的负载（包括CPU、内存、磁盘、网络）不平衡，降低集群的可靠性，影响集群的稳定运行。所以在分配机架之前，需要进行全局的统筹，合理地设置机架。

本章节主要介绍分布式消息服务RabbitMQ的死信和TTL。 死信和TTL（Time To Live）是RabbitMQ中需要慎用的2个特性，它们可能会对性能产生负面影响。 死信 死信是RabbitMQ中的一种消息机制，在消费消息时，如果队列里的消息满足以下任意一种情况，那么该消息将成为“死信”。 “requeue”被设置为“false”，消费者使用“basic.reject”或“basic.nack”否定应答（NACK）消息。 消息在队列的存活时间超过设置的TTL时间。 队列的消息数量已经超过最大队列长度。 死信消息会被RabbitMQ进行特殊处理，如果配置了死信队列信息，该消息将会被存储到死信队列中，如果没有配置，该消息将会被丢弃。 更多关于死信的说明，请参考Dead Letter Exchanges。 使用队列参数配置死信交换机和路由 为队列配置死信交换机，并在申明队列时指定“xdeadletterexchange”和“xdeadletterroutingkey”参数。队列根据“xdeadletterexchange”将死信消息发送到死信交换机中，并根据“xdeadletterroutingkey”为死信消息设置死信路由Key。 以下示例演示在Java客户端配置死信交换机和路由： channel.exchangeDeclare("some.exchange.name", "direct"); Map args new HashMap (); args.put("xdeadletterexchange", "some.exchange.name"); args.put("xdeadletterroutingkey", "someroutingkey"); channel.queueDeclare("myqueue", false, false, false, args); TTL TTL即过期时间。RabbitMQ支持设置消息和队列的TTL，消息的TTL可以通过以下两种方法设置： 通过队列属性设置：队列中所有消息的具有相同的过期时间。 对消息本身单独设置：每条消息可以设置不同的TTL。 如果两种方法同时使用，以较小的TTL为准。 消息在队列中的生存时间超过了TTL后，消息会被丢弃，如果队列设置了死信交换机，丢弃的消息会被转发到死信交换机，由死信交换机将其路由到死信队列。 更多关于TTL的说明，请参考TTL。

介绍分布式消息服务RabbitMQ惰性队列能力。 使用场景 RabbitMQ从3.6.0版本开始引入了惰性队列（Lazy Queue）的概念。惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中，它的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储。当消费者由于各种各样的原因（比如消费者下线、宕机亦或者是由于维护而关闭等）而致使长时间内不能消费消息造成堆积时，惰性队列就很有必要了 默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当RabbitMQ需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。虽然RabbitMQ的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在消息量特别大的时候 惰性队列会将接收到的消息直接存入文件系统中，而不管是持久化的或者是非持久化的，这样可以减少了内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免，惰性队列和持久化消息可谓是“最佳拍档”。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启之后消息一样会丢失。

介绍分布式消息服务RabbitMQ消息持久化功能。 使用场景 在生产过程中，难免会发生服务器宕机的事情，RabbitMQ也不例外，可能由于某种特殊情况下的异常而导致RabbitMQ宕机从而重启，那么这个时候对于消息队列里的数据，包括交换机、队列以及队列中存在消息恢复就显得尤为重要了。RabbitMQ本身带有持久化机制，包括交换机、队列以及消息的持久化。持久化的主要机制就是将信息写入磁盘，当RabbtiMQ服务宕机重启后，从磁盘中读取存入的持久化信息，恢复数据。 设置交换器持久化 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“交换器管理”后，点击“新建”按钮。 （5）点击“新建”后出现以下窗口，是否持久化选择是。 设置队列持久化 （1）登录管理控制台。 （2）进入RabbitMQ管理控制台。 （3）在实例列表页在操作列，目标实例行点击“管理”。 （4）点击“队列管理”后，点击“新建”按钮。 （5）点击“新建”后出现以下窗口，是否持久化选择是。

服务名称 Spark SQL作业 Spark jar作业 Flink SQL作业 Flink jar作业 APIG x x √ x CSS √ √ √ √ DCS Redis √ √ √ √ DDS Mongo √ √ √ √ DMS Kafka x x √ √ DWS √ √ √ √ MRS HBase √ √ √ √ MRS Kafka x x √ √ MRS OpenTSDB √ √ x √ RDS MySQL √ √ √ √ RDS PostGre √ √ √ √

本文主要介绍分布式消息服务RabbitMQ的业务迁移最佳实践。 RabbitMQ迁移指将生产与消费消息的客户端切换成连接新RabbitMQ，部分还涉及将持久化的消息文件迁移到新的RabbitMQ。提供以下2种方案： 方案一：不迁移数据，先切换生产，再切换消费。 方案二：先迁移数据，然后同时切换生产和消费。 方案一：不迁移数据，先切换生产，再切换消费 针对线下单机或集群实例，在不迁移数据的情况下，首先将消息生产切换到线上实例，不再生产消息到线下实例，消费方同时消费线下以及线上实例。当线下实例消息全部消费完后，将消息消费切换到线上实例，完成整个迁移过程。 说明 该方案无法保障消息消费的有序性。 确保客户端与线上实例可连通。 通过以下方法，确认线下实例是否消费完成： 1. 在RabbitMQ WebUI页面查看，如图1所示。 Overview视图中，可消费消息数（Ready）以及未确认的消息数（Unacked）都为0时，说明消费完成。 图1 RabbitMQ WebUI 2. 调用API查看。 curl s u username:password XGET 参数说明： username：线下实例登录RabbitMQ WebUI的帐号 password：线下实例登录RabbitMQ WebUI的密码 ip：线下实例登录RabbitMQ WebUI的IP地址 port：线下实例登录RabbitMQ WebUI的端口号 回显信息中“messagesready”和“messagesunacknowledged”都为0时，说明消费完成。 图2 回显信息

介绍分布式消息服务RabbitMQ死信和TTL功能。 死信 称为死信的信息，需要如下几个条件： 消息被消费者拒绝（通过basic.reject 或者 back.nack），并且设置 requeuefalse。 消息过期，队列设置了TTL（Time To Live）时间并且消息过期。 超过了队列的长度限制消息被丢弃。 为队列配置死信交换机，并在申明队列时指定“xdeadletterexchange”和“xdeadletterroutingkey”参数。队列根据“xdeadletterexchange”将死信消息发送到死信交换机中，并根据“xdeadletterroutingkey”为死信消息设置死信路由Key。 以下示例演示在Java客户端配置死信交换机和路由 channel.exchangeDeclare("some.exchange.name", "direct"); Map args new HashMap (); args.put("xdeadletterexchange", "some.exchange.name"); args.put("xdeadletterroutingkey", "someroutingkey"); channel.queueDeclare("myqueue", false, false, false, args); TTL RabbitMQ可以对消息和队列设置TTL. 目前有两种方法可以设置。第一种方法是通过队列属性设置，队列中所有消息都有相同的过期时间。第二种方法是对消息进行单独设置，每条消息TTL可以不同。如果上述两种方法同时使用，则消息的过期时间以两者之间TTL较小的那个数值为准。消息在队列的生存时间一旦超过设置的TTL值，就称为dead message， 消费者将无法再收到该消息。 设置队列TTL 通过队列属性设置消息TTL的方法是在queue.declare方法中加入xmessagettl参数，单位为ms. 以下示例演示在Java客户端设置队列TTL。 Map argss new HashMap (); argss.put("xmessagettl",6000); channel.queueDeclare(queueName, durable, exclusive, autoDelete, argss);

本文主要介绍分布式消息服务RabbitMQ的实例规格。 RabbitMQ实例规格 RabbitMQ实例兼容开源RabbitMQ 3.8.35，实例类型包括单机和集群，实例规格请参考下表。 说明 为了保证稳定性，服务端限制了单条消息的最大长度为50MB，请勿发送大于此长度的消息。 下表中TPS，是指以2KB大小的消息为例的每秒处理消息条数，测试场景为不开启持久化的非镜像队列，实时生产实时消费，队列无积压。此数据仅供参考，生产使用需要以实际压测性能为准。 服务端的性能主要跟以下因素相关：队列数、消息堆积、连接数、channel、消费者数、镜像队列、优先级队列、消息持久化和exchange类型等，在选择实例规格时，请根据业务模型压测结果选择。 一条连接最多可以开启2047个channel。 表1 RabbitMQ实例规格 型号 代理数 存储空间范围 TPS参考值 单个代理最大消费者数 单个代理建议队列数 单个代理最大连接数 rabbitmq.2u4g.single 1 100GB~30000GB 10000 20000 200 3000 rabbitmq.4u8g.single 1 100GB~30000GB 20000 30000 400 4500 rabbitmq.8u16g.single 1 100GB~30000GB 35000 50000 800 7500 rabbitmq.16u32g.single 1 100GB~30000GB 45000 80000 1600 12000 rabbitmq.24u48g.single 1 100GB~30000GB 50000 100000 2400 15000 rabbitmq.2u4g.cluster 3/5/7 3/5/7100GB~30000GB 30000~70000 20000 200 3000 rabbitmq.4u8g.cluster 3/5/7 3/5/7100GB~30000GB 45000~80000 30000 400 4500 rabbitmq.8u16g.cluster 3/5/7 3/5/7100GB~30000GB 85000~120000 50000 800 7500 rabbitmq.12u24g.cluster 3/5/7 3/5/7100GB~30000GB 100000~150000 60000 1200 10000 rabbitmq.16u32g.cluster 3/5/7 3/5/7100GB~30000GB 130000~180000 80000 1600 12000 rabbitmq.24u48g.cluster 3/5/7 3/5/7100GB~30000GB 150000~200000 100000 2400 15000

本文介绍分布式消息服务MQTT的Keep Alive设置推荐。 在MQTT中，Keep Alive是一个用于保持客户端和服务器之间的活动连接的机制。它是通过客户端定期发送PINGREQ消息来实现的，以确保连接保持活动状态。当服务器接收到PINGREQ消息后，会回复PINGRESP消息，表示连接仍然活动。 Keep Alive的设置取决于你的应用需求和网络环境。以下是一些建议： 1. 根据网络稳定性设置：如果你的网络环境非常稳定，连接很少会断开，你可以将Keep Alive设置为较长的时间，例如60秒或更长。这样可以减少PINGREQ和PINGRESP消息的频繁发送，减少网络流量和资源消耗。 2. 根据应用实时性设置：如果你的应用对实时性要求较高，需要及时获取和响应消息，则可以将Keep Alive设置为较短的时间，例如10秒或更短。这样可以快速检测到连接丢失，并尽快重新连接或采取相应的处理措施。 3. 根据网络延迟设置：如果你的网络延迟较高，连接速度较慢，你可能需要将Keep Alive设置为较长的时间，以允许更多的时间来处理网络延迟和连接恢复。 需要注意的是，Keep Alive的设置不应过于频繁或过于长久。太频繁的Keep Alive会增加网络流量和服务器负载，太长久的Keep Alive可能会导致连接超时和断开。 一般来说，根据网络稳定性和应用实时性的考虑，将Keep Alive设置为30秒到5分钟之间是比较常见的。你可以根据你的具体需求和实际情况进行调整和优化。

计费周期 包年/包月RabbitMQ实例的计费周期是根据您购买的时长来确定的（以UTC+8时间为准）。一个计费周期的起点是您开通或续费资源的时间（精确到秒），终点则是到期日的23:59:59。 例如，如果您在2023/03/08 15:50:04购买了一个时长为一个月的RabbitMQ实例，那么其计费周期为：2023/03/08 15:50:04 ~ 2023/04/08 23:59:59。 计费示例 假设您于2023/03/08 15:50:04在“广州4”购买了一个包年/包月RabbitMQ实例（规格：rabbitmq.2u4g.cluster3，总存储空间：超高I/O 300GB），计费资源包括实例费用（代理规格和代理数量），以及存储空间费用（超高I/O 300GB）。购买时长为一个月，并在到期前手动续费1个月，则： 第一个计费周期为：2023/03/08 15:50:04 ~ 2023/04/08 23:59:59 第二个计费周期为：2023/04/08 23:59:59 ~ 2023/05/08 23:59:59 您需要为每个计费周期预先付费，各项RabbitMQ资源单独计费，计费公式如表2所示。 表2 计费公式 资源类型 计费公式 资源单价 实例费用 实例规格单价 购买时长 请参见分布式消息服务RabbitMQ[]( 存储空间费用 存储空间单价 购买时长 请参见分布式消息服务RabbitMQ[]( 图2 包年/包月RabbitMQ实例费用计算示例 说明 图2中价格仅供参考，实际计算请以分布式消息服务RabbitMQ

本章节介绍了如何修改分布式消息服务RocketMQ实例的信息。 操作场景 购买RocketMQ实例成功后，您可以根据自己的业务情况对RocketMQ实例的部分参数进行调整，包括实例名称、企业项目、描述和安全组。 操作步骤 1. 登录分布式消息服务RocketMQ控制台。 2. 单击RocketMQ实例的名称，进入实例详情页面。 图1 实例详情 3. 以下参数支持修改。 o 实例名称 企业项目 o 描述 o 公网访问（公网访问的修改方法，请参考设置实例公网访问。） o 安全组 o ACL访问控制（2021年8月21号后购买的实例，才支持修改） 参数修改完成后，通过以下方式查看修改结果。 o 修改“公网访问”，系统跳转到“后台任务管理”页签，并显示当前任务的操作进度和结果。 o 修改“实例名称”、“描述”、“ACL访问控制”、“企业项目”和“安全组”后，右上角直接提示修改结果。

介绍分布式消息服务RabbitMQ预取值功能 使用场景 所谓消息预取机制，它定义了在一个信道上，消费者允许的最大未确认的消息数量。 一旦未确认的消息数量达到了设置的预取值，RabbitMQ就停止传递更多消息，除非至少有一条未完成的消息得到了确认。 如何设置合适的预取值 通常，增加预取将提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的，但是，在这种情况下已传递但尚未处理的消息的数量也会增加，从而增加了消费者的 RAM 消耗(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式，消费者消费了大量的消息如果没有确认的话，会导致消费者连接节点的内存消耗变大，所以找到合适的预取值是一个反复试验的过程，不同的负载该值取值也不同 100 到 300 范围内的值通常可提供最佳的吞吐量，并且不会给消费者带来太大的风险。 预取值为 1 是最保守的。当然这将使吞吐量变得很低，特别是消费者连接延迟很严重的情况下，特别是在消费者连接等待时间较长的环境 中。对于大多数应用来说，稍微高一点的值将是最佳的。 设置预取值 设置预取值的java示例代码如下 ConnectionFactory factory new ConnectionFactory(); Connection connection factory.newConnection(); Channel channel connection.createChannel(); channel.basicQos(20, false);

本节介绍如何快速连接RocketMQ并生产和消费消息。 本章节将为您介绍分布式消息服务RocketMQ（以下简称RocketMQ）入门的使用流程，以创建一个开启SSL的RocketMQ实例，客户端使用内网通过同一个VPC连接RocketMQ实例生产消费消息为例，帮助您快速上手RocketMQ。 1. 在ECS环境中进入“rocketmqtutorial/bin”目录。 plaintext cd rocketmqtutorial/bin 2. 运行生产普通消息命令。 命令示例如下： plaintext JAVAOPTDtls.enabletrue sh mqadmin sendMessage n "10.xxx.xxx.89:8100;10.xxx.xxx.144:8100" t Topic01 p "hello rocketmq" 10.xxx.xxx.89:8100;10.xxx.xxx.144:8100：表示RocketMQ实例的“连接地址”，即11中记录的连接地址。 Topic01：表示RocketMQ实例下创建的Topic名称，即4中创建的Topic名称。 hello rocketmq：表示生产消息的内容，可自定义。 3. 运行消费普通消息命令。 命令示例如下： plaintext JAVAOPTDtls.enabletrue sh mqadmin consumeMessage n "10.xxx.xxx.89:8100;10.xxx.xxx.144:8100" t Topic01 如上图中BODY显示的内容即为消费消息的内容。 如需停止消费使用Ctrl+C命令退出。

标签可以识别资源，您可以将作用相同的分布式消息服务RocketMQ资源通过标签进行归类，便于搜索和资源聚合。本文介绍标签的使用说明以及标签的相关操作。 使用说明 标签都由一对键值对（KeyValue）组成。 资源的任一标签的标签键（Key）必须唯一。 例如，实例先添加了type:order标签，后续如需添加type:pay标签，需先删除type:pay标签。 添加标签 1. 登录分布式消息服务RocketMQ控制台，在左侧导航栏单击实例列表 。 2. 在顶部菜单栏，选择地域，如华东1。 在该地域的所有实例都展示在实例列表页面。 3. 在实例列表页面，找到您想要添加标签的实例，在其标签列，将光标移动至图标，在弹出的消息框中，单击 + 添加 。 4. 在编辑标签面板，按要求输入标签键和标签值 ，然后单击确定 。 根据标签过滤资源 说明 本文介绍如何通过标签过滤实例列表。 1. 在实例列表页面，单击筛选标签 。 2. 分别在标签键和标签值下的列表中选择对应的值，然后单击搜索，列表中将只显示绑定了对应标签的实例。

本节介绍了编译工程生产消费的主要内容点,包括引入依赖、绑定BindingKey、生产消息和消费消息。 前提条件 创建分布式消息服务RabbitMQ实例。 操作步骤 RabbitMQ是一个开源的消息队列中间件，支持生产者和消费者之间的异步通信。在上述资源准备完成后，接下来需要编译工程生产消费，主要分以下几个步骤： 1、编写生产者代码：编写一个生产者程序。该程序将连接到RabbitMQ服务器，并将消息发送到队列中。 2、编写消费者代码：编写一个消费者程序。该程序将连接到RabbitMQ服务器，并从队列中接收消息。 3、运行生产者和消费者：运行生产者程序，它将发送消息到队列中。然后运行消费者程序，它将从队列中接收并处理消息。 4、验证结果：检查生产者和消费者程序的输出，确保消息被正确发送和接收。 引入依赖 在使用RabbitMQ时，你需要在你的项目中引入相应的依赖。具体的依赖项可能会因你的项目和需求而有所不同。在使用RabbitMQ之前，请确保查阅官方文档以获取最新的依赖项和使用说明。 以Java编程语言为例，可以使用RabbitMQ的Java客户端库。你可以在Maven或Gradle构建工具中添加以下依赖项： com.rabbitmq amqpclient 5.7.0 也可以通过下载JAR包来引入依赖。 绑定BindingKey 在RabbitMQ中，绑定键（Binding Key）是用于绑定交换机（Exchange）和队列（Queue）的关键字。当一个消息被发送到交换机时，交换机会根据绑定键将消息路由到相应的队列中。 绑定键是在创建绑定（Binding）时指定的，它定义了消息应该如何被路由到队列。绑定键通常与消息的属性或内容进行匹配，以确定消息应该发送到哪个队列。 绑定键可以具有不同的形式，取决于使用的交换机类型。以下是一些常见的绑定键形式： 直接匹配（Direct Match）：绑定键与消息的路由键（Routing Key）完全匹配时，消息会被路由到相应的队列。 通配符匹配（Wildcard Match）：绑定键可以使用通配符进行模式匹配。常见的通配符有和

服务后缀 服务说明 zos dns msgc crs apm lts faas gts 全局事务：该服务由天翼云全局事务服务提供，全局事务服务是一款专为实现分布式环境下高性能事务一致性而设计的服务工具。它可以与MySQL、PostgreSQL等数据源，以及Spring Cloud、Dubbo等RPC框架和消息队列等中间件产品配合混合使用，以支持用户各种分布式数据库事务、多库事务、消息事务和服务链路级事务的组合需要 prome 应用性能监控：Prometheus监控为云上托管Prometheus服务，可为您的容器集群提供多种开箱即用的预置监控大盘与监控规则，实现免搭建的高效运维场景。 ags Agent沙箱：Agent 沙箱提供安全、弹性、可扩展的云端沙箱运行环境。在使用Agent沙箱产品时，通过连接该终端节点服务，可实现在内网调用沙箱服务。

给予 systemd 服务文件可执行权限 sudo chmod +x /etc/systemd/system/filebeat.service 启用并启动 Filebeat 服务 echo "Enabling and starting Filebeat service..." sudo systemctl daemonreload sudo systemctl enable filebeat sudo systemctl start filebeat echo "Filebeat service has been started." 输出 Filebeat 的进程状态 echo "Filebeat service status:" sudo systemctl status filebeat cat 2. 登录数据归集节点的ECS并部署Filebeat（与步骤2部署方式相同）数据归集节点Filebeat.yml： filebeat.inputs: type: kafka enabled: true hosts: kafka机器ip:kafka端口 topics: ["icmpprobe"] groupid: "filebeaticmpprobeopensearchtest" worker: 6 fields: type: "icmp" type: kafka enables: true hosts: kafka机器ip:kafka端口 topics: ["httpprobe"] groupid: "filebeathttpprobeopensearchtest" fields: type: "http" filebeat.config.modules: enabled: false path: /opt/filebeat/filebeat8.12.2linuxx8664/modules.d/.yml reload.enabled: false setup.template.settings: index.numberofshards: 1 setup.kibana: processors: decodejsonfields: fields: ["message"] overwritekeys: true target: "" dropfields: when: equals: fields.type: "icmp" fields: ["log","ecs","agent","host","input","kafka","Total","SourceIP","RemoteIP","JobId","message","Rtts ms"] ignoremissing: true dropfields: when: equals: fields.type: "http" fields: ["log","ecs","agent","host","input","kafka","message","JobId","SourceIP","HttpUrl"] ignoremissing: true output.elasticsearch: enabled: true hosts: [" username: "OpenSearch用户名" password: "OpenSearch密码" ssl.verificationmode: none worker: 6 indices: index: "icmpindex%{+yyyyMMdd}" when.contains: fields: type: "icmp" index: "httpindex%{+yyyyMMdd}" when.contains: fields: type: "http" logging.level: info seccomp: defaultaction: allow syscalls: action: allow names: rseq 3. 配置OpenSearch： a. 查看是否数据成功投递到了OpenSearch中。 b. 创建Visualization需要用到的indexpattern。 4. 配置Visualization： a.创建Visualization： b.配置横纵坐标。 c.展示效果图:

介绍分布式消息服务RabbitMQ查看虚拟主机操作内容。 场景描述 在RabbitMQ中，虚拟主机（Virtual Host）是一个逻辑隔离的消息代理环境，用于分隔不同应用或不同团队之间的消息流。当需要查看虚拟主机的信息时，可能有以下场景描述： 管理员查看虚拟主机配置：管理员需要查看虚拟主机的配置信息，包括虚拟主机的名称、权限设置、连接数限制等。这可以帮助管理员了解当前系统的虚拟主机情况，进行配置管理和优化。 开发人员查看虚拟主机队列信息：开发人员需要查看虚拟主机中队列的信息，包括队列的名称、消息数量、消费者数量等。这可以帮助开发人员了解当前队列的状态，监控消息的流动情况，进行故障排查和性能调优。 运维人员查看虚拟主机连接信息：运维人员需要查看虚拟主机的连接信息，包括连接的客户端IP、连接数、协议等。这可以帮助运维人员监控连接的使用情况，检测异常连接，进行资源管理和安全审计。 操作步骤 （1）在虚拟主机管理页面，点击目标虚拟主机名称，即可参看虚拟主机详情。 （2）查看虚拟主机概览，主要展示最近时间段各类型消息数量和消息tps统计。 （3）参看用户配置权限及读写权限信息。 （4）查看用户主题权限信息。