Skip to main content
Gå til innhold

Alerting

Alerts notify you when something needs attention. Instead of watching dashboards constantly, set up alerts to proactively inform you of issues.

Recommended: Grafana Alerting​

For most teams, Grafana Alerting is the easiest way to get started. You configure alerts directly in the Grafana UI - no YAML files or deployments needed.

What You Can Alert On​

  • Log patterns: Alert when error logs exceed a threshold
  • Metrics: Alert when request latency is too high
  • Absence: Alert when expected data stops arriving

Security Note​

Authentication Mode

Grafana alerting requires your organization in Grafana to use BasicAuth mode to connect to the databases (instead of OAuth). This is a slightly different security model. Contact the Platon team on #platon to enable alerting for your organization.

Setting Up Grafana Alerting​

  1. Go to Grafana
  2. Navigate to Alerting → Alert rules
  3. Click New alert rule
  4. Configure your query and threshold
  5. Set up notification destinations (Slack, Teams)

Notification Channels​

Grafana can send alerts to:

  • Slack: Post to a channel
  • Microsoft Teams: Post to a channel
  • Argus: Contact Platon team on slack to configure contact point to send alerts to Argus from Grafana.

Configure destinations in Alerting → Contact points.

Label Your Alerts With Your Team Name and Org ID​

Required when routing to Argus

If you send alerts from Grafana to Argus, every alert rule must carry a team label with your team name and an orgid label with your Grafana organization ID.

Alerts are aggregated in Argus from Grafana as a single source. These labels follow the alert into Argus as tags, and those tags are what let you filter your own alerts. Without them, your alerts arrive in Argus with no way to distinguish them from everyone else's, and you can't build a notification profile that reaches only your team.

LabelValuePurpose
teamYour team name, for example my-teamIdentifies which team owns the alert
orgidYour Grafana organization IDIdentifies which Grafana organization the alert came from

The orgid value is the ID of your organization in Grafana — the same organization you log in to at grafana.platon.sikt.no and where your alert rules and data sources live. If you're unsure which org ID applies to your team, ask the Platon team on #platon.

To add the labels when creating or editing an alert rule in Grafana:

  1. Go to Alerting → Alert rules and create or edit a rule
  2. In the Configure labels and notifications section, click Add labels
  3. Add a label with key team and your team name as the value, for example team = my-team
  4. Add a second label with key orgid and your Grafana organization ID as the value
  5. Save the rule

Then, in Argus, create a filter on those tags (for example team=my-team and orgid=<your-orgid>) and link it to your notification profile — see Configuring Notifications.

Use the same team name and org ID consistently across all your alert rules so a single Argus filter catches everything from your team.

Recommended tags​

Argus supports using filters to find things that are on planned maintenance. For this to work well we need to be using the same tags for the same things.

Freetext in a tag is hard to filter on.

Special keys and the format of their values​

host : If the alert is about a host or something that has a hostname, tag with host followed by the fully qualified domain name (fqdn).

ip4 : If you need to tag an ip v4 address, use the key ip4, and the value should be in the dotted base-10 integer form, not any variation of hex. Always 255.255.255.255, never ffffffff or 0xffffffff or other variants.

ip6 : If you need to tag an ip v6 address, use the key ip6, and the value should be in the lowercase hex-form, without square brackets, and without ending with dotted integer form. Always 2001:db8::ff00:1342:8329, never [2001:db8::ff00:1342:8329] or 2001:db8::ff00:19.66.131.41 or other variants.

mac : MAC addresses have the key mac and the value is in lower case hex separated by colons. Always ff:ff:ff:ff:ff:ff, never ffffffffff or FFFFFFFFFFFF.

kundetjeneste : For the SSC to care, it must have kundetjeneste set to something they care about, like for instance Campus_CNaaS.

kunde : The SSC are also great fans of kunde being set to the domain name of the customer, if it is a customer-related problem. If it is an internal problem, use kunde=sikt.no.

The SSC can make tickets of alerts in Argus and may use the SSC tags to put the ticket in the correct queue.

Format of values​

Timestamps should be in ISO8601 format, preferrably in UTC. If the timezone is UTC it should end with 'z'. Always 2026-09-10T12:34:56z. If the timezone is not UTC, drop it or use the ±hh:mm variant: 2026-09-10T12:34:56+01:00. If a correct tiemstamp is really, really important, have both a UTC timestamp and a local timestamp. The name of the key of the local timestamp should be prefixed with the name of the key of the utc timestamp, so: reported=2026-09-10T12:34:56z and reported_local=2026-09-10T12:34:56+01:00.

Learn More​

Alternative: Prometheus Rules​

The preferred way to send alerts to the Sikt Service Center is Grafana Alerting with Argus as the contact point, as described above.

Prometheus Rules & Argus is there for teams that prefer alerting as code - configuration files version-controlled alongside your application - or that need Probe-based black-box monitoring. Those alerts can be forwarded to the Service Center too.