<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Where can I find the list of SAS metrics exposed for Prometheus scraper? in Administration and Deployment</title>
    <link>https://communities.sas.com/t5/Administration-and-Deployment/Where-can-I-find-the-list-of-SAS-metrics-exposed-for-Prometheus/m-p/980040#M30494</link>
    <description>&lt;P&gt;There is no list of metrics exposed by the components of SAS Viya 4.&amp;nbsp; However, because SAS Viya has been instrumented using the Prometheus model, it is fairly straightforward to collect this information on your own.&amp;nbsp; And, since the Prometheus format is self-documentating the results will include information that helps to clarify what numbers are being returned.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The Prometheus metric model makes metrics available via an HTTP endpoint on each pod.&amp;nbsp; So, the first step is to identify that endpoint.&amp;nbsp; SAS Viya makes that easier by including the needed information in Kubernetes annotations on the pod.&amp;nbsp; In the example below, we've used the&amp;nbsp;&lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#0000FF"&gt;kubectl describe pod&lt;/FONT&gt;&lt;/STRONG&gt;&amp;nbsp;command to list the relevant annotations for one of the SAS Viya pods.&lt;/P&gt;
&lt;PRE&gt;$ kubectl -n viya describe pod sas-compute-c6d4dbfbc-tkx5k |grep prometheus

                  prometheus.io/path: /internal/metrics
                  prometheus.io/port: 8080
                  prometheus.io/scheme: https
                  prometheus.io/scrape: true
&lt;/PRE&gt;
&lt;P data-unlink="true"&gt;From that information, we can construct the URL needed to scrape the metrics from the pod.&amp;nbsp; However, since that endpoint will only be available from &lt;EM&gt;within&lt;/EM&gt; the Kubernetes cluster itself, we'll need to use either Kubernetes port-forwarding to make it externally accessible or access it from inside the cluster in some way.&amp;nbsp;&amp;nbsp;I think the &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#0000FF"&gt;kubectl exec&lt;/FONT&gt;&lt;/STRONG&gt; command makes the latter approach fairly easy.&amp;nbsp; Using the information obtained by the above command, we can construct the following command which runs a curl command inside the pod itself to scrape the metrics endpoint:&lt;/P&gt;
&lt;P data-unlink="true"&gt;&lt;STRONG&gt;&lt;FONT face="courier new,courier"&gt;&lt;FONT color="#0000FF"&gt;kubectl -n viya exec sas-compute-c6d4dbfbc-tkx5k -- curl&lt;/FONT&gt; &lt;FONT color="#0000FF"&gt;https://localhost:8080/internal/metrics&lt;/FONT&gt;&lt;/FONT&gt;&lt;/STRONG&gt;&amp;nbsp;.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;And here's an excerpt of what we get back when we do that:&lt;/P&gt;
&lt;PRE&gt;$ kubectl -n viya exec sas-compute-c6d4dbfbc-tkx5k -- curl https://localhost:8080/internal/metrics

# HELP go_cgo_go_to_c_calls_calls_total Count of calls made from Go to C by the current process.
# TYPE go_cgo_go_to_c_calls_calls_total counter
go_cgo_go_to_c_calls_calls_total 1.9507996e+07

# HELP go_cpu_classes_gc_mark_assist_cpu_seconds_total Estimated total CPU time goroutines spent performing GC tasks to assist the GC and prevent it from falling behind the application. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.
# TYPE go_cpu_classes_gc_mark_assist_cpu_seconds_total counter
go_cpu_classes_gc_mark_assist_cpu_seconds_total 0.27903992

# HELP go_cpu_classes_gc_mark_dedicated_cpu_seconds_total Estimated total CPU time spent performing GC tasks on processors (as defined by GOMAXPROCS) dedicated to those tasks. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.
# TYPE go_cpu_classes_gc_mark_dedicated_cpu_seconds_total counter
go_cpu_classes_gc_mark_dedicated_cpu_seconds_total 7.690484447
&lt;/PRE&gt;
&lt;P&gt;This output excerpt shows 3 metrics (there are quite a few more).&amp;nbsp; You can see the self-documenting features I mentioned: each metric is preceded by a &lt;FONT color="#339966"&gt;&lt;STRONG&gt;&lt;FONT face="courier new,courier"&gt;#HELP&lt;/FONT&gt; &lt;/STRONG&gt;&lt;/FONT&gt;and a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;#TYPE &lt;/FONT&gt;&lt;/STRONG&gt;line.&amp;nbsp; The &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;HELP &lt;/FONT&gt;&lt;/STRONG&gt;line provides the name of the metric (e.g.&amp;nbsp;&lt;FONT color="#339966"&gt;&lt;EM&gt;&lt;FONT face="courier new,courier"&gt;go_cpu_classes_gc_mark_assist_cpu_seconds_total&lt;/FONT&gt;&lt;/EM&gt;&lt;/FONT&gt;) and a short text description (e.g.&amp;nbsp;&lt;FONT color="#339966"&gt;&lt;EM&gt;&lt;FONT face="courier new,courier"&gt;Estimated total CPU time goroutines spent performing GC tasks to assist the GC and prevent it from falling behind the application. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.&lt;/FONT&gt;&lt;/EM&gt;&lt;/FONT&gt;)&amp;nbsp; of the metric.&amp;nbsp; &amp;nbsp;The &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;TYPE &lt;/FONT&gt;&lt;/STRONG&gt;line repeats the metric name and identifies the type of metric: a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;counter&amp;nbsp;&lt;/FONT&gt;&lt;/STRONG&gt;metric is a number that only moves in one direction (something like elapsed time, for example) while a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;gauge &lt;/FONT&gt;&lt;/STRONG&gt;metric is a number that can move up or down (e.g. something like CPU usage).&amp;nbsp; Refer to the &lt;A href="https://prometheus.io/docs/concepts/metric_types/" target="_blank" rel="noopener"&gt;Prometheus documentation&lt;/A&gt; for a complete list of metric types.&amp;nbsp; The third line returned (that does not start with a #) is the actual metric value.&amp;nbsp; &amp;nbsp;I should mention that the set of metrics returned by a component may change over time or between releases.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Greg Smith&lt;/P&gt;
&lt;P&gt;Principal Software Developer&lt;/P&gt;
&lt;P&gt;SAS&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 04 Dec 2025 17:22:10 GMT</pubDate>
    <dc:creator>sasgzs</dc:creator>
    <dc:date>2025-12-04T17:22:10Z</dc:date>
    <item>
      <title>Where can I find the list of SAS metrics exposed for Prometheus scraper?</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Where-can-I-find-the-list-of-SAS-metrics-exposed-for-Prometheus/m-p/979637#M30485</link>
      <description>&lt;P&gt;I am looking for the complete list of SAS Viya metrics exposed by SAS pods/services etc. for Prometheus.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is this documented anywhere?&lt;/P&gt;</description>
      <pubDate>Thu, 27 Nov 2025 06:56:06 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Where-can-I-find-the-list-of-SAS-metrics-exposed-for-Prometheus/m-p/979637#M30485</guid>
      <dc:creator>EyalGonen</dc:creator>
      <dc:date>2025-11-27T06:56:06Z</dc:date>
    </item>
    <item>
      <title>Re: Where can I find the list of SAS metrics exposed for Prometheus scraper?</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Where-can-I-find-the-list-of-SAS-metrics-exposed-for-Prometheus/m-p/980040#M30494</link>
      <description>&lt;P&gt;There is no list of metrics exposed by the components of SAS Viya 4.&amp;nbsp; However, because SAS Viya has been instrumented using the Prometheus model, it is fairly straightforward to collect this information on your own.&amp;nbsp; And, since the Prometheus format is self-documentating the results will include information that helps to clarify what numbers are being returned.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The Prometheus metric model makes metrics available via an HTTP endpoint on each pod.&amp;nbsp; So, the first step is to identify that endpoint.&amp;nbsp; SAS Viya makes that easier by including the needed information in Kubernetes annotations on the pod.&amp;nbsp; In the example below, we've used the&amp;nbsp;&lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#0000FF"&gt;kubectl describe pod&lt;/FONT&gt;&lt;/STRONG&gt;&amp;nbsp;command to list the relevant annotations for one of the SAS Viya pods.&lt;/P&gt;
&lt;PRE&gt;$ kubectl -n viya describe pod sas-compute-c6d4dbfbc-tkx5k |grep prometheus

                  prometheus.io/path: /internal/metrics
                  prometheus.io/port: 8080
                  prometheus.io/scheme: https
                  prometheus.io/scrape: true
&lt;/PRE&gt;
&lt;P data-unlink="true"&gt;From that information, we can construct the URL needed to scrape the metrics from the pod.&amp;nbsp; However, since that endpoint will only be available from &lt;EM&gt;within&lt;/EM&gt; the Kubernetes cluster itself, we'll need to use either Kubernetes port-forwarding to make it externally accessible or access it from inside the cluster in some way.&amp;nbsp;&amp;nbsp;I think the &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#0000FF"&gt;kubectl exec&lt;/FONT&gt;&lt;/STRONG&gt; command makes the latter approach fairly easy.&amp;nbsp; Using the information obtained by the above command, we can construct the following command which runs a curl command inside the pod itself to scrape the metrics endpoint:&lt;/P&gt;
&lt;P data-unlink="true"&gt;&lt;STRONG&gt;&lt;FONT face="courier new,courier"&gt;&lt;FONT color="#0000FF"&gt;kubectl -n viya exec sas-compute-c6d4dbfbc-tkx5k -- curl&lt;/FONT&gt; &lt;FONT color="#0000FF"&gt;https://localhost:8080/internal/metrics&lt;/FONT&gt;&lt;/FONT&gt;&lt;/STRONG&gt;&amp;nbsp;.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;And here's an excerpt of what we get back when we do that:&lt;/P&gt;
&lt;PRE&gt;$ kubectl -n viya exec sas-compute-c6d4dbfbc-tkx5k -- curl https://localhost:8080/internal/metrics

# HELP go_cgo_go_to_c_calls_calls_total Count of calls made from Go to C by the current process.
# TYPE go_cgo_go_to_c_calls_calls_total counter
go_cgo_go_to_c_calls_calls_total 1.9507996e+07

# HELP go_cpu_classes_gc_mark_assist_cpu_seconds_total Estimated total CPU time goroutines spent performing GC tasks to assist the GC and prevent it from falling behind the application. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.
# TYPE go_cpu_classes_gc_mark_assist_cpu_seconds_total counter
go_cpu_classes_gc_mark_assist_cpu_seconds_total 0.27903992

# HELP go_cpu_classes_gc_mark_dedicated_cpu_seconds_total Estimated total CPU time spent performing GC tasks on processors (as defined by GOMAXPROCS) dedicated to those tasks. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.
# TYPE go_cpu_classes_gc_mark_dedicated_cpu_seconds_total counter
go_cpu_classes_gc_mark_dedicated_cpu_seconds_total 7.690484447
&lt;/PRE&gt;
&lt;P&gt;This output excerpt shows 3 metrics (there are quite a few more).&amp;nbsp; You can see the self-documenting features I mentioned: each metric is preceded by a &lt;FONT color="#339966"&gt;&lt;STRONG&gt;&lt;FONT face="courier new,courier"&gt;#HELP&lt;/FONT&gt; &lt;/STRONG&gt;&lt;/FONT&gt;and a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;#TYPE &lt;/FONT&gt;&lt;/STRONG&gt;line.&amp;nbsp; The &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;HELP &lt;/FONT&gt;&lt;/STRONG&gt;line provides the name of the metric (e.g.&amp;nbsp;&lt;FONT color="#339966"&gt;&lt;EM&gt;&lt;FONT face="courier new,courier"&gt;go_cpu_classes_gc_mark_assist_cpu_seconds_total&lt;/FONT&gt;&lt;/EM&gt;&lt;/FONT&gt;) and a short text description (e.g.&amp;nbsp;&lt;FONT color="#339966"&gt;&lt;EM&gt;&lt;FONT face="courier new,courier"&gt;Estimated total CPU time goroutines spent performing GC tasks to assist the GC and prevent it from falling behind the application. This metric is an overestimate, and not directly comparable to system CPU time measurements. Compare only with other /cpu/classes metrics.&lt;/FONT&gt;&lt;/EM&gt;&lt;/FONT&gt;)&amp;nbsp; of the metric.&amp;nbsp; &amp;nbsp;The &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;TYPE &lt;/FONT&gt;&lt;/STRONG&gt;line repeats the metric name and identifies the type of metric: a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;counter&amp;nbsp;&lt;/FONT&gt;&lt;/STRONG&gt;metric is a number that only moves in one direction (something like elapsed time, for example) while a &lt;STRONG&gt;&lt;FONT face="courier new,courier" color="#339966"&gt;gauge &lt;/FONT&gt;&lt;/STRONG&gt;metric is a number that can move up or down (e.g. something like CPU usage).&amp;nbsp; Refer to the &lt;A href="https://prometheus.io/docs/concepts/metric_types/" target="_blank" rel="noopener"&gt;Prometheus documentation&lt;/A&gt; for a complete list of metric types.&amp;nbsp; The third line returned (that does not start with a #) is the actual metric value.&amp;nbsp; &amp;nbsp;I should mention that the set of metrics returned by a component may change over time or between releases.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Greg Smith&lt;/P&gt;
&lt;P&gt;Principal Software Developer&lt;/P&gt;
&lt;P&gt;SAS&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 04 Dec 2025 17:22:10 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Where-can-I-find-the-list-of-SAS-metrics-exposed-for-Prometheus/m-p/980040#M30494</guid>
      <dc:creator>sasgzs</dc:creator>
      <dc:date>2025-12-04T17:22:10Z</dc:date>
    </item>
  </channel>
</rss>

