"Can it be microbursts?"
Certainly possible, even likely. One reason likely . . .
"As you can see from the screenshots, the data rate is way below 10G, even below 1G."
Extreme bursting can drive effective TCP data transfer rates way, way down. The usual cause for this is timeouts waiting on ACKs for data packets sent, but dropped.
"Is there a way to tell what packets/data is being discarded?"
Unsure on a 3850 platform, beyond directing different traffic types to different egress queues and checking egress queue stats.
"Do we need to bother with it at all as we don't experience any problems??"
Ah, (laugh) that's the 64 bit question. If you truly don't believe it's adverse to your service requirements, then what you have is only an "academic" problem.
I've written, on these forums, I consider an interface congested whenever a frame/packet cannot be immediately transmitted. Yet, whether one frame/packet is waiting, or a thousand, such "congestion" doesn't define whether you have a problem or not. If congestion is a problem, then it might be mitigated with additional bandwidth and/or QoS. (BTW, you can also have issues w/o any "congestion". In such cases, generally QoS won't help while additional bandwidth may, or may not, help.)
In cases where congestion isn't considered a problem, QoS and/or plans to add bandwidth might be made to possibly avoid/mitigate future congestion (e.g. possibly QoS configured now) or quickly mitigate future congestion (e.g. SFP to SFP+, Etherchannel, multiple ECMP L3 paths, etc.).
"Any other recommendations?"
If what you're seeing doesn't appear to be adverse to your service requirements, continue to monitor your service levels and address the issue then. However, that approach might lead you into being "slow" to mitigate a future service issue as you, yet, don't really understand the current cause of what you're seeing now.
In other words, it's probably worthwhile to get to the "cause now", so you can mitigate it, if needed, in the future, but as you don't have a "problem" now, this could be a low priority project.
Not withstanding the forgoing, the most likely issue is caused by 3850 having insufficient buffer resources for your traffic (not an uncommon issue with Catalyst 3Ks, including earlier gens).
There's a reason Cisco has much (much) more expensive switches in their product line up and/or why they generally recommend their Nexus series for data centers. Different switches all seem to have FE, gig, 10g, etc. ports, but what's "behind" those ports can be quite different, as is the "performance" capabilities.
An independent benchmark for most switches might show a switch capable of "wire-speed/line-rate" on all ports concurrently (e.g. port1=>port2, p2=>p3, . . . , p48=>p1), but that's very rarely a real world usage example.
Cannot say regarding resource allocations on a 3850, but on the prior 3750 there was a fixed (and same) buffer RAM allocate per each bank of 24 copper ports and for the "uplink" ports. I.e. balancing ports usage across these banks can better share buffer RAM.
Or, cannot say regarding the 3850s, but again on the first gen 3750, its ring usage was rather wasteful (such as traffic between two ports on the same physical switch member was also transmitted on the ring, and/or, traffic being sent between stack switch members, was removed by the original sending switch, not the receiving switch). Besides a 3850 offering more stack ring bandwidth, how it uses the ring is likely better than a 3750 too, yet unlikely as efficient as a fabric within a chassis switch.
Or, also in other words, perhaps you may find the "best" long term solution is the replace your 3K switches with "better" switches. (Also again, there really is a reason they cost more, beyond increased profit margins.)
(BTW, on the old Catalyst 6500s/7600s, much of the platform's overall "performance" also depended on the line card[s {plural because even the mix of line cards impacted overall performance}], and what optional modules it might have, that hosted its gig, 10g, etc., ports.)
