metrics: Feature planning, umbrella issue

[bzub]

I got excited about metrics since #65 landed, so this issue is just for mapping out short and long-term goals for kube-router metrics. Once we agree on the the abstract goals I will create issues to track their implementation. I will edit this issue with any changes we discuss.

Phase 1 (short term goals)

Configuration

• Add a --metrics-port option to change the port.
  • --metrics-port=0 means disabled. Default port should be uncommon.
• Provide a k8s Service definition for kube-router metrics port to our example manifests
• Provide a ServiceMonitor definition to support prometheus-operator users

Phase 2 (Expanded Metrics)

Additional Metrics (Basic)

• BGP basics. See: gobgp monitor
  • Peering/Neighbor status changes
  • RIB changes
• kube-router app metrics
  • error counter
  • iptable rules counter

Phase 3

Additional Metrics (Advanced/Debugging)

Could use or draw inspiration from k8sconntrack

• Low level conntrack
• TCP/UDP
• iptable stats
• other /proc metrics within the scope of Nodes, Services, Endpoints and Pod networking

Features and Configuration

• Create a Grafana dashboard to quickly visualize metrics
  • Related to network visualization proposal in provide service visualization #12
• Support annotations to enable metrics per-service
  • This is to support adding CPU intensive metrics and debugging scenarios, to be implemented in another issue.

[murali-reddy]

@bzub excellent set of goals. i think short term goals can be stright away fixed.

[aauren]

Closing as stale. Some prometheus metrics have been added, and while there is still some stuff that could be done from this checklist, I think that it would be better served in a new ticket that takes the current state into account.