Buddhi metric reporter service api

[eguzki]

Metric reporter endpoint computes expected metric usage from traffic information.

Buddhi knows relation between traffic paths and metric hits. Using that relation, metric usage report is generated based on traffic information.

Traffic information can be generated using /paths/amp endpoint as follows:

$ curl http://127.0.0.1:8089/paths/amp?lines=5 2>/dev/null > traffic.csv
$ cat traffic.csv
"53f07c14-e35e-4bfa-b0b1-9d3a993fad14.benchmark.3sca.net","/1?app_id=ddfa9a8842a3822e&app_key=73418183a69b027a"
"e75ef4f7-54da-4ec6-a4b2-33a163764385.benchmark.3sca.net","/1?app_id=5e4618aa57d801cd&app_key=fe4db52e5e86668f"
"e75ef4f7-54da-4ec6-a4b2-33a163764385.benchmark.3sca.net","/11?app_id=ceeeb23abfd0adfd&app_key=fbdfae99a587811e"
"31b75b9b-fbb4-4223-8736-b93c34676f04.benchmark.3sca.net","/1?user_key=aa5736e41a3888db"
"e75ef4f7-54da-4ec6-a4b2-33a163764385.benchmark.3sca.net","/111?app_id=ca2f8ff8b0a8707c&app_key=4b349db5bb77b9db"

Then, metric report can be generated requesting /report/amp endpoint as follows:

$ curl -X POST --data-binary "@traffic.csv" http://127.0.0.1:8090/report/amp 2>/dev/null
{"53f07c14-e35e-4bfa-b0b1-9d3a993fad14":{"6527c16b-dfeb-46e7-93d8-4eef0a6abbe3":1,"0dfb13fa-410e-4394-9fad-f0b785e1e680":1},"e75ef4f7-54da-4ec6-a4b2-33a163764385":{"dabdb86c-5344-4ff5-b8c7-65740357ecc6":6,"439402ef-ee9a-4c2a-856e-59928a3cef10":3,"e7265d03-efa7-4641-80b6-6d4a0d44713b":2,"937ebcef-1afd-4498-91a7-696c069f4668":1},"31b75b9b-fbb4-4223-8736-b93c34676f04":{"267c1777-53f7-4568-b9c0-2af28571a1dc":1,"2641b733-2030-4fac-9248-c1b8d3a4f02b":1}}

Report shows usage for every metric involved in traffic. Pretty printed

{
  "53f07c14-e35e-4bfa-b0b1-9d3a993fad14": {
    "6527c16b-dfeb-46e7-93d8-4eef0a6abbe3": 1,
    "0dfb13fa-410e-4394-9fad-f0b785e1e680": 1
  },
  "e75ef4f7-54da-4ec6-a4b2-33a163764385": {
    "dabdb86c-5344-4ff5-b8c7-65740357ecc6": 6,
    "439402ef-ee9a-4c2a-856e-59928a3cef10": 3,
    "e7265d03-efa7-4641-80b6-6d4a0d44713b": 2,
    "937ebcef-1afd-4498-91a7-696c069f4668": 1
  },
  "31b75b9b-fbb4-4223-8736-b93c34676f04": {
    "267c1777-53f7-4568-b9c0-2af28571a1dc": 1,
    "2641b733-2030-4fac-9248-c1b8d3a4f02b": 1
  }
}

Additionally, traffic path template from single traffic profile has been removed. Removing specific traffic path template for single profile, now, there is only one traffic path template for all traffic profiles based on /[1]{0..3} template.

[davidor]

A metric ID by itself does not identify a metric. It also needs the service ID.
If I remember correctly, Apisonator will let you create 2 different metrics with the same ID under different services.

[eguzki]

Correct,

What format would be appropriate?

{
   "svc_a":{
       "metric_a_1": 3,
       "metric_a_2": 6,
        "metric_a_3": 8,
       }
   },
   "svc_b":{
       "metric_b_1": 1,
       "metric_b_2": 2,
        "metric_b_3": 7,
       }
   }
}

or CSV

"service", "metric", "counter"
"svc_a", "metric_a_1", 5
"svc_a", "metric_a_2", 5
"svc_a", "metric_a_3", 5
"svc_b", "metric_b_1", 5
"svc_b", "metric_b_2", 5
"svc_b", "metric_b_3", 5

[davidor]

I'd return JSON in this case because it allows us to represent the service -> metric relationships

[eguzki]

@davidor updated response body format to

{ service_id => { metric_id: counter} }