ELK

收到工单 用户提工单到L2说写入消息堆积了，第一时间检查ElasticSearch这边的日志和监控，把一百多个节点的日志都遍历看了一遍，并没有看到任何异常的关键字，再把 Grafana 监控看了一个遍，也没有任何明显异常的指标，只有少数几个data节点超出85%水位，没法办法只能从写入端的日志去着手了，刚开始就看到每分钟内多次的 http 429报错，还有就是socket timeout的报错，从下午排查到晚上，实在ElasticSearch这边没有任何异常，客户那边也上会了，问了下，你们这个重试是怎样的？说等待十秒重试一次吧，另外客户是通过Bulk API来批量发送请求的，但是每次Bulk发送的大小不固定，小于2000直接发送，大于2000截断发送（这个肯定是不合理的，后面再讲），这个等待重试，加入ElasticSearch因为写入请求太多导致阻塞，那么简单的等待重试，肯定是解决不了任何问题的，当天就推荐用户修改为退避式重试，修改完后的写入端日志里，不再有429的报错了，但是还有会有socket timeout的报错，结合之前注意到的，猜想是请求发送的次数太多了，然而单个Bulk的数据量很明显不到推荐值，没有被充分利用，官方推荐的Bulk大小是5-15MB，然而目前的情况是，几十条甚至一两条的写入请求也会被直接发送出去。推荐用户修改Bulk单次提交数据量后，仍然没有任何缓解的效果，消息队列消费不完，还是经常性出现堆积。data节点的配置是16C64G，检查了写入线程数也就是默认是16，这个没法改，最大也就改到17，写入线程队列是6.X ElasticSearch的默认值200，这个改大也不能解决消费慢的问题，只能让更多的线程在排队。其他方面，不同索引的刷新配置refresh_interval设置的30-60s，这个也是一个合理的值，其他的translog落盘配置，检查过也都是默认值。唯一一处疑点就是mapp...

Elasticsearch Service 提供了多种官方的熔断器（circuit breaker），用于防止内存使用过高导致 ES 集群因为 OutOfMemoryError 而出现问题。Elasticsearch 设置有各种类型的子熔断器，负责特定请求处理的内存限制。此外，还有一个父熔断器，用于限制所有子熔断器上使用的内存总量。 Circuit breaker settings 断路器设置 Elasticsearch contains multiple circuit breakers used to prevent operations from causing an OutOfMemoryError. Each breaker specifies a limit for how much memory it can use. Additionally, there is a parent-level breaker that specifies the total amount of memory that can be used across all breakers. Elasticsearch 包含多个断路器，用于防止操作导致 OutOfMemoryError。每个断路器都指定了其可以使用的内存量的限制。此外，还有一个父级断路器，用于指定可在所有断路器中使用的内存总量。 Except where noted otherwise, these settings can be dynamically updated on a live cluster with the cluster-update-settings API. 除非另有说明，否则可以使用 cluster-update-settings API 在实时集群上动态更新这些设置。 For information about circuit breaker errors, see Circuit breaker errors. 有关断路器错误的信息，请参阅断路器错误。 下面提到的静态和动态的意思是，这个配置参数的属性 动态设置（Dynamic Settings）： 可以使用集群更新设置API在运行中的集群上进行配置和更新。 在未启动或已关闭的节点上，也可以通过elasticsearch.yml文件进行本地配置。 静态设置（Static Settings）： 只能在未启动或已关闭的节点上通过elasticsearch.yml文件进行配置。 必须在集群中的每个相关节点上进行设置。 主要用于配置静态的集群设置和节点设置。 静态设置的配置只在节点启动时生效，不会受到集群运行时的影响。 Parent circuit breaker父断路器 The parent-level breaker can be configured with the following settings: 可以使用以下设置配置父级断路器： indices.breaker.total.use_real_memory (Static) Determines whether the parent breaker should take real memory usage into account (true) or only consider the amount that is reserved by child circuit breakers (false). Defaults to true. （静态）确定父断路器是应考虑实际内存使用情况 （true） 还是仅考虑子断路器保留的内存量 （false）。默认值为 true。 indices.breaker.total.limit (Dynamic) Starting limit for overall parent breaker. Defaults to 70% of JVM heap if indices.breaker.total.use_real_memory is false. If indices.breaker.total.use_real_memory is true, defaults to 95% of the JVM heap. （动态）整体母断路器的起始限制。如果 JVM 为 false，则默认为 JVM 堆的 70%indices.brea...

Elasticsearch 的团队致力于不断改进 Elasticsearch 和 Apache Lucene，以保护您的数据。与任何分布式系统一样，Elasticsearch 非常复杂，每个部分都可能遇到需要正确处理的边缘情况。我们将讨论在面对硬件和软件故障时，为改进 Elasticsearch 在健壮性和弹性方面所做的持续努力。 提升ElasticSearch的弹性：https://www.elastic.co/cn/videos/improving-elasticsearch-resiliency ElasticSearch和弹性：https://www.elastic.co/cn/elasticon/conf/2016/sf/elasticsearch-and-resiliency 参考资料：https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html 本文不是ElasticSearch的Release docs，只关注与ElasticSearch在弹性/稳定性方面的进展。 V5.0.0 使用两阶段提交进行集群状态发布 Elasticsearch中的主节点会持续监控集群节点，并在某个节点无法及时响应其PING请求时将其从集群中移除。如果主节点剩下的节点过少，它将主动放弃主节点的角色，然后开始新的主节点选举过程。当网络分区导致主节点失去许多从节点时,在检测到节点丢失并且主节点下行之前，有一个很短的时间窗口。在这个时间窗口内,主节点可能会错误地接受和确认集群状态变更。为了避免这种情况,我们在集群状态发布中引入了一个新的阶段,其中提议的集群状态会发送给所有节点,但尚未提交。只有在足够多的节点主动确认更改后,更改才会被提交,并向节点发送提交消息#13062。A master node in Elasticsearch continuously monitors the cluster nodes and removes any node from the cluster that doesn’t respond to its pings in a timely fashion. If the master is left with too few nodes, it will step down and a new master election will start.When a network partition causes a master node to lose many followers, there is a short window in time until the node loss is detected...

材料准备 如题，使用Docker Compose 运行Elastic Stack 8.X，五个月前还在前司做7.9版本的ELK迁移，如今已经是前司了，当时总共不到20TB，最近问前同事数据量已经到40TB了，而且根据她发我的截图来看，三千多个索引，副本分片却只有两千多，不操心了，事不关己高高挂起，反正现在负责ELK的是新来的陌生人。今天看已经发到8.10版本了，来装一个感受下新特性。 官方Docker Compose 官方安装指引文档 额外操作参考博客 version: "2.2" services: setup: image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION} volumes: - certs:/usr/share/elasticsearch/config/certs user: "0" command: > bash -c ' if [ x${ELASTIC_PASSWORD} == x ]; then echo "Set the ELASTIC_PASSWORD environment variable in the .env file"; exit 1; elif [ x${KIBANA_PASSWORD} == x ]; then echo "Set the KIBANA_PASSWORD environment variable in the .env file"; exit 1; fi; if [ ! -f config/certs/ca.zip ]; then echo "Creating CA"; bin/elasticsearch-certutil ca --silent --pem -out config/certs/ca.zip; unzip config/certs/ca.zip -d config/certs; fi; if [ ! -f config/certs/certs.zip ]; then echo "Creating certs"; echo -ne \ "instances:\n"\ " - name: es01\n"\ " dns:\n"\ " - es01\n"\ " - localhost\n"\ " ip:\n"\ " - 127.0.0.1\n"\ " - name: es02\n"\ " dns:\n"\ " - es02\n"\ " - localhost\n"\ " ip:\n"\ " - 127.0.0.1\n"\ " - name: es03\n"\ " dns:\n"\ " - es03\n"\ " - localhost\n"\ " ip:\n"\ " - 127.0.0.1\n"\ > config/certs/instances.yml; bin/elasticsearch-certutil cert --silent --pem -out config/certs/certs.zip --in config/certs/instances.yml --ca-cert config/certs/ca/ca.crt --ca-key config/certs/ca/ca.key; unzip config/certs/certs.zip -d config/certs; fi; echo "Setting file permissions" chown -R root:root config/certs; find . -type d -exec chmod 750 \{\} \;; find . -type f -exec chmod 640 \{\} \;; echo "Waiting for Elasticsearch availability"; until curl -s --cacert config/certs/ca/ca.crt https://es01:9200 | grep -q "missing authentication credentials"; do sleep 30; done; echo "Setting kibana_system password"; until curl -s -X POST --cacert config/certs/ca/ca.crt -u "elastic:${ELASTIC_PASSWORD}" -H "Content-Type: application/json" https://es01:9200/_security/user/kibana_system/_password -d "{\"password\":\"${KIBANA_PASSWORD}\"}" | grep -q "^{}"; do sleep 10; done; echo "All done!"; ' healthcheck: test: ["CMD-SHELL", "[ -f config/certs/es01/es01.crt ]"] interval: 1s timeout: 5s retries: 120 es01: depends_on: setup: condition: service_healthy image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION} volumes: - certs:/usr/share/elasticsearch/config/certs - esdata01:/usr/share/elasticsearch/data ports: - ${ES_PORT}:9200 environment: - node.name=es01 - cluster.name=${CLUSTER_NAME} - cluster.initial_master_nodes=es01,es02,es03 - discovery.seed_hosts=es02,es03 - ELASTIC_PASSWORD=${ELASTIC_PASSWORD} - bootstrap.memory_lock=true - xpack.security.enabled=true - xpack.security.http.ssl.enabled=true - xpack.security.http.ssl.key=certs/es01/es01.key - xpack.security.http.ssl.certificate=certs/es01/es01.crt - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.enabled=true - xpack.security.transport.ssl.key=certs/es01/es01.key - xpack.security.transport.ssl.certificate=certs/es01/es01.crt - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.verification_mode=certificate - xpack.license.self_generated.type=${LICENSE} mem_limit: ${MEM_LIMIT} ulimits: memlock: soft: -1 hard: -1 healthcheck: test: [ "CMD-SHELL", "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'", ] interval: 10s timeout: 10s retries: 120 es02: depends_on: - es01 image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION} volumes: - certs:/usr/share/elasticsearch/config/certs - esdata02:/usr/share/elasticsearch/data environment: - node.name=es02 - cluster.name=${CLUSTER_NAME} - cluster.initial_master_nodes=es01,es02,es03 - discovery.seed_hosts=es01,es03 - bootstrap.memory_lock=true - xpack.security.enabled=true - xpack.security.http.ssl.enabled=true - xpack.security.http.ssl.key=certs/es02/es02.key - xpack.security.http.ssl.certificate=certs/es02/es02.crt - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.enabled=true - xpack.security.transport.ssl.key=certs/es02/es02.key - xpack.security.transport.ssl.certificate=certs/es02/es02.crt - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.verification_mode=certificate - xpack.license.self_generated.type=${LICENSE} mem_limit: ${MEM_LIMIT} ulimits: memlock: soft: -1 hard: -1 healthcheck: test: [ "CMD-SHELL", "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'", ] interval: 10s timeout: 10s retries: 120 es03: depends_on: - es02 image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION} volumes: - certs:/usr/share/elasticsearch/config/certs - esdata03:/usr/share/elasticsearch/data environment: - node.name=es03 - cluster.name=${CLUSTER_NAME} - cluster.initial_master_nodes=es01,es02,es03 - discovery.seed_hosts=es01,es02 - bootstrap.memory_lock=true - xpack.security.enabled=true - xpack.security.http.ssl.enabled=true - xpack.security.http.ssl.key=certs/es03/es03.key - xpack.security.http.ssl.certificate=certs/es03/es03.crt - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.enabled=true - xpack.security.transport.ssl.key=certs/es03/es03.key - xpack.security.transport.ssl.certificate=certs/es03/es03.crt - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt - xpack.security.transport.ssl.verification_mode=certificate - xpack.license.self_generated.type=${LICENSE} mem_limit: ${MEM_LIMIT} ulimits: memlock: soft: -1 hard: -1 healthcheck: test: [ "CMD-SHELL", "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'", ] interval: 10s timeout: 10s retries: 120 kibana: depends_on: es01: condition: service_healthy es02: condition: service_healthy es03: condition: service_healthy image: docker.elastic.co/kibana/kibana:${STACK_VERSION} volumes: - certs:/usr/share/kibana/config/certs - kibanadata:/usr/share/kibana/data ports: - ${KIBANA_PORT}:5601 environment: - SERVERNAME=kibana - ELASTICSEARCH_HOSTS=https://es01:9200 - ELASTICSEARCH_USERNAME=kibana_system - ELASTICSEARCH_PASSWORD=${KIBANA_PASSWORD} - ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES=config/certs/ca/ca.crt mem_limit: ${MEM_LIMIT} healthcheck: test: [ "CMD-SHELL", "curl -s -I http://localhost:5601 | grep -q 'HTTP/1.1 302 Found'", ] interval: 10s timeout: 10s retries: 120 volumes: certs: driver: local esdata01: driver: local esdata02: driver: local esdata03: driver: local kibanadata: driver: local 步骤分析 来欣赏下官方文档里面都干了些啥吧 创建了一个卷用来存储各种证书 判断ElasticSear...

今天中午散步回来，美女同事跟我说，最近的日志没有进来，我登上kibana一看，我靠，近两天的日志全没有（部分索引有，部分索引量变少了，部分索引完全没有新日志进来）。怎么办，看日志呗，毕竟咱不能像美女同事一样把这个情况告诉别人然后摆烂吧，本文记录处理的全流程。 ...

elasticsearch-dump、logstash、reindex、snapshot方式进行数据迁移，实际上这几种工具大体上可以分为以下几类： scroll query + bulk:批量读取旧集群的数据然后再批量写入新集群，elasticsearch-dump、logstash、reindex都是采用这种方 snapshot:直接把旧集群的底层的文件进行备份，在新的集群中恢复出来，相比较scroll query + bulk的方式，snapshot的方式迁移速度最快。 从源 ES 集群通过备份api创建数据快照，然后在目标 ES 集群中进行恢复，无网络互通要求、迁移速度快、运维配置简单、适用于数据量大，接受离线数据迁移的场景,Snapshot and restore 模块允许创建单个索引或者整个集群的快照到远程仓库。所以首先需要创建一个存储快照的地方，存储方案可以选择一个NFS的共享存储，或者对象存储。 ...

搭建了一套新环境，为了测试kibana配置ldap，并且对es中超大的索引进行导出存档。 在搭建的过程中发现，kiban连接es失败，网上查找资料后发现解决方案，发现只要删除.security-7这个索引就能够清除之前设置的密码，重新设置。.security-7索引中应该包含了用户登录等一些信息。利用curl命令执行删除索引的操作时，删除了另外一个测试环境的该索引，删除后，一切认证相关的功能全都失效，kibana无法登录，查找资料进行恢复。 ...

最近工作中遇到的一个问题，网络组把网络设备的“陈年”老日志传到ELK，这样的问题就是日志的时间是过去的，但是logstash在生成时间戳然后输入到es时，默认的是当前的时间戳。于是需求就是将日志中的时间代替它生成的时间戳，开搞! ...

容器时代越来越多的传统应用将会逐渐容器化，而日志又是应用的一个关键环节，那么在应用容器化过程中，如何方便快捷高效地来自动发现和采集应用的日志，如何与日志存储系统协同来高效存储和搜索应用日志。本文将主要跟大家分享下如何通过Log-Pilot来采集容器的标准输出日志和容器内文件日志。 ...

之前已经有elastalert的安装配置文档了，虽然经过了测试但是发现部分内置命令无法正常运行，并且不支持新版本kibana，代码仓库长时间没有更新，于是换用新版本的elastalert2. ...