With Cisco FSO Platform, metrics will be reported straight from the code. Not like utilizing any form of auto-instrumentation characteristic, that is helpful when a service proprietor is aware of what must be reported. A typical use case can be enabling reporting of area particular metrics – like variety of objects within the catalogue for e-shops, variety of unfinished orders, SQL queries to particular desk, and so on. Mainly, something which could be attention-grabbing to watch for some time period, or in contrast amongst completely different implementation variations.
Arms-on steering on tips on how to set this up
Open Telemetry has a really helpful method of how the metric reporting ought to be routed to any software program. The service which will likely be reporting the information goes to ship them to the open telemetry collector, which is a fairly handy common receiver, processor and exported of (not solely) open telemetry formatted knowledge. Open Telemetry collector will then be configured to relay all the information to the FSO Platform tenant.
The very first thing that you want to safe is a FSO Platform tenant, to which the information will movement. I occur to have one prepared, however I must get the principal and clientId and clientSecret used to export knowledge. After logging in, I opened a “Configuration” tab, then chosen “Kubernetes and APM,” named my configuration, and adopted the knowledge introduced to me:
That ought to be all I must configure my Open Telemetry collector.
Open Telemetric Collector configuration
Subsequent, I used Docker picture otel/opentelemetry-collector-contrib:newest, since that’s the only method for me to run the collector. All I must do is to offer the best configuration, which is finished by supplying –config parameter.
After some brief analysis, I made a decision to make use of the next configuration:
Then the one factor left to do is to begin the collector:
% docker run --rm -t -v $PWD/otel-config.yaml:/and so on/otel-collector-config.yaml -p 4317:4317 otel/opentelemetry-collector-contrib:newest --config=/and so on/otel-collector-config.yaml
The collector begins actually shortly, I solely verified that each one the extensions I added are initialised, no errors printed out.
My go-to language is Java, so lets attempt that first. Open Telemetry offers a fairly in depth checklist of SDK libraries for any trendy languages and runtimes. The Java SDK appears to be probably the most mature one on that checklist. This doesn’t imply that Java is the one alternative. Realistically, there may be already assist for reporting Open Telemetry knowledge from any actively used language. And if not, there may be all the time an choice to report knowledge utilizing completely different receivers. For instance, you should use Prometheus or Zipkin assist which your programming or runtime atmosphere already has.
Metric Knowledge Supply
Since I don’t have any utility prepared for this experiment, I selected to do the guide instrumentation (it’s going to probably be extra enjoyable anyway).
After establishing a venture and a dependency on the newest SDK model accessible (1.29.0), I put collectively the next class package deal com.cisco.fso:
Let’s undergo some necessary components of this code snippet.
First one is the Useful resource declaration. In Open Telemetry, each knowledge level must be reported within the context of a useful resource, together with metrics. Right here I’m declaring my useful resource as one thing with the attributes service.title and service.occasion.id — which is a de-facto customary, described as a part of the Open Telemetry semantic conventions.
If you happen to discover that house extra, you’ll discover a number of different conventions, defining which useful resource attributes ought to be reported for numerous parts, like container, pod, service operating deployed on some cloud supplier and plenty of extra. By utilizing service.title and service.occasion.id, we’re reporting a service. On FSO Platform that is mapped to the kind apm:service_instance.
One other half price mentioning is the metric initialization. You’ll be able to see that I named my metric “my.first.metric”, set the kind to gauge, declared that will probably be reporting lengthy values, and registered a callback, which does return random lengthy values. Not very helpful, however ought to be ok to get some knowledge in.
After executing this system, you will note new logs reported by the Open Telemetry Collector we began earlier than:
Exploring ingested metrics utilizing FSO Platform
It is a good signal that the information arrived from my Java program to the collector. Additionally, the collector incorporates additional logs which recommend that it was in a position to report the information to the platform. So, let’s get again to the browser and take a look at whether or not we are able to see reported knowledge.
Apparently my service was registered by the platform, however there are usually not a lot knowledge reported. And, any metrics that are displayed by default, are usually not populated. Why is that taking place?
All of the metrics that are there are derived from spans and traces which might be reported by any customary APM Service and even any framework which you’d be utilizing. The Open Telemetry SDK has good auto-discoverable options for Spring, Micronaut, and different instruments you could be utilizing. After placing some load to your service, you’ll see these. However that’s not what we need to do in the present day. We need to see our crucial “my.first.metric” knowledge factors.
For that, we might want to use Question Builder, a System Software of FSO Platform, which lets you question saved knowledge straight utilizing Unified Question Language.
FETCH metrics(dynamicmetrics:my.first.metric) FROM entities(apm:service_instance)[attributes(service.name)='manualService']
This explicit question fetches the reported metric for the apm:service_instance, which was mapped from the useful resource reported utilizing the Java snippet above. It retrieves values of a metric my.first.metric and exhibits them on the output. The dynamicmetrics string represents a particular namespace for metrics, which have been ingested however are usually not outlined in any of the options which the present tenant is at the moment subscribed to.
Clearly, that is solely the start and most of you wouldn’t be solely reporting customized metrics by hand, you’d be instrumenting code of your present functions, infrastructure, cloud suppliers and something you possibly can mannequin.
Able to attempt? Get said with Cisco FSO Platform
Associated assets
Share:
