For metrics, you want various kind of parameters for gross trouble-shooting:
- customer class (if you have it)
- session state (not-established, negotiating, lobby, game, etc)
- size of packet
- number of payload messages per packet
- payload message types
- packet direction (to server or from server)
- number of dropped packets detected
- number of duplicate packets detected
- number of reordered packets detected
- measured round-trip latency
- number of malformed packets
In the best of worlds, you chuck all of this at some reporting infrastructure, and generate an online cube where you can slice your traffic across arbitrary dimensions (each of the things above classify packets across some dimension.) This doesn't necessarily need to be real-time, because it's useful for finding things you didn't know about your game. Each individual dimension could separately be real-time, and the drill-down would be relegated to a baked cube, for example.
At that point, you can get reports like "number of packets that are re-ordered, containing the 'fire weapon' payload."
Now, there's a second level of diagnosis, where you can get this data sliced, in real-time, based on specific identifiers. Specific IP. Specific game instance. Specific player. Random sampling. Etc. Being able to have a customer on the line and turn on tracing of that particular customer's traffic is super helpful while debugging.
Another useful feature is the ability to capture and play back traffic, both for analysis, and for actual system analysis. If you can capture all packets that go in since server start, then you can reproduce any server state offline for debugging!