烂笔头

在 Windows 系统上面使用 Sublime text 3，创建了一个 Shell 文件，然后上传到 Linux 系统去执行。结果总是报错：未预期的符号，附近有语法错误，折腾了我一个多小时，反复仔细检查了脚本没有发现问题，最后没想到是文件的格式在不同操作系统下不兼容，本质是回车换行符的问题，气死我了。

利用 Shell 脚本，做一个简单的 Kafka 消费偏移量监控功能，当数据积压过多时，发送信息。当然，发送通知利用了 Server 酱这个服务，感谢她。

昨天查看 Elasticsearch 集群监控，发现有几个 Elasticsearch 节点的 JVM Heap 异常，上下波动非常频繁，进一步查看 GC，发现 Full GC 非常频繁，每分钟达到 5-10 次，而累加耗时有 10-20 秒，也就是说有 17%-33% 的时间都在做 Full GC，这显然是不健康的。

进一步查看 CPU 使用情况，发现 CPU 使用率由正常的 20% 左右，达到现在的 50%-70%，这也是不正常的。

排查方向是看是否有大量的 aggregations 请求或者排序 sort 操作，这种情况才会造成大量的内存占用【fielddata 缓存】。当然其它情况也有可能，但概率低【例如大查询，query 语句复杂，数据量大】，具体情况需要具体对待。排查的过程就不说了，由此做引子，先简单对 fielddata 缓存做入门指引。

首先声明，本文记录的内容是 fielddata 缓存数据、熔断器，不是 text 开启 fielddata 属性那种含义，给出 3 个链接：modules-fielddata、circuit-breaker、cluster-nodes-stats 。

最近 Elasticsearch 集群出了一个小事故，根本原因在于对集群请求的监控不完善，以及对 Elasticsearch 访问权限无监控【目前是使用 LDAP 账号就可以登录访问，而且操作权限很大，这有很大的隐患】。因此，最近准备上线 Search Guard，先在测试环境部署安装了一遍，并测试了相关服务，整理了如下安装部署文档，以供读者参考。

开发环境基于 Elasticsearch v5.6.8、Search Guard v5.6.8-19.1、Java v1.8 。

在 Elasticsearch 中，有参数可以指定查询结果返回的字段，这样可以使查询结果更简约，看起来更清晰。如果是大批量 scroll 取数，还可以减少数据在网络中的传输，从而降低网络 IO。本文使用简单的查询来举例，演示环境基于 Elasticsearch v5.6.8。

本文记录一些工作当中常用的小工具、小技巧，有时候自己可以查看备忘，同时也给读者参考。当然，内容是在不断补充的，涉及的维度也会扩展。

在常规的 Spark 任务中，出现警告：Not enough space to cache rdd_0_255 in memory! (computed 8.3 MB so far)，接着任务就卡住，等了很久最终 Spark 任务失败。排查到原因是 RDD 缓存的时候内存不够，无法继续处理数据，等待资源释放，最终导致假死现象。本文中的开发环境基于 Spark v1.6.2。

在业务中只要有使用到 Elasticsearch 的场景，那么有时候会遇到需要重构索引的情况，例如 mapping 被污染了、某个字段需要变更类型等。如果对 reindex API 不熟悉，那么在遇到重构的时候，必然事倍功半，效率低下。但是如果熟悉了，就可以方便地进行索引重构，省时省力。

本文演示内容基于 Elasticsearch v5.6.8，在以后会不断补充完善。

今天的 Spark Streaming 程序莫名出现异常【对于一个 task 来说，Spark Streaming 会重试 4 次，全部重试都失败后整个 Stage 才会失败】，紧接着 task 中的 batch 就会卡住不动【后来查到卡住是其它原因造成的】，使得整个 Spark Streaming 任务进程进入到等待状态，所有的 batch 都处于 queued 状态，数据流无法继续执行。本文内容基于 Spark v1.6.2。

在一个非常简单的业务场景中，偶尔出现异常：413 Request Entity Too Large，业务场景是写入数据到 Elasticsearch 中，异常日志中还有 Nginx 字样。

本文记录排查过程，本文环境基于 Elasticsearch v5.6.8，使用的写入客户端是 elasticsearch-rest-high-level-client-5.6.8.jar。