hyperxu

一个专注于运维领域的个人技术博客


  • 首页

  • 分类

  • 归档

  • 标签

  • 关于

  • 公益404

  • 搜索

Clickhouse可观测实践:5 分钟本地部署 ClickStack

发表于 2025-06-25 | 分类于 clickhouse | 阅读次数

在上一篇文章中,我们深入探讨了 ClickStack 的架构设计与核心价值。我们知道,它凭借 ClickHouse 与 OpenTelemetry 的精妙组合,为可观测性领域带来了成本与效率的双重革新。纸上得来终觉浅,跟随以下步骤,你可以快速在本地运行一个完整的 ClickStack 实例,并导入一些样例数据体验ClickStack在日志、追踪、指标全领域的、高性能且极具性价比的解决方案。

1.搭建测试环境

工欲善其事,必先利其器。为了顺利完成本次实验,请确保你的本地开发环境已安装Docker和Git。

由于是测试环境,我们选择All-in-One的部署模式,单个 Docker 容器,捆绑了所有 ClickStack 组件,用于演示和局部全栈测试。

这个综合的 Docker 镜像捆绑了所有 ClickStack 组件:

  • ClickHouse
  • HyperDX
  • OpenTelemetry (OTel) 收集器(在端口 4317 和 4318 上暴露 OTLP)

此选项包含身份验证,允许在会话和用户之间持久保存仪表板、警报和保存的搜索。

1.1.使用Docker部署

以下命令将运行一个 OpenTelemetry 收集器(在端口 4317 和 4318 上)和 HyperDX 界面(在端口 8080 上)。

1
docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 docker.hyperdx.io/hyperdx/hyperdx-all-in-one

部署成功后会打印环境信息

阅读全文 »

解构 ClickStack:不止是降本,更是可观测性架构的一次演进

发表于 2025-06-19 | 分类于 clickhouse | 阅读次数

1.我们的可观测性平台做对了吗

作为工程师,我们每天都在与系统的复杂性搏斗。而可观测性平台,本应是我们在黑暗中探索的明灯。但现实往往是,这盏“灯”本身就价格不菲,还时常忽明忽暗。

你是否也面临着这些似曾相识的场景?

  • 高昂的账单: 每月审视商业 SaaS 服务的账单,感觉每一行日志、每一个指标都在燃烧经费。
  • 运维的泥潭: 维护着一套由 ELK、Prometheus、Jaeger 等“攒”起来的系统,不同组件的升级、扩容和协调,消耗了大量精力。
  • 低效的排障: 发现问题时,不得不在 Grafana、Kibana、Jaeger UI 之间来回跳转,复制粘贴 TraceID,宝贵的排障时间就在这无尽的“上下文切换”中流逝。
    阅读全文 »

一次CPU sys上涨引发对kafka PageCache的思考

发表于 2020-10-12 | 分类于 kafka | 阅读次数

1.CPU sys 上涨背景

配置 机型 A 机型 B
CPU 48C 48C
MEM 8*32G 12*16G
DATA DISK 12*960G SSD 12*4T SSD

线上某个kafka集群由于种种原因,从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看,排除其他客观因素,置换后,CPU总核数少了一半,使用率上升其实也是预期之内的。事实上置换后,集群CPU使用率确实也由原有的 20%提升至 40%,上升了约 1 倍多。但置换后,cpu sys使用率均值约达到了 12%,较为抢眼,系统相关服务却并无异常,令人有些困惑。

阅读全文 »

kafka消费组及重平衡的影响

发表于 2020-06-14 | 分类于 kafka | 阅读次数

消费组应该算是kafka中一个比较有特色的设计模式了,而他的重平衡机制也是我们在实际生产使用中,无法避免的一个问题。

消费组

Consumer Group为kafka提供了可扩展、高容错特性的消费者机制。简单介绍下,大致有以下特点:

  • 一个Consumer Group内可以有多个Consumer实例,该实例可以是一个进程,也可以是进程下的多线程
  • 每个Consumer Group有一个唯一标识的Group ID
  • 不同Consumer Group之间相互独立,互不影响
  • Consumer Group内实例,与订阅的topic分区关系是一对一,或一对多的关系,Consumer Group会通过Coordinator尽量保持公平分配
阅读全文 »

kafka生产者的幂等和事务处理

发表于 2020-05-06 | 分类于 kafka | 阅读次数

之前和大家聊过kafka是如何保证消息不丢失的,今天再讲讲在不丢消息的同时,如何实现精确一次处理的语义实现。

消息组件对消息的可靠性保障,常见的模式有3种:

  • 最多一次(at most once):消息可能会丢失,但不会重复
  • 至少一次(at least once):消息不会丢失,但有可能重复
  • 精确一次(exactly once):消息不会丢失,且不会重复,精准一次发送

kafka默认情况下,提供的是至少一次的可靠性保障。即broker保障已提交的消息的发送,但是遇上某些意外情况,如:网络抖动,超时等问题,导致Producer没有收到broker返回的数据ack,则Producer会继续重试发送消息,从而导致消息重复发送。
相应的,如果我们禁止Producer的失败重试发送功能,消息要么写入成功,要么写入失败,但绝不会重复发送。这样就是最多一次的消息保障模式。
但对于消息组件,排除特殊业务场景,我们追求的一定是精确一次的消息保障模式。kafka通过幂等性(Idempotence)和事务(Transaction)的机制,提供了这种精确的消息保障。

阅读全文 »
12…7
hyperxu

hyperxu

35 日志
10 分类
21 标签
RSS
GitHub Facebook 知乎
© 2025 hyperxu | 浙ICP备15043518号-3
由 Hexo 强力驱动
主题 - NexT.Mist