|
| 1 | +[[release-highlights-7.0.0]] |
| 2 | +=== 7.0.0 release highlights |
| 3 | +++++ |
| 4 | +<titleabbrev>7.0.0</titleabbrev> |
| 5 | +++++ |
| 6 | + |
| 7 | +Each release of {beats} brings new features and product improvements. |
| 8 | +Here are the highlights of the new features and enhancements in 7.0.0. |
| 9 | + |
| 10 | +Refer to the {beats} <<breaking-changes-7.0, Breaking Changes>> and <<release-notes, |
| 11 | +Release Notes>> for a list of bug fixes and other changes. |
| 12 | + |
| 13 | +//NOTE: The notable-highlights tagged regions are re-used in the |
| 14 | +//Installation and Upgrade Guide |
| 15 | + |
| 16 | +// tag::notable-highlights[] |
| 17 | + |
| 18 | +[float] |
| 19 | +==== Elastic Common Schema (ECS) |
| 20 | + |
| 21 | +The {ecs-ref}/index.html[Elastic Common Schema], or ECS, is an open source |
| 22 | +specification that defines a common set of document fields for event data |
| 23 | +ingested into {es}. ECS makes it dramatically easier for users to correlate data |
| 24 | +across sources and develop common content, such as dashboards and machine |
| 25 | +learning jobs. |
| 26 | + |
| 27 | +In 7.0, all {beats} and {beats} modules generate ECS format events by default. |
| 28 | +This means that adopting ECS is as easy as upgrading to {beats} 7.0. All {beats} |
| 29 | +module dashboards in 7.0 make use of ECS. |
| 30 | + |
| 31 | +Migrating to a common schema means that many fields have been renamed. We have |
| 32 | +developed an upgrade procedure that uses {es} field aliases to make the |
| 33 | +transition easier. After the upgrade is complete, we strongly advise that you |
| 34 | +adjust your custom {kib} dashboards, machine learning jobs, and other content to |
| 35 | +use the new ECS field names. |
| 36 | + |
| 37 | +See the {beats-ref}/upgrading.html[{beats} upgrade documentation] for more |
| 38 | +information. |
| 39 | + |
| 40 | +[float] |
| 41 | +==== Index lifecycle management (ILM) |
| 42 | + |
| 43 | +In 6.6, {es} added advanced capabilities for index management. Rather than |
| 44 | +simply performing management actions on your indices on a set schedule, you can |
| 45 | +base actions on other factors such as shard size and performance requirements. |
| 46 | +You control how indices are handled as they age by attaching a lifecycle policy |
| 47 | +to the index template used to create them. You can update the policy to modify |
| 48 | +the lifecycle of both new and existing indices. This set of capabilities are |
| 49 | +grouped in the {ref}/index-lifecycle-management.html[index lifecycle management |
| 50 | +(ILM)] APIs. |
| 51 | + |
| 52 | +In 7.0, {beats} defaults to rotating indices by using ILM policies, if the {es} |
| 53 | +version to which they connect supports ILM. The default policy rotates indices |
| 54 | +when they reach 50 GB or 30 days. You can edit the ILM policy by using the {kib} |
| 55 | +management UI, or directly via the {es} API. |
| 56 | + |
| 57 | +[float] |
| 58 | +==== Stack monitoring |
| 59 | + |
| 60 | +The full suite of modules to {stack-ov}/monitoring-production.html[monitor your |
| 61 | +{stack}] are now GA. These include the {metricbeat} modules for {es}, {ls}, and |
| 62 | +{kib}. |
| 63 | + |
| 64 | +In the future, we will switch to {metricbeat} as the recommended agent |
| 65 | +for monitoring the {stack}. To prepare for the switch, see |
| 66 | +{ref}/configuring-metricbeat.html[Collecting {es} monitoring data with {metricbeat}]. |
| 67 | + |
| 68 | +[float] |
| 69 | +==== Logs and infrastructure metrics |
| 70 | + |
| 71 | +{beats} adds several new modules, focusing on datastores and the cloud. |
| 72 | + |
| 73 | +On the cloud side, {metricbeat} adds the |
| 74 | +{metricbeat-ref}/metricbeat-module-aws.html[AWS] module, which collects and |
| 75 | +centralizes basic resource utilization metrics from all your EC2 instances, |
| 76 | +directly from Cloudwatch. A widely used messaging platform, |
| 77 | +{metricbeat-ref}/metricbeat-module-nats.html[NATS], earns its own module for |
| 78 | +capturing stats, connections, routes, and subscriptions metrics. |
| 79 | + |
| 80 | +For datastores, {metricbeat} offers modules for Microsoft SQL Server and |
| 81 | +CouchDB. The {metricbeat-ref}/metricbeat-module-mssql.html[MSSQL] module |
| 82 | +captures transaction log and performance counters, while the |
| 83 | +{metricbeat-ref}/metricbeat-module-couchdb.html[CouchDB] module provides a |
| 84 | +server metricset. |
| 85 | + |
| 86 | +[float] |
| 87 | +==== Security analytics data sources |
| 88 | + |
| 89 | +For data relevant to security analytics, {filebeat} adds a |
| 90 | +{filebeat-ref}/filebeat-module-zeek.html[Zeek] module that integrates with the |
| 91 | +popular open-source Zeek project, formerly known as Bro, and a |
| 92 | +{filebeat-ref}/filebeat-module-santa.html[Santa] module, which tracks process |
| 93 | +executions on macOS. These modules add to the list of modules added already in |
| 94 | +the 6.x series, including {filebeat-ref}/filebeat-module-suricata.html[Suricata], |
| 95 | +{filebeat-ref}/filebeat-module-iptables.html[IPtables], and |
| 96 | +{filebeat-ref}/filebeat-module-netflow.html[NetFlow]. |
| 97 | + |
| 98 | +In addition, the {auditbeat} |
| 99 | +{auditbeat-ref}/auditbeat-module-system.html[system] module keeps improving, and |
| 100 | +the transition to ECS makes all {beats} modules more useful for security |
| 101 | +use cases. |
| 102 | + |
| 103 | +// end::notable-highlights[] |
0 commit comments