OpenTelemetry sa produksyon: Itigil ang pag-debug sa dilim

Ang unang pagkakataon na talagang kailangan mo ng pagmamasid ay hindi kapag kalmado kang tumitingin sa isang dashboard. Ito ay kapag isinulat ng isang user ang "mabagal ang pag-checkout", ang graph ng error ay mukhang normal at sa mga log ay makikita mo lamang ang isang hilera ng mga nakadiskonektang mensahe.

Ginawa ang OpenTelemetry upang maiwasan ang sandaling iyon: hindi para magkaroon ng mas maraming graphics, ngunit para ikonekta ang mga piraso. Ang isang kahilingan ay pumapasok sa API, tumatawag sa isang database, dumaan sa isang panlabas na provider, nag-post ng isang nakapila na trabaho, at maaaring mabigo ang tatlong serbisyo sa ibang pagkakataon. Nang walang distributed tracing, i-reconstruct mo ang kwentong iyon sa pamamagitan ng kamay. Sa OpenTelemetry at least mayroon kang mapa.

Ang punto ay hindi ang trace, ito ay ang kuwento

Ang trace ay isang sequence ng span. Maglagay ng ganyan parang malamig. Sa pagsasagawa, ang bawat span ay isang piraso ng kuwento: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Dumarating ang halaga kapag sinimulan mong sagutin ang mga totoong tanong:

aling panlabas na serbisyo ang bumabagal?
nagmula ba ang mga error sa isang partikular na bersyon?
nakakaapekto ba ang problema sa lahat o isang nangungupahan lang?
ang muling pagtatago ba ay isang timeout?
ang asynchronous na trabaho ay nagsisimula ngunit pagkatapos ay namatay sa ibang lugar?

Ang mga tanong na ito ay hindi malulutas sa pamamagitan ng isang console.log itinapon sa pagmamadali. Sa katunayan, kadalasan ang log na idinagdag sa isang emergency ay nakakatulong sa iyo ngayon at nagiging ingay bukas.

Paano ko ito ilalagay sa isang app Node.js

Ang pinakamalusog na setup ay simple: ang app ay gumagawa ng telemetry, ang Collector ang magpapasya kung saan ito ipapadala.

Node.js app -> OpenTelemetry Collector -> backend di observability

Bakit hindi direktang i-export sa vendor? Dahil sa una ay tila mas mabilis, pagkatapos ay napagtanto mo na ang bawat serbisyo ay may iba't ibang mga pagsasaayos, iba't ibang mga muling pagsubok, iba't ibang mga filter at walang sentrong punto upang alisin ang sensitibong data o baguhin ang patutunguhan.

Ang Collector ay nakakabagot sa lahat ng tamang paraan. Nakakatanggap ito ng OTLP, gumagawa ng batching, nakakapag-filter, nakakagawa ng sampling, nakakapagdagdag ng mga karaniwang attribute at nakakapag-export sa maraming system.

Self-instrumentation: mabuti, ngunit hindi sapat

Sa Node.js magsisimula ako sa auto-instrumentation. Nagbibigay ito sa iyo ng agarang pagpapakita sa HTTP, mga sinusuportahang framework, database at karaniwang mga aklatan.

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

Pagkatapos ay simulan mo ang SDK bago ang natitirang bahagi ng app:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Gayunpaman, nakikita nito ang balangkas, hindi ang iyong produkto. Alam nitong gumawa ka ng query, ngunit hindi nito alam na ang query ay nasa "lumikha ng pagkakasunud-sunod" o "i-renew ang subscription." Para diyan kailangan mo ng span mga manwal sa mga punto kung saan mahalaga ang pangingibabaw.

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

Hindi ko ilalagay ang span mga manual kahit saan. Ilalagay ko sila kung saan, alas tres ng umaga, gusto kong maunawaan kung ano ang nangyari nang hindi binabasa ang kalahati ng base ng code.

Tatlong panuntunan na umiiwas sa maraming kaguluhan

Unang tuntunin: ang bawat serbisyo ay dapat may service.name, kapaligiran at bersyon. Mukhang walang halaga, ngunit kung wala ang mga katangiang ito, ang trace ay hindi gaanong kapaki-pakinabang. Kapag may nasira ang isang deploy, gusto mong mag-filter ayon sa bersyon sa loob ng dalawang segundo.

Pangalawang panuntunan: huwag maglagay ng sensitibong data sa mga katangian. Ang mga email, token, integer payload, at address ay hindi dapat mapunta sa isang observability backend nang hindi sinasadya. Kung kailangan mong tumukoy ng user, isaalang-alang ang mga internal na ID, pag-hash, o mga field na hindi gaanong sensitibo.

Pangatlong panuntunan: bigyang-pansin ang kardinalidad. Ang user.id bilang katangian ng trace ay maaaring magkaroon ng kahulugan. Bilang isang label ng sukatan, maaari nitong sirain ang iyong mga gastos at pagganap.

Mga Sukatan: kakaunti, ngunit mabuti

Magsisimula ako sa napakapraktikal na sukatan:

mga rate, mga error at tagal ng mga kahilingan;
latency ng mga panlabas na dependencies;
bilang ng mga timeout at muling pagsubok;
lalim ng mga buntot;
tagal ng trabaho;
porsyento ng mga error sa bawat bersyon.

Ang natitira ay idinagdag kung kinakailangan. Ang mga dashboard na puno ng mga graph na walang tinitingnan ay mga kasangkapan, hindi pagmamasid.

Mga Log: Kapaki-pakinabang pa rin, ngunit naka-link

Ang mga log ay hindi nawawala. Sila ay nagiging mas kapaki-pakinabang kapag sila ay nagdadala ng trace_id at span_id. Kaya maaari kang magsimula sa isang log ng error at buksan ang trace, o magsimula sa mabagal na trace at basahin lamang ang mga log na ginawa sa landas na iyon.

Kung walang ugnayan, naghahanap ka ng mga karayom. Sa ugnayan, at least alam mo kung aling drawer ang titingnan.

Ang checklist na gagamitin ko bago sabihin ang "kami ay sakop"

Ang trace ay talagang tumatawid sa maraming serbisyo.
Kasama sa mga log ang trace_id at span_id.
Ang Collector ay naka-configure sa batching at mga limitasyon sa memorya.
Ang mga error ay naitala sa span.
May patakaran sa pag-sample.
Ang mga sukatan ay may kinokontrol na kardinalidad.
Sinasala ang sensitibong data.
Nagsisimula ang mga alerto sa mga sintomas ng user, hindi sa mga random na graph.

Konklusyon

Hindi nilulutas ng OpenTelemetry ang mga problema sa produksyon nang mag-isa. Ngunit ang paraan ng pakikitungo mo sa kanila ay nagbabago. Sa halip na bulag na magdagdag ng mga log, sisimulan mong sundin ang aktwal na landas ng isang kahilingan.

Para sa akin ang senyales na ito ay gumagana ay simple: kapag may nangyari, ang koponan ay hihinto sa pagtatanong ng "saan tayo tumitingin?" at magsisimulang magtanong "bakit mabagal ang pirasong iyon?". Doon nagiging tool ang observability, hindi isang koleksyon ng mga dashboard.

Mga Pinagmulan