在Linux上下载GitHub文件太慢了，直接受不了。于是我做了一个用于加速 GitHub 文件下载速度的代理服务，基于 Cloudflare 运行，可以加速 Releases、源码包、仓库文件、Raw、Gist 的下载以及 git clone。

• 地址： https://github.geekery.cn/
• 项目源码： https://github.com/Paper-Dragon/github-proxy

如果能分清笨、傻、蠢、痴、呆、愚，就能体会古人识人的深刻智慧。

这六个字常被随口骂出来，听起来全是贬义。细想却不尽然：它们不是智力的判决书，而是六种常见的处境，六面贴着自己的镜子。人一辈子难逃其中几面；认清它们，也就认清了自己卡在何处，该往哪走。

笨

别人两三遍就会，你要练十遍，这叫笨。

笨不等于智商低，只是资质有限、上手偏慢。同一道题，别人一眼看穿，你要反复琢磨；同一件事，别人举一反三，你得按部就班。这不丢人，丢人的是把「慢」误当成「不行」，还没练够就先认输。

《射雕》里的郭靖便是典型。记性不佳，悟性也平平，却肯下苦功，一招一式练到骨子里。别人靠灵光，他靠遍数；到头来一样能成事。笨的出路不在抱怨天赋，而在用勤奋把差距一点点补上——慢没关系，别停。

什么是运维绿皮书

作为一个技术宅，我经常编写各种文档和使用说明。由于很早就接触了博客系统，我一直习惯使用 Markdown 格式来编写文档。Markdown 的简洁和易读性让我能够高效地记录和分享技术知识。然而，随着经验的积累，我发现博客系统并不是最佳的解决方案。虽然许多博客平台提供了专栏功能，而且像网易云笔记这样的编辑器也能通过 Markdown 管理文档，但这些工具往往带有过多的功能和界面元素，不够纯粹。

随着时间的推移，我积累的资料越来越多，这些文档也变得越来越杂乱无章。它们通常散落在电脑的各个角落，内容不系统化，管理起来也非常不便。这种情况下，我迫切需要一个工具来帮助我系统地组织和管理这些分散的 Markdown 文件。

E Elasticsearch

弹性搜索，日志存储

L Logstash

日志收集

K Kibana

日志展示

实战

环境

操作系统优化

systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/SELINUX.*/SELINUX=disabled/g' /etc/selinux/conf

# 时间一致

# 域名解析
172.16.100.18 elk-node1
172.16.100.21 elk-node2

环境说明

• 除 JumpServer 自身组件外，其他组件的高可用请参考对应的官方文档进行部署
• 按照此方式部署后，后续只需要根据需要扩容 JumpServer 节点然后添加节点到 HAProxy 即可
• 如果已经有 HLB 或者 SLB 可以跳过 HAProxy 部署，第三方 LB 要注意 session 和 websocket 问题
• 如果已经有 云存储 (* S3/Ceph/Swift/OSS/Azure) 可以跳过 MinIO 部署，MySQL Redis 也一样
• 生产环境中，应该使用 Ceph 等替代 NFS，或者部署高可用的 NFS 防止单点故障
• Redis 高可用快速部署可以参考此项目

ELK+Kafka集群

前言

前言

业务层可以直接写入到kafka队列中，不用担心elasticsearch的写入效率问题。 图示

Kafka

Apache kafka是消息中间件的一种，是一种分布式的，基于发布/订阅的消息系统。能实现一个为处理实时数据提供一个统一、高吞吐、低延迟的平台，且拥有分布式的，可划分的，冗余备份的持久性的日志服务等特点。

术语

1、kafka是一个消息队列服务器。kafka服务称为broker（中间人）, 消息发送者称为producer（生产者）, 消息接收者称为consumer（消费者）;通常我们部署多个broker以提供高可用性的消息服务集群.典型的是3个broker;消息以topic的形式发送到broker,消费者订阅topic,实现按需取用的消费模式;创建topic需要指定replication-factor(复制数目, 通常=broker数目);每个topic可能有多个分区(partition), 每个分区的消息内容不会重复

2、kafka-broker-中间人

3、webserver/logstash-producer[prəˈdu:sə®]-消息生产者/消息发送者
Producer：
kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/“partitions leader列表"等信息；
当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
消息由producer直接通过socket发送到broker，中间不会经过任何"路由层”，事实上，消息被路由到哪个partition上由producer客户端决定；比如可以采用"random"“key-hash”"轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
在producer端的配置文件中,开发者可以指定partition路由的方式。
Producer消息发送的应答机制设置发送数据是否需要服务端的反馈,有三个值0,1,-1
0:producer不会等待broker发送ack
1:当leader接收到消息之后发送ack
-1:当所有的follower都同步消息成功后发送ack

4、elasticsearch-consumer-消费者

5、logs-topic-话题

6、replication-facter-复制数目-中间人存储消息的副本数=broker数目

7、一个topic有多个分区partition
partition：
（1）、Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
（2）、在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；一个Topic中的每个partions，只会被一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。

LF规定的包

教程里使用的 https://github.com/arut/nginx-rtmp-module.git 这个模块太老了，3年之前更新过，所以重新更改方案使用了https://github.com/winshining/nginx-http-flv-module，这个模块在实现前者的功能的同时还实现了flv拉流量的功能，功能上强很多，而且更新及时。

Zabbix 构建企业级监控告警平台

一. 简介

Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。它能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。

二.监控对象

源代码: *.html*.jsp *.php*.py
数据库： MySQL,MariaDB,Oracle,SQL Server,DB2
应用软件：Nginx,Apache,PHP,Tomcat agent

摘录自：http://www.dellhpibm.com/js-47.html

系统内存指南

PowerEdge 系统支持 DDR4 寄存式 DIMM (RDIMM)、低负载 DIMM (LRDIMM) 以及非易失性 DIMM (NVDIMM-N) 和 DCPMM。系统内存可容纳执行由处理器的说明进行操作。

系统包含 24 个内存插槽，分为两组（每组 12 个），每个处理器一组。每组的 12 个插槽分入六通道。每个处理器均分配有六个内存通道。在每个通道中，第一个插槽的释放拉杆标为白色，第二个插槽的标为黑色。