解答一个关于日志系统的思路

在一个群里看到一个面试题,试着去解答一下,毕竟正好花时间了解过日志这方面的内容。 希望能达到的使用场景: 在写业务逻辑时也能进行结构化的log, 并且log被转移到一个数据库, 一个UI前端以这个log数据库为支持, 可以可视化各种指标, 并且保留未来可以对指标进行alarm的可能性 ...

2015-06-09 · 7 min

解答一个关于日志系统的思路

在一个群里看到一个面试题,试着去解答一下,毕竟正好花时间了解过日志这方面的内容。 希望能达到的使用场景: 在写业务逻辑时也能进行结构化的log, 并且log被转移到一个数据库, 一个UI前端以这个log数据库为支持, 可以可视化各种指标, 并且保留未来可以对指标进行alarm的可能性 ...

2015-06-09 · 7 min

nginx做负载均衡器以及proxy缓存配置

关于nginx的安装和基本配置请参考nginx,本文在原基础上完成以下几个功能: 结合proxy和upstream模块实现nginx负载均衡 结合nginx_upstream_check_module模块实现后端服务器的健康检查 使用nginx-sticky-module扩展模块实现Cookie会话黏贴(session-sticky效果) 使用proxy模块实现静态文件缓存 使用ngx_cache_purge实现更强大的缓存清除功能 1. 安装及模块说明 上面提到的3个模块都属于第三方扩展模块,需要提前下好源码,然后编译时通过--add-moudle=src_path一起安装。 ...

2015-06-02 · 11 min

nginx做负载均衡器以及proxy缓存配置

关于nginx的安装和基本配置请参考nginx,本文在原基础上完成以下几个功能: 结合proxy和upstream模块实现nginx负载均衡 结合nginx_upstream_check_module模块实现后端服务器的健康检查 使用nginx-sticky-module扩展模块实现Cookie会话黏贴(session-sticky效果) 使用proxy模块实现静态文件缓存 使用ngx_cache_purge实现更强大的缓存清除功能 1. 安装及模块说明 上面提到的3个模块都属于第三方扩展模块,需要提前下好源码,然后编译时通过--add-moudle=src_path一起安装。 ...

2015-06-02 · 11 min

nginx配置ssl加密(单双向认证、部分https)

nginx下配置ssl本来是很简单的,无论是去认证中心买SSL安全证书还是自签署证书,但最近公司OA的一个需求,得以有个机会实际折腾一番。一开始采用的是全站加密,所有访问http:80的请求强制转换(rewrite)到https,后来自动化测试结果说响应速度太慢,https比http慢慢30倍,心想怎么可能,鬼知道他们怎么测的。所以就试了一下部分页面https(不能只针对某类动态请求才加密)和双向认证。下面分节介绍。 ...

2015-05-28 · 7 min

nginx配置ssl加密(单双向认证、部分https)

nginx下配置ssl本来是很简单的,无论是去认证中心买SSL安全证书还是自签署证书,但最近公司OA的一个需求,得以有个机会实际折腾一番。一开始采用的是全站加密,所有访问http:80的请求强制转换(rewrite)到https,后来自动化测试结果说响应速度太慢,https比http慢慢30倍,心想怎么可能,鬼知道他们怎么测的。所以就试了一下部分页面https(不能只针对某类动态请求才加密)和双向认证。下面分节介绍。 ...

2015-05-28 · 7 min

Nginx+Keepalived实现站点高可用

公司内部 OA 系统要做线上高可用,避免单点故障,所以计划使用2台虚拟机通过 Keepalived 工具来实现 nginx 的高可用(High Avaiability),达到一台nginx入口服务器宕机,另一台备机自动接管服务的效果。(nginx做反向代理,实现后端应用服务器的负载均衡)快速搭建请直接跳至 第2节。 ...

2015-05-18 · 10 min

Nginx+Keepalived实现站点高可用

公司内部 OA 系统要做线上高可用,避免单点故障,所以计划使用2台虚拟机通过 Keepalived 工具来实现 nginx 的高可用(High Avaiability),达到一台nginx入口服务器宕机,另一台备机自动接管服务的效果。(nginx做反向代理,实现后端应用服务器的负载均衡)快速搭建请直接跳至 第2节。 ...

2015-05-18 · 10 min

nginx配置location总结及rewrite规则写法

1. location正则写法 一个示例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 location = / { # 精确匹配 / ,主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索 # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 开头的地址,匹配符合以后,还要继续往下搜索 # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。 [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { # 匹配所有以 gif,jpg或jpeg 结尾的请求 # 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则 [ configuration E ] } location /images/ { # 字符匹配到 /images/,继续往下,会发现 ^~ 存在 [ configuration F ] } location /images/abc { # 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在 # F与G的放置顺序是没有关系的 [ configuration G ] } location ~ /images/abc/ { # 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用 [ configuration H ] } location ~* /js/.*/\.js 已=开头表示精确匹配 如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。 ^~ 开头表示uri以某个常规字符串开头,不是正则匹配 ~ 开头表示区分大小写的正则匹配; ~* 开头表示不区分大小写的正则匹配 / 通用匹配, 如果没有其它匹配,任何请求都会匹配到 顺序 no优先级: (location =) > (location 完整路径) > (location ^~ 路径) > (location ,* 正则顺序) > (location 部分起始路径) > (/) ...

2015-05-17 · 9 min

nginx配置location总结及rewrite规则写法

1. location正则写法 一个示例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 location = / { # 精确匹配 / ,主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索 # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 开头的地址,匹配符合以后,还要继续往下搜索 # 只有后面的正则表达式没有匹配到时,这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。 [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { # 匹配所有以 gif,jpg或jpeg 结尾的请求 # 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则 [ configuration E ] } location /images/ { # 字符匹配到 /images/,继续往下,会发现 ^~ 存在 [ configuration F ] } location /images/abc { # 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在 # F与G的放置顺序是没有关系的 [ configuration G ] } location ~ /images/abc/ { # 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用 [ configuration H ] } location ~* /js/.*/\.js 已=开头表示精确匹配 如 A 中只匹配根目录结尾的请求,后面不能带任何字符串。 ^~ 开头表示uri以某个常规字符串开头,不是正则匹配 ~ 开头表示区分大小写的正则匹配; ~* 开头表示不区分大小写的正则匹配 / 通用匹配, 如果没有其它匹配,任何请求都会匹配到 顺序 no优先级: (location =) > (location 完整路径) > (location ^~ 路径) > (location ,* 正则顺序) > (location 部分起始路径) > (/) ...

2015-05-17 · 9 min