蓝宝石的傻话

MickeyBee's BLOG

蓝宝石的傻话
0%

发表于： 分类于：

引言

在物联网应用中，温湿度监控是一个常见且重要的需求。ESP01 作为一款低成本、低功耗的 Wi-Fi 模块，为实现温湿度监控提供了一个便捷的解决方案。本文将详细介绍如何使用 ESP01 主板进行温湿度监控开发，包括硬件连接、代码实现和功能解析。

发表于： 分类于：

概述：

MongoDB 目前使用广泛，但是缺乏有效的可观测能力。 DeepFlow 在可观测能力上是很优秀的解决方案，但是却缺少了对 MongoDB 协议的支持。 该文是为 DeepFlow 扩展了 MongoDB 协议解析，增强 MongoDB 生态的可观测能力，简要描述了从协议文档分析到在 DeepFlow 内实现代码解析的过程拆解。

发表于： 分类于：

部署过程和指令参考： pixie install

Pixie平台主要由以下组件组成：

  • Pixie Edge Module 边缘模块(PEM): Pixie’s agent, installed per node. PEMs use eBPF to collect data, which is stored locally on the node. Pixie的代理，安装在每个节点上。PEM使用eBPF收集数据，这些数据存储在节点本地。

发表于： 分类于：

时分系统和Linux

首先我们补习一下时分系统，时分系统是一个非常重要的操作系统概念,它最大限度地提高了运算机的利用率,是实现多道程序并发执行的重要手段。 我们日常工作用到的Linux系统 内核也采用了时分系统的思想,主要体现在以下几个方面:

发表于：

前情概述：

在《监控系统企业架构演进史-跨地域混合云》中，监控系统已经逐步成熟且企业化发展。 这一章节简单讲述一下期间的拨测能力搭建，以下是这套系统的发展史，在监控平台搭建的过程中，内部监控采集还不足以满足企业业务需求，在计划发展apm之前，异地拨测的黑匣子监控也纳入了该系统的一个子功能。

发表于：

前情概述：

在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。 前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。 在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。

发表于：

Prometheus是一个开源的监控与时间序列数据库系统,在近年来得到了越来越广泛的应用。 官方的架构图如图所示： 本系列文章会以Prometheus的在一个企业里的部署架构演进过程中逐步理解和深入各种组件和概念。 先通过下图简单了解这个演进发展史

发表于： 分类于：

概述:

  • TCP BBR 致力于解决两个问题：
    • 在有一定丢包率的网络链路上充分利用带宽。非常适合高延迟、高带宽的网络链路。
    • 降低网络链路上的 buffer 占用率，从而降低延迟。非常适合慢速接入网络的用户。
  • 测试目的: 这次的测试主要是针对丢包率.更有说服力的测试请参考 Lawrence Brakmo的BBR Report .
  • BBR的另一面

测试准备：

  • ADDR01：aaa.aaa.aaa.aaa
1
2

$ uname -r
4.8.6-x86_64-linode78
  • ADDR02：bbb.bbb.bbb.bbb
1
2

# uname -r
4.8.6-x86_64-linode78

测试方式：

  • 模拟丢包1%-30%的场景，分别测试不同内核开启BBR先后的情况。 用到的tc指令：
1
2
3
4
5
6
7
8

# 清理tc规则：
tc qdisc del root dev eth0
# 模拟1%丢包：
tc qdisc add dev eth0 root netem loss 1%
# 模拟10%丢包：
tc qdisc add dev eth0 root netem loss 10%
# 模拟30%丢包：
tc qdisc add dev eth0 root netem loss 30%
  • 测试从从ADDR02传数据到ADDR01,ADDR01的内核不变,ADDR02在每次测试都会调整内核重启。

测试过程：

  • 步骤略,test.gz约160MB,过程大致如下: 没有启用BBR的情况，从ADDR02传数据到ADDR01：
1
2
3
4
5
6

$ rsync -ave "ssh -l mickey"  --progress test.gz [email protected]:/home/mickey/test.gz
sending incremental file list
test.gz
   166042909 100%    3.27MB/s    0:00:48 (xfer#1, to-check=0/1)
sent 166063274 bytes  received 31 bytes  3288382.28 bytes/sec
total size is 166042909  speedup is 1.00

  • 测试数据比对:

4.8.6-x86_64-linode784.9.15-x86_64-linode78非linode的官方4.10内核(generic)
没有启动BBR正常情况3.27MB/s3.36MB/s没有测试
启动BBR正常情况没有测试3.45MB/s2.31MB/s
启动BBR丢包1%3.19MB/s没有测试没有测试
启动BBR丢包10%没有测试3.21MB/s2.81MB/s
启动BBR丢包30%97.30kB/s(在20分钟内没有传输完成中断得到的最后结果)1.35MB/s1.15MB/s

  • 测试总结和当时情况(以上述结果来总结):

    • linode自己编译的内核有明显针对性优化,效果比较明显.
    • 启动bbr后在丢包30%的情况下还能完成传输,bbr的效果也比较明显;
    • 4.10内核选择了generic没有选择lowlatency.
    • 本来还打算测50%的丢包.但是50%设置后几乎无法远程操作ADDR01而放弃测试.

附录：

  • centos7官方内核的升级方法：
    • 升级内核:
1
2
3

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml -y
  • 更新启动
1
2
3

egrep ^menuentry /etc/grub2.cfg | cut -f 2 -d \'
grub2-set-default 0  #default 0表示第一个内核设置为默认运行, 选择最新内核就对了
reboot
  • 开启BBR：
1
2
3
4

modprobe tcp_bbr
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p