Varsling og alarmer¶

Plattformen har fire måter å varsle på: varsler fra jobber, varsler fra pipelines, SQL-alarmer og ferskhetsvarselet fra bundle-malen. Teamet setter opp alle fire selv, i bundlen sammen med ressursen de gjelder. Hvorfor ansvaret er delt slik, står det om i Overvåking.

Varslingskanaler¶

Et varsel sendes på e-post eller til en notification destination. E-postadresser skriver du rett inn i konfigurasjonen til jobben, pipelinen eller alarmen. En notification destination er et objekt i workspacet som lagrer det som trengs for å nå en annen kanal, for eksempel en Slack-webhook.

Notification destinations opprettes og endres av en workspace-admin, det vil si teamets egen admingruppe. Når destinasjonen finnes, kan alle i workspacet bruke den. Konfigurasjonen lagres kryptert i workspacet. Jobber, pipelines og alarmer peker på destinasjonen med ID-en dens, som du finner med databricks notification-destinations list. I en bundle kan en variabel slå opp ID-en fra navnet med lookup: notification_destination. Se Sette opp Slack-varsler for oppsettet.

Varsler på jobber¶

En jobb sender varsler ved hendelser i kjøringen. Varslene konfigureres i to felt på jobben: email_notifications sender e-post, og webhook_notifications sender til notification destinations, inntil tre per hendelse. Hendelsene er:

De to siste hendelsene krever at jobben har en regel under health.rules. En regel sier at en metrikk ikke skal overstige en terskel, med operatoren GREATER_THAN og en verdi. RUN_DURATION_SECONDS måler kjøretiden i sekunder. Metrikkene for etterslep i strømmer, STREAMING_BACKLOG_*, er beskrevet i Add notifications on a job.

Under notification_settings kan du begrense varslene:

Alle feltene kan stå på jobben eller på hver enkelt task. Et varsel på jobben sendes én gang per kjøring, selv om en task feiler og prøves på nytt flere ganger underveis. Et varsel på tasken sendes for hvert enkelt feilede forsøk.

Eksempel på en jobb som sender e-post ved feil og lang kjøretid, og i tillegg varsler i Slack ved feil:

resources:
  jobs:
    paddeobservasjoner:
      name: paddeobservasjoner
      email_notifications:
        on_failure:
          - padda@example.org
        on_duration_warning_threshold_exceeded:
          - padda@example.org
      webhook_notifications:
        on_failure:
          - id: ${var.slack_destination_id}
      health:
        rules:
          - metric: RUN_DURATION_SECONDS
            op: GREATER_THAN
            value: 3600
      notification_settings:
        no_alert_for_skipped_runs: true

Destinasjonen har ulik ID i hvert workspace. Derfor settes ID-en som en variabel per target i databricks.yml.

Varsler på pipelines¶

En pipeline har egne varsler under notifications, uavhengig av jobben som eventuelt kjører den. Hvert varsel har en liste med e-postadresser i email_recipients og en liste med hendelser i alerts:

resources:
  pipelines:
    paddeobservasjoner:
      name: paddeobservasjoner
      notifications:
        - email_recipients:
            - padda@example.org
          alerts:
            - on-update-fatal-failure
            - on-flow-failure

Pipelinevarsler kan bare gå på e-post. Kjører pipelinen som en task i en jobb, feiler jobben når pipelinen feiler, og jobbens varsler sendes. Det er slik en feilet pipeline når Slack.

SQL-alarmer¶

En SQL-alarm, SQL alert i Databricks, er en SQL-spørring som kjører på tidsplan mot et SQL Warehouse, og som varsler når resultatet bryter en betingelse, for eksempel at data ikke kom, eller at en karantenetabell har fått nye rader.

En alarm består av:

Hver gang alarmen kjører, får den tilstanden OK, TRIGGERED eller ERROR. Varsel sendes når alarmen blir TRIGGERED. retrigger_seconds er minste antall sekunder mellom to varsler mens alarmen fortsatt er utløst. Med notify_on_ok får du også varsel når alarmen går tilbake til OK.

Alarmer defineres som ressursen alerts i bundlen. Eksemplet under varsler når karantenetabellen fra Håndtere rader som ikke lar seg konvertere har fått nye rader det siste døgnet:

resources:
  alerts:
    karantene_nye_rader:
      display_name: Nye rader i karantene for paddeobservasjoner
      warehouse_id: ${var.warehouse_id}
      query_text: |
        SELECT *
        FROM ${var.catalog}.silver_default.paddeobservasjoner_karantene
        WHERE lagt_i_karantene > current_timestamp() - INTERVAL 1 DAY
      evaluation:
        source:
          name: observasjon_id
          aggregation: COUNT
        comparison_operator: GREATER_THAN
        threshold:
          value:
            double_value: 0
        empty_result_state: OK
        notification:
          subscriptions:
            - user_email: padda@example.org
            - destination_id: ${var.slack_destination_id}
      schedule:
        quartz_cron_schedule: 0 0 7 * * ?
        timezone_id: Europe/Oslo

Spørringen kjører som identiteten i run_as, som må ha lesetilgang til tabellene den spør mot. En alarm kan også evalueres av en egen task i en jobb, for eksempel rett etter pipelinen som fyller tabellen. Tasken evaluerer alarmen når jobben kjører, mens alarmens egen tidsplan fortsetter uavhengig. Se SQL alert task for jobs.

Ferskhetsvarsel¶

Ferskhetsvarselet er en jobb fra bundle-malen som feiler når en overvåket tabell ikke har fått nye data innenfor maksalderen sin. Feilen varsles som for andre jobber, med webhook_notifications. Oppsettet står i Sette opp ferskhetsvarsel.

Malvalget include_freshness_alert¶

slack_destination_id slår opp destinasjonen med navnet REPLACE_WITH_DESTINATION_NAME i både stage og prod, så databricks bundle validate og deploy feiler til navnet er byttet ut. Med eksempeljobbene overvåker den genererte jobben tabellen bronze_nyctaxi fra eksempelpipelinen. Uten eksempeljobbene (include_example_jobs: no) overvåker den en plassholder, TODO_table, som ikke kan sjekkes før den er byttet ut.

Jobben¶

Tidsplanen har pause_status: PAUSED, så jobben kjører bare når noen starter den. Med pause_status: UNPAUSED kjører den etter tidsplanen i både stage og prod, selv om stage-targeten har mode: development. Feil i stage varsler slack_destination_id for stage-targeten.

Hver kjøring som finner et problem, sender ett varsel. Med daglig tidsplan blir det ett varsel per dag til problemet er løst.

Overvåkede tabeller¶

Hver overvåket tabell er én parameter på tasken, med tre verdier skilt av mellomrom:

<fullt tabellnavn> <kolonne med innlastingstidspunkt> <maksalder>

parameters:
  - ${var.catalog}.${var.schema}.bronze_nyctaxi load_date 25h
  - ${var.catalog}.${var.schema}.raw_nyctaxi load_date 25h

• Alle tre verdiene er påkrevd. Det finnes ingen standardverdier.
• Tabellnavnet er fullt kvalifisert, katalog.skjema.tabell. Med ${var.catalog} peker stage og prod på hver sin katalog.
• Kolonnen med innlastingstidspunkt må ha typen TIMESTAMP. En kolonne av typen DATE eller TIMESTAMP_NTZ kan ikke sjekkes.
• Maksalderen er et positivt heltall fulgt av m (minutter), h (timer) eller d (døgn), for eksempel 30m, 25h eller 8d.

En parameter som ikke har nøyaktig tre verdier, eller som har en ugyldig maksalder, feiler jobben før noen tabell er sjekket. Feilmeldingen siterer parameteren.

Måling og utfall¶

Dataferskheten er tiden fra det nyeste innlastingstidspunktet i tabellen, max(<kolonne>), til nå, regnet i UTC.

Jobben sjekker alle tabellene før den rapporterer. For hver tabell logger den én INFO-linje med navn, nyeste innlastingstidspunkt, alder og maksalder, også når alle er OK. Har minst én tabell et problem, feiler jobben med én feilmelding som lister alle problemene, én linje per tabell. Tabeller med for gamle data og tabeller som ikke kan sjekkes, står i hver sin liste.

Slack-meldingen sier bare at jobben feilet, med teksten Task freshness_alert failed with message: Workload failed, see run output for details. Hvilke tabeller som har problemer, står i kjøreresultatet (run output) til kjøringen.

Begrensninger¶

• Full refresh. En full refresh skriver innlastingstidspunktet på nytt for alle rader, også når kilden ikke har nye data. Tabellen ser da fersk ut, og varselet går ikke før maksalderen er passert på nytt.
• Bare tabeller med kolonne med innlastingstidspunkt. En tabell uten en slik kolonne kan ikke overvåkes. Se Sette opp ferskhetsvarsel.
• Bare nye bundles. Valget finnes i bundle-malen og legges ikke inn i bundles som allerede er generert.

Relatert innhold¶

Forklaringer:

• Overvåking — hvorfor varsling er teamets ansvar

Guider:

• Sette opp Slack-varsler — opprette en notification destination for Slack
• Sette opp ferskhetsvarsel — ta i bruk ferskhetsvarselet i en bundle generert med include_freshness_alert: yes
• Feilsøke med logger og Gjenopprette etter feil i pipelines — når varselet har kommet
• Håndtere rader som ikke lar seg konvertere — karantenetabellen fra alarmeksemplet

Referanser:

• Datakvalitet — expectations og DQX, som lar kvalitetssjekker feile jobben
• SQL Warehouse — warehousene alarmer kjører på
• Declarative Automation Bundles — der konfigurasjonen bor

Ekstern dokumentasjon:

• Add notifications on a job
• Manage notification destinations
• Pipelines API: notifications
• Alerts V2 API