运维

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 前言 最近打算在blog里面，增加个性化推荐，以增加访问量。这一切的前提是，我要能够标识出每个用户，以及记录用户的浏览记录。这里笔者采用openresty在cookie中写入用户标识，然后在日志中记录下用户的浏览记录，供后续分析使用 2. 详解 1）nginx 配置 upstream blog { server 127.0.0.1:8080; } server { listen 80; #端口 server_name blog.vearne.cc; location ^~ /archives/ { rewrite_by_lua_file 'conf/lua/set-ck.lua'; proxy_pass http://blog; } location /{ proxy_pass http://blog; } } 2）Lua脚本 set-ck.lua 如果用户没有对应的cookie "UT_ID", 则注入cookie的同时，返回一个302临时跳转, 客户再次访问时，由于已经拥有响应cookie，所以可以直接访问后端服务 local cookie_name = "cookie_UT_ID" local request_uri = ngx.var.request_uri if ngx.var[cookie_name] == nil then local uuid = io.open("/proc/sys/kernel/random/uuid", "r"):read() local mycookie = string.format("UT_ID=%s; Expires=%s", uuid, ngx.cookie_time(ngx.time() + 86400 * 1000)) ngx.header["Set-Cookie"] = mycookie ngx.header["Location"] = request_uri ngx.exit(302) end 这里另一个有趣的地方是，可以直接通过读取文件 "/proc/sys/kernel/random/uuid" 来生成一个uuid ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 聊聊几种服务器之间传文件的方式 1. 使用scp命令 scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 DESCRIPTION :scp copies files between hosts on a network. scp 支持传输单个文件和文件夹 scp /home/test/1.mp3 root@192.168.8.100:/home/root/music 2. 使用python 可以直接使用下面命令，启动简单的文件服务器(单线程) python2 python -m SimpleHTTPServer 8080 python3 python3 -m http.server --cgi 8080 下载 wget http://192.168.10.100:8080/tt.png 注意 请自行替换服务地址和文件名 3. 使用nc命令 接收端 nc -l 8080 > tt.png 发送端 nc 192.168.10.100 8080 < tt.png 注意 请自行替换服务地址和文件名 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 引言 WebP格式，谷歌（google）开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器宽带资源和数据空间。Facebook Ebay等知名网站已经开始测试并使用WebP格式。 但WebP是一种有损压缩。相较编码JPEG文件，编码同样质量的WebP文件需要占用更多的计算资源。 目前谷歌、阿里巴巴、搜狐都有在采用此方案，另外七牛云支持同步转换，可以直接使用。 注意:某些Android版本不兼容webp格式。 安装webp 编码/解码工具 mac 上安装webp非常简单 brew install webp 让我们看看实际转换的效果, cwebp支持对PNG/JPEG/TIFF 格式的转换 # 编码 cwebp -q 80 8260434328.jpg -o 8260434328_80.webp # 解码 dwebp 8260434328_80.webp -o 8260434328.jpg 原图 大小: 130KB 质量因子:80 大小: 73KB 质量因子:80 大小: 35KB 大家可以看到图片大小减少了75%左右，但感官上，图片的画质几乎没有影响。 注意 如果图片无法正常浏览，请使用chrome浏览器 关于移动端使用WebP，请阅读参考资料1 参考资料 移动端如何使用 WebP 请我喝瓶饮料

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 公司的测试的网络硬盘太小，我一直想要一个NAS盘，用云主机来做NAS确实太贵，平常又用不了，能不能用对象存储来做网盘呢，用多少，付多少钱，还可以无限扩容。 最近青云推出了QingStor™对象存储本地盘 QingStor™ 对象存储本地盘可将 QingStor™ 对象存储的存储空间挂载为 Windows /Linux 等平台下的磁盘或文件目录，由 QingStor™ 对象存储为其提供无限容量的在线文件存储空间，而不占用本地磁盘空间。用户可以像操作本地磁盘一样方便、快捷地访问或存取 QingStor™ 对象存储存储空间（Bucket）中的各常用类型文件（如文档、图片、音视频、二进制归档、压缩文件等）。 下面的qsfs就是青云的对象存储，通过qsfs-fuse，青云的对象存储可以像网盘一样挂载主机上，无论是云主机还是本地主机 root@ecs-hb-xxx:/qincloud$ df -Th Filesystem Type Size Used Avail Use% Mounted on /dev/vda1 ext4 40G 29G 8.8G 77% / tmpfs tmpfs 1.9G 0 1.9G 0% /dev/shm qsfs fuse.qsfs 16E 9.8M 16E 1% /qincloud 上面是在我的阿里云主机上使用qsfs-fuse的例子 如果你的对象存储不在pek3a，你需要指定zone，否则会提示 root@ecs-hb-hb1-xxxx:~$ qsfs bucket01 /qincloud/ -c=/root/.qincloud -d FUSE library version: 2.8.3 nullpath_ok: 0 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 INIT: 7.14 flags=0x0000f07b max_readahead=0x00020000 E0410 17:25:45.466140 1405 Drive.cpp:212] [ERROR] NotFound, QingStorHeadBucket:NotFound(404) E0410 17:25:45.466606 1405 Operations.cpp:1511] [ERROR] Unable to connect bucket ut-bucket01 INIT: 7.12 flags=0x00000011 max_readahead=0x00020000 max_write=0x00020000 unique: 1, success, outsize: 40 Segmentation fault 启动命令 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 在记一次使用阿里云REDIS出现的故障一文，中我记录了由于DNS解析, 导致无法访问阿里云redis的服务地址, 里面涉及了/etc/resolv.conf， 通过修改resolv.conf可以修改系统默认的DNS服务器 说明 关于resolv.conf其他参数，请阅读参考资料2 常见配置1 通常我们会这么配置 nameserver 119.29.29.29 nameserver 223.5.5.5 nameserver 114.114.114.114 nameserver DNS服务器的地址 在常见配置1中，系统顺序尝试每个dns服务器的地址。如果响应超时(默认为5秒)，则尝试下一个地址 常见配置2 另外云主机通常是这样配置的 options timeout:1 attempts:1 rotate nameserver 10.143.22.116 nameserver 10.143.22.118 timeout 请求dns服务器超时设置，单位:秒，默认为5秒，具体值需要查 resolv.h attempts 每个dns服务器的重试次数 rotate 使用轮训的方式选择DNS服务器，而不是顺序尝试 参考资料 DNS域名解析过程 resolv.conf 请我喝瓶饮料

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 前言 我们公司的很多服务都是完全部署在阿里云上，甚至包括很多数据库。比如Redis和MySQL 事件的经过 阿里云的Redis为了方便内网访问（其实也只能在内网访问）使用的域名形如 xxxx.redis.rds.aliyuncs.com 时间 在20xx-xx-xx 23:00 ~ 24:00 症状 发现某个服务无法访问 继而排查日志发现，我们的服务会访问Redis，但是Redis的这个域名无法解析了；在没有做任何操作的情况下，域名在24点后可以正常解析了，服务也就自然的恢复了。 排查 对比这台机器和其它机器，发现他们的DNS的配置文件风格不大像 故障机器 [root@hostA ~]$ cat /etc/resolv.conf nameserver 119.29.29.29 nameserver 223.5.5.5 nameserver 114.114.114.114 其它阿里云机器 [root@hostB ~]#cat /etc/resolv.conf options timeout:1 attempts:1 rotate nameserver 10.143.22.116 nameserver 10.143.22.118 hostA的DNS文件显然是有运维兄弟修改过了，在正常情况下，hostA这样配置不会有什么问题 但是在某些特定情况下，可能会引发灾难 极端情况 参考资料1，描述了DNS解析的整个过程 比如我们使用119.29.29.29（DNSPOD，其实DNSPOD早就被腾讯收购了）作为Local DNS，图中的Name Server其实是域名的权威服务器，aliyuncs.com的权威服务假定是ns4.aliyun.com，明显这是阿里云的机器 极端情况1 我是假定步骤8的网络出现了异常（DNSPOD -> aliyun） 显然在这种情况下，在hostA已经不可能成功解析域名 获得域名权威服务器信息可用以下方法 AUTHORITY SECTION 即为域名的权威服务器信息 ╰─$ dig aliyuncs.com ; <<>> DiG 9.9.3 <<>> aliyuncs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64838 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;aliyuncs.com. IN A ;; ANSWER SECTION: aliyuncs.com. 300 IN A 140.205.32.8 ;; AUTHORITY SECTION: aliyuncs.com. 99637 IN NS ns4.aliyun.com. aliyuncs.com. 99637 IN NS ns3.aliyun.com. aliyuncs.com. 99637 IN NS ns5.aliyun.com. 极端情况2 如果阿里云主机到DNSPod(119.29.29.29) 出现网络故障，显然域名也就无法解析了 ...

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 引子： 公司一个项目需要使用Redis，单实例的Redis性能不够，但出于成本考虑，不打算使用集群模式，因而选择了Redis的Proxy模式，为了方便部署，干脆打成了RPM包。这里分享出来，以飨众人。 RPM包下载地址： 链接: https://pan.baidu.com/s/1dP7Ilo 密码: p456 说明： 构建简单的Redis Cluster 基于 Redis 版本为4.0.1 Redis Proxy 为唯品会开发的多线程版本的twemproxy –twemproxies(版本1.2.1) 项目地址： https://github.com/vipshop/twemproxies 安装&&启动&&停止 1.安装 rpm -ivh redis_tp_cluster-0.0.1-4.x86_64.rpm 安装完成以后， 1.1 配置文件在 /etc/redis中 ## Redis共10个实例 /etc/redis/7001.conf /etc/redis/7002.conf /etc/redis/7003.conf /etc/redis/7004.conf /etc/redis/7005.conf /etc/redis/7006.conf /etc/redis/7007.conf /etc/redis/7008.conf /etc/redis/7009.conf /etc/redis/7010.conf # Redis Proxy 配置文件 /etc/redis/nutcrackers.yml 1.2 bin文件在 /usr/local/bin/redis-server /usr/local/bin/redis-cli /usr/local/bin/nutcrackers 1.3 启动脚本 /etc/init.d/redis_tp_cluster.sh 2.启动 /etc/init.d/redis_tp_cluster.sh start 3.停止 /etc/init.d/redis_tp_cluster.sh stop 重要 Redis Proxy默认 服务地址 127.0.0.1:22121 密码 b8@40fc02d52 如果需要调整请修改 /etc/redis/nutcrackers.yml 参考资料： 1.Redis rpm包下载地址

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 我在《我的监控世界观》1 ~ 4 中更多的阐述了对于某个监控点的监控、存储、展现。但是在现实世界中，整个世界的联系更像是一个图，每个点可以是某个监控点，而边是他们之间的调用关系或者数据流 举例： webserver –> mysql 对于一个最简单的web 服务, 它可能有两部分组成，webserver 和 mysql存储店铺、商品信息，webserver 服务直接和浏览器用户进行交互。在这样一个业务场景中，webserver 上有的监控点，可能包括单位时间内的UV、PV，而mysql 上的监控点可能有连接数，每秒请求数等等 这样，我们就把监控点和我们的自身的业务逻辑紧密的结合起来了。并且我们可以想到每一家公司的业务是完全不同的，所以如果我们把监控也分出层次的话，我们发现监控也是有层次的 3 业务层级的监控 2 监控点数据收集、存储、聚合 1 监控点数据采集 1）监控点数据的采集无法采取通行方案 除了基础类型的监控比如 CPU使用率、load、磁盘使用率 但是类似UV, PV 的业务指标很难统一起来 2）监控点数据收集、存储、聚合 是可以使用通行方案去解决的 最近我看到一篇文章提出用使用ES来做后聚合，可以无需做先聚合 3）业务层级的监控要反映业务流中各个应用，服务之间的调用关系，特别要反映数据的流向，流量的大小等等。数据流是贯穿各个模块的最核心的元素 后记： 这篇文章是我2014年的文章 现在看来，其中的很多观点还是具有指导意义 开源监控系统的重点在2，剩下的部分只要暴露良好的接口出来，让别人容易做二次开发即可。 请我喝瓶饮料

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 真正有必要存储的数据可能有两个 应用的历史状态信息（时序数据） 应用的监控项数据（元数据） 1. RRD 早期的开源监控系统，如cacti、nagios和ganglia,采用的是RRD，这种做法的好处是占用空间小，而且数据点的聚合是自动完成的，不需要监控系统的开发者自己开实现，另外出图也比较方便 但它的缺点也不少: 数据的提取和迁移非常的不方便 聚合点的调整不方便 监控数据的后期统计和分析十分不便 由于它的出图是直接保存为图片格式的导致传输成本更大 2. RMDB 这几年开始，不少监控系统如zabbix开始采用RMDB来存储监控项的数据，个人认为这种做法，应该是各大互联网公司的监控系统的主流做法，监控系统的数据存储具有以下特点: 大量的写操作，但是写操作相对均匀，突发现象较少 对时间的敏感度不是特别高，特别适合批量写的做法 读操作较少（相对于写操作），单次读取的数据量较大 且一般只做插入，不做变更 对于以mysql为代表的关系型数据库而言，经过调优以后，每秒至少可处理 10000+的写请求，再考虑读写分库的做法，对于一家拥有数万台机器的公司而言，我相信以关系型数据库作为存储，应该也是没有问题的 3.Hbase 以OpenTSDB作为代表，以Hbase 来存储数据 这个做法的好处是存储空间可以无限扩容，提取速度也比较快，因为笔者对Hbase 也不是特别了解，因此也不敢妄下结论，但是总是觉得用它来作为存储，有些杀鸡用牛刀的感觉。 后记 本文是我2014年的文章 这里做一点补充 其实所有的时序型数据库，比如ES，InfluxDB等等都可以用来存储监控数据 监控数据的典型特点是 高频写，低频读，而且一般比较平稳，没有太多的尖峰 对于RRD数据库好处是空间小，且可以自动聚合，不过扩容比较难，需要预先就设定好大小 对于RMDB的最大问题，数据需要经常清理，但是向MySQL这样的数据库，即使数据删除了，所占的磁盘空间也不能自动回收，这个是比较麻烦的 对于HBase Hadoop这套东西上手的难度太大，一般人玩不转。这也是让人都疼的东西 对于ES，搭建确实简单，如果数据按月分库，也确实能够支持历史数据清理的问题，不过ES比较吃内存。不过要是数据做前期聚合，就占用空间，后聚合，如果查询时间跨度大，速度有可能变慢 对于InfluxDB, 它没有集群模式

版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 根据我对这个领域的理解，监控系统中最重要的三个实体只有: 应用 主机 监控项 这三个概念都是高度抽象的，首先谈谈应用，应用可以理解为某个真实的服务，也可以理解为某个抽象的服务，比如前文提到的主机的所有状态，它们的组合就可以构成一个抽象意义上的应用，至于名字，你可以随便的指定。但不论是何种应用，它以下几个特点: 有一组可以采集的状态信息 “部署"在相应的主机上 有对应的报警接收人，报警接收人也是监控领域非常重要的实体，但是它与应用是强耦合的，一种应用往往只对应到一组固定的报警接收人，也就是一一对应 监控项，表示的是我们对应用状态信息选择性的关注，也就是对应用的关注点。应用有很多的状态，但是并非每种状态都是需要我们关注的，比如，一台运行中的主机，它的uptime，可能对我们来说就不是很重要，但它确确实实是一种状态，我们对监控项需要有一种判断，以决定应用的状态，可以采用阈值判断，也可以采用某种模型来进行判断。 最后来谈谈主机，主机的概念，非常复杂，通常意义上的主机，只得是可以部署应用的真实存在的物理机或者虚拟机，然而，在实际开发中我们发现，主机可以代表很多其它东西，比如某个路由器，甚至是某个作为其它应用负载均衡的nginx。 如果nginx 做为反向代理部署在机器A上，某网站， 为了负载均衡，部署在两台机器B, C上，那么通过访问nginx可以访问到 A和B, 如果把这个网站的服务当成一个应用，那么访问机器B, 机器C, 和直接访问机器A上的nginx ，几乎可以得到同样的状态信息。 主机的概念太多抽象，它可以有IP信息，也可以没有，它甚至可以只是一个域名。 后记 这是我2014年的文章，我看到open-falcon中引入了一个新的词汇 Endpoint来描述我文中的主机，我觉得还是很贴切的, 因为Endpoint可以没有实际的物理意义