Graylog 通过 Input 搜集日志，每个 Input 单独配置 Extractors 用来做字段转换。 Graylog 中日志搜索的基本单位是 Stream，每个 Stream 可以有自己单独的 Elastic Index Set，也可以共享一个 Index Set。用 Set 是因为日志的保存会使用一个前缀然后滚动创建新的 Index。Stream 通过配置条件匹配日志，满足条件的日志添加 stream ID 标识字段并保存到对应的 Elastic Index Set 中。同一个 Input 中的日志可以属于不同的 Stream，不同 Input 中的日志可以属于同一个 Stream，就是同一条日志也可以属于多个 Stream。 系统会有一个默认的 Stream，所有日志默认都会保存到这个 Stream 中，除非匹配了某个 Stream，并且这个 Stream 里配置了不保存日志到默认 Stream。 下图是日志处理流程图 Graylog 日志处理 后文会分别分享各个步骤需要注意的一些地方。
Graylog 通过 Inputs 收集日志，方式以被动接收为主，需要在产生日志的地方将日志发送给 Graylog。比较常用的一些方式： 程序中直接集成可以发送日志给 Graylog 的库，在 Github 中搜索 GELF 可以找到大量各种语言、框架、环境下的库。 采用传统的文件来记录日志，在机器上启动一个 agent 程序抓取日志文件新的内容然后发给 Graylog。 使用 syslog 写日志，利用 rsyslog 的转发功能把日志发给 Graylog。 服务器端日志个人推荐最后一种方式，优点有 不依赖 Graylog，可以替换成任何能接收 syslog 的其它方案。 容易 Fallback，rsyslog 可以配置成同时保存到本地文件和转发 Graylog。当 Graylog 出现问题至少还有本地日志文件可以用。 rsyslog 的日志保存，转发已经非常成熟和稳定。 缺点是 rsyslog 日志会把整条日志作为 message 字段保存。Graylog 内部每条日志是作为 Elastic 的 Document 保存的，细化出更多的字段能满足复杂查询和数据分析的需求。所以 Graylog 基于 JSON 制定了 GELF 协议，使用 GELF 协议的 Input 可以在产生日志时直接设置各种字段。不过 Graylog 还提供了 Extractor，和 fluentd, logstash 中的 filter 相似，可以从日志中提取结构化字段出来，比如 JSON Extractor 可以解析 JSON 格式日志。使用过类似工具的应该对 Grok 很熟悉，Graylog 也提供了支持。所以使用 rsyslog 也只需要制定下日志格式，然后配置下 Extractor。 Graylog 自带了丰富的 Inputs 可供使用，同时可以通过插件扩展，可以结合自己的使用场景选择合适的方式。 本文接下来会介绍日志收集需要注意的地方，以及如何基于 rsyslog 来打造集中日志系统。
如果想在已有的 Rails app 上使用其它语言加些 API，同时能直接使用 Rails 的登陆信息，最简单的就是用 Nginx 等代理将不同的服务映射到相同的域名下，其它的 App 解密 Cookie 获得登陆信息。 本文以 Ruby 代码为例说明 Rails 的 Cookie 是如何加密，然后以 Go 为例说明如何解密的。 Rails Cookie 加密…
使用 Graylog 之前试过很多方案，包括流行的 ELK，也用过 fluentd 搭配各种存储，influxdb, mongodb 等等。但这些方案在日志量大了之后出现性能瓶颈都没有提供解决方案。而 Graylog 作为整合方案，使用 elasticsearch 存储，mongodb 缓存，带流量控制 (throttling)，简单易用的查询界面，方便的管理界面，易于扩展。转移到 Graylog 省心了不少。在使用过程中积累了些经验，准备陆续分享出来。 第一篇是关于如何安装 Graylog。
最近把 Graylog 升级到集群。因为使用了 syslog UDP 作为输入，所以需要做个 UDP 的负载均衡。因为机器在阿里云，所以首先是创建了个阿里云内网的 UDP 负载均衡，但是发现负载不平均，而且也没办法关闭检测连接的心跳包。而常见的 HTTP 负载均衡工具 HAProxy 不支持 UDP。最后发现 Nginx 是可以实现 UDP 负载均衡的。
Redis 比较常见的是作为读缓存。读取数据的时候检查 Redis 是否存在，存在的话缓存命中，不需要访问后端存储。没命中的话从后端存储中获得，并同时存入 Redis。写数据的时候直接写入后端存储，清除 Redis 中对应的缓存或者更新成新的值。这种模型可以安全的随时删除缓存中的内容而不会造成数据丢失，因为最新的数据一定是写入到后端存储里了。 但如果系统的瓶颈出现在了写入这块，上面的模型就没法解决了。稍加修改可以得到写缓存的模型： 读的时候检查 Redis，如果 Redis 存在直接使用 Redis 中的数据，否则从后端存储中读取。 写的时候只写入 Redis，通过消息队列通知后台任务把 Reids 中缓存的内容保存到后端存储中。 后台任务监听消息队列，在把缓存内容保存成功之后从 Redis 中删除对应的内容。 任务队列可以使用 Redis 的 LIST 来实现，官方的 RPOPLPUSH – Redis 命令文档中已经很详细描述了如何实现一个可靠的消息队列。于是剩下的问题就是如何能保证安全的删除已经保存过的缓存？…
最近在公司的一个 Cocos2D-X 项目中碰到一个问题，TTF 文本加描边后会变宽，而且很明显没有对齐，字和描边之间没齐，每个字的水平基准线也没有对齐。最后发现是排版的代码有问题，官方分支上已经修复，但是这个项目使用的是 quick 分支出来的社区版，所以手动把修改做了个补丁提交了个修复TTF 描边效果的 PR。 在 Cocos2D-X 是 TTF 的排版是使用的开源库 FreeType 2，核心的实现基本都在 cocos/2d/CCFontFreeType.cpp 中的 FontFreeType::getGlyphBitmap。原理是通过 FreeType 为每个字生成位图，然后通过 FreeType 返回的排版信息放到合适的位置，而问题就出现加了描边之后，位置计算的不正确。 为了弄清楚原因，又去看了下相关的文档，了解了下 Cocos2D-X 具体是如何排版 TTF 的。
在上一次游戏测试中，因为用了新的机器，并且从 ansible 切换到了 salt stack，其中 nofile 相关的配置步骤漏掉了，结果所有进程的 nofile 限制是默认的 1024。结果就是当在线人数达到一定数据之后，出现大量 lua 找不到文件的错误，导致后来的玩家没法登录，已经在线的玩家也没法正常游戏。 开发服务端程序，nofile 是很重要的配置。它限制了一个进程最多能够打开的文件数量。对于高并发的服务，每个连接都会打开一些文件，尤其是使用像 Lua 这样的脚本语言，更是要打开大量的文件。 当前的限制可以使用 ulimit -a 查看。 要修改也比较简单，以 Ubuntu 为例，最简单的就是修改 /etc/security/limits.conf，在该文件中添加下面内容即可，不需要重启，新创建的进程会使用新的配置。 * hard nofile 1000000 * soft nofile 1000000…
一图胜千言，通过截图加标注能够很直白的说明问题。不过有时候会碰到标注很多很复杂的情况，比如针对截图对 UI 或者游戏系统进行分析，这个时候结合思维导图就比较方便了。 OmniGraffle 是个图表绘制和图表绘制工具。通过结构化编辑，和自动图表风格，也可以作为思维导图工具。而使用锚点编辑的连接功能 ，可以在图片的对应位置上使用引导线来引出各个主题。
我写了不少 macOS 脚本来自动化我的工作。这个脚本可以是用的最多的。我用它来在各种 App 中，将当前选中的对象做为任务添加到 OmniFocus 中。通过捕获的链接可以在 OmniFocus 中直接打开相关的文档。