feat: Add Prometheus metric to track sql stmts per transaction

[yvardhineni]

• Added a new summary metric transaction_sql_stmts to track the number of exec/querys stmts executed per transaction
• Introduced a new struct managedTx to to hold the context and connection of a transaction
• Introduced a new field execStmtsCounter and queryStmtsCounter in the managedConn to track the number of exec querys in a transaction.
• When SQL lib opens a transaction we are storing the connection for that transaction and context of the transaction in the managedTx.
• Context is used to store the required grpc labels for the metric. i.e. grpc method, grpc service
• Added a UnaryInterceptor to the grpc server to store the grpc method and grpc service in the context
• On commit or rollback of the transaction we are removing the connection from the managedTx and resetting the counters to 0
• On commit of the transaction we are observing the transaction_sql_stmts metric by the number of exec/querys got exexuted in the transaction

[yvardhineni]

sample metrics:

# HELP transaction_exec_query_total The number of times exec query is called in a transaction
# TYPE transaction_exec_query_total summary
transaction_exec_query_total_sum{grpc_method="SayHello",grpc_service="helloworld.Greeter"} 4
transaction_exec_query_total_count{grpc_method="SayHello",grpc_service="helloworld.Greeter"} 2

[daniel-garcia]

LGTM but add some tests for this.

[daniel-garcia]

The Exec() call above also needs an inc()

[yvardhineni]

Updated Metrics:

# HELP transaction_sql_stmts_total The number of sql stmts called in a transaction by statement type per grpc service and method
# TYPE transaction_sql_stmts_total summary
transaction_sql_stmts_total_sum{grpc_method="List",grpc_service="infoblox.service.SampleService",stmt="exec"} 4
transaction_sql_stmts_total_count{grpc_method="List",grpc_service="infoblox.service.SampleService",stmt="exec"} 2
transaction_sql_stmts_total_sum{grpc_method="List",grpc_service="infoblox.service.SampleService",stmt="query"} 2
transaction_sql_stmts_total_count{grpc_method="List",grpc_service="infoblox.service.SampleService",stmt="query"} 2

[kd7lxl]

The naming convention is to suffix counters with _total. Since this is a summary, I think stmnts is the unit. I don't see any examples in the best practices of summaries named like counters. So naming might be like transaction_sql_stmts:

• transaction_sql_stmts_sum
• transaction_sql_stmts_count

This doesn't seem related to hotload. I would like to see it as a separate module with a signature like dbmetrics.WrapDB(*sql.DB) *sql.DB. (You can add other arguments and error if it would be useful.) We can still wrap hotload if we want, but it would also be useful on its own.

[daniel-garcia]

The naming convention is to suffix counters with _total. Since this is a summary, I think stmnts is the unit. I don't see any examples in the best practices of summaries named like counters. So naming might be like transaction_sql_stmts:

• transaction_sql_stmts_sum
• transaction_sql_stmts_count

This doesn't seem related to hotload. I would like to see it as a separate module with a signature like dbmetrics.WrapDB(*sql.DB) *sql.DB. (You can add other arguments and error if it would be useful.) We can still wrap hotload if we want, but it would also be useful on its own.

It may be useful as a standalone module however, we need this to be enabled on sql.Open so that we minimize changes to app code. Not it all instances can apps wrap the created sql.DB object.

[yvardhineni]

The naming convention is to suffix counters with _total. Since this is a summary, I think stmnts is the unit. I don't see any examples in the best practices of summaries named like counters. So naming might be like transaction_sql_stmts:

• transaction_sql_stmts_sum
• transaction_sql_stmts_count

Updated the name to transaction_sql_stmts