本站导航
技术相关
Python学习指南
Linux实践指南
前端
数据库
云原生实践指南
书影音
书单
影单
工具
office+project+visio2019激活
广告过滤规则
再见,CentOS
CentOS Stream 8 end of builds is May 31, 2024. CentOS Linux 7 end of life is June 30, 2024.
在技术的洪流中,没有永恒的王者。2020年12月8日,Red Hat 公司宣布了一项震惊业界的消息:CentOS 将不再作为独立的、长期支持的发行版存在,而是转型为CentOS Stream,一个滚动发布的上游测试平台。这意味着,那个曾经陪伴无数开发者和企业用户走过风风雨雨的 CentOS,即将退出历史舞台,留下一片思考与探索的空间。
CentOS,全称 Community Enterprise Operating System,自 2003 年诞生以来,便以其免费、稳定、兼容性强的特点迅速赢得了全球用户的青睐。它基于 Red Hat Enterprise Linux(RHEL)源代码构建,几乎完美地复刻了RHEL的功能和性能,但又免去了高昂的订阅费用,成为许多个人开发者、初创企业和教育机构的首选操作系统。
然而,Red Hat 的这一决定,无疑是对开源社区的一次重大冲击。对于依赖 CentOS 的用 ...
502 Bad Gateway 排障思路
参考:排查 502 Bad Gateway 的常见思路
使用 Chrome 开发者工具(Edge等Chromium内核的浏览器也行)确认报错的接口,拿到基础信息
修改 Chrome 生成的 cURL 命令直接请求后端,绕过 Nginx,快速确认是负载均衡的问题还是后端问题
查看 Nginx 的日志,在 access log 中检索报错的接口
如果是 Nginx 层面的问题,查看 Nginx 的配置文件,确认是否有超时配置
如果是后端服务的问题,根据 response 做基本判断
Connection refused 大概率是后端服务没启动
Empty reply from server 大概率是后端服务在处理请求的时候 panic 了,或者被 OOM kill 了
如果后端返回 502,说明后端至少没 crash,可以继续查看后端服务日志
dmesg –T |grep –i "out of memory" 确认是否是 OOM 问题
左耳朵耗子的话
转载自左耳朵耗子的话
昨天,一整天都不开心。朋友圈里,几乎每翻一屏,都能看到有人在转左耳朵耗子离世的消息。作为一名创造者,左耳朵耗子为这个世界留下了很多作品,比如他的博客 CoolShell、他的极客时间专栏左耳听风,以及他的公司 MegaEase。感慨世事无常的同时,我也在回忆,左耳朵耗子讲过的那些有分量的话。
对于生者来说,左耳朵耗子是一个好榜样。他近乎偏执地追求技术驱动创新,他敢于挑战权威、从不盲从,他知世故而不世故的作风,将会永远留在我们心里。
我司的池老师和陈皓是多年老友,他 15 号凌晨就得知了这个噩耗,中午他写了一篇悼文放到了墨问便签上,看得让人泪目。
沉痛缅怀好友左耳朵耗子
今天早上来了公司,我猛然想起两年前,和他的连麦直播。那一次,他完整地阐述了他为什么创业,他的梦想是什么,他这辈子想做件什么事。记得当时弹幕区里有用户说,这场直播,是自己人生觉醒的分水岭,意义非凡。我赶忙找到了那期直播的视频(差点丢了),然后约同事和朋友一起,完成了内容精编。
这是左耳朵耗子给我们留下的精神遗产。我们在怀念他的时候,不妨去理解和实践他的人生观和做事观吧。以下,是具体内容。
创业为 ...
ip 地址多种写法
ping 0On Linux:
1234$ ping 0PING 0 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.075 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.065 ms
On Mac:
1234$ ping 0PING 0 (0.0.0.0): 56 data bytesping: sendto: No route to hostping: sendto: No route to host
在这里,它翻译为一个空路由0.0.0.0。
0 是可选的1234$ ping 127.1PING 127.1 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.079 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.065 ms
需 ...
Nginx:限流
📖参考:
Nginx如何限流
nginx documentation
概述流量限制(rate-limiting),是 Nginx 中一个非常实用,却经常被错误理解和错误配置的功能。我们可以用来限制用户在给定时间内 HTTP 请求的数量。
流量限制可以用作安全目的,比如可以减慢暴力密码破解的速率。通过将传入请求的速率限制为真实用户的典型值,并标识目标URL地址(通过日志),还可以用来抵御 DDOS 攻击。更常见的情况,该功能被用来保护上游应用服务器不被同时太多用户请求所压垮。
如何限流Nginx 的”流量限制”使用漏桶算法(leaky bucket algorithm),该算法在通讯和分组交换计算机网络中广泛使用,用以处理带宽有限时的突发情况。就好比,一个桶口在倒水,桶底在漏水的水桶。如果桶口倒水的速率大于桶底的漏水速率,桶里面的水将会溢出;同样,在请求处理方面,水代表来自客户端的请求,水桶代表根据”先进先出调度算法”(FIFO)等待被处理的请求队列,桶底漏出的水代表离开缓冲区被服务器处理的请求,桶口溢出的水代表被丢弃和不被处理的请求。
限流使用的模块Nginx 的 limit ...
Bash命令使用技巧总结
开源地址:onceupon/Bash-Oneliner: A collection of handy Bash One-Liners and terminal tricks for data processing and Linux system maintenance.
Terminal TricksUsing Ctrl keys12345678910111213141516Ctrl + n : same as Down arrow.Ctrl + p : same as Up arrow.Ctrl + r : begins a backward search through command history.(keep pressing Ctrl + r to move backward)Ctrl + s : to stop output to terminal.Ctrl + q : to resume output to terminal after Ctrl + s.Ctrl + a : move to the beginning of line.Ctrl + e ...
Zabbix 5.0:通过 LLD 方式自动化监控阿里云 RDS
之前做了RDS监控,由于 RDS 实例数量增多,手动添加的方式已经不够效率,故改为 LLD(Low-level discovery) 方式做监控。
什么是 LLDLLD(Low-level discovery),即低级发现,提供了一种在计算机上为不同实体自动创建监控项,触发器和图形的方法。例如,Zabbix 可以在你的机器上自动开始监控文件系统或网络接口,而无需为每个文件系统或网络接口手动创建监控项。此外,可以配置 Zabbix 根据定期执行发现后的得到实际结果,来移除不需要的监控。
用户可以自己定义发现类型,只要它们遵循特定的 JSON 协议。
采集数据脚本调用阿里云 Api,采集 RDS 相关数据,相关配置可参考之前的文章,采集脚本略。
需要将 Api 返回的数据处理,将字段修改为 {#MACRO} 形式的 LLD 宏,最后生成 json 格式的数据:
例如:
12345678910[{ "{#DBINSTANCEID}": "rr-XXX", "{#DBNAME ...
Windows 在连接有线网卡的情况下自动连无线WIFI
电脑连接有线网卡的情况下,默认不会主动连wifi。特殊情况需要同时连无线wifi,每次得手动去连wifi,然而网上大部分教程都是教你不连有线网卡的情况下自动连wifi,并不能解决当前情况。
解决方法:
Win键+R打开,输入regedit,打开注册表编辑器。
找到以下路径:HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WcmSvc\GroupPolicy。
在GoupPolicy下,右侧空白区域,鼠标右键–>新建–>DWORD(32位)值。
把这个新建的DWORD(32位)改名为fMinimizeConnections。
关闭注册表编辑器,重启电脑。
Kubernetes:存储管理
参考:Volumes | Kubernetes、Persistent Volumes | Kubernetes、Kubernetes 基础入门实战
简单来说,存储卷是定义在Pod资源之上可被其内部的所有容器挂载的共享目录,该目录关联至宿主机或某外部的存储设备之上的存储空间,可由Pod内的多个容器同时挂载使用。Pod存储卷独立于容器自身的文件系统,因而也独立于容器的生命周期,它存储的数据可于容器重启或重建后继续使用。
存储卷并非Kubernetes上一种独立的API资源类型,它隶属于Pod资源,且与所属的特定Pod对象有着相同的生命周期。
PV(PersistentVolume)与PVC(PersistentVolumeClaim)就是在用户与存储服务之间添加的一个中间层,管理员事先根据PV支持的存储卷插件及适配的存储方案(目标存储系统)细节定义好可以支撑存储卷的底层存储空间,而后由用户通过PVC声明要使用的存储特性来绑定符合条件的最佳PV定义存储卷,从而实现存储系统的使用与管理职能的解耦,大大简化了用户使用存储的方式。
前置知识
Kubernetes:Pod总结(一)
Kubern ...