# Reason for Scale 1000000 for IIS event.duration **URL:** \ **Category:** Beats\ **Tags:** filebeat\ **Created:** [May 23, 2021, 3:04pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762 "2021-05-23T15:04:21Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![danielw](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@danielw](https://discuss.elastic.co/u/danielw)\ **Post date:** [May 23, 2021, 3:04pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/1 "2021-05-23T15:04:21Z")
I'm trying to figure out what is the reason for the scale of 1000000 when using the filebeat module for iis for the duration field. Seems a bit strange when trying to build a dashboard for Reponse Times where every value is multiplicated by 1000000. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [May 23, 2021, 3:24pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/2 "2021-05-23T15:24:21Z")
Hi @danielw Exactly which fields are you looking at. You can look at the exported fields definitions and see the units [here](https://www.elastic.co/guide/en/beats/filebeat/current/exported-fields.html). Many of the time related fields are in micro or nano seconds to support needed resolution. Depending on what visualization you are using there are different ways to handle. Which visualization? You could also go in the index pattern and edit the default formatting for the field and set it how you prefer. ---
**Author:** ![danielw](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@danielw](https://discuss.elastic.co/u/danielw)\ **Post date:** [May 24, 2021, 2:19pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/3 "2021-05-24T14:19:05Z")
Hi Stephen, thanks for your reply: The field in question ist the time-taken field from the Windows IIS Log: This is the part in the Module Pipeline Defintion: ``` - script: lang: painless source: ctx.event.duration = Math.round(ctx.temp.duration * params.scale) params: scale: 1000000 if: ctx.temp?.duration != null ``` This field is usualy milliseconds. I can understand that there are steps taken to harmonize time units . I was just a bit curious why it is scaled by such a big factor. When we start to write and use our custom filebeat-modules we want to use also ecs format as it seems to be an usefull thing worth taking into consideration. So i want to stay as close to default settings as possible. Currently i'm just playing a bit around and tried to do a simple timebased line chart showing iis time taken -\> that was the point where i started looking for as the values did seem a bit high for iis response times 🙂 ![image](https://us1.discourse-cdn.com/elastic/original/3X/3/d/3df0f155369de45d63f63bbccdcf47c479f7225a.png) ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [May 24, 2021, 2:48pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/4 "2021-05-24T14:48:59Z")
Just to be clear you are using the IIS module of Filebeat correct? @danielw **EDITED : Read wrong.... Corrected** interesting... I can just make out what you are graphing is `event.duration` (note it really helps us if you refer to the exact field name you are looking at) So if you look at the definition of event.duration [here](https://www.elastic.co/guide/en/beats/filebeat/current/exported-fields-ecs.html) ` event.duration` Duration of the event in **nanoseconds**. If event.start and event.end are known this value should be the difference between the end and start time. ``` type: long format: duration ``` So it looks like it is turned from **ms** (probably what the `ctx.temp.duration) it is _ **multiplied** _ by 1,000,000 in the pipeline to become nanoseconds. Hmm but that does not right in your graph because then 5000 nanoseconds would be just 5 microseconds did you already do some scaling in the graph? Perhaps you should be looking at the actual IIS Fields that you can find [here](https://www.elastic.co/guide/en/beats/filebeat/current/exported-fields-iis.html) ... huh no response times here so that must be the equivalent. **Just corrected / changed...** ---
**Author:** ![danielw](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@danielw](https://discuss.elastic.co/u/danielw)\ **Post date:** [May 24, 2021, 5:22pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/5 "2021-05-24T17:22:47Z")
> [@stephenb](#): > > So if you look at the definition of event.duration [here](https://www.elastic.co/guide/en/beats/filebeat/current/exported-fields-ecs.html) Exactly, it is the time-taken field i'm refering to and i try to use the module "iis" with filebeat. Allthough i have added a grok pattern to the default module to reflect our log settings. I have seen that x-forwarded-for was allready commited to filebeat repository but i wasn't able to find it in the latest 7.12 release 🙂 IIS-Log setting: ![image](https://us1.discourse-cdn.com/elastic/original/3X/a/d/ad5881df11a1c8cc978e33977efcd9ffa511b26f.png) The Grok Block including my modified pattern: ``` - grok: field: message patterns: - '%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{IPORHOST:destination.address}) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NOTSPACE:http.request.referrer}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:temp.duration:long})' - '%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{NOTSPACE:iis.access.site_name}) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NOTSPACE:iis.access.cookie}) (?:-|%{NOTSPACE:http.request.referrer}) (?:-|%{NOTSPACE:destination.domain}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:http.response.body.bytes:long}) (?:-|%{NUMBER:http.request.body.bytes:long}) (?:-|%{NUMBER:temp.duration:long})' - '%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{NOTSPACE:iis.access.site_name}) (?:-|%{NOTSPACE:iis.access.server_name}) (?:-|%{IPORHOST:destination.address}) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|HTTP/%{NUMBER:http.version}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NOTSPACE:iis.access.cookie}) (?:-|%{NOTSPACE:http.request.referrer}) (?:-|%{NOTSPACE:destination.domain}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:http.response.body.bytes:long}) (?:-|%{NUMBER:http.request.body.bytes:long}) (?:-|%{NUMBER:temp.duration:long})' - '%{TIMESTAMP_ISO8601:iis.access.time} \[%{IPORHOST:destination.address}\]\(http://%{IPORHOST:destination.address}\) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) \[%{IPORHOST:source.address}\]\(http://%{IPORHOST:source.address}\) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:temp.duration:long})' - '%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{IPORHOST:destination.address}) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:temp.duration:long})' - '%{TIMESTAMP_ISO8601:iis.access.time} (?:-|%{NOTSPACE:iis.access.site_name}) (?:-|%{NOTSPACE:iis.access.server_name}) (?:-|%{IPORHOST:destination.address}) (?:-|%{WORD:http.request.method}) (?:-|%{NOTSPACE:url.path}) (?:-|%{NOTSPACE:url.query}) (?:-|%{NUMBER:destination.port:long}) (?:-|%{NOTSPACE:user.name}) (?:-|%{IPORHOST:source.address}) (?:-|%{NOTSPACE:user_agent.original}) (?:-|%{NOTSPACE:http.request.referrer}) (?:-|%{NUMBER:http.response.status_code:long}) (?:-|%{NUMBER:iis.access.sub_status:long}) (?:-|%{NUMBER:iis.access.win32_status:long}) (?:-|%{NUMBER:http.response.body.bytes:long}) (?:-|%{NUMBER:http.request.body.bytes:long}) (?:-|%{NUMBER:temp.duration:long}) (?:-|%{IPORHOST:network.forwarded_ip})' ignore_missing: true ``` i did see that the "time-taken" field was parsed with the pattern (?:-|%{NUMBER:temp.duration:long}) and later gets modified and written into event.duration ``` - script: lang: painless source: ctx.event.duration = Math.round(ctx.temp.duration * params.scale) params: scale: 1000000 if: ctx.temp?.duration != null ``` the event.duration description fits the description of time-taken quite well, sort of 🙂 `The time-taken field measures the length of time that it takes for a request to be processed. The client-request time stamp is initialized when HTTP.sys receives the first byte of the request.` so i thought thats ok. but it seems that i havent read the part of the event.duration description, the one with "nanoseconds" Now it makes sense to me, at least some, as all entries for event.duration will get translated to nanoseconds. I will try to keep this in mind when creating a visualisation of the data. `Duration of the event in nanoseconds. If event.start and event.end are known this value should be the difference between the end and start time.` Thank you very much, the link to the event.duration description realy helped. Now i have to find out how to get the displayed valued back to ms in the visualisation. best regards Dan ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [May 24, 2021, 5:25pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/6 "2021-05-24T17:25:34Z")
Great Job Digging In! I learned something too! I edited the title in case anyone looking / searching in the future. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [May 24, 2021, 5:43pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/7 "2021-05-24T17:43:26Z")
@danielw depending what visualization you use you can adjust that. In TSVB you can do this.... (this is an example where the data is in us) ![Screen Shot 2021-05-24 at 10.39.28 AM](https://us1.discourse-cdn.com/elastic/original/3X/b/5/b543d0e00eb4f80b5122218b9dfe819a35051ce2.png) Then in the options you can do this... you might want to give it a try.... ![Screen Shot 2021-05-24 at 10.39.41 AM](https://us1.discourse-cdn.com/elastic/original/3X/1/6/1693215842fa93a32a455571e2a59adf29408f8e.png) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 21, 2021, 7:43pm UTC](https://discuss.elastic.co/t/reason-for-scale-1000000-for-iis-event-duration/273762/8 "2021-06-21T19:43:47Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.