abap-observability-tools / abap-metrics-provider Goto Github PK

https://blogs.sap.com/2020/10/19/basis-daily-monitoring-t-codes/

• metrics store and dependet object
  => category (system), key (shortdumps_no), value (3)

https://blogs.sap.com/2020/10/19/basis-daily-monitoring-t-codes/

So that the objects can be transported

Merge with testing repo (https://github.com/JohannesKonings/docker-abap-metrics-provider-tester)

the first pick of the metric group is enough to catch the right timestamp for the last run filed

https://github.com/Goala/abap-metrics-provider/blob/7b666f3ddc0e65ddc1bc8697f850ca046d476f31/src/zcl_amp_strategist.clas.abap#L32

• prometheus -> prometheus
• telegraf -> telegraf_http_json

https://blogs.sap.com/2020/04/10/view-pipo-monitoring-logs-from-a-sap-abap-program/

https://github.com/Goala/abap-metrics-provider/pull/47

Json output is broken when selected scenrio has noch metrics inside metrics store

header: scenario name | converter class
dependent entries: metric group name | metric class

table snap

e.g. https://github.com/pacroy/abap-prometheus is based on shared objects.
Currently it's implemented as a DDIC table: https://github.com/Goala/abap-metrics-provider/blob/master/src/zamp_store.tabl.xml

transaction zamp_config

• total DB time
• total requests
• top 5 requests
• ...

https://help.sap.com/viewer/a24970c68fcf4770a64bf9a78e3719e2/7.5.9/en-US/f1be2e59f44d448180703d6a497ec1e2.html

following how github calls the default branch

replaces #3

transaction zamp_config

If the collection of the metrics e.g. for the workload retrieve the data since the last run it needs the information as timestamp or date and time.

• with different categories

The reports zamp_metrics_provider and zamp_clear_zamp_store should have an authority check.

https://github.com/Goala/abap-metrics-provider/blob/d2e02d8147150ba48a438d863cf7246f13b91734/src/zamp_scraper/zcl_amp_scraper.clas.abap#L25

Should the scenario only be used in the component provider or also in the scrapper.
A scenario could be a bracket around the metrics for specific collection frequency, but it can also be used from different metric targets.

This only affects the query on the metric store.

https://blogs.sap.com/2020/03/11/create-sap-performance-analysis-dashboard-with-abap-download-data/

STMS_MONI
SXMB_EP_MONI
SXMB_MONI
SXMB_MONI_BPE
SXMS_MONI_DB
SXMS_MONI_IND
SXMS_MONI_JOB

That's necessary to get the right converter and the right metrics

Example with prometheus key value converter:
SID_100_prometheus_jobs_jobs_aborted
SID_100_prometheus_jobs_jobs_finished
SID_100_prometheus_runtime_errors_runtime_errors
SID_100_prometheus_workloads_workload_no_of_records

Proposal:
SID_100_prometheus_jobs_aborted
SID_100_prometheus_jobs_finished
SID_100_prometheus_runtime_errors_number
SID_100_prometheus_workloads_no_of_records

#74
#73

https://github.com/Goala/abap-metrics-provider/tree/main/local-tests/grafana/dashboards/examples_influxdb

https://github.com/Goala/abap-metrics-provider/blob/main/docs/README.md

Customizing table for scenario, metric name and collector class.
Scenario is the bracket around some metrics collector classes and can be used to schedule the jobs in different frequencies (e.g. every 5 minutes, every night at 1 a.m.)

Otherwise a previous status will not be overwritten if it does not occur in the current run.

https://github.com/Goala/abap-metrics-provider/blob/d1ff9b0685b623c56454865ebdc0a0fc936314bd/src/zamp_collector/zcl_amp_c_jobs.clas.abap#L29-L46