Time grain is the time resolution at which a metric is computed and stored. Hourly, daily, weekly, monthly. It is part of the metric’s definition rather than a display option, and treating it as a display option is a reliable source of wrong numbers.
Two kinds of metric behave completely differently over time, and they need to be distinguished explicitly.
A point-in-time metric describes a state at an instant. Number of assets without an agent installed. It has a value at every moment and no natural notion of accumulation.
A period metric describes something that happened across a window. Number of incidents raised. It has no meaning without a window attached.
Adding two daily values makes sense for the second and is nonsense for the first. Yet a chart will happily render both the same way, and a rollup will happily sum both.
The definition should state the grain, whether the metric is point-in-time or period, and the timezone.
Timezone gets skipped constantly and matters more than expected. A daily metric computed in UTC for an organization operating in GST shifts every boundary by four hours, which moves records between days and makes month-end figures disagree with the local ledger.
Moving to a coarser grain requires an aggregation rule, and the correct rule depends on the metric. Sum for counts of events. Average or maximum for rates. Last value in the window, usually, for point-in-time state.
Moving to a finer grain than the source supports requires carrying values forward. See last known value carry-forward. It is legitimate as long as it is declared, and misleading when it is silent, because a flat line from a monthly source looks the same as a genuinely stable daily one.
The common case, and the one where most errors live. A metric drawing on a source that updates continuously and another that updates monthly cannot be more precise than its slowest input, however precise the chart looks.
State the effective grain of the composed metric rather than the grain of the fastest source feeding it.
From the blog