0-日志平台调研1.2.3.https://github.https://github.4. https://www.g

1.无需每天再花时间去搜索异常日志，配合定时任务后更多的精力可以放在走查上报了什么问题、问题的原因与解决方式
2.前期可以将上报问题分配给自己来观察项目中是否需要大量的排除某些异常及问题，这个过程也是提升自己排查和分析能力的过程
3.配合定时任务灰度期间更快的发现上报问题并通知到群，让灰发更安心，硬装组使用此方式实践收益较多
4.稳定性提升的一种手段与方式，从历史记录问题分析，除业务问题外，潜在的性能、缓存、兼容性、依赖、权限、脏数据、超时等问题可以通过这种方式得以暴露

各大厂商基于ES日志系统：

进程管控：

1.supervisor
2.cesi

ES监控：

1.es_exporter
2.netdata（影响主机）
3.Kopf
4.bigdesk
5.elasticsearch-sql
6.Slow log监控
7.B站，基于elastalert二次开发
8.XPack

索引管理：

1.curator github.com/elastic/cur…
2.jiacrontab

性能优化：

1.elastic-hq：性能分析
2.cerebro：索引管理、settings
3.whatson：segment分析
4.es cat api

日志规范：

1.日志规范

为什么ELK的架构下要增加一个kafka？

1.袋鼠云，阿里云下的一个专门做日志的
2.斗鱼，使用kafka为了spark
3.饿了么，使用MQ为了做多活方案设计
4.新浪，为了spark做一些个性化的数据分析
5.华泰证券，为了做跨版本的升级，为了在日志里面集成metric，alert
6.阿里云，为了做实时数据和离线数据，日志聚合
7.苏宁，ES的river做kafka数据的清洗过滤
8.京东，前置应用索引创建策略，做流量均衡
9.网易，为了预估索引和分片
10.携程，做数据的parse，做failover之类的支持，做二进制压缩
11.B站，前置用于区分不同的日志，按照日志定级走不通的topic
12.百度，不知道这个kafka在里面干嘛，好像数据流的作用

采集端：

1.对于INFO级别以下的日志进行随机采样，采样功能放在log agent采集端、采样率通过配置中心下发
2.分布式问题

3.需要支持socket的方式，方便APP的日志上报

4.rsyslog手机Linux的日志

解析端：

1.输出到多个目的地的时候要小心，性能差的输出会阻塞整个通道
2.袋鼠云，logstash：github.com/DTStack/jlo…
3.携程，HangOut：github.com/childe/hang…

kibana权限的事情：

1.携程，github.com/childe/espr…

lucene:

1.将⼀次⻓merge合并操作尽量分散在多次merge合并操作中调整lucenemerge操作相关参数:mergeFactor
2.将⽇志量⼤的应⽤分布到多个lucene 索引中，同时避免不同⼤应⽤分布到相同lucene 索引上:maxMergeSize

index：

1.预估N天数据量的大小，进行按照小时、天或者月创建索引
2.新的索引放在IO性能好的节点上
• 根据数据量合理的规划索引pattern和shard数
• disabled _all 节省存储空间、提升索引速度
• 不需要分词的字段设成 not_analyzed
• 对于不要求100%⾼可⽤的内部系统，可不设置副本，提升index速度和减少存储

shard：

1.根据数据量的大小预估分片的数量
2.运维层面看苏宁

nginx：

1.转发请求

client：

1.分摊master节点的工作
2.处理index和bulk request请求
3.处理查询请求、负责结果汇总

data：

1.data节点全部替换成物理机
2.于实时性要求⾮常⾼的需求，优先SSD

tribe：

1.做多集群路由

------------------------------------
性能相关：

1.小的index没必要创建多个shard，shard_num = max(avg(last 7 days) / 30GB , 2)
ES Output plugin关键参数：
• idle_flush_time # 默认1s，在可以容忍的延迟范围，尽量长
• flush_size # 提升到单worker吞吐量不再提升为止
• Workers # 并非越多越好，一般1到2个足够
index settings: _all.enabled: false
index dynamic_templates : only text for string fields
stale node
• index.codec: best_compression
• 定期对index force_merge
调整FD句柄数，推荐64K
禁用swap交换
ulimit -l unlimited 锁内存
关闭swap交换或锁内存 ulimit -l unlimited/bootstrap.mlockall: true
bootstrap.mlockall: true
不分词的字符串字段设成not_analyzed
index.store.type
Ø mmapfs（默认） -- 适⽤于⼩索引
Ø niofs -- 适⽤于⼤索引、历史索引
◼ 索引刷新间隔 index.refresh_interval 为30s或更大
◼ 事务日志持久化模式 index.translog.durability 为 async
◼ 推迟分片分配 index.unassigned.node_left.delayed_timeout 为 10m
◼ 合并线程数 index.merge.scheduler.max_thread_count 对机械硬盘为1 ◼ 限制节点分片数 index.routing.allocation.total_shards_per_node 一般为1或2 ◼ Mapping
 norms 不需要计算字段的评分，将该参数设为false
 ignore_malformed 忽略这个字段错误并保留该文档中的其他字段，设为ture
 _source 文档原始内容，可以考虑删除
 dynamic_templates 动态模板将默认的字符串类型映射为keyword
 如果不需要按数字大小排序或过来，不使用int类型，使用keyword

• 设置合理的refresh时间
index.refresh_interval: 300S
• 设置合理的flush间隔
index.translog.flush_threshold_size: 4g
index.translog.flush_threshold_ops: 50000
• 合理配置throttling
indices.store.throttle.max_bytes_per_sec: 200mb
• 适当调整bulk队列
threadpool.bulk.queue_size: 1000

• 有时可能因为gc时间过长，导致该数据节点被主节点踢出集群的情况，导致集群出现不健康的
状态，为了解决这样的问题，我们适当的调整ping参数。(master)
discovery.zen.fd.ping_timeout: 40s
discovery.zen.fd.ping_interval: 5s
discovery.zen.fd.ping_retries: 5
• 调整数据节点的JVM新⽣代⼤⼩
数据节点young gc频繁,适当调转新⽣代⼤⼩（-Xmn3g），降低young gc的频率。
• 在进⾏检索和聚合操作时，ES会读取反向索引，并进⾏反向解析，然后进⾏排序，将结果保存
在内存中。这个处理会消耗很多Heap，有必要进⾏限制，不然会很容易出现OOM。
Disabled analyzed field fielddata
限制Field Data的Heap Size的使⽤
indices.fielddata.cache.size: 40%
indices.breaker.fielddata.limit: 50%

-----------------------------------

ES的JVM优化：

调整cms gc开始时间
-XX:CMSInitiatingOccupancyFraction=70
调整jvm heap⽐例
新⽣代:⽼年代 == 1:4
-XX:NewRatio=4
CMS更换为G1
调整值：
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:GCPauseIntervalMillis=1000
-XX:InitiatingHeapOccupancyPercent=35
内存的设置和ES2不通，导致采用的默认内存大小
随着分片数的增多，jvm的使用率偏高，GC的越来越频繁
lucene cache使⽤⽅式调整为filter cache

大量数据拉取正确方法:

◦ Scan & scroll API分批次拉取
◦ 类似数据库cursor
◦ 数据不排序，资源消耗低

JVM：袋鼠云、华泰
数据迁移：华泰