Oldposts

2022-09-07-分布式事务 database 分布式事务 常规的数据库事务指的是在集中环境下的数据库执行某些业务操作。而分布式事务就复杂多了，这和CAP理论有关。事务一定是要追求 ACID 的，这个C指的是一致性，在分布式系统中却是最容易被抛弃的。 CAP 理论告诉我们，在分布式系统中，一致性、可用性、分区容忍性三者不可兼得，必然需要舍弃某个点。分区容忍性是一定会出现的，可用性是分布式系统的重要作用，也不可抹去，这样的话就需要丢弃一致性。 强一致性：理论中的一致性，单点数据库可以做到 弱一致性：实践中的一致性，其实是不保证一致性，例如 Redis 最终一致性：如果数据在一段时间之内没有被另外的操作所更改，那它最终将会达到与强一致性过程相同的结果 一些分布式事务的实现： 可靠事务队列：通过队列中间件实现分布式事务，也即是最大努力交付，在整个体系中没有“事务回滚”的概念，如果出现了异常情况，需要一个新的事务去处理 TCC事务：Try-Confirm-Cancel - Try：尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好全部需用到的业务资源（保障隔离性）。 - Confirm：确认执行阶段，不进行任何业务检查，直接使用 Try 阶段准备的资源来完成业务处理。Confirm 阶段可能会重复执行，因此本阶段所执行的操作需要具备幂等性。 - Cancel：取消执行阶段，释放 Try 阶段预留的业务资源。Cancel 阶段可能会重复执行，也需要满足幂等性。 SAGA事务：将大事务分割成连续的且原子性的小事务，对每一个小事务都有一个补偿动作；当分布式事务出现问题之后，可以不断重试失败的小事务，也可以按照倒叙进行补偿动作的实施，从而使该事务进行逻辑上的回滚。

2022-09-06-Go的参数传递 Go Go的参数传递 结论：Go的参数传递一定是值传递的。 参数传递指的是将变量传入到函数内。 先搞明白两个概念： 变量名：一个标识符 变量内容：变量指向的内容 对于变量，会区分基础类型和引用类型。基础类型的变量传入到函数内，是完全的复制过去，是值传递；引用类型的变量传入到函数内，也是完全的复制过去，但复制的是指针的地址，这也是值传递。下面一段代码可以解释： package main import "fmt" func change(p1 []int) { fmt.Printf("p1的内存地址是: %p\n", &p1) // p1的内存地址是: 0xc000010060 fmt.Printf("函数里接收到slice的内存地址是：%p\n", p1) // 函数里接收到slice的内存地址是：0xc000100000 p1 = append(p1, 30) } func main() { p := make([]int, 3) // 返回一个指针 p = append(p, 20) fmt.Printf("p的内存地址是: %p\n", &p) // p的内存地址是: 0xc000010030 fmt.Printf("slice的内存地址是：%p\n", p) // slice的内存地址是：0xc000100000 change(p) // 重新生成一份地址p1 指向slice地址 fmt.Printf("修改之后p的内存地址 %p\n", &p) // 修改之后p的内存地址 0xc000010030 fmt.Printf("修改之后slice的内存地址 %p\n", p) // 修改之后slice的内存地址 0xc000100000 fmt.Println("修改之后的slice:", p) // 修改之后的slice [0 0 0 20] fmt.Println(*&p) // [0 0 0 20] } p的内存地址是: 0xc000010030 slice的内存地址是：0xc000100000 p1的内存地址是: 0xc000010060 函数里接收到slice的内存地址是：0xc000100000 修改之后p的内存地址 0xc000010030 修改之后slice的内存地址 0xc000100000 修改之后的slice: [0 0 0 20] [0 0 0 20] 可以看到，引用类型的变量在传递过程中，其实是对指针进行了一个拷贝，且在函数内的变化不会影响到主函数的引用类型的变化。 ...

2022-06-28-crust概览 Block Chain [[Crust]] crust 概览 一个web3的分布式存储系统，处于波卡生态链。 crust Maxwell crust shadow 经济模型 参考：CRUST 经济白皮书 五个角色 商户：提供存储资源和存储检索服务 验证人：出块，兼任商户 候选人：竞争失败的验证人，没有出块权利，但是享有周期性奖励，兼任商户 担保人：向验证人/候选人借钱，以此获得一些收益 用户：花钱存东西 上述五个角色的收入成本结构参考白皮书第三页。 token 和 GPOS GPOS：结合了 PoW 和 PoS，要求验证人必须要有足够的算力（存储量），也要有足够的质押（质押不够找担保人）。 token的产生和销毁： 产生： 主网启动产生：20,000,000 区块产生：第一年 5,000,000，之后每年发行量为上年的 88 %，直到通胀率达到2.8%之后不再衰减。 经济模型 算力是根据存储数据量进行计算的，分为两个阶段： 一阶段是在主网启动初期，直接计算算力，这个值跟存储数据量有关，理论上没有上限。除此之外，它还有几个特点。存储的有效数据的副本越多，意味着数据越好，此时的有效存储系数最高可以达到9（当副本大于 183 个）。这个系数每年减半。但此时的存储节点只能获得算力值，而无法获得存储奖励（只有文件池的前四个商户可以获得）。 二阶段是要求全网的有效额度达到全网CRU发行总量的一定比例R之后进入。在该算法下，有了算力上限值，此时主要就是看自身的存储算力占全网总算力的比率。通过调整R，可以改变经济模型的倾向，使模型更稳定。R 是根据全网 staking 比率来进行计算的。当 staking 降低了，经济模型就提高 staking 的作用，从而使得 staking 趋于稳定。 ROI，投资回报率。对于不同的角色，有不同的计算公式，但大抵逻辑是差不多的。收益主要包括：区块奖励、周期性奖励分配和存储市场收入。 存储资源市场 文件存储服务 文件检索服务 对于存储服务，用户需要支付钱发起交易。商户接单后进行数据存储。当商户提交了存储证明后，订单生效。用户支付的钱，80%给全网奖励池，20%给该文件特有的奖励池。存储费用会根据全网资源使用率进行变动。 技术方案 MPoW：Meaningful Proof of Work GPoS：Guaranteed Proof of Stake 基于 TEE 实现的 MPoW TEE 可以算是 TPM 的软件实现，目前 Intel 平台的 SGX 以及 ARM 平台的 TrustZone 是两种具体实现。 ...

2022-06-15-101.145 外网不通问题 Linux 101.145 外网不通问题 起因以及经过：2022-06-15 11:48，A 提出该台机器无法访问外网，现场 B 通过脚本修改了 netplan 信息，接着换了网口，换了光模块，最后按照 https://blog.csdn.net/weixin_46151178/article/details/124581558 配置了网口自动 ip 配置。 13:15 接入调查。 这台机器的操作系统大约是在 2021/8/13 安装的，当时用于 chia 服务。查看 本地网络信息，发现结果比较奇怪。 root@gt:/# hostname -I 169.254.8.172 169.254.8.177 172.17.0.1 172.28.101.145 169.254.7.111 root@gt:/# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 3c:ec:ef:b5:3b:5e brd ff:ff:ff:ff:ff:ff altname enp3s0 inet 169.254.8.172/16 brd 169.254.255.255 scope link eno1:avahi valid_lft forever preferred_lft forever 3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 3c:ec:ef:b5:3b:5f brd ff:ff:ff:ff:ff:ff altname enp4s0 inet 169.254.8.177/16 brd 169.254.255.255 scope link eno2:avahi valid_lft forever preferred_lft forever 6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:16:01:30:26 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 7: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 6c:b3:11:09:45:e0 brd ff:ff:ff:ff:ff:ff inet 172.28.101.145/24 brd 172.28.101.255 scope global enp2s0f0 valid_lft forever preferred_lft forever inet6 fe80::6eb3:11ff:fe09:45e0/64 scope link valid_lft forever preferred_lft forever 8: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 6c:b3:11:09:45:e2 brd ff:ff:ff:ff:ff:ff inet 169.254.7.111/16 brd 169.254.255.255 scope link enp2s0f1:avahi valid_lft forever preferred_lft forever inet6 fe80::6eb3:11ff:fe09:45e2/64 scope link valid_lft forever preferred_lft forever root@gt:/# root@gt:/# root@gt:/# ps -ef|grep avahi avahi 11003 1 20 12:34 ? 00:11:29 avahi-daemon: running [gt-18.local] avahi 11047 11003 0 12:34 ? 00:00:00 avahi-daemon: chroot helper avahi-a+ 20959 15551 0 12:44 ? 00:00:00 avahi-autoipd: [eno1] bound 169.254.8.172 root 20960 20959 0 12:44 ? 00:00:00 avahi-autoipd: [eno1] callout dispatcher avahi-a+ 20987 15551 0 12:44 ? 00:00:00 avahi-autoipd: [enp2s0f0] sleeping root 20988 20987 0 12:44 ? 00:00:00 avahi-autoipd: [enp2s0f0] callout dispatcher avahi-a+ 21079 15551 0 12:45 ? 00:00:00 avahi-autoipd: [docker0] sleeping root 21080 21079 0 12:45 ? 00:00:00 avahi-autoipd: [docker0] callout dispatcher avahi-a+ 21095 15551 0 12:45 ? 00:00:00 avahi-autoipd: [eno2] bound 169.254.8.177 root 21096 21095 0 12:45 ? 00:00:00 avahi-autoipd: [eno2] callout dispatcher avahi-a+ 21662 15551 0 12:45 ? 00:00:00 avahi-autoipd: [enp2s0f1] bound 169.254.7.111 root 21663 21662 0 12:45 ? 00:00:00 avahi-autoipd: [enp2s0f1] callout dispatcher root 85190 61128 0 13:31 pts/4 00:00:00 grep --color=auto avahi 像是通过 avahi 给所有网卡都配置了 ip，这是因为 修改了 /etc/NetworkManager/NetworkManager.conf 的 ifupdown –> manage=true，这导致了网口的 ip 都配置好了。但这些和无法接通外网无关，修改配置 manage=false，重启机器开始排查。 ...

2022-06-11-136.26 宕机分析 Linux 136.26 机器宕机分析 第一次宕机分析 CPU: 42 PID: 7755 Comm: lotus-seal-work Tainted: P OE 4.15.0-184-generic #194-Ubuntu 报错表示内核被污染，污染的 flag 参考：https://www.kernel.org/doc/html/v5.8/admin-guide/tainted-kernels.html 从下述三个日志片段来看，和新加的 nvme 可能有关系。 [Sat Jun 11 10:21:50 2022] WARNING: CPU: 42 PID: 7755 at /build/linux-dJz1Tt/linux-4.15.0/kernel/time/timer.c:898 mod_timer+0x3d8/0x3f0 [Sat Jun 11 10:21:50 2022] Modules linked in: binfmt_misc amd64_edac_mod edac_mce_amd kvm_amd kvm irqbypass nvidia_drm(POE) nvidia_modeset(POE) ipmi_ssif xfs snd_hda_codec_hdmi input_leds joydev nvidia(POE) snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore k10temp shpchp ipmi_si ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ast ttm drm_kms_helper syscopyarea crct10dif_pclmul crc32_pclmul sysfillrect ghash_clmulni_intel sysimgblt pcbc ixgbe igb fb_sys_fops aesni_intel aes_x86_64 crypto_simd glue_helper dca hid_generic [Sat Jun 11 10:21:50 2022] i2c_algo_bit cryptd nvme ptp usbhid drm ahci nvme_core pps_core libahci hid mdio i2c_piix4 [Sat Jun 11 10:21:50 2022] CPU: 42 PID: 7755 Comm: lotus-seal-work Tainted: P OE 4.15.0-184-generic #194-Ubuntu [Sat Jun 11 10:21:50 2022] Hardware name: Supermicro Super Server/H11DSi, BIOS 2.3 08/02/2021 [Sat Jun 11 10:21:50 2022] RIP: 0010:mod_timer+0x3d8/0x3f0 [Sat Jun 11 10:21:50 2022] RSP: 0018:ffff8e4e4f083d10 EFLAGS: 00010097 [Sat Jun 11 10:21:50 2022] RAX: 00000001000542fd RBX: 0000000100054300 RCX: 00000001000542f3 [Sat Jun 11 10:21:50 2022] RDX: 00000001000542f9 RSI: ffff8e4e4f083d30 RDI: ffff8e4e4ed9f740 [Sat Jun 11 10:21:50 2022] RBP: ffff8e4e4f083d68 R08: 0000000000000082 R09: ffff8e4e4e406d00 [Sat Jun 11 10:21:50 2022] R10: ffff8e4e4f083d78 R11: 0000000000000001 R12: ffff8e4e4ed9f740 [Sat Jun 11 10:21:50 2022] R13: ffffc5c3cf29a0d0 R14: 00000000ffffffff R15: ffff8f4dea833858 [Sat Jun 11 10:21:50 2022] FS: 00007febae7fc700(0000) GS:ffff8e4e4f080000(0000) knlGS:0000000000000000 [Sat Jun 11 10:21:50 2022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Sat Jun 11 10:21:50 2022] CR2: 00007f70c57f0000 CR3: 00000060f3da8000 CR4: 0000000000340ee0 [Sat Jun 11 10:21:50 2022] Call Trace: [Sat Jun 11 10:21:50 2022] <IRQ> [Sat Jun 11 10:21:50 2022] queue_iova+0x129/0x140 [Sat Jun 11 10:21:50 2022] __unmap_single.isra.27+0xa3/0x100 [Sat Jun 11 10:21:50 2022] unmap_sg+0x5f/0x70 [Sat Jun 11 10:21:50 2022] nvme_pci_complete_rq+0xb4/0x130 [nvme] [Sat Jun 11 10:21:50 2022] __blk_mq_complete_request+0xd2/0x140 [Sat Jun 11 10:21:50 2022] blk_mq_complete_request+0x19/0x20 [Sat Jun 11 10:21:50 2022] nvme_process_cq+0xdf/0x1c0 [nvme] [Sat Jun 11 10:21:50 2022] nvme_irq+0x23/0x50 [nvme] [Sat Jun 11 10:21:50 2022] __handle_irq_event_percpu+0x44/0x1a0 [Sat Jun 11 10:21:50 2022] handle_irq_event_percpu+0x32/0x80 [Sat Jun 11 10:21:50 2022] handle_irq_event+0x3b/0x60 [Sat Jun 11 10:21:50 2022] handle_edge_irq+0x83/0x1a0 [Sat Jun 11 10:21:50 2022] handle_irq+0x20/0x30 [Sat Jun 11 10:21:50 2022] do_IRQ+0x50/0xe0 [Sat Jun 11 10:21:50 2022] common_interrupt+0x90/0x90 [Sat Jun 11 10:21:50 2022] </IRQ> [Sat Jun 11 10:21:50 2022] RIP: 0010:get_page_from_freelist+0x203/0x1400 [Sat Jun 11 10:21:50 2022] RSP: 0018:ffffa6c59ef47878 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffdb [Sat Jun 11 10:21:50 2022] RAX: 00000000000000a6 RBX: 0000000000000004 RCX: fffff189000d6020 [Sat Jun 11 10:21:50 2022] RDX: 000000000002bdaa RSI: 0000000000000004 RDI: 0000000000000202 [Sat Jun 11 10:21:50 2022] RBP: ffffa6c59ef47988 R08: 000000000002bd60 R09: fffff18900632760 [Sat Jun 11 10:21:50 2022] R10: ffffffffffffffff R11: 0000000000000000 R12: ffff8e504f2d5d00 [Sat Jun 11 10:21:50 2022] R13: ffffa6c59ef47998 R14: fffff18900632740 R15: fffff189000663c0 [Sat Jun 11 10:21:50 2022] ? pagevec_lookup_range+0x24/0x30 [Sat Jun 11 10:21:50 2022] __alloc_pages_nodemask+0x11c/0x2c0 [Sat Jun 11 10:21:50 2022] alloc_pages_current+0x6a/0xe0 [Sat Jun 11 10:21:50 2022] __page_cache_alloc+0x81/0xa0 [Sat Jun 11 10:21:50 2022] __do_page_cache_readahead+0x113/0x2c0 [Sat Jun 11 10:21:50 2022] ondemand_readahead+0x11a/0x2c0 [Sat Jun 11 10:21:50 2022] ? ondemand_readahead+0x11a/0x2c0 [Sat Jun 11 10:21:50 2022] page_cache_async_readahead+0x71/0x80 [Sat Jun 11 10:21:50 2022] generic_file_read_iter+0x795/0xc00 [Sat Jun 11 10:21:50 2022] ? xfs_file_write_iter+0xa8/0xc0 [xfs] [Sat Jun 11 10:21:50 2022] ? _cond_resched+0x19/0x40 [Sat Jun 11 10:21:50 2022] ? down_read+0x12/0x40 [Sat Jun 11 10:21:50 2022] xfs_file_buffered_aio_read+0x5a/0x100 [xfs] [Sat Jun 11 10:21:50 2022] xfs_file_read_iter+0x72/0xe0 [xfs] [Sat Jun 11 10:21:50 2022] generic_file_splice_read+0xdb/0x180 [Sat Jun 11 10:21:50 2022] do_splice_to+0x79/0x90 [Sat Jun 11 10:21:50 2022] splice_direct_to_actor+0xd0/0x230 [Sat Jun 11 10:21:50 2022] ? do_splice_from+0x30/0x30 [Sat Jun 11 10:21:50 2022] do_splice_direct+0x98/0xd0 [Sat Jun 11 10:21:50 2022] vfs_copy_file_range+0x2e2/0x310 [Sat Jun 11 10:21:50 2022] SyS_copy_file_range+0x127/0x1d0 [Sat Jun 11 10:21:50 2022] do_syscall_64+0x73/0x130 [Sat Jun 11 10:21:50 2022] entry_SYSCALL_64_after_hwframe+0x41/0xa6 [Sat Jun 11 10:21:50 2022] RIP: 0033:0x7fec0ea1825a [Sat Jun 11 10:21:50 2022] RSP: 002b:00007febae7f8e10 EFLAGS: 00000293 ORIG_RAX: 0000000000000146 [Sat Jun 11 10:21:50 2022] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fec0ea1825a [Sat Jun 11 10:21:50 2022] RDX: 0000000000000009 RSI: 0000000000000000 RDI: 0000000000000008 [Sat Jun 11 10:21:50 2022] RBP: 0000000000000000 R08: 0000000040000000 R09: 0000000000000000 [Sat Jun 11 10:21:50 2022] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [Sat Jun 11 10:21:50 2022] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000040000000 [Sat Jun 11 10:21:50 2022] Code: fd ff ff 49 89 44 24 10 48 89 45 c0 e9 b1 fc ff ff 0f 0b e9 aa fc ff ff 49 89 44 24 10 e9 bf fc ff ff 49 89 41 10 e9 55 fd ff ff <0f> 0b e9 af fc ff ff 0f 0b 41 8b 47 20 e9 47 fd ff ff e8 81 f9 [Sat Jun 11 10:21:50 2022] ---[ end trace f41e5ef4806c7438 ]--- Jun 11 09:56:03 fil kernel: [ 1.456460] dpc: probe of 0000:60:03.1:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456505] dpc: probe of 0000:40:01.1:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456548] dpc: probe of 0000:40:01.2:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456592] dpc: probe of 0000:40:01.3:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456636] dpc: probe of 0000:20:03.1:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456680] dpc: probe of 0000:00:01.1:pcie010 failed with error -524 Jun 11 09:56:03 fil kernel: [ 1.456726] dpc: probe of 0000:80:01.1:pcie010 failed with error -524 [Sat Jun 11 10:05:57 2022] INFO: task lotus-seal-work:2651 blocked for more than 120 seconds. [Sat Jun 11 10:05:57 2022] Tainted: P OE 4.15.0-184-generic #194-Ubuntu [Sat Jun 11 10:05:57 2022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Sat Jun 11 10:05:57 2022] lotus-seal-work D 0 2651 1 0x00000000 第二次挂掉分析报告 basic：预计 2022-06-12 13:47 机器挂掉 监控异常： 在挂掉的时候，CPU 的使用率打满了 内存多次异常释放 网卡 enp33s0 的网络流量比较高，且出现了“快速拉高，快速降低”的情况，和内存多次异常释放有关联 4 块 ssd 的 io wait 比较长 下面进行系统日志分析： ...

2022-06-09-zabbix接入业务监控数据 Monitoring [[Zabbix]] zabbix 接入业务监控指标 zabbix 体系内，所有的数据都是由 zabbix-agent 采集的，业务监控指标是通过脚本的方式，也就是 UserParameter 的方式进行的。 这个模式的采集语句为：UserParameter=get_mysql_status[*],/usr/local/zabbix/zabbix-script/get_mysql_status.sh $1 $2 $3 其实也是 key，value 的变种，只不过在内部进行了细节处理。上述的语句含义是，指标名字为 get_mysql_status，数据获取为执行一个脚本，获得返回值。这个脚本可以接受参数，参数是通过对key的括号内赋值获得。 由此可以，zabbix 的业务接入需要做的事包括： 数据获取的脚本，可以接受不同的参数，只可以返回一个值 在 zabbix-agent 的配置文件中加入 UserParameter 语句 重启 zabbix-agent 程序 在 zabbix-server 上（建立模板），在模板上建立监控项，需要配置key和参数，然后指定业务机器链接到这个新的模板上 如果业务监控有10个值，那么脚本就一个，通过不同的参数配置，内部有十个不同的处理逻辑，每次执行返回一个值；server 段配置新模板，配置 10 个监控项，按照预定的 key[参数] 的方式告知 agent 如何执行获取值。 有一些场景可能会比较麻烦，例如脚本执行一个命令可以获得若干个想要的指标，对于 zabbix 接入，没办法只执行脚本一次，而是若干次，每次获取值的一部分。

2022-06-09-系统规范 Linux 系统规范v20220609 系统规范的目的是尽量保持系统层面的一致性，方便管理，也方便业务的快速批量上线。以下的描述都是针对 x86-64 硬件环境的规范，arm 硬件环境的规范再谈。 操作系统选择 大部分情况下应该选择 Ubuntu Server 20.04.4，不允许用户直接升级内核。特殊情况需要安装不同版本的操作系统以及内核升级，应告知资源管理方，进行决断、操作以及记录。 目前操作系统的安装都是人工通过 Ubuntu installer 进行安装，在安装过程中会经历几个步骤，按照以下的要求进行选择： 主板启动尽量选择 UEFI 启动，这会影响到磁盘的分区表 语言选择：English 键盘布局选择：English(US) 网络配置放在系统安装后进行 选择安装的系统盘选择 entire disk，不使用 LVM，直接全盘单分区 用户名配置为：帐号：nl 密码：nashCloud0101 安装软件选择 OpenSSH 等待安装完成并启动。 操作系统优化 优化的步骤会比较多，这里只提出方案，具体的操作过程单独细说。 apt-mark 锁定内核版本 关闭内存 swap netplan 配置网络，不要通过桌面环境进行网络配置 DNS 优化配置 国内一个主 DNS 国外一个副 DNS 更新 apt 源，使用国内可用源 nl 用户 sudo 免密配置 时区设置，ntp设置 关闭 systemd-networkd-wait-online.service 服务，加快系统重启速度 配置 hostname 为主板 UUID 配置 hosts.sh 定期执行 bash 优化配置，增加历史记录时间配置 vim 优化配置 journald 优化配置 一些系统内核的优化，主要是网络连接数 软件配置 需要安装一些常用软件。 ...

2022-06-06-基于 Prometheus 的监控体系设计 Monitoring Prometheus 基于 Prometheus 的监控体系设计 数据整合中心 数据采集器 半自动化的target配置 网络隔离问题 告警实现 展示实现 监控整体部署 业务监控接入 1. 数据整合中心 采用 Prometheus 作为数据整合中心，它具有： 强大的扩展性 极简的设计，仅需要几个配置文件和单个二进制程序就可以运行 运行速度快，底层使用 tsdb 进行存储，默认存储15天 采用 Pull 的模式进行数据整合，需要网络的畅通 中心化的配置管理 支持各种服务发现，常用的为：file_sd、consul_sd 支持 API 管理，也支持 Web 页面的管理 labels 支持，方便对监控主体的描述 可使用 systemd 进行托管。 Prometheus.io Github/Prometheus 2. 数据采集器 node_exporter：Linux 平台的物理信息采集，默认开启 42 大项监控，默认关闭 21 大项监控。自带 text collector 功能，允许用户自己书写脚本采集数据。node_exporter blackbox_exporter：用于网络黑盒测试的采集器，特别的仅需要部署一个程序而不需要在每个节点都部署。可以用于 web 服务、http 服务、ssh 服务状态的检测。black_exporter mysqld_exporter：用于监控 MySQL 服务各种指标。mysqld_exporter nvidia_gpu_prometheus_exporter：基于 NVML 库，用于监控 GPU 运行状态。 nvidia_gpu_prometheus_exporter cAdvisor：用于监控 docker 容器资源消耗等信息。cadvisor 以上采集器都是单个二进制程序运行，基本不需要配置文件，启动后都需要占据一个端口。如果实际场景只允许单个端口，那么需要做个整合。 ...

2022-05-31 监控系统选型 Monitoring 监控系统选型 在 nash 的业务内，监控系统的目的是： 及时获取物理机器的信息 快速配置业务监控的需求 自动化的响应底层物理机器快速变动的场景 多个网络子段互相隔离 目的详解 及时获取物理机器的信息 没有压力，大部分监控系统都可以做到。 快速配置业务监控的需求 可以从两个角度去考虑： 业务监控需求的实现 业务监控和节点进行绑定 前者可以是脚本触发，或 metrics 暴露，从而获得数据。后者需要一个中间调度平台去实现，通过中间件人为的对业务和节点进行绑定。需要注意的是，多个业务可以对应单个节点。 自动化的响应底层物理机器快速变动的场景 这是比较难做到的。这和第四点需要的技术有关联。一般来说，对于监控中心来说，会有两种模式： pull：集中化配置，由主节点主动的获取数据 push：分布式配置，由被监控节点主动上报数据 两者没有绝对的好与坏，得看场景，在不需要考虑网络隔离/网络不可达的情况下，pull 模式更好，自动化的模式更容易做；而出现了网络隔离/网络不可达，或集群内节点过多，则会用到 push 模式，对于监控中心来说是相对被动的。 当然也有折中的方案，例如 zabbix server + zabbix proxy。对于 zabbix server 来说是 push 模式，被动的接受 zabbix proxy 推送数据，但对于 zabbix proxy 来说可以是 pull 模式，集中化配置。 在初期还是先考虑手动响应物理机器的快速变动，通过中间平台确认下架机器，上架机器。 一个方案就是机器上架后运行脚本，告诉中间件，然后开始进行监控部署。下架在另一个接口实现。 多个网络子段互相隔离 多个网段的隔离在没有足够好的管理平台下，无论做什么都是比较麻烦的，这里先不去考虑这个问题怎么处理，直接使用 push /部分 push 的方案。 选择 市场上能够直接实现上述四个目的的系统，应该是不存在的。 Prometheus：不通过，一个根本的原因就是网络问题，该系统只支持 pull 模式，它更适合云平台，网络互通情况。 zabbix：可以使用，但需要中间件和它的 api 进行优化，但这是单点系统，需要考虑负载问题。 Open-Falcon：不推荐使用，停更四年，二开成本不低，架构复杂 cat：美团的监控系统，已开源。美团的技术是可以信任的，这个项目的热度也挺高的，还在维护中，接入公司比较多，可以考虑。但需要机器去验证适不适合nash的环境。 参考 一篇文章全面了解监控知识体系 深度剖析开源分布式监控CAT Mt-Falcon——Open-Falcon在美团点评的应用与实践 常用的17个运维监控系统（必备知识） dianping/cat XiaoMi/open-falcon** zabbix proxy分布式监控部署 Zabbix Agent active主动模式配置(多图详解)

2022-05-13-aptos 激励测试网1的节点搭建 Block Chain Aptos aptos 激励测试网1的节点搭建 该文档参考官方文档以及中文社区给出的文档，仅包含验证节点和全节点的搭建过程，搭建后的 kyc 过程请参考：2022-05-14-aptos激励测试网1kyc 镜像部署 镜像部署是最简便的部署方式，也是最推荐的方式。 前置条件： Docker Docker-compose v2.2.1 aptos cli 硬件要求： CPU: 4 cores (Intel Xeon Skylake or newer). Memory: 8GiB RAM 300GB of disk space 1.创建运行路径并进入 mkdir -p /opt/aptos/ait1 # 创建数据路径 mkdir -p /opt/aptos/ait1/data/aptos-fullnode mkdir -p /opt/aptos/ait1/data/aptos-validator cd /opt/aptos/ait1 2. 安装前置条件 # 安装 Docker wget -O get-docker.sh https://get.docker.com sudo sh get-docker.sh rm -f get-docker.sh # 安装 docker-compose sudo curl -L "https://github.com/docker/compose/releases/download/v2.5.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/bin/docker-compose chmod +x /usr/bin/docker-compose docker -v docker-compose -v # 安装 aptos cli wget -O /tmp/aptos-cli-0.1.1-Ubuntu-x86_64.zip https://github.com/aptos-labs/aptos-core/releases/download/aptos-cli-v0.1.1/aptos-cli-0.1.1-Ubuntu-x86_64.zip unzip /tmp/aptos-cli-0.1.1-Ubuntu-x86_64.zip chmod +x aptos 3. 下载三个文件 # docker compose 文件，这个文件内需要修改 volumes 相关内容，可以直接用下面的文件进行替换 wget https://raw.githubusercontent.com/aptos-labs/aptos-core/main/docker/compose/aptos-node/docker-compose.yaml # 默认的 validator 配置文件 wget https://raw.githubusercontent.com/aptos-labs/aptos-core/main/docker/compose/aptos-node/validator.yaml # 默认的 fullnode 配置文件 wget https://raw.githubusercontent.com/aptos-labs/aptos-core/main/docker/compose/aptos-node/fullnode.yaml 修改 docker-compose.yaml ...