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中出現的複雜檢測和動作留出了足夠的空間。