Shaping often would help in situations like this, but to use shaping, as it's egress only, we would need to apply it to the device on the other side of the port having ingress capacity issues. (The latter the reason why I asked about what the other side device is, and does OP have management access to it.)
However as interface stats show interface running at gig, but OP says it's 10 Mbps, another way to "shape" egress (and ingress!!!) is to run the Ethernet link at 10 or 100 Mbps (assuming other side can too). 10 Mbps, would, I'm 99.99% sure, remove ingress stress, and works better than a software shaper, for egress, but it could push traffic to queue on the other side device (and we don't know [yet?] how well that device would process the possible additional queuing). Also, I don't know, yet, whether 10 Mbps is both up and down and what QoS policy is applied to g0/0 as I also see "Queueing strategy: Class-based queueing" in interface stats.
Possibly running interface at 100 Mbps would reduce any ingress gig burst stress, and for egress, we can shape for 10 Mbps (again the latter, i.e. software shaping, not as "good" as running the interface at 10 Mbps, but such is often the case when making trade-offs).
There are other wady to mitigate some of the ingress issues, such as increasing in hold-queue and/or changing SPD parameters (I've experience in both, but don't know if latter supported on these ISRs), or even obtaining a more "powerful" router (another interesting stats would be CPU history), but if CIR is only 10 Mbps, running across a gig link, physically slowing physical bandwidth, to 100 Mbps, avoids getting into more complex configurations and also still provides a way to easily still increase CIR (?), well at least up to 100 Mbps (if you want to really run at gig rates, you'll want a more "powerful" router [which, BTW, what model 2900 is this?]).
