Read about the updates and bug fixes that have been included in this release.

illustrations-rocket-white-720x420.png

Elastic Stack 7.17.17 released

In this blog post, we'll give an overview of the Elastic data stream naming scheme and how it works.

blog-banner-time-series.png

blog-thumb-time-series.png

An introduction to the Elastic data stream naming scheme

<p>For the Elastic Stack 7.0 release, ingestion (namely Beats) went through a big change by adopting the <a href="https://www.elastic.co/blog/introducing-the-elastic-common-schema">Elastic Common Schema</a> (ECS). One of the reasons for this is to make the correlation of events from logs, metrics and traces easier. This helps to make systems more “observable”. If you want to learn all about observability, check out the blog post “<a href="https://www.elastic.co/blog/observability-with-the-elastic-stack">Observability with the Elastic Stack</a>”.
</p><p>In this blog post I want to cover how the Elastic Common Schema changed the data we ingest, how it makes it possible to better correlate data, how it affects our <a href="https://www.elastic.co/guide/en/infrastructure/guide/7.0/infrastructure-ui-overview.html">Infrastructure</a>, <a href="https://www.elastic.co/guide/en/infrastructure/guide/7.0/logs-ui-overview.html">Logs</a>, <a href="https://www.elastic.co/guide/en/kibana/7.0/apm-ui.html">APM</a> and <a href="https://www.elastic.co/guide/en/kibana/7.0/xpack-uptime.html">Uptime</a> UIs, and how it will help you to make your system more observable.
</p><h2>Have a problem? Let’s start with the&nbsp;host...</h2><p>When investigating an issue, one of the first questions often asked is: Which host / machine is affected? As soon as the host on which an issue happens is known, it should be simple to get all the data about this host. This data could be:
</p><ul>
	<li>Logs from the system, like the auth and system logs</li>
	<li>Metrics like CPU, memory, and disk</li>
	<li>Logs from the services running on the host</li>
	<li>Metrics from the services running on the host</li>
	<li>APM data from the services running on the host</li>
	<li>Heartbeat data pinging the host</li>
	<li>...</li>
</ul><p>Before ECS it was not as simple as querying all the available data on a single field to get all events related to the host. For the hostname, there was <code>beat.hostname</code>, <code>host.name</code> and <code>hostname</code>, depending on which shipper was sending the data. The meaning of these could also have been different, sometimes containing what the&nbsp;<code>hostname</code> command returns or the fully qualified hostname depending on the use case. In addition to that there are also the fields defined by our users which might contain the host data based on their definition. There was no common schema that we could share with our users and recommend them to use.
</p><p>Hostname wasn’t the only field that had this kind of problem, as many other fields like IP addresses or information about&nbsp;services did too. To solve this problem we decided to introduce ECS to not only have a standard that is used internally, but can also be adopted by our users.
</p><p>As an example, with ECS we now have <code>host.name</code> and <code>source.ip</code>. Every data point ingested into these fields now has the same meaning. With the release of Elastic Stack 7.0, all shippers — &nbsp;all <a href="https://www.elastic.co/beats/">Beats</a> and all <a href="https://www.elastic.co/guide/en/apm/agent/index.html">APM agents</a> — have moved to ECS. This means that all events, whether they be logs, metrics, or APM traces shipped from a host, or Heartbeat data about the uptime of host or service, they will contain the field and have it populated with the same meaning. This allows you to easily jump from logs to metrics to APM traces and compare the data.
</p><p>ECS also allows to answer other questions. For example, all information about MySQL services can be retrieved by running a query <code>service.type: mysql</code>. Combine this with a query on the host fields, and all information about a MySQL instance on a single host is available.
</p><h3>Field changes&nbsp;on the ingest side</h3><p>ECS not only defines the <code>host.*</code> fields to store information about a host, it also contains <a href="https://www.elastic.co/guide/en/ecs/1.0/ecs-field-reference.html">many other fields</a> which are important to filter and group on. An example is the service fields like <code>service.type</code> which stores which service the event data was pulled. Or in the case of web server logs like Apache or Nginx, <code>source.*</code> fields like <code>source.ip</code> can be used to identify the source of an event. This had implications on a large portion of fields shipped by Beats.
</p><p>Not only were the generic meta information that each Beat ships adapted to ECS, but also all the <a href="https://www.elastic.co/guide/en/beats/filebeat/7.0/filebeat-modules-overview.html">Filebeat</a>, <a href="https://www.elastic.co/guide/en/beats/metricbeat/7.0/metricbeat-modules.html">Metricbeat</a> and <a href="https://www.elastic.co/guide/en/beats/auditbeat/7.0/auditbeat-overview.html">Auditbeat</a> modules. This has the effect, especially on the logging side, that the number of different fields was heavily reduced. Access logs shipped by an Apache or Nginx server are now ingested in almost the same format. If you use both services in your infrastructure, you can now correlated the data and build a single <a href="https://www.elastic.co/guide/en/kibana/7.0/ml-jobs.html">machine learning job</a> on top of it.
</p><p>As many fields changed, if you built your own dashboards on top of the old field structure in 6.x, check out this <a href="https://www.elastic.co/guide/en/beats/libbeat/7.0/breaking-changes-7.0.html">breaking change list</a> to see all the fields that were changed. Also check the <a href="https://www.elastic.co/guide/en/beats/libbeat/7.0/upgrading-6-to-7.html">Upgrading Beats from 6.x to 7.x guide</a>. If you are only using our Infra or Logs UI, make sure that all your data you want to see in the 7.0 UI was created with versions 6.6 or 6.7 of Filebeat and Metricbeat. In 6.6, some ECS alias fields were introduced for compatibility reasons.
</p><p>Many&nbsp;more changes happened on the Filebeat module side than on the Metricbeat modules. The reason for this is that metrics are specific and unique. A metric about the size of a table in MySQL cannot be correlated with the index size of an Elasticsearch index. Most adjustments that happened to metrics fields were around <code>host.name</code> and IP fields which are meta information about the metrics itself.
</p><h3>Elastic Common Schema&nbsp;in the UI</h3><p>The Logging and Infrastructure UI in 7.0 heavily depend on ECS fields. This means if shippers other than Beats follow ECS, the basic functionality will keep working. An example here are the <a href="https://www.elastic.co/guide/en/ecs/1.0/ecs-container.html">container</a> or the <a href="https://www.elastic.co/guide/en/ecs/1.0/ecs-cloud.html">cloud</a> fields. If an event contains the metadata around which cloud instance an event is coming from, the Infra UI can automatically group by it:</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltae0994a68d6ec66e/5cd51d79c2aeb0a25b17b5b2/image1.png" data-sys-asset-uid="bltae0994a68d6ec66e" width="450">
</p><p>The Logs&nbsp;UI depends on ECS on the <code>message</code> and the <a href="https://www.elastic.co/guide/en/ecs/1.0/ecs-log.html"><code>log</code></a> fields. If the message field exists in an event, the Logs&nbsp;UI can automatically visualise the data correctly. Our UIs&nbsp;will rely more and more on ECS, this means if you ship data based on ECS, our UI’s will be able to make sense of it too.
</p><h3>How to use the Elastic Common Schema</h3><p>Now that most of the data in the Elastic Stack is following ECS, there are a variety of ways to use it. If you have your logs, metrics and traces all stored in the same Elasticsearch cluster, you can use a search request across multiple indices. Most APIs in Elasticsearch by default allow <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.0/multi-index.html">specify multiple indices</a> or a pattern that matches multiple indices.
</p><p>In case you have a cluster for logs, one for metrics and one for APM, Elasticsearch supports this use case with <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.0/modules-cross-cluster-search.html">cross-cluster search</a> (CCS). CCS allows you to connect multiple clusters and then specify similar to the above multi index search, to search across multiple clusters.
</p><p>Cross-cluster search also works for use cases where you might have local logging and metrics clusters in different parts of the world. To get all the data for a specific <code>host.ip</code> across all your cluster, it’s just one search and you will have all the information together in one place.
</p><h3>What means ECS for the future of Observability?</h3><p>ECS just got started and will further evolve. The more standardised fields there are, the better the UI, and the easier it is for users can make sense of their data. It will make it easier for the user to better understand what the meaning of each value is. ECS can be used to correlate different data types based on the ECS fields. The capability of Elasticsearch having all the data in one or multiple clusters to make it available combined with ECS to correlate all the data makes this combination a great tool for your Observability needs. The more Elastic Stack data that is mapped&nbsp;to ECS, the more powerful the combination becomes.
</p><p>Not all data is shipped by Beats, so you often have also your own data. We encourage you to map your own data to ECS. This will not only allow you to correlate your data with all the other data but directly gives some context to each of your fields through the definition of ECS. Others looking at your data will understand what each field means. It also guarantees that as long as the same major version of ECS is used, no breaking changes happen. If your fields are mapped to ECS, they will not conflict with other fields shipped by Beats.&nbsp;</p><p>To get started with mapping your events to ECS, best go to the <a href="https://www.elastic.co/guide/en/ecs/1.0/ecs-reference.html">ECS docs pages</a>. And if you want to see your ECS-normalized data within the curated APM, Infrastructure, Logs, and Uptime UIs, spin up a <a href="https://www.elastic.co/cloud/elasticsearch-service">14-day free trial of the Elasticsearch Service</a>. As always, if you have any questions, reach out on <a href="https://discuss.elastic.co">Discuss</a>.</p>

o11y-ecs-banner.jpg

o11y-ecs-thumb.jpg

Why Observability loves the Elastic Common Schema

<html><head></head><body><p>
	To better understand which parts of our Golang applications are covered by test suites, we wanted to have a coverage report that aggregates data from all of our automated tests. However, we couldn&apos;t find any information on how to generate coverage reports from system tests of Golang applications. We found a solution using the Golang toolchain and this is a guide of how we did it. The screenshot below from Codecov.io shows an example test coverage report from our <a href="https://www.elastic.co/products/beats">Packetbeat</a> product.
</p><p>
	<img src="https://api.contentstack.io/v2/assets/575e4cb89e7a83165490c859/download?uid=blt6260e47de342f6e1" data-sys-asset-uid="blt6260e47de342f6e1" alt="Coverage Report Overview" style="max-width:100%">
</p><p>
	Having a code coverage report for unit tests is common practice and very well supported by the <a href="https://blog.golang.org/cover">Go toolchain</a>. The challenge with services which highly depend on the environment, like the operating system or other services, is that unit tests can only cover certain cases. Sometimes writing a simple test that runs the binary and compares the output with the expected output is much easier and faster. In addition, it reproduces what is happening when the binary is executed. Unfortunately in most cases these system tests do not count to the coverage report which also makes it hard to identify which parts of the code were actually run by executing the binary.
</p><h2>Our Code Coverage Challenge</h2><p>
	At <a href="https://www.elastic.co/">Elastic</a>, we develop the <a href="https://www.elastic.co/products/beats">Beats</a> products using Golang. Packetbeat is an open source project written in Golang that is designed to provide real&#x2011;time analytics for web, database, and other network protocols. During the implementation of Packetbeat, we faced the challenge that the most valuable tests were the system tests that executed the binary and checked the expected output. These tests allow us to generate <a href="https://en.wikipedia.org/wiki/Pcap">pcap</a> files, feed it through Packetbeat and see if the outcome is as expected. Like this we are able to get files from users with problems and can fully reproduce the problem. In case we fixed a bug, we didn&#x2019;t have any insights if the specific test covered the code changes except through introducing lots of log messages. Based on this we looked for a simpler solution that allowed us to identify which lines were executed by system tests.
</p><h2>Our Test Coverage Reports</h2><p>
	During the implementation of the test code coverage for the Packetbeat project we faced different challenges which we managed to overcome. Now all our Beats automatically generate a coverage report for unit and system tests. These coverage reports are generated by our continuous integration system for each pull request and are published. An excerpt of one of these reports can be seen below. The report does not only show us which lines were executed and which not, but also the number of times each line was executed. This can be seen by the small number 34 in the screenshot, which means the line above was executed 34 times. The red lines were not executed by the unit or system tests.
</p><p>
	<img src="https://api.contentstack.io/v2/assets/575e4cb83dc542cb38c089ce/download?uid=blt0e0abd822b02d8e8?uid=blt0e0abd822b02d8e8" data-sys-asset-uid="blt50e4681a1adf0706" alt="HTML Coverage Report" style="max-width:100%">
</p><h2>System Test Coverage Guide</h2><p>
	The goal of this blog post is to have a guide on how to implement a coverage report for system tests in your own Golang project. If you just want to see it working check out our <a href="https://github.com/elastic/packetbeat">Packetbeat</a> and <a href="https://github.com/elastic/filebeat">Filebeat</a> repositories. Inside the <a href="https://github.com/elastic/filebeat/blob/master/Makefile">Makefile</a> the command <code>full-coverage</code> generates all the reports and html outputs. To try it out, <a href="https://github.com/elastic/filebeat">clone</a> one of the repositories and run the command <code>make full-coverage</code> inside the repository.
</p><p>
	The paragraphs below give a step-by-step description how you can implement a coverage report for system tests in your own Golang project.
</p><h3>Step 1: Generating the Binary</h3><p>
	To run system tests, a compiled binary of the application is required. This binary is then executed in different environments with different configurations. Golang offers a unique way to generate a coverage binary instead of the default binary generated by <code>go build</code>. The binary for the code coverage which is generated writes a unique counter after every line of code and checks how many times this counter was called after the binary was executed. More technical details on how this works can be found on the <a href="https://blog.golang.org/cover">go cover documentation</a>.
</p><p>
	When <code>go test</code> is executed, this coverage binary is automatically generated again and disposed of afterwards. Golang also allows to generate this coverage binary with the following command:
</p><pre class="prettyprint">go test -c -covermode=count -coverpkg ./...
</pre><p>
	The file generated is automatically called <code>packetname.test</code>. To specify a different value, the param <code>-o</code> followed by the binary name can be used. The <code>-c</code> flag is used to generate the test binary and  <nobr><code>-covermode=count</code></nobr> makes sure the binary is generated with coverage counting inside. <code>./...</code> at the end of the command makes sure the coverage binary is generated for all sub packages under the same path, but not imported packages. If you only want to have the coverage for specific packages, you can list them here separated with a comma. For more details run <code>go test -help</code>.
</p><h3>Step 2: Create Main Test File</h3><p>
	Now that we know how to generate the binary, we have to make sure the binary will execute as expected. There are some requirements to your code base for the binary to work as expected. The first one is that there is at least one <code>*_test.go</code> file in the package. Otherwise the binary is not generated. I recommend to create the file <code>main_test.go</code> or a testfile with the same filename where your <code>func main() {}</code> is in.
</p><p>
	In our case <a href="https://github.com/elastic/filebeat/blob/master/main_test.go">main_test.go</a> file has the following content:
</p><pre class="prettyprint">package main
// This file is mandatory as otherwise the filebeat.test binary is not generated correctly.
import (
  &quot;testing&quot;
  &quot;flag&quot;
)
var systemTest *bool
func init() {
  systemTest = flag.Bool(&quot;systemTest&quot;, false, &quot;Set to true when running system tests&quot;)
}
// Test started when the test binary is started. Only calls main.
func TestSystem(t *testing.T) {
  if *systemTest {
     main()
  }
}
</pre><p>
	The file defines a <code>systemTest</code> flag and contains a single test case which calls the main function. Running the test binary starts to execute the tests. In our case this means <code>TestSystem</code> is called as this is the only test. Running <code>TestSystem</code> means calling <code>main()</code> which starts the application as the normal binary would. This means running the test binary is identical to running the normal binary except that the lines executed are tracked. To prevent this test from running when the unit tests are running, the command line flag <code>systemTest</code> was added. In case it is not set, the <code>main()</code> function will not be called. To run the system tests, the flag must be set by appending <code>-systemTest</code> during the execution of the test binary.
</p><h3>Step 3: Global Command Line Flags</h3><p>
	In order to define different test environments for the system tests, using the command line flags is often quite important. Before the implementation of the system test coverage we used <a href="https://golang.org/pkg/flag/#FlagSet">FlagSet</a> to keep flags as local as possible. Unfortunately with the coverage binary these didn&apos;t work as expected. For the test binary, all flags must be known before the execution of the tests. If a flag is defined during the execution of a test, the test binary will complain during startup that the flag is not defined. An example is shown below:
</p><pre class="prettyprint">$ ./packetbeat.test -undefinedFlag
flag provided but not defined: -undefinedFlag
</pre><p>
	To make the command line flags work with the test binary, make sure that the required flags are defined as part of the main FlagSet and are defined outside methods and functions. It can be either done directly during the assignment of variables or as part of the <code>init()</code> functions which are called before starting the test. Here an example from <a href="https://github.com/elastic/filebeat/blob/master/beat/filebeat.go">Filebeat</a>:
</p><pre class="prettyprint">var configDirPath string
// Init config path flag
func init() {
  flag.StringVar(&amp;configDirPath, &quot;configDir&quot;, &quot;&quot;, &quot;path to additional filebeat configuration directory with .yml files&quot;)
}
</pre><p>
	To ensure your flags work correctly be sure to follow the rule above. Also make sure that your application flags do not conflict with the golang test flags. Verify that all your flags are part of the test binary by running <code>testbinary -h</code>. A list similar to the example below will be printed out. This list will include the golang test flags.
</p><pre class="prettyprint">$ ./packetbeat.test -h
Usage of ./packetbeat.test:
  -I string
          file
  -N    Disable actual publishing for testing
    -O    Read packets one at a time (press Enter)
  -c string
        Configuration file (default &quot;/etc/beat/beat.yml&quot;)
  -cpuprofile string
        Write cpu profile to fil
  ...
</pre><h3>Step 4: Test your Binary</h3><p>
	To see if your binary works as expected, you can execute it manually and generate coverage data. For Packetbeat, it looks like this:
</p><pre class="prettyprint">packetbeat.test -systemTest -c config.yml -test.coverprofile coverage.cov
</pre><p>
	The <code>-systemTest</code> flag is used to start the main test as was discussed before. The <code>-c config.yml</code> flag is a Packetbeat specific flag which is required. Make sure to put all application specific flags before the test flags. The flag <code>-test.coverprofile coverage.cov</code> is a standard flag of the test binary and defines to which file the coverage output should be written. After running the binary with the command above, a file <code>coverage.cov</code> is generated in the same directory where the binary was executed.
</p><p>
	If no <code>coverage.cov</code> was generated then check if the binary actually started or if there were any errors in the output. The content generated in the <code>.cov</code> files should look similar to:
</p><pre class="prettyprint">mode: count
github.com/elastic/packetbeat/sniffer/pfring_stub.go:27.43,29.2 1 0
github.com/elastic/packetbeat/sniffer/pfring_stub.go:31.32,32.2 0 0
github.com/elastic/packetbeat/packetbeat.go:72.13,82.2 1 1
github.com/elastic/packetbeat/packetbeat.go:84.47,87.2 1 1
...
</pre><h3>Step 5: Setup System Tests</h3><p>
	Additional code is needed to test the binary with various inputs and validate the outputs. In our case we created a small system test framework in Python. Any other language that can execute binaries and that fits you could be used for this.
</p><p>
	In the case of <a href="https://github.com/elastic/packetbeat">Packetbeat</a> and <a href="https://github.com/elastic/filebeat">Filebeat</a>, our test framework generates a new directory for each test where the log output of the test binary is recorded, where the input and output of the test binary are copied, and where the coverage report is stored. This makes it really simple to debug a failing test as all the information exists. The code of our test framework and the tests can be found <a href="https://github.com/elastic/packetbeat/tree/master/tests">here</a>.
</p><p>
	To get started with your system test framework, the first tests can also be executed manually and the outputs can be verified. Based on what you learn from the manual testing it can be better evaluated what the requirements are for the system test framework. For Packetbeat the system test framework was already in place before the system test coverage implementation as these tests were also run without the coverage. To add the coverage test binary only a change of the command line flags was necessary. If you already have a system test framework in place, it can probably be adapted to implement the coverage. If not, find the best way for you and your team to implement these executions.
</p><h3>Step 6: Collect and Convert Coverage</h3><p>
	After running the test binary for all system tests, many different <code>coverage.cov</code> files exist. For the overall coverage report all the <code>coverage.cov</code> files from the system tests must be collected and merged into one file. This can be done with the following commands:
</p><pre class="prettyprint">mkdir coverage
echo &apos;mode: count&apos; &gt; ./coverage/system.cov
tail -q -n +2 ./coverage/*.cov &gt;&gt; ./coverage/system.cov
</pre><p>
	The coverage reports are stored in the coverage directory which is created first. A file <code>system.cov</code> is generated which will contain all coverage reports. On top of each coverage file, the mode must be listed. In all our cases we use <code>mode:count</code>. As all reports also have this line on top, all the content of the <code>.cov</code> files is aggregated ignoring the first line. In our case we use the command <code>tail -q -n +2</code> for this, which reads the full file starting at the second line.
</p><p>
	To make this file more human readable, Golang provides the <code>go cover tool</code> which can convert the output to an HTML file. To generate the HTML file, run the following command:
</p><pre class="prettyprint">go tool cover -html=./coverage/system.cov -o coverage/system.html
</pre><p>
	This generates the full coverage report in the file <code>system.html</code> and makes it available to view in the browser.
</p><h2>Conclusion</h2><p>
	In our case we now have a framework that runs our system tests on Windows, Linux and OS X and directly reports the coverage. The test binary created above can be executed in all cases where the normal binary is used, and it also generates a coverage report. It can even be used to run an application with some test traffic for a few minutes and then check what parts of the applications were executed.
</p><h3>Microservice Environment Coverage Reports</h3><p>
	As Golang is a popular language for Microservices, having coverage reports for binaries offers an additional opportunity. Microservices are a suite of independently deployable services. To test if multiple Microservices work together as intended, a full environment with multple Microservices has to be started. This environment is then tested by sending requests to the services and monitoring the output. Then the output is compared with the expected outcome. Unfortunately the only indication on which parts of each Microservice were executed during these tests are logging and monitoring information. No detailed insight into which lines of code were executed exists. With the coverage test binary it is possible to gain these insights.
</p><p>
	Instead of testing one binary as we described in the guide above, during the Microservice environment tests multiple binaries are executed. With the coverage test binary, it is possible to have a coverage report for each Microservice running in the test environment. The only change needed to generate the report is to create a coverage test binary for each Microservice. This binary is then run inside the test environment instead of the standard binary. After the tests the coverage reports from each Microservice must be collected and processed as described in Step 6. This method allows to gain detailed insights into which services were run and which lines of code were executed during the tests. Based on this information each Microservice can be improved
</p><h3>Multiple Coverage Files</h3><p>
	In our environment we run unit, integration, and system tests which all report coverage. For each test type we generate a separate coverage and html file. To also have a report which combines all these individual reports, we run the same command to aggregate the coverage files and generate a <code>full.cov</code> coverage file. This gives us a complete overview of which lines of code are covered by our different test suites. If you run the coverage report for larger applications or for longer times, be aware that the coverage reports can get quite large.
</p><h3>Next Steps</h3><p>
	We use the same test framework for all of our Beats projects. Next we plan to refactor and extract the testing framework part so improvements from one project don&apos;t have to be copied to all the other projects. This could make it possible that the framework can also be used for other Golang projects to provide system test coverage and make the setup simpler. Contributions here are more than welcome.
</p><p>
	If you have questions, <a href="https://discuss.elastic.co/c/beats">contact us</a> in the Elastic forum under the <a href="https://discuss.elastic.co/c/beats">Beats category</a>.
</p></body></html>

golang-coverage-report-overview.jpg

Code Coverage for your Golang System Tests

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Software Engineer

Nicolas Ruflin

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/elastic-cloud-account-terms" target="_self">服务条款</a>，并且您同意通过您提供的上述联系方式接收<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">所选的通信</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/serverless-preview-terms" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>提交即表示您同意 <a href="/cn/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 服务条款</a>。我们将会按照 <a href="/cn/legal/privacy-statement">Elastic 的隐私声明</a>处理您的个人数据。
</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/terms-of-use" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。</p>

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

本页内容尚不支持所选语言。Elastic 正在不断努力，以实现对多种语言内容的支持。感谢您在此期间给予的耐心与陪伴！

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

查看本次网络研讨会在我的时区的开始时间

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

无法实时参加？注册后我们会给您发送录像。您还将收到相关内容的电子邮件。

Author

Articles by Nicolas Ruflin

Software Engineer, Elastic

Elastic Stack 7.17.17 released

An introduction to the Elastic data stream naming scheme

Why Observability loves the Elastic Common Schema

Code Coverage for your Golang System Tests