[DOCS] Fix description of rename processor

libbeat/processors/actions/docs/rename.asciidoc

@@ -2,19 +2,21 @@
 === Rename fields from events
 
 The `rename` processor specifies a list of fields to rename. Under the `fields`
-key each entry contains a `from: old-key` and a `to: new-key` pair. `from` is
-the origin and `to` the target name of the field.
-
-Renaming fields can be useful in cases where field names cause conflicts. For
-example if an event has two fields, `c` and `c.b`, that are both assigned scalar
-values (e.g. `{"c": 1, "c.b": 2}`) this will result in an Elasticsearch error at
-ingest time. This is because the value of a cannot simultaneously be a scalar
-and an object. To prevent this rename_fields can be used to rename `c` to
-`c.value`.
-
-Rename fields cannot be used to overwrite fields. To overwrite fields either
-first rename the target field or use the `drop_fields` processor to drop the
-field and then rename the field.
+key, each entry contains a `from: old-key` and a `to: new-key` pair, where:
+
+* `from` is the original field name
+* `to` is the target field name
+
+The `rename` processor cannot be used to overwrite fields. To overwrite fields
+either first rename the target field, or use the `drop_fields` processor to drop
+the field and then rename the field.
+
+TIP: You can rename fields to resolve field name conflicts. For example, if an
+event has two fields, `c` and `c.b` (where `b` is a subfield of `c`), assigning
+scalar values results in an {es} error at ingest time. The assignment `{"c": 1,
+"c.b": 2}` would result in an error because `c` is an object and cannot be
+assigned a scalar value. To prevent this conflict, rename `c` to `c.value`
+before assigning values.
 
 [source,yaml]
 -------