Elastic Stack 7.7 最新功能体验

Elastic在美国时间5月13号发布了最新的7.7版本。该版本在三个解决方案上均有大幅的更新，比如：
在全观察性解决方案上，推出了大家期盼已久的APM上的service maps功能，借助该功能，我们可以通过服务之间的调用关系来绘制整个服务之间的调用关系拓扑图，并通过这个逻辑拓扑图厘清复杂系统的结构，比如复杂业务系统内部调用关系链，系统与系统之间的关系，系统与中间件、数据库之间的链接关系等。并且，可以在这个关系图上实时监控整个调用链路上的性能情况，协助运维人员及时发现链路上的性能瓶颈点。
而在安全功能方面，Elastic SIEM继续增强，开箱即用的规则由目前的92条增加到130条，同时增加了案件处理器，可以通过track case的方式分析安全事件，并把该案件推送到ServiceNow等常用的IT服务管理软件，将安全事件的最终和管理集成到企业统一的IT事件管理平台上。
在搜索方面，Elastic推出了Enterprise Search，将原先分开的App search和Workplace search两个软件合并一个安装包中，并且Workplace search正式由Beta版本进化到GA版本。
同时，还有一些跨解决方案的功能，比如Kibana上的Alert功能，它不同于构建在ES上的Watcher API，它是由Kibana提供的告警功能，集成在APM，Metric, Uptime, SIEM等App上，在我们分析数据的上下文位置进行告警设置。相对于Watcher来说，Alert提供了更加简单易用的操作，同时更好的和Kibana上的App进行了集成，在basic license的基础上也能使用基本功能，于Watcher交相辉映，相得益彰。

在这篇文章里面，我们将指导大家使用docker容器环境，快速拉起一个Elastic Stack 7.7版本的集群，带大家体验部分令人心动的新功能。

集群搭建

这里，默认大家有能力构建一套Docker环境，我们在Docker环境上，通过以下docker-compose.xml文件来拉起Elastic Stack 7.7的集群:

version: '2.2'

services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es02,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.license.self_generated.type=trial
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=$CERTS_DIR/es01/es01.key
      - xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.http.ssl.certificate=$CERTS_DIR/es01/es01.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.transport.ssl.certificate=$CERTS_DIR/es01/es01.crt
      - xpack.security.transport.ssl.key=$CERTS_DIR/es01/es01.key
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data01:/usr/share/elasticsearch/data
      - ./certs:$CERTS_DIR
    ports:
      - 9200:9200
    networks:
      - elastic

    healthcheck:
      test: curl --cacert $CERTS_DIR/ca/ca.crt -s https://localhost:9200 >/dev/null; if [[ $$? == 52 ]]; then echo 0; else echo 1; fi
      interval: 30s
      timeout: 10s
      retries: 5

  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.license.self_generated.type=trial
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=$CERTS_DIR/es02/es02.key
      - xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.http.ssl.certificate=$CERTS_DIR/es02/es02.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.transport.ssl.certificate=$CERTS_DIR/es02/es02.crt
      - xpack.security.transport.ssl.key=$CERTS_DIR/es02/es02.key
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data02:/usr/share/elasticsearch/data
      - ./certs:$CERTS_DIR
    networks:
      - elastic

  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:${VERSION}
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.license.self_generated.type=trial
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=$CERTS_DIR/es03/es03.key
      - xpack.security.http.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.http.ssl.certificate=$CERTS_DIR/es03/es03.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.security.transport.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.security.transport.ssl.certificate=$CERTS_DIR/es03/es03.crt
      - xpack.security.transport.ssl.key=$CERTS_DIR/es03/es03.key
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data03:/usr/share/elasticsearch/data
      - ./certs:$CERTS_DIR
    networks:
      - elastic
  kib01:
    image: docker.elastic.co/kibana/kibana:${VERSION}
    container_name: kib01
    # depends_on: {"es01": {"condition": "service_healthy"}}
    ports:
      - 5601:5601
    environment:
      SERVERNAME: localhost
      ELASTICSEARCH_URL: https://es01:9200
      ELASTICSEARCH_HOSTS: https://es01:9200
      ELASTICSEARCH_USERNAME: kibana
      ELASTICSEARCH_PASSWORD: xxxxxx
      ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES: $CERTS_DIR/ca/ca.crt
      SERVER_SSL_ENABLED: "true"
      SERVER_SSL_KEY: $CERTS_DIR/kib01/kib01.key
      SERVER_SSL_CERTIFICATE: $CERTS_DIR/kib01/kib01.crt
      XPACK_ENCRYPTEDSAVEDOBJECTS_ENCRYPTIONKEY: fhjskloppd678ehkdfdlliverpoolfcr
    volumes:
      - ./certs:$CERTS_DIR
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
  certs:
    driver: local

networks:
  elastic:
    driver: bridge

为了始终强调数据安全的重要性，即便是演示，我们还是在集群里面把基本的安全功能全部打开，包括登录权限控制和节点通信加密。
具体的认证文件的生成步骤可以查看TLS配置文档。
这时，你应该在某个目录下具有以下文件:

注意：可能你需要执行以下命令，去更好内置的用户名和密码

docker exec -it es01 sh
sh-4.2$ cd /usr/share/elasticsearch 
sh-4.2$ bin/elasticsearch-setup-passwords interactive  --url https://es01:9200

然后，我们在当前目录下，运行我们的docker-compose.xml:

docker-compose up

等容器里的集群初始化完毕，即可通过https访问kibana:

准备演示数据

我们提到过，7.7版本上有众多新的功能，其中就包括我们的APM。我们使用Elastic公司在github上的项目apm-integration-testing，来生成对应的APM数据。我们使用这个项目的理由是：

• 上面准备了多个开发语言的测试agent。我们可以通过这些不同开发语言的Agent来查看Elastic APM agent的功能
• 整个测试环境包含了用于demo的前端，后端，数据库的实例，我们可以检测分布式追踪和service maps的功能
• 该项目支持Elastic各个版本的agent和Elastic Stack，方便我们进行有针对性的检测

大家可以查看apm-integration-testing项目的README.md和QUICK_START.md文件来了解如何运行这个集成测试。

以下是该项目支持的命令示例：

Persona	Flags	Motivation / Use Case	Team	Comments
CI Server	python scripts/compose.py start 8.0.0 --java-agent-version ${COMMIT_SHA} --build-parallel --with-agent-java-spring --no-apm-server-dashboards --no-apm-server-self-instrument --no-kibana --force-build	Prepare environment for running tests for APM Java agent	APM Agents
CI Server	python scripts/compose.py start 8.0.0 --apm-server-build https://github.com/elastic/apm-server@${COMMIT_HASH} --build-parallel --no-apm-server-dashboards --no-apm-server-self-instrument --with-agent-rumjs --with-agent-dotnet --with-agent-go-net-http --with-agent-nodejs-express --with-agent-ruby-rails --with-agent-java-spring --with-agent-python-django --with-agent-python-flask --force-build	Prepare environment for running tests for APM Server	APM Server
Demos & Screenshots	./scripts/compose.py start --release --with-opbeans-dotnet --with-opbeans-go --with-opbeans-java --opbeans-java-agent-branch=pr/588/head --force-build --with-opbeans-node --with-opbeans-python --with-opbeans-ruby --with-opbeans-rum --with-filebeat --with-metricbeat 7.3.0	demos, screenshots, ad hoc QA. It’s also used to send heartbeat data to the cluster for Uptime	PMM	Used for snapshots when close to a release, without the --release flag
Development	./scripts/compose.py start 7.3 --bc --with-opbeans-python --opbeans-python-agent-local-repo=~/elastic/apm-agent-python	Use current state of local agent repo with opbeans	APM Agents	This works perfectly for Python, but has problems with Node.js. We are not mounting the local folder as a volume, but copy it. This is to avoid any side effects to the local repo. The node local dev folder can get very large due to node_modules, which takes some time to copy.
	./scripts/compose.py start 7.3 --bc --start-opbeans-deps	This flag would start all opbeans dependencies (postgres, redis, apm-server, …), but not any opbeans instances	APM Agents	This would help when developing with a locally running opbeans. Currently, we start the environment with a --with-opbeans-python flag, then stop the opbeans-python container manually
Developer	./scripts/compose.py start master --no-apm-server	Only use Kibana + ES in desired version for testing	APM Server
Developer	./scripts/compose.py start --release 7.3 --no-apm-server	Use released Kibana + ES, with custom agent and server running on host, for developing new features that span agent and server.	APM Agents	If --opbeans-go-agent-local-repo worked, we might be inclined to use that instead of running custom apps on the host. Would have been handy while developing support for breakdown graphs. Even then, it’s probably still faster to iterate on the agent without involving Docker.
Developer	./scripts/compose.py start master --no-kibana	Use newest ES/master, with custom kibana on host, for developing new features in kibana	APM
Developer	./scripts/compose.py start 6.3 --with-kafka --with-zookeeper --apm-server-output=kafka --with-logstash --with-agent-python-flask	Testing with kafka and logstash ingestion methods	APM
Developer	./scripts/compose.py start master --no-kibana --with-opbeans-node --with-opbeans-rum --with-opbeans-x	Developing UI features locally	APM UI
Developer	./scripts/compose.py start master --docker-compose-path - --skip-download --no-kibana --with-opbeans-ruby --opbeans-ruby-agent-branch=master > docker-compose.yml	Developing UI features againt specific configuration	APM UI	We sometimes explicity write a docker-compose.yml file and tinker with it until we get the desired configuration becore running docker-compose up
Developer	scripts/compose.py start ${version}	Manual testing of agent features	APM Agents
Developer	./scripts/compose.py start master --with-opbeans-java --opbeans-java-agent-branch=pr/588/head --apm-server-build https://github.com/elastic/apm-server.git@master	Test with in-progress agent/server features	APM UI
Developer	compose.py start 7.0 --release --apm-server-version=6.8.0	Upgrade/mixed version testing	APM	Then, without losing es data, upgrade/downgrade various components

我们可以选择在这个docker compose里面是否运行：

• 各种语言的apm agent
• kibana, elasticsearch, logstash, beats
• kafka
• 以上组件的版本

这算是一个比较强大的脚本了，可以接收非常多的参数。我们注意到，这里面也是可以运行整个elastic stack的，我们可以直接在这里指定Elastic stack的版本为7.7，直接在这个集成工具上尝新。 但不方便的是，要配置参数却不是这么简单。

因此，如果我们在第一节的基础上搭建了集群，又想使用这个apm-integration-testing项目，需要把两个不同docker-comose.xml创建的容器群连接起来。
可以修改第一节的network参数为：

networks:
  apm-integration-testing:
    external:
      name: apm-integration-testing

同时，需要把容器es01的名字改为elasticsearch。[因为apm server, 各种beats直接以容器名作为dns来访问elasticsearch]

另一个需要注意的是，这个项目中不同的APM agent是需要编译的，因此可能会涉及到在dockhub上拉取组件，一次，我们需要在docker环境上配置代理，才能完成编译：

我这里通过命令：

./scripts/compose.py start --release --with-filebeat --with-metricbeat --with-opbeans-go --with-opbeans-python --with-opbeans-node --with-opbeans-rum --with-opbeans-java --no-elasticsearch --no-kibana --remove-orphans  8.0.0-SNAPSHOT

运行了最新8.0.0分支上的各种agent，以及filebeat和metricbeat，并且不启动es和kibana。有以下容器被创建：

Pulling apm-server             ... done
Pulling filebeat               ... done
Pulling metricbeat             ... done
Pulling postgres               ... done
Pulling redis                  ... done
Pulling opbeans-load-generator ... done
Creating localtesting_8.0.0-SNAPSHOT_filebeat   ... done
Creating localtesting_8.0.0-SNAPSHOT_metricbeat ... done
Creating localtesting_8.0.0-SNAPSHOT_redis      ... done
Creating localtesting_8.0.0-SNAPSHOT_apm-server ... done
Creating localtesting_8.0.0-SNAPSHOT_postgres   ... done
Recreating localtesting_8.0.0-SNAPSHOT_opbeans-go ... done
Recreating localtesting_latest_opbeans-node       ... done
Recreating localtesting_latest_opbeans-python     ... done
Recreating localtesting_latest_opbeans-java       ... done
Recreating localtesting_8.0.0-SNAPSHOT_opbeans-rum ... done
Recreating localtesting_8.0.0-SNAPSHOT_opbeans-load-generator ... done

数据会通过容器别名elasticsearch，发送到elasticsearch:9200。
如果我们运行命令：compose.py status
可以看到这个demo环境上还有

lexlideMacBook-Pro:apm-integration-testing lex.li$ ./scripts/compose.py status
Status for all services:

                  Name                                 Command                  State                                                         Ports                                                   
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
localtesting_7.7.0_apm-server               /usr/local/bin/docker-entr ...   Up (healthy)   127.0.0.1:14250->14250/tcp, 127.0.0.1:14268->14268/tcp, 127.0.0.1:6060->6060/tcp, 127.0.0.1:8200->8200/tcp
localtesting_7.7.0_filebeat                 /usr/local/bin/docker-entr ...   Up                                                                                                                       
localtesting_7.7.0_metricbeat               /usr/local/bin/docker-entr ...   Up                                                                                                                       
localtesting_7.7.0_opbeans-go               /opbeans-go -log-json -log ...   Up (healthy)   127.0.0.1:3003->3000/tcp                                                                                  
localtesting_7.7.0_opbeans-load-generator   /app/entrypoint.sh honcho  ...   Up                                                                                                                       
localtesting_7.7.0_opbeans-rum              dumb-init -- node_modules/ ...   Up (healthy)   127.0.0.1:9222->9222/tcp                                                                                  
localtesting_7.7.0_postgres                 docker-entrypoint.sh postgres    Up (healthy)   0.0.0.0:5432->5432/tcp                                                                                    
localtesting_7.7.0_redis                    docker-entrypoint.sh --save      Up (healthy)   0.0.0.0:6379->6379/tcp                                                                                    
localtesting_latest_opbeans-java            /bin/bash /app/entrypoint. ...   Up (healthy)   127.0.0.1:3002->3000/tcp                                                                                  
localtesting_latest_opbeans-node            /app/entrypoint.sh pm2-run ...   Up (healthy)   127.0.0.1:3000->3000/tcp                                                                                  
localtesting_latest_opbeans-python          /bin/bash /app/entrypoint. ...   Up (healthy)   127.0.0.1:8000->3000/tcp                                                                                  
lexlideMacBook-Pro:apm-integration-testing lex.li$ 

访问http://localhost:3003，可以看到模拟的这个环境：

体验service map

在以上的例子中，我启动了go、node、python、java、nodejs前端的用例，并且在背后有postgres和redis。所有的数据通过apm server汇总到elasticsearch，我们可以在7.7版本的kibana上查看这些服务：

通过service map, 可以查看服务的逻辑拓扑：

这里可以说明的是，我对通过命令：

./scripts/compose.py start --release --with-filebeat --with-metricbeat --with-opbeans-go --with-opbeans-python --with-opbeans-node --with-opbeans-rum --with-opbeans-java --no-elasticsearch --no-kibana --remove-orphans  8.0.0-SNAPSHOT

创建的几个容器服务是一无所知的，我只知道有一个前端的界面，可以看到一些商品和定单，但页面背后运行了哪些程序，他们互相的调用关系，在看到这个图之前，我无法得知。
这个service map通过使用实时transction数据来构建服务依赖关系映射的聚合视图，可以自动创建service map。而且由于这些地图是根据实时数据动态创建的，因此它们可以作为系统依赖关系的实时视图，从而加快了故障排除问题的速度，尤其是在当今的分布式和临时性的云原生环境中。 我们在以下例子中可见一斑：

这里，我们关闭Python服务：

我们可以把时间切换到最近1分钟，可以看到Python服务就从service map“消失了”：

它变成了一个没有被监控到下游业务。从上游业务的APM Error信息，我们也可以看到这个Python业务无法访问。

service map同时还补充了Elastic APM中的分布式跟踪功能。分布式跟踪提供了针对特定事务的单个服务调用的瀑布视图，而service map提供了服务之间如何通信的更聚合视图，并且我们可以轻松地从service map跳转到特定服务的详细信息，并跳转回来，这是其调查工作流程的一部分。

APM Agent central config

通过YAML文件管理代理配置绝非易事。YAML文件中的一个小错误（是制表符还是空格？）会导致大量时间花费在调试文件上。在7.7版本中，在Kibana中的APM应用程序中加入了配置大多数代理配置属性的功能。这个Agent central config功能可以轻松编辑代理的配置，而不必处理单个代理的配置文件。使用反馈指示器，您还可以快速确定您的更改是否已应用于所选服务。

比如，我修改了Java Agent的一些参数：

体验新的Log categorization

Log categorization可通过将日志数量减少到少数代表性类别（将异常显示在顶部）来减少分析日志所需的人力。7.7中，这个日志分类功能得到了增强，为每个类别包括示例日志行，使您可以像检查其他任何日志行一样对其进行检查，同时允许您更深入地研究机器学习UI以进行进一步的研究。

我们可以直接用几个demo agent的日志作为示例：

可以看到，在没做任何日志的解析工作（没有logstash介入，没有提取字段）的情况下：

机器学习功能仍然能够发现各种模式，并且通过提供示例日志让我们更轻松的理解日志

体验全新的alert框架

这个alert和我们之前的指导的watcher是两个东西。alert构建在kibana上，需要多个Kibana来保证高可用 (2019年1月，kibana在6.7版本中添加了任务管理器。这为Kibana提供了具有永久任务的后台调度，这些任务可以分布在多个Kibana实例中，以实现可伸缩性和可用性。诸如任务管理器之类的警报基础层组件不仅可以提供警报功能，还可以提供更多功能。例如，任务管理器可以在Kibana中提供更好的计划报告体验。)，它现在只支持threshold的方式来设置阀值告警，也不支持painless script等复杂的条件查询，以及chain watcher等级联条件。但alert是对watcher API的一个很好补充，它简单易用，最重要的是它集成在Kibana的各个应用当中，方便我们在任何的调查/分析的上下文中，随手就可设置告警，比如：

在alerts管理页面配置

在 metric页面配置：

在uptime页面配置：

在APM页面配置：

同时，将检测到的错误集成到历史数据中，并在图表上标注：
当然，这个功能目前还只是一个beta版本，但如果我们查看一下alert功能的愿景，你就知道，这个feature又绝不仅仅是对对watcher API的补充，alerting框架的最终目标是满足我们在Elastic stack中发出警报的愿景的系统：

• 到处警报：警报是Kibana中一流的空间感知实体。这使得可以在组之间细分警报的创建和查看，并允许将警报与SIEM，Monitoring和Uptime等产品进行丰富的集成。警报是补充功能，可以与Watcher一起使用，但不能代替它。
• 警报意义：丰富的警报集成将与Kibana UI一起提供，该UI提供了警报类型的全面视图，以及用于关联和理解警报历史的工具。
• 检测和动作：API和插件经过精心设计，因此只要可以在Kibana服务器上运行的JavaScript中能够支持的检测或动作机制，它都能做到。这为通过SIEM或我们的可观察性解决方案之类的产品在Kibana中出现的复杂检测和动作留出了足够的空间。