Hei igjen, Observability-venner! I forrige artikkel introduserte jeg OpenTelemetry (OTEL) og hvorfor det er fremtiden for Observability. Nå skal vi ta på oss dykkerdrakten og utforske de dypere lagene av OTEL-dammen. Ikke vær redd – vi har redningsvest i form av enkle forklaringer og kodeeksempler!

OTEL-oppskriften: Ingredienser og krydder i detalj

1. Spesifikasjonen: Den hellige gralen

OTEL-spesifikasjonen er selve bibelen for Observability. Den definerer hvordan ting skal gjøres på tvers av språk og plattformer. Her er noen viktige punkter:

• Stabilitet: OTEL lover bakoverkompatibilitet for APIer. Det betyr at du kan oppdatere uten å frykte at alt bryter sammen.

• Livsløp: Komponenter går gjennom faser som eksperimentell, stabil, og til slutt kanskje pensjonert.
• Ytelsesfokus: OTEL er designet for å ha minimal påvirkning på applikasjonens ytelse.

2. Signaler: Høydepunkter fra hver

Spor (Traces): Spor er som en detaljert reisedagbok for dataene dine. En span er som et stopp på reisen til dataene dine. Hver gang systemet ditt utfører en operasjon, registreres det som en span i et større trace. Her er et enkelt eksempel på hvordan du kan starte et spor i Java:

Tracer tracer = GlobalOpenTelemetry.getTracer("MinApp");
Span span = tracer.spanBuilder("MinOperasjon").startSpan();
try {
    // Din logikk her
} finally {
    span.end();
}

Metrikker: Metrikker er tallene som forteller hvor «varmt» systemet ditt er. OTEL lar deg definere målinger som kan aggregeres på ulike måter. For eksempel:

Meter meter = GlobalOpenTelemetry.getMeter("MinApp");
LongCounter counter = meter.counterBuilder("requests").build();

for (int i = 0; i < 10; i++) {
    counter.add(1); // Øk telleren med 1 for hver iterasjon
}

Logger: Logger er den gamle traveren, men OTEL gir dem nytt liv ved å knytte dem til spor og metrikker. OTEL fokuserer på å kontekstualisere eksisterende logger, ikke på å erstatte dem.

Bagasje (Baggage): Bagasje er som en ryggsekk full av nyttig info som følger med på data-reisen. Dette er den ekstra informasjonen du legger til OTEL-enheter, som for eksempel en bruker-ID eller en spor-ID, som gjør det lettere å identifisere dem senere. For eksempel:

Baggage.current()
.toBuilder()
.put("UserID", "12345")
.build()
.makeCurrent();

3. Kontekstspredning: Den magiske linken

Kontekstspredning er sausen som binder alt sammen. Det sørger for at informasjon som sporings-ID og bagasje følger med på tvers av tjenester. OTEL bruker W3C Trace Context som standard, noe som betyr at det fungerer sømløst med mange eksisterende systemer.

4. Semantiske konvensjoner: Esperanto for Observability

OTEL har definert et felles «språk» for å beskrive ting. For eksempel:

• service.name: Navnet på tjenesten din

• cloud.provider: Hvilken skyleverandør du bruker

• http.method: HTTP-metoden for en nettforespørsel

Ved å bruke disse konvensjonene, kan verktøy lettere forstå og korrelere data på tvers av systemer.

5. Ressurs: Identitetskortet til dataene dine

En ressurs i OTEL-verden er som et ID-kort for dataene dine. Det forteller hvor dataene kommer fra. Her er et eksempel på hvordan du kan definere en ressurs i Java:

Resource resource = Resource.getDefault()
.merge(Resource.create(Attributes.of(
ResourceAttributes.SERVICE_NAME, "min-awesome-app",
ResourceAttributes.SERVICE_VERSION, "1.0"
)));

6. Collector: Den hardtarbeidende mellommannen

OTEL Collector er som en sentralbordoperatør for telemetridata. Den kan:

• Motta data i mange formater (OTLP, Jaeger, Prometheus, etc.)

• Prosessere og transformere data

• Sende data videre til ulike backends

Dataene samles inn via pipelines, hvor du kan definere hvordan dataene skal mottas, behandles og sendes videre. For eksempel, sporingsdata kan mottas via OTLP og eksporteres til en backend som Prometheus.

Du kan konfigurere en Collector med en YAML-fil, for eksempel:

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

7. OTLP-protokollen: Den lynraske dataekspressen

OTLP (OpenTelemetry Protocol) er designet for å være rask og effektiv. Den bruker Protocol Buffers for serialisering og støtter både gRPC og HTTP/protobuf.

Hvorfor er dette så kult? Dypere dykk

1. Standardisering: Med OTEL slipper du å bekymre deg for om verktøyene dine snakker samme språk. Alt er designet for å fungere sømløst sammen.
2. Fleksibilitet: Bytt ut backends uten å røre instrumenteringskoden. For eksempel, hvis du vil bytte fra Jaeger til Zipkin for sporingsdata, trenger du bare å endre konfigurasjonen, ikke koden.
3. Fremtidssikring: OTEL er et CNCF-prosjekt med bred støtte i industrien. Det betyr at det sannsynligvis vil være relevant i mange år fremover.
4. Bedre feilsøking: Med korrelerte data på tvers av spor, metrikker og logger, blir det mye enklere å finne rotårsaken til problemer.

Hvordan kommer du i gang?

• Automatisk instrumentering: Mange starter med automatisk instrumentering for raskt å få innsikt i hvordan systemet deres oppfører seg. Etter dette kan du legge til manuell instrumentering for å få enda mer innsikt i koden din.
• Start med å legge til OTEL-avhengigheter i prosjektet ditt. For Java, kan du for eksempel bruke Gradle:

dependencies {
    implementation platform("io.opentelemetry:opentelemetry-bom:1.21.0")
    implementation 'io.opentelemetry:opentelemetry-api'
    implementation 'io.opentelemetry:opentelemetry-sdk'
    implementation 'io.opentelemetry:opentelemetry-exporter-otlp'
}

• Konfigurer en global OpenTelemetry-instans:

SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
    .addSpanProcessor(
        BatchSpanProcessor.builder(OtlpGrpcSpanExporter.builder().build()).build()
    )    
    .setResource(
        Resource.getDefault().merge(
            Resource.create(Attributes.of(ResourceAttributes.SERVICE_NAME, "min-service"))
        )
    )
    .build();


OpenTelemetry openTelemetry = OpenTelemetrySdk.builder()
    .setTracerProvider(sdkTracerProvider)
    .build();

• Start med å instrumentere noen nøkkeloperasjoner i koden din. Bruk semantiske konvensjoner der det er mulig.

• Sett opp en OTEL Collector for å samle og eksportere data til ditt foretrukne backend-system.

• Gradvis utvid instrumenteringen etter hvert som du blir mer komfortabel med OTEL.

Husk, Rom ble ikke bygget på en dag, og et perfekt Observability-system blir det heller ikke. Men med OTEL har du verktøyene du trenger for å bygge et førsteklasses Observability-system. I neste artikkel skal vi dykke enda dypere og se på avanserte teknikker for OTEL-instrumentering. Så hold pusten og gjør deg klar for neste dykk i OTEL-havet!