AutoMQ 开源可观测性方案:夜莺 Flashcat

Prometheus2.25 新特性讲解 前言 Prometheus作为第二个从CNCF毕业的顶级项目,其成熟程度是毋庸置疑的,甚至推出了另一个CNCF项目OpenMetrics,希望将Prometheus的指标格式演进成为一个行业规范。 更新总览 在Prometheus-v2.25.0版本中更新一览: [实验性功能]支持remote_write请求,默认不启用,启用需要启动参数指定--enable-feature = remote-write-receiver [实验性功能]新增'@'修饰符,默认不启用,启用需要启动参数指定 阅读详情

01 引言

在现代企业中,随着数据处理需求的不断增长,AutoMQ [1] 作为一种高效、低成本的流处理系统,逐渐成为企业实时数据处理的关键组件。然而,随着集群规模的扩大和业务复杂性的增加,确保 AutoMQ 集群的稳定性、高可用性和性能优化变得尤为重要。因此,集成一个强大而全面的监控系统对于维护 AutoMQ 集群的健康运行至关重要。夜莺监控系统(Nightingale)[2] 以其高效的数据采集、灵活的告警管理和丰富的可视化能力,成为企业监控AutoMQ 集群的理想选择。通过使用夜莺监控系统,企业可以实时掌握 AutoMQ 集群的运行状态,及时发现和解决潜在问题,优化系统性能,确保业务的连续性和稳定性。

AutoMQ 概述

AutoMQ 是一种基于云重新设计的流处理系统,它在保持与 Apache Kafka 100% 兼容的前提下,通过将存储分离至对象存储,显著提升了系统的成本效益和弹性能力。具体来说,AutoMQ 通过构建在 S3 上的流存储库 S3Stream,将存储卸载至云厂商提供的共享云存储 EBS 和 S3,提供低成本、低延时、高可用、高可靠和无限容量的流存储能力。与传统的 Shared Nothing 架构相比,AutoMQ 采用了 Shared Storage 架构,显著降低了存储和运维的复杂性,同时提升了系统的弹性和可靠性。AutoMQ 的设计理念和技术优势使其成为替换企业现有 Kafka 集群的理想选择。通过采用 AutoMQ,企业可以显著降低存储成本,简化运维,并实现集群的自动扩缩容和流量自平衡,从而更高效地应对业务需求的变化。此外,AutoMQ 的架构支持高效的冷读操作和服务零中断,确保系统在高负载和突发流量情况下的稳定运行。它的存储结构如下:

AutoMQ 存储结构

夜莺概述

夜莺监控系统(Nightingale)是一款开源的云原生观测分析工具,采用 All-in-One 设计理念,集数据采集、可视化、监控告警和数据分析于一体。其主要优势包括高效的数据采集能力、灵活的告警策略和丰富的可视化功能。夜莺与多种云原生生态紧密集成,支持多种数据源和存储后端,提供低延迟、高可靠性的监控服务。通过使用夜莺,企业可以实现对复杂分布式系统的全面监控和管理,快速定位和解决问题,从而优化系统性能和提高业务连续性。

02 前置条件

为了实现集群状态的监控,你需要如下环境:

  • 部署一个可用的 AutoMQ 节点/集群,并开放 Metrics 采集端口
  • 部署夜莺监控及其依赖环境
  • 部署 Prometheus [4] 以获取 Metrics 数据

03 部署 AutoMQ、Prometheus 以及夜莺监控

部署 AutoMQ

参考 AutoMQ 文档:集群方式部署 | AutoMQ [5] 。在部署启动前,添加如下配置参数以开启 Prometheu 的拉取接口。通过以下参数启动 AutoMQ 集群以后,每个节点将会额外开放一个 HTTP 接口供我们拉取 AutoMQ 的监控指标。这些指标的格式均遵循 Prometheus Metrics 的格式。

bin/kafka-server-start.sh ...
--override  s3.telemetry.metrics.exporter.type=prometheus 
--override  s3.metrics.exporter.prom.host=0.0.0.0 
--override  s3.metrics.exporter.prom.port=8890 
....

当启用 AutoMQ 监控指标后,可以在任意一台节点上通过 HTTP 协议拉取到 Prometheus 格式的监控指标,地址为:http://{node_ip}:8890,响应结果示例如下:

....
kafka_request_time_mean_milliseconds{otel_scope_name="io.opentelemetry.jmx",type="DescribeDelegationToken"} 0.0 1720520709290
kafka_request_time_mean_milliseconds{otel_scope_name="io.opentelemetry.jmx",type="CreatePartitions"} 0.0 1720520709290
...

关于指标介绍,可以参考 AutoMQ 官网文档:Metrics | AutoMQ [6] 。

部署 Prometheus

Prometheus 可以通过下载二进制包部署,也可以通过 Docker 方式部署。以下是这两种部署方式的介绍。

二进制部署

为了方便使用,你可以新建一个脚本,并根据需要修改 Prometheus 的下载版本,最后执行脚本即可完成部署。首先,新建脚本:

cd /home
vim install_prometheus.sh
# !!! 粘贴下面的脚本内容 并保存退出
# 授予权限
chmod +x install_prometheus.sh
# 执行脚本
./install_prometheus.sh

脚本内容如下:

version=2.45.3
filename=prometheus-${version}.linux-amd64
mkdir -p /opt/prometheus
wget https://github.com/prometheus/prometheus/releases/download/v${version}/${filename}.tar.gz
tar xf ${filename}.tar.gz
cp -far ${filename}/*  /opt/prometheus/

# config as a service 
cat <<EOF >/etc/systemd/system/prometheus.service
[Unit]
Description="prometheus"
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple

ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/prometheus/data --web.enable-lifecycle --web.enable-remote-write-receiver

Restart=on-failure
SuccessExitStatus=0
LimitNOFILE=65536
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=prometheus


[Install]
WantedBy=multi-user.target
EOF

systemctl enable prometheus
systemctl restart prometheus
systemctl status prometheus

随后修改 Prometheus 的配置文件,增加采集 AutoMQ 可观测数据的任务,并重启 Prometheus,执行命令:

# config 配置文件内容填下面的
vim /opt/prometheus/prometheus.yml
# 重启 Prometheus
systemctl restart prometheus

配置文件内容参考如下,请将下列中的client_ip修改为 AutoMQ 开放的可观测数据暴露地址:

# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
      
  - job_name: "automq"
    static_configs:
      - targets: ["{client_ip}:8890"]

部署完成后,我们可以通过浏览器访问 Prometheus,查看是否真正采集到了 AutoMQ 的 Metrics数据,访问http://{client_ip}:9090/targets:

Docker 部署

如果你已经有一个在运行的 Prometheus Docker 容器,请先执行命令删除该容器:

docker stop prometheus
docker rm prometheus

新建配置文件,并在 Docker 启动时进行挂载:

mkdir -p /opt/prometheus
vim /opt/prometheus/prometheus.yml
# 配置内容参考上述 “二进制部署” 中的配置

启动 Docker 容器:

docker run -d 
  --name=prometheus 
  -p 9090:9090 
  -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml 
  -m 500m 
  prom/prometheus 
  --config.file=/etc/prometheus/prometheus.yml 
  --enable-feature=otlp-write-receiver 
  --web.enable-remote-write-receiver

这样你便得到了一个采集 AutoMQ Metrics 的 Prometheus 服务,关于更多 AutoMQ Metrics 与 Prometheus 集成的介绍,可以参考:将 Metrics 集成到 Prometheus | AutoMQ [7]。

部署夜莺监控

夜莺监控可以通过下面三种方式进行部署,关于更详细的部署说明可以参考官方文档 [8]:

  • Docker compose 方式部署
  • 二进制方式部署
  • Helm 方式部署

接下来我将采用二进制的方式进行部署。

下载夜莺

请在夜莺 Github releases [9] 页中选择合适的版本进行下载,这里我们采用的版本是v7.0.0-beta.14。如果你是 amd 架构的机器,可直接执行如下命令:

cd /home
# 下载
wget https://github.com/ccfos/nightingale/releases/download/v7.0.0-beta.14/n9e-v7.0.0-beta.14-linux-amd64.tar.gz
mkdir -p /home/flashcat
# 解压文件到 /home/flashcat 文件夹
tar -xzf /home/n9e-v7.0.0-beta.14-linux-amd64.tar.gz -C /home/flashcat
# 进入主目录
cd /home/flashcat

配置依赖环境

夜莺依赖 MySQL 和 Redis,因此需要提前安装这两个环境。你可以通过 Docker 方式部署,也可以通过执行命令进行安装,参考命令如下:

# install mysql
yum -y install mariadb*
systemctl enable mariadb
systemctl restart mariadb
mysql -e "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('1234');"

# install redis
yum install -y redis
systemctl enable redis
systemctl restart redis

这里 Redis 设置的是无密码的。并且这里指定 MySQL 数据库的密码为1234,如果你需要更改为其他的密码,要在夜莺的配置文件中进行配置,以保证夜莺能连接到你的数据库。修改夜莺配置文件:

vim /home/flashcat/etc/config.toml

修改 [DB] 下的用户名和密码:
[DB]
# postgres: host=%s port=%s user=%s dbname=%s password=%s sslmode=%s
# postgres: DSN="host=127.0.0.1 port=5432 user=root dbname=n9e_v6 password=1234 sslmode=disable"
# sqlite: DSN="/path/to/filename.db"
DSN = "{username}:{password}@tcp(127.0.0.1:3306)/n9e_v6?charset=utf8mb4&parseTime=True&loc=Local&allowNativePasswords=true"
# enable debug mode or not

导入数据库表

执行如下命令:

mysql -uroot -p1234 < n9e.sql

请通过数据库工具检测是否成功导入数据库表:

> show databases;
+--------------------+
| Database           |
+--------------------+
| n9e_v6             |
+--------------------+

> show tables;
+-----------------------+
| Tables_in_n9e_v6      |
+-----------------------+
| alert_aggr_view       |
| alert_cur_event       |
| alert_his_event       |
| alert_mute            |
| alert_rule            |
| alert_subscribe       |
| alerting_engines      |
| board                 |
| board_busigroup       |
| board_payload         |
| builtin_cate          |
| builtin_components    |
| builtin_metrics       |
······

修改夜莺配置文件

你需要修改夜莺的配置文件,进行 Prometheus 数据源的设置:

vim /home/flashcat/etc/config.toml

# 修改 [[Pushgw.Writers]] 部分的内容为
[[Pushgw.Writers]]
# Url = "http://127.0.0.1:8480/insert/0/prometheus/api/v1/write"
Url = "http://{client_ip}:9090/api/v1/write"

启动夜莺

在夜莺的根目录 /home/flashcat下执行:./n9e。成功启动后,可在浏览器中访问 http://{client_ip}:17000,默认的登录账号和密码为:

  • 账号:root
  • 密码:root.2020

接入 Prometheus 数据源

左侧边栏集成 -> 数据源 -> Prometheus。

至此,我们的夜莺监控就部署结束了。

04 夜莺监控 AutoMQ 集群状态

接下来,我将介绍夜莺监控提供的一部分功能,帮助你更好地了解夜莺与 AutoMQ 集成的可用功能。

即时查询

选择内置的 AutoMQ 指标:

可以尝试查询一些数据,比如Fetch请求处理时间的平均值 kafka_request_time_50p_milliseconds:

同时你也可以自定义一些指标,并利用表达式对指标进行聚合:

警报功能

选择左侧边栏警报 -> 警报规则 -> 新建规则。比如我们可以给 kafka_network_io_bytes_total设置报警,这个指标的意义是 Kafka Broker 节点通过网络发送或接收的字节总数,通过对这个指标设置表达式,就能够计算 Kafka Broker 节点的入站网络 I/O 速率。表达式为:

sum by(job, instance) (rate(kafka_network_io_bytes_total{direction="in"}[1m]))

设置警报规则:

Data preview:

同时你也可以设置发生警报时会通知到的群组:

创建完告警后,让我们来模拟高并发的消息处理场景:短时间内总共2500000条消息被发送到 AutoMQ 节点,我采用的方式是通过 Kafka SDK 的方式进行消息发送,一次共 50 个 Topic ,给每个 Topic 发送 500 条消息,共 100 次。示例如下:

import org.apache.kafka.clients.admin.AdminClient;
import org.apache.kafka.clients.admin.AdminClientConfig;
import org.apache.kafka.clients.admin.NewTopic;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.clients.producer.ProducerRecord;
import org.apache.kafka.clients.producer.RecordMetadata;
import org.apache.kafka.common.serialization.StringSerializer;

import java.util.ArrayList;
import java.util.List;
import java.util.Properties;
import java.util.concurrent.ExecutionException;

public class KafkaTest {

    private static final String BOOTSTRAP_SERVERS = "http://{}:9092"; // your automq broker ip
    private static final int NUM_TOPICS = 50;
    private static final int NUM_MESSAGES = 500;

    public static void main(String[] args) throws Exception {
        KafkaTest test = new KafkaTest();
        // test.createTopics();    // create 50 topics
        for(int i = 0; i < 100; i++){
            test.sendMessages();   // 25,000 messages will be sent each time, and 500 messages will be sent to each of 50 topics.
        }
    }
    
    public void createTopics() {
        Properties props = new Properties();
        props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVERS);

        try (AdminClient adminClient = AdminClient.create(props)) {
            List<NewTopic> topics = new ArrayList<>();
            for (int i = 1; i <= NUM_TOPICS; i++) {
                topics.add(new NewTopic("Topic-" + i, 1, (short) 1));
            }
            adminClient.createTopics(topics).all().get();
            System.out.println("Topics created successfully");
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        }
    }

    public void sendMessages() {
        Properties props = new Properties();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVERS);
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

        try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
            for (int i = 1; i <= NUM_TOPICS; i++) {
                String topic = "Topic-" + i;
                for (int j = 1; j <= NUM_MESSAGES; j++) {
                    String key = "key-" + j;
                    String value = "{\"userId\": " + j + ", \"action\": \"visit\", \"timestamp\": " + System.currentTimeMillis() + "}";
                    ProducerRecord<String, String> record = new ProducerRecord<>(topic, key, value);
                    producer.send(record, (RecordMetadata metadata, Exception exception) -> {
                        if (exception == null) {
                            System.out.printf("Sent message to topic %s partition %d with offset %d%n", metadata.topic(), metadata.partition(), metadata.offset());
                        } else {
                            exception.printStackTrace();
                        }
                    });
                }
            }
            System.out.println("Messages sent successfully");
        }
    }
}

随后我们可以在夜莺控制台看到报警信息:

告警详细信息:

仪表盘

首先我们可以利用已知的指标建立自己的仪表盘,如下所示是对 AutoMQ 消息请求处理时间,消息总数,网络 IO 比特数进行的统计仪表盘:

同时,我们也可以利用官方内置的仪表盘进行监测。左侧边栏 -> 聚合 -> 模板中心:

选择 AutoMQ,可以看到有几个 DashBoard 可以选用:

我们选择 Topic Metrics 仪表盘,展示内容如下:

这里展示了 AutoMQ 集群在最近一段时间内的消息输入和输出的占用情况、消息输入和请求的速率、消息大小等。这些指标用于监控和优化 AutoMQ 集群的性能和稳定性:通过消息输入和输出的占用情况,可以评估生产者和消费者的负载,确保集群能正常处理消息流量;消息输入速率用于实时监控生产者发送消息的速率,从而识别潜在的瓶颈或突发流量;请求速率帮助了解客户端请求的频率,以便优化资源分配和处理能力;消息大小指标则用于分析消息的平均大小,从而调整配置以优化存储和网络传输效率。通过监控这些指标,能够及时发现并解决性能问题,确保 AutoMQ 集群的高效和稳定运行。至此,我们的集成过程已完成。关于更多的使用方式,你可以参考夜莺的官方文档 [10] 进行体验。

05 总结

通过本文的介绍,我们详细阐述了如何使用夜莺监控系统(Nightingale)对 AutoMQ 集群进行全面监控。我们从AutoMQ 和夜莺的基本概念入手,逐步讲解了如何部署 AutoMQ、Prometheus 和夜莺,并配置监控和告警规则。通过这种集成,企业可以实时掌握 AutoMQ 集群的运行状态,及时发现和解决潜在问题,优化系统性能,确保业务的连续性和稳定性。夜莺监控系统以其强大的数据采集能力、灵活的告警机制和丰富的可视化功能,成为企业监控复杂分布式系统的理想选择。希望本文能为您在实际应用中提供有价值的参考,助力您的系统运维更加高效和稳定。

引用

[1] AutoMQ:https://www.automq.com/zh
[2] 夜莺监控:https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v7/introduction/
[3] 夜莺架构:https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v7/introduction/
[4] Prometheus:https://prometheus.io/docs/prometheus/latest/getting_started/
[5] 集群方式部署 | AutoMQ:https://docs.automq.com/zh/docs/automq-opensource/IyXrw3lHriVPdQkQLDvcPGQdnNh
[6] Metrics | AutoMQ:https://docs.automq.com/zh/docs/automq-opensource/ArHpwR9zsiLbqwkecNzcqOzXn4b
[7] 将 Metrics 集成到 Prometheus:https://docs.automq.com/zh/automq/observability/integrating-metrics-with-prometheus
[8] 部署说明:https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v7/install/intro/
[9] 夜莺 Github releases:https://github.com/ccfos/nightingale
[10] 夜莺官方文档:https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v7/overview/

关于我们

我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队,曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念,重新设计并实现了 Apache Kafka 和 Apache RocketMQ,带来高达 10 倍的成本优势和百倍的弹性效率提升。

🌟 GitHub 地址:https://github.com/AutoMQ/automq
💻 官网:https://www.automq.com?utm_source=openwrite

FlashCat_v2.1.1_b30_p5.8.1_m1000_gdsf7.apk 立即下载

相关推荐

SAP中成本估算没有找到工艺路线消息处理实例

在针对成品的标准成本核算处理过程中,系统中会经由设定好的策略来收集成品相关成本组成,最终计算出产成品的标准成本。关于成本组成,可以归纳为三个基本要素,料,工,费。即标准成本就是要知道,生产一件成品,需要消耗多少钱的原材料?消耗多少钱的人工?以及其它的间接消耗? 某日,接到CO同事的反馈,在用CK11N做产成品标准价格核算时,提示没有工艺路线确定,但该消息为绿灯,可以通过。基于业务上的谨慎,提出分析。 从提示可以看出问题与工艺路线有关。因为,成品工艺路线中设定有成品生产所耗工时,所以,在计算产成品标准

专注SAP应用技术文章写作,致力于拉近用户与系统间的距离; 6279

AutoMQ:云原生 Kafka 解决方案,降低10倍成本100%完美兼容

AutoMQ 重新设计了 Kafka 的架构,基于云的基础设施,将存储分离至对象存储,实现了 Apache Kafka100% 的兼容性。它不仅提供了10 倍的成本优势,还带来了百倍的弹性,极大地提升了扩展性和性能。与传统的 Kafka 对比,AutoMQ 通过创新的存算分离架构,减少了运维复杂度,并充分利用了云环境中的共享存储特性。官网:https://www.automq.com/zhAutoMQ 通过云原生的架构优化,显著提升了 Kafka 的弹性和性能,并大幅降低了成本。

jast 1675

FPGA时序约束:从时钟树到数据路径的深度解析与优化策略

本文深入解析FPGA时序约束的核心技术与优化策略,涵盖时钟树结构分析、时序报告解读和数据路径优化。重点探讨Vivado工具中的时序约束方法,包括时钟定义、异常约束和物理优化,帮助工程师掌握寄存器级时序分析和系统级协同设计,实现高性能FPGA设计。

u5v6w7的博客 652

AutoMQ 携手阿里云共同发布新一代云原生 Kafka,帮助得物有效压缩 85% Kafka 云支出!

以成本换效率的上云方式需要高速发展的业务来支撑,在今天降本的大环境下,以云原生,甚至多云原生重新设计的云服务相较于「Cloud-Hosted」的云服务将在弹性、成本、容量、效率等各方面有数量级的优势,云托管(Cloud-Hosted)类型的云服务即将被淘汰。稳定性有其高大上的一面,也有需要埋头苦干的另一面,聪明人一起坚持做一件事情可能是得物稳定性的内涵,郝豪提到他在业务场景的治理上,告警规则的梳理上,持续做了 3 年,从 21 年到 23 年持续在投入,每一年都有不同的方向和目标。

AutoMQ的博客 2406

从零到一:手把手教你构建自定义ReaxFF力场参数

本文手把手教你从零构建自定义ReaxFF力场参数,详解反应力场的动态键序机制与参数化逻辑。通过LAMMPS实战演示,涵盖训练数据准备、参数优化算法选择及性能优化技巧,助力研究人员精准模拟化学反应过程。适用于材料科学、催化研究等领域,特别适合已掌握分子动力学基础的进阶用户提升力场开发能力。

weixin_28365523的博客 1058

HexView 脚本自动化工具:从刷写文件处理到批量转换实战

本文详细介绍了如何利用HexView脚本自动化工具高效处理嵌入式刷写文件。通过实战演示,文章展示了如何使用bat脚本实现S19、HEX等格式文件的剪切、填充、合并与批量转换,构建自动化流水线,从而显著提升汽车电子等领域的开发与生产效率。

weixin_29237635的博客 356

原理剖析:AutoMQ 如何实现分区持续重平衡

01 引言 在一个线上 Kafka 集群中,流量的波动、Topic 的创建和删除、Broker 的消亡和启动都随时可能发生,而这些变化可能导致流量在集群各个节点间分布不均,从而导致资源浪费、影响业务稳定。此时则需要主动将 Topic 的不同分区在各个节点间移动,以达到平衡流量和数据的目的。当前,Apache Kafka 仅提供了分区迁移工具,但具体的迁移计划则需要运维人员自行决定,而对于动...

gaoliang1719的专栏 268

GoPro官方API实战:从蓝牙配对到Wi-Fi流媒体,构建跨平台控制应用

本文详细解析了GoPro官方API的开发实践,涵盖蓝牙配对、Wi-Fi流媒体控制等关键技术。通过实战案例,指导开发者如何构建跨平台控制应用,解决设备发现、指令解析、视频流传输等核心问题,并分享Android平台迁移经验与常见问题排查方法。

weixin_30727835的博客 397

AutoMQ 如何实现没有写性能劣化的极致冷读效率

Apache Kafka 一直以来都以极致的吞吐能力受到广大开发者和使用者的喜爱。AutoMQ[1] 在保证与 Apache Kafka 100% 兼容并且提供极致弹性和降本能力的基础上,不仅做到了相比Kafka更加极致的吞吐能力,同时还解决了Kafka冷读时,写吞吐性能劣化的问题。接下来,本文将从追赶读的实现来说明 AutoMQ 如何做到单机 1K 分区并发追尾读达到 1GB/s 的极致吞吐能力,并且在追赶读过程中避免发送流量的性能劣化。

AutoMQ的博客 1213

MuMu模拟器过检测实战:从硬件伪装到API欺骗的完整避坑指南

本文详细介绍了MuMu模拟器过检测的实战技术,从硬件伪装到API欺骗的全方位解决方案。通过修改CPU/GPU信息、内存分布、系统属性和行为模拟等关键技术,帮助用户有效绕过现代应用的模拟器检测机制,提升模拟器的隐蔽性和稳定性。

xxx12的博客 1397

第 5 篇:责任链模式 (Chain of Responsibility) —— 协议栈的流水线

本文介绍了责任链模式在嵌入式通信协议解析中的应用。针对传统"面条式"代码维护困难的问题,提出将各协议解析器解耦为独立处理单元,通过链表形式串联。文章详细展示了模式实现:定义抽象处理者接口、实现具体协议处理器、构建链表管理器。该方案具有内存占用低(O(1)栈空间)、可动态扩展、支持优先级调整等优势,并探讨了性能优化策略及动态插件系统等扩展应用,为嵌入式通信协议处理提供了清晰的架构方案。

一路往蓝-Anbo 的博客 179

AutoMQ 集成 Debezium

在现代企业中,数据处理需求的不断增长使得实时监控和响应数据库变化变得尤为重要。无论是电商平台的订单处理、库存管理,还是金融系统的交易监控,都需要对数据库中的变化进行实时捕捉和处理。这不仅能提高系统响应速度,还能在数据发生变化时及时采取相应的业务操作。为了实现这一目标,本文将介绍如何使用 Debezium [1] 监测 MySQL 数据库的变化,并将这些变化事件发送到 AutoMQ [2] 中。AutoMQ 作为一种高效、低成本的流处理系统,具有高弹性和高可用性,是企业实时数据处理的理想选择。

AutoMQ的博客 1100

【主题建模】一种基于深度学习的主题建模方法:BERTopic(实战篇)

BERTopic 是基于深度学习的一种主题建模方法。2018 年底,Devlin et al. 提出了 Bidirectional Encoder Representations from Transformers (BERT)。BERT 是一种用于 NLP 的预训练策略,它成功地利用了句子的深层语义信息。

Data · Model · Agent · Repeat 2万+

夜莺(Flashcat)V6监控(一):介绍及其部署

夜莺监控( Nightingale )是一款国产、开源云原生监控分析系统,采用 All-In-One 的设计,集数据采集、可视化、监控告警、数据分析于一体。于 2020 年 3 月 20 日,在 github 上发布 v1 版本,已累计迭代 60 多个版本。从 v5 版本开始与 Prometheus、VictoriaMetrics、Grafana、Telegraf、Datadog 等生态紧密协同集成,提供开箱即用的企业级监控分析和告警能力,已有众多企业选择将 Prometheus + AlertManage

m0_61323675的博客 2万+

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

lwip-2.0.3

lwip是瑞典计算机科学院(SICS)的Adam Dunkels 开发的一个小型开源的TCP/IP协议栈。实现的重点是在保持TCP协议主要功能的基础上减少对RAM 的占用。

海外开发者为 AutoMQ 写的精品介绍,太干了!

在 KRaft 模式下的每个 broker 都保留了元数据的本地副本,而控制器群的领导者负责管理更新并将其复制到所有的 brokers,这大大降低了操作的复杂性和可能的故障点。AutoMQ 的工程师们开始思考:“是否存在一种方法,可以将所有的 Kafka 数据存储在对象存储中,同时还能保持像在本地硬盘上一样的高性能?传统的 Kafka 依赖于独立的 ZooKeeper 服务器来进行集群元数据的管理,但是 KRaft 模式消除了对 ZooKeeper 的依赖,简化了 Kafka 的运行并提升了其弹性。

AutoMQ的博客 1095

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

原理剖析:AutoMQ 如何基于裸设备实现高性能的 WAL

Delta WAL 在 AutoMQ 中的主要职责是作为持久化写入缓冲区,配合 Log Cache 将写入的数据以 WAL 的形式在云盘上做高效的持久化。在云盘上持久化成功后才会返回客户端成功。而数据的读取则均会从内存中读取并返回客户端。AutoMQ S3Stream 设计了冷热隔离的缓存 Log Cache(缓存新写入数据)和 Block Cache(缓存从对象存储中拉取的数据)。Log Cache 中的数据在 WAL 的数据没有上传到对象存储之前在内存中不会失效。

AutoMQ的博客 1349

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

AutoMQ多协议支持:MQTT、AMQP协议适配器开发

随着物联网(IoT)和企业级消息通信需求的增长,单一消息协议已无法满足多样化场景。AutoMQ作为云原生消息队列,通过协议适配器架构支持多协议接入,本文将详细介绍MQTT(消息队列遥测传输)和AMQP(高级消息队列协议)适配器的开发实践,帮助开发者快速扩展AutoMQ的协议兼容性。 ## 协议适配器架构设计 AutoMQ的多协议支持基于Kafka Connect框架实现,通过源连接器(Sour...

gitblog_00758的博客 543

重磅!AutoMQ 品牌全新升级

2024 年伊始,AutoMQ 作为一家专业的消息队列和流存储软件服务供应商,正式发布全新的 logo 和官网与大家见面!一直以来,我们致力于引领消息和流存储走向云原生时代!希望通过这次品牌升级,不断创新,为大家提供更先进的产品和服务!新 logo 以"M"字母为核心设计元素,融合"A"字母,不仅象征着 AutoMQ 的名字,更代表了我们对核心业务和理念的坚持。

AutoMQ的博客 990

AutoMQ 如何实现分区持续重平衡?

在一个线上 Kafka 集群中,流量的波动、Topic 的创建和删除、Broker 的消亡和启动都随时可能发生,而这些变化可能导致流量在集群各个节点间分布不均,从而导致资源浪费、影响业务稳定。此时则需要主动将 Topic 的不同分区在各个节点间移动,以达到平衡流量和数据的目的。

AutoMQ的博客 1353

开源布道 共创生态——2024 AutoMQ 布道师计划启动!

AutoMQ 布道师在 AutoMQ 社区中扮演着至关重要的角色,他们是 AutoMQ 社区的积极贡献者,是高效数据处理和流存储的倡导者,也是对云原生技术充满热忱的探索者。他们运用自己的专业能力,通过创作深度内容和社区互动,分享对 AutoMQ 产品的技术洞察与个人见解,将 AutoMQ 的产品优势和实用技巧传递给更广泛的用户群体,与 AutoMQ 一同成长。如果你也认同我们的产品和理念,那么欢迎你加入 AutoMQ 布道师的行列,和我们一起探索云原生技术的潜能,创造更开放、更多元、更具活力的开源生态。

AutoMQ的博客 1215

AutoMQ 产品动态 | 发布 1.1.0,兼容至 Apache Kafka 3.7,支持 Kaf

现在我们基于对象存储优先、存算分离、多云原生等技术理念,重新设计并实现了 Apache Kafka 和 Apache RocketMQ,带来高达 10 倍的成本优势和百倍的弹性效率提升。AutoMQ 进一步发挥云存储的优势,在 1.1.0 版本宣布支持 Regional ESSD,为客户在多 AZ 容灾场景下提供更低的故障 RTO。KIP-714:新增多语言统一的客户端 Metrics,提供从服务端查询客户端 Metrics 的能力(3.7.0)

AutoMQ的博客 1489

AutoMQ:云原生Kafka的革命性替代方案

你是否正面临Kafka集群扩展困难、跨可用区流量成本高昂、存储容量受限等痛点?AutoMQ作为一款云原生的Kafka分支,通过将存储与计算分离并迁移至S3或兼容S3的对象存储,实现了10倍成本优化、秒级弹性扩展和毫秒级延迟,彻底改变了传统Kafka的运维模式。本文将从核心优势、架构解析、快速部署和实际应用场景四个维度,带你全面了解这款革命性的消息队列解决方案。 ## 核心优势:重新定义云原生消息

gitblog_00068的博客 940

Kafka 痛点专题|AutoMQ 如何解决 Kafka 冷读副作用

本文着重剖析了 Kafka 在冷读时产生问题的原理,以及 AutoMQ 的解法。下一篇 《Kafka 痛点专题》我们将探讨 Kafka 痛点中的 No.1 ,即弹性,敬请期待。END关于我们我们来自 Apache RocketMQ 和 Linux LVS 项目的核心团队,曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。

AutoMQ的博客 1167

夜莺(Flashcat)V6监控(二):夜莺页面全网最详细功能介绍及案列

目录(一):如何把数据转发给多个时序库(二):监控仪表盘的配置(三):告警的配置管理 (1):告警规则①: 基础配置②:规则配置:分为Metric和Host机器类型的告警③: 生成配置④:通知配置 (2): 内置规则 (3) 屏蔽规则 (4) 订阅规则 (5) 活跃告警 (6) 历史告警(三):时序指标(四):日志分析(五):链路追踪(六):基础设施(七):告警自愈(八):人员组织(九):系统配置(1)数据源:(2)通知设置:(十):对接邮箱告警案列配置 (1) 创建告警规则

m0_61323675的博客 1万+
上一篇: 就在今晚!亚马逊云科技数据开源软件-流式数据湖 Tech Talk等你来!
下一篇: 如何通过 CloudCanal 实现从 Kafka 到 AutoMQ 的数据迁移
AutoMQ
博客等级 码龄3年 1206粉丝 157原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值