# Basic logstash mutations **URL:** \ **Category:** Logstash\ **Created:** [August 29, 2019, 12:43am UTC](https://discuss.elastic.co/t/basic-logstash-mutations/197244 "2019-08-29T00:43:52Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\ **Post date:** [August 29, 2019, 11:40pm UTC](https://discuss.elastic.co/t/basic-logstash-mutations/197244/4 "2019-08-29T23:40:28Z")
> [@Evan\_Something](#): > > but the Grok way is to parse the entire field at once I disagree 🙂 That is the way a lot of grok examples are written, because grok is well matched to standardized formats. And most folk start with a single line format, such as a web server log, so that is how they first learn to use grok, so that is how they first write an example of using it. But you can use grok to pull out more than one small fields from diffently formatted lines, as mentioned [here](https://discuss.elastic.co/t/how-to-search-log-line-for-a-specific-pattern-format/196977/2). And if you have a fixed prefix it may make a lot more sense to use dissect to parse that prefix, as described [here](https://discuss.elastic.co/t/assistance-with-grokparsefailure/196720/3). grok can parse almost anything, and as a result folks tend to use it to parse almost everything, but parsing the entire line using a single grok expression is often not the best approach. It will work, but there may be other approaches that in the long run are easier to maintain, and/or less CPU intensive, and/or less fragile. Sometimes you get all of the ands 😉 --- _[View the full topic](https://discuss.elastic.co/t/basic-logstash-mutations/197244)._