easy-accordion-free domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114zoho-flow domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114With Cisco FSO Platform, metrics can be reported directly from the code. Unlike using any kind of auto-instrumentation feature, this is useful when a service owner knows what needs to be reported. A\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n With Cisco FSO Platform, metrics can be reported directly from the code. Unlike using any kind of auto-instrumentation feature, this is useful when a service owner knows what needs to be reported. A typical use case would be enabling reporting of domain specific metrics \u2013 like number of items in the catalogue for e-shops, number of unfinished orders, SQL queries to specific table, etc. Basically, anything which might be interesting to observe for some period of time, or compared among different implementation versions.<\/p>\n Open Telemetry<\/a> has a recommended way of how the metric reporting should be routed to any software. The service which will be reporting the data is going to send them to the open telemetry collector<\/a>, which is a quite convenient universal receiver, processor and exported of (not only) open telemetry formatted data. Open Telemetry collector will then be configured to relay all the data to the FSO Platform tenant.<\/p>\n The first thing that you need to secure is a FSO Platform<\/a> tenant, to which the data will flow. I happen to have one ready, but I need to get the principal and clientId and clientSecret used to export data. After logging in, I opened a \u201cConfiguration\u201d tab, then selected \u201cKubernetes and APM,\u201d named my configuration, and followed the information presented to me:<\/p>\n FSO Platform \u2013 Getting Agent Principal<\/em><\/p>\n That should be all I need to configure my Open Telemetry collector.<\/p>\n Next, I used Docker image otel\/opentelemetry-collector-contrib:latest<\/strong>, since that\u2019s the simplest way for me to run the collector. All I need to do is to provide the right configuration, which is done by supplying \u2013config<\/strong>\u00a0parameter.<\/p>\n After some short research, I decided to use the following configuration:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n Then the only thing left to do is to start the collector:<\/p>\n % docker run –rm -t -v $PWD\/otel-config.yaml:\/etc\/otel-collector-config.yaml
The collector starts really quickly, I only verified that all the extensions I added are initialised, no errors printed out.<\/p>\n My go-to language is Java, so lets try that first. Open Telemetry provides a quite extensive list of SDK libraries for any modern languages<\/a> and runtimes. The Java SDK<\/a> seems to be the most mature one on that list. This doesn\u2019t mean that Java is the only choice. Realistically, there is already support for reporting Open Telemetry data from any actively used language. And if not, there is always an option to report data using different receivers<\/a>. For example, you can use Prometheus or Zipkin support which your programming or runtime environment already has.<\/p>\n Since I don\u2019t have any application ready for this experiment, I chose to do the\u00a0manual instrumentation<\/a> (it will most likely be more fun anyway).<\/p>\n After setting up a project and a dependency on the latest SDK version available (1.29.0), I put together the following class package com.cisco.fso:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n Let\u2019s go through some important parts of this code snippet.<\/p>\n First one is the\u00a0Resource<\/a> declaration. In Open Telemetry, every data point needs to be reported in the context of a resource, including metrics. Here I am declaring my resource as something with the attributes service.name <\/strong>and service.instance.id<\/strong> \u2014\u00a0which is a\u00a0de-facto standard<\/a>, described as part of the Open Telemetry semantic conventions.<\/p>\n If you explore that space more, you\u2019ll find lots of other conventions, defining which resource attributes should be reported for various components, like container, pod, service running deployed on some cloud provider and many more. By using service.name<\/strong> and service.instance.id<\/strong>, we are reporting a service. On FSO Platform this is mapped to the type apm:service_instance<\/strong>.<\/p>\n Another part worth mentioning is the metric initialization. You can see that I named my metric \u201cmy.first.metric\u201d, set the type to\u00a0gauge<\/a>, declared that it will be reporting long values, and registered a callback, which does return random long values. Not very useful, but should be good enough to get some data in.<\/p>\n After executing the program, you will see new logs reported by the Open Telemetry Collector we started before:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n This is a good sign that the data arrived from my Java program to the collector. Also, the collector contains further logs which suggest that it was able to report the data to the platform. So, let\u2019s get back to the browser and check out whether we can see reported data.<\/p>\n FSO Platform \u2013 Cloud Native Application Observability \u2013 Service Entity view<\/em><\/p>\n Apparently my service was registered by the platform, but there are not much data reported. And, any metrics which are displayed by default, are not populated. Why is that happening?<\/p>\n All the metrics which are there are derived from spans and traces which would be reported by any standard APM Service and even any framework which you\u2019d be using. The Open Telemetry SDK has nice auto-discoverable features for Spring, Micronaut, and other tools you might be using. After putting some load to your service, you would see those. But that\u2019s not what we want to do today. We want to see our very important \u201cmy.first.metric\u201d data points.<\/p>\n For that, we will need to use Query Builder, a System Application of FSO Platform, which allows you to query stored data directly using Unified Query Language<\/a>.<\/p>\n FETCH metrics(dynamicmetrics:my.first.metric)
This particular query fetches the reported metric for the\u00a0apm:service_instance<\/strong>,\u00a0which was mapped from the resource reported using the Java snippet above. It retrieves values of a metric\u00a0my.first.metric<\/strong>\u00a0and shows them on the output. The\u00a0dynamicmetrics<\/strong>\u00a0string represents a special namespace for metrics, which were ingested but are not defined in any of the\u00a0solutions<\/a>\u00a0which the current tenant is currently\u00a0subscribed\u00a0to.<\/p>\n FSO Platform \u2013 Query Builder<\/p>\n Obviously, this is only the beginning and most of you wouldn\u2019t be only reporting custom metrics by hand, you\u2019d be instrumenting code of your existing applications, infrastructure, cloud providers and anything you can model.<\/p>\n Ready to try? Get stated with Cisco FSO Platform<\/a>\u00a0<\/strong><\/p>\n Learn more: Visit the Cisco Full Stack Observability resources hub<\/a><\/p>\n \u00a0\u00a0With Cisco FSO Platform, metrics can be reported directly from the code. This blog gives you hands-on guidance on how to set this up.\u00a0\u00a0Read More<\/a>\u00a0Cisco Blogs\u00a0<\/p>","protected":false},"excerpt":{"rendered":" <\/p>\n With Cisco FSO Platform, metrics can be reported directly from the code. Unlike using any kind of auto-instrumentation feature, this is useful when a service owner knows what needs to be reported. A\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n With Cisco FSO Platform, metrics can be reported directly from the code. Unlike using any kind of auto-instrumentation feature, this is useful when a service owner knows what needs to be reported. A typical use case would be enabling reporting of domain specific metrics \u2013 like number of items in the catalogue for e-shops, number of unfinished orders, SQL queries to specific table, etc. Basically, anything which might be interesting to observe for some period of time, or compared among different implementation versions.<\/p>\n Open Telemetry<\/a> has a recommended way of how the metric reporting should be routed to any software. The service which will be reporting the data is going to send them to the open telemetry collector<\/a>, which is a quite convenient universal receiver, processor and exported of (not only) open telemetry formatted data. Open Telemetry collector will then be configured to relay all the data to the FSO Platform tenant.<\/p>\n The first thing that you need to secure is a FSO Platform<\/a> tenant, to which the data will flow. I happen to have one ready, but I need to get the principal and clientId and clientSecret used to export data. After logging in, I opened a \u201cConfiguration\u201d tab, then selected \u201cKubernetes and APM,\u201d named my configuration, and followed the information presented to me:<\/p>\n FSO Platform \u2013 Getting Agent Principal<\/em><\/p>\n That should be all I need to configure my Open Telemetry collector.<\/p>\n Next, I used Docker image otel\/opentelemetry-collector-contrib:latest<\/strong>, since that\u2019s the simplest way for me to run the collector. All I need to do is to provide the right configuration, which is done by supplying \u2013config<\/strong>\u00a0parameter.<\/p>\n After some short research, I decided to use the following configuration:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n Then the only thing left to do is to start the collector:<\/p>\n % docker run –rm -t -v $PWD\/otel-config.yaml:\/etc\/otel-collector-config.yaml
The collector starts really quickly, I only verified that all the extensions I added are initialised, no errors printed out.<\/p>\n My go-to language is Java, so lets try that first. Open Telemetry provides a quite extensive list of SDK libraries for any modern languages<\/a> and runtimes. The Java SDK<\/a> seems to be the most mature one on that list. This doesn\u2019t mean that Java is the only choice. Realistically, there is already support for reporting Open Telemetry data from any actively used language. And if not, there is always an option to report data using different receivers<\/a>. For example, you can use Prometheus or Zipkin support which your programming or runtime environment already has.<\/p>\n Since I don\u2019t have any application ready for this experiment, I chose to do the\u00a0manual instrumentation<\/a> (it will most likely be more fun anyway).<\/p>\n After setting up a project and a dependency on the latest SDK version available (1.29.0), I put together the following class package com.cisco.fso:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n Let\u2019s go through some important parts of this code snippet.<\/p>\n First one is the\u00a0Resource<\/a> declaration. In Open Telemetry, every data point needs to be reported in the context of a resource, including metrics. Here I am declaring my resource as something with the attributes service.name <\/strong>and service.instance.id<\/strong> \u2014\u00a0which is a\u00a0de-facto standard<\/a>, described as part of the Open Telemetry semantic conventions.<\/p>\n If you explore that space more, you\u2019ll find lots of other conventions, defining which resource attributes should be reported for various components, like container, pod, service running deployed on some cloud provider and many more. By using service.name<\/strong> and service.instance.id<\/strong>, we are reporting a service. On FSO Platform this is mapped to the type apm:service_instance<\/strong>.<\/p>\n Another part worth mentioning is the metric initialization. You can see that I named my metric \u201cmy.first.metric\u201d, set the type to\u00a0gauge<\/a>, declared that it will be reporting long values, and registered a callback, which does return random long values. Not very useful, but should be good enough to get some data in.<\/p>\n After executing the program, you will see new logs reported by the Open Telemetry Collector we started before:<\/p>\n <\/a>Click image to access the gist in Github<\/em><\/p>\n This is a good sign that the data arrived from my Java program to the collector. Also, the collector contains further logs which suggest that it was able to report the data to the platform. So, let\u2019s get back to the browser and check out whether we can see reported data.<\/p>\n FSO Platform \u2013 Cloud Native Application Observability \u2013 Service Entity view<\/em><\/p>\n Apparently my service was registered by the platform, but there are not much data reported. And, any metrics which are displayed by default, are not populated. Why is that happening?<\/p>\n All the metrics which are there are derived from spans and traces which would be reported by any standard APM Service and even any framework which you\u2019d be using. The Open Telemetry SDK has nice auto-discoverable features for Spring, Micronaut, and other tools you might be using. After putting some load to your service, you would see those. But that\u2019s not what we want to do today. We want to see our very important \u201cmy.first.metric\u201d data points.<\/p>\n For that, we will need to use Query Builder, a System Application of FSO Platform, which allows you to query stored data directly using Unified Query Language<\/a>.<\/p>\n FETCH metrics(dynamicmetrics:my.first.metric)
This particular query fetches the reported metric for the\u00a0apm:service_instance<\/strong>,\u00a0which was mapped from the resource reported using the Java snippet above. It retrieves values of a metric\u00a0my.first.metric<\/strong>\u00a0and shows them on the output. The\u00a0dynamicmetrics<\/strong>\u00a0string represents a special namespace for metrics, which were ingested but are not defined in any of the\u00a0solutions<\/a>\u00a0which the current tenant is currently\u00a0subscribed\u00a0to.<\/p>\n FSO Platform \u2013 Query Builder<\/p>\n Obviously, this is only the beginning and most of you wouldn\u2019t be only reporting custom metrics by hand, you\u2019d be instrumenting code of your existing applications, infrastructure, cloud providers and anything you can model.<\/p>\n Ready to try? Get stated with Cisco FSO Platform<\/a>\u00a0<\/strong><\/p>\n Learn more: Visit the Cisco Full Stack Observability resources hub<\/a><\/p>\nHands-on guidance on how to set this up<\/h2>\n
Open Telemetric Collector configuration<\/h2>\n
\n-p\u00a04317:4317\u00a0otel\/opentelemetry-collector-contrib:latest –config=\/etc\/otel-collector-config.yaml<\/p>\nMetric Data Source<\/h2>\n
Exploring ingested metrics using FSO Platform<\/h2>\n
\nFROM entities(apm:service_instance)[attributes(service.name)=’manualService’]<\/p>\nRelated resources<\/h2>\n
Hands-on guidance on how to set this up<\/h2>\n
Open Telemetric Collector configuration<\/h2>\n
\n-p\u00a04317:4317\u00a0otel\/opentelemetry-collector-contrib:latest –config=\/etc\/otel-collector-config.yaml<\/p>\nMetric Data Source<\/h2>\n
Exploring ingested metrics using FSO Platform<\/h2>\n
\nFROM entities(apm:service_instance)[attributes(service.name)=’manualService’]<\/p>\nRelated resources<\/h2>\n